close search bar

Sorry, not available in this language yet

close language selection
 

UK National Health Service (NHS) infected – with a typo

The UK’s NHS web site (http://www.nhs.uk/), or to be precise, links embedded in it, have been infecting visitors with malware. At the end of the day, it was probably a straightforward typo in the coding of the web page. What lessons can we learn here? How could we have stopped that? Sadly, there’s not much to learn, except that it’s very dangerous out there on the Internet. Here’s why.

First the lesson: there really aren’t any broken URLs any more. Every URL is going to go somewhere. It’s vitally important that, as the author of a web site, you ensure that you’re only going to legitimate places. To do this, many sites employ a link-checker program. It reads the HTML, checks all the links and makes sure none are broken. The problem with that is that the malicious site returns an HTTP 200 ‘successful’ status and some syntactically correct JavaScript. An automated link checker is not going to flag that. Only a human looking at the URLs that are referenced might notice the one-character difference and think “that’s weird, I wonder what that is.” In the old days, a broken URL would actually cause an error. Your browser would have thrown an error. But today, with people “squatting” on typos, that domain name will resolve somehow.

There are really very few lessons for the NHS, unfortunately. Triple check all links? I suppose. Monitor your egress on your network and alert if people start going to strange domains? Maybe. If anything this just wakes us up to the dangers of Typo Squatting. Many firms own many variations on their name. We own citigal.com, Google owns gooogle.com (3 Os instead of 2). But it’s impractical to own all variations. And frankly, the NHS was ultimately beholden to how well Google defended its name. And Google cannot be expected to buy every possible spelling mistake near its names. If this was an innocent typo, I struggle to find a lesson for the web developers. Sometimes the result is simply “oops.”

So how did the attack proceed?

The attacker owned the domain googleaspis.com. If you believe the whois information, that domain was registered yesterday at a registrar in the Czech republic. It’s possible he happened to notice the misspelling on the NHS web site and decided to take advantage of it. I wonder if it’s possible to set up a Google search monitoring for sites that include misspellings, and then have Google alert you when there’s a vulnerable web site.

It appears that someone had written HTML that tried to invoke Google Translate. The HTML had a single character mistake. Instead of referencing the correct JavaScript, they referenced a domain called ‘googleaSpis.com’. They meant to go to ‘googleapis.com’. Notice the extra S. This could have been a “hack” where some malicious person found a way to insert this extra letter and then exploit the resulting condition. Because the official NHS statement is that it was a “coding error”, I will assume that (a) they’re being honest, and (b) it was an innocent typo by a web developer. The letter “S” is right next to the letter “A” on the keyboard. It’s easy to imagine how this could happen accidentally.

The ramifications are significant. JavaScript coming from an unknown site (not Google) was inserted into the body of the web page sent from the NHS to innocent visitors’ web browsers. The web browsers, doing what the NHS site told them to do, went off to googleaspis.com and requested the page at that location. They received a single line of JavaScript.
window.location=’http://js.googleaspis.com’;

This simple JavaScript is used countless times all over the web. It tells your browser to replace the current location (i.e., the page you’re currently looking at) with the page at the named URL. Instantly your browser bounces you away from the NHS web site and off to js.googleaspis.com. Requesting that page simply results in a 302 redirect. Yet again, another common technique that the world uses for good: it tells your web browser that the page you’re looking for (js.googleaspis.com) is not here. Instead it sends you to http://ww92.js.googleaspis.com/. When I chased it, I ended up at a landing page at http://backup.com-ez.net/. I chased a few more links (taking a fair bit of care) and finally ended up at http://www.mypcbackup.com/. I followed a lot of redirects that were click-through advertising links.

A few important things to realize about this investigation: I am not a forensic investigator. I did very little to disguise myself, I did not pretend to use a vulnerable machine or browser, and I did my investigating many hours after the attack had been discovered. Malware can be clever. The web sites can figure out that I’m using research tools and not browsers. They can figure out where my IP address came from and determine whether or not (based on my current country) they want to send me any malware at all. They can send me to other sites because I’m probably not their target. Thus, the path that MY browser took while researching for this article might be totally different than the path and consequences that someone else’s browser would take. For example, some of the servers are in the Czech republic. They could, for example, serve something harmless to other Czech computers and serve the malware to all others. There was a case not long ago of a Russian malware site that did that. If the malware distributor was clever, his web site sent me something totally different from what he’d send a vulnerable PC user. There’s no way for me to know. I don’t have the tools to figure that out.

Typo squatting is a major issue. Unfortunately, there is very little we can do to combat it. End users can use a service like OpenDNS. They try to identify typo squatting URLs and redirect your browser to a safe web page if you go to one. Software authors can do very little. They can only be diligent about what sites they link to and do their utmost to be sure that they link to known sites correctly.

 
Synopsys Editorial Team

Posted by

Synopsys Editorial Team


More from Security news and research