Saturday 8 December 2012

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?

Friday 16 March 2012

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.

Sunday 15 January 2012

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.