Human Denial of Service using One Time Spam

The Krebs on Security blog reports of a new service offered by hackers. The service floods an individual with garbage communications in an effort to prevent the victim from being able to receive and process valid communications. Such an attack is effectively a Denial-of-Service attack on humans - or an HDoS attack. One possible goal of such an attack is to prevent a person from receiving notification of some other action that the attacker has done, such as resetting the person's password, which in many systems causes an email to be sent to that person.

This new form of attack is interesting in many ways, but I'd like to focus on the usage of one-time spam as the mechanism used to flood the target's email account.

Contemporary spam filters are quite good in filtering out spam. Yet these hackers are able to get thousands of junk emails through the best spam filters. Krebs and other commentators wondered if these hackers have found some way to circumvent the spam filters.

The answer is no. These HDoS hackers don't need to circumvent the spam filters because the junk email they're sending isn't really spam.

Spam is a situation where a single message is sent to many email addresses. The email used to deliver the message may be personalized, but the message must be the same because the goal of spam is to offer a single product or service to many people.

Spam filters rely on the fact that the same spam email (with possibly minor changes) gets sent to many email accounts.  When the spam filters recognize a pattern for a large amount of email being sent to email accounts monitored by the spam filter they decide this is spam and filter it for all email accounts (unless the mails are from a white listed source).

The junk email used by the HDoS hackers isn't spam – it’s a targeted attack against a single user.  So the Junk email generator used here can generate truly unique emails that are not sent to any other user – and there’s no way for the spam filters to recognize this as spam. Such unique junk emails can be called "One-Time Spam" - and much like one-time pads [Wikipedia], they are invincible.

We've discussed variants of the classic Turing test in previous posts. The classic Turing test is interactive - the evaluator presents various challenges and uses the responses to identify if the responder is a human or a machine. But one can define a non-interactive Turing test in which the evaluator doesn't present any challenges and receives a single message - and needs to evaluate if the source of the message is human or a machine.

It is not difficult to create a machine that can pass a non-interactive Turing test - and this is all a one-time spam generator needs to do.

Alternatively the HDoS hackers can use crowd sourcing - simply intercepting real emails being sent over the internet and using each such email once as a junk email. This is no longer strictly one-time spam, but the chances of a spam filter identifying such a mail as a spam are close to zero - and the HDoS hacker only needs some of his junk emails to pass the filter.

HDoS attacks can't be prevented based on the content of the junk email, but there are other methods that can be used to identify such an attack and filter out the offending mail. The most trivial technique is checking if a mail account is receiving a very large number of emails from a single source address. This is the main technique used to prevent classic DoS attacks - and can similarly be circumvented by using multiple source computers for a distributed denial of service (DDoS) attack. 

HDoS and One-Time Spam are nonregistered trademarks of the Good Enough Security blog :-)

Security QotD #1

From a paper on mobile device user authentication:

A threat model for mobile devices that does not account for usage by the device owner’s children is undoubtedly incomplete.

Tell me about it.

Replay attack on Apple In-App Purchases

The Next Web reports of a flaw in the Apple In-App Purchase process which allows the re-use of In-App Purchase receipts. Using this flaw a hacker named Alexey V. Borodin has created an online service that allows people to receive In-App Purchase services without paying for them.

The normal process of authenticating In-App Purchases is as follows:

1. The client device sends a request to Apple to make the In-App Purchase
2. Apple charges the client user and returns a digitally signed receipt of the purchase to the client device
3. The client devices sends the receipt to the application server as a proof of purchase to receive the in-app service

The problem is that the digitally signed receipt is the same for all clients. So if one person makes a purchase and receives a receipt, that person can then distribute the receipt to others who can then get the In-App service without paying Apple. This is what Borodin did.

Now it's not as simple as that. The client device expects to receive the receipt from Apple - not from Borodin. The client device goes to a server with an Apple domain name and authenticates the server using TLS. So how could Borodin impersonate Apple?

The answer lies in the fact that DNS and TLS security in iOS (and in general) are intended to protect client users from a malicious third party - not to protect Apple from malicious clients. Because of this iOS allows the client user to override the DNS server and to add her own CA (Certificate Authority) certificates. So the client user can easily point the client device to Borodin's site instead of Apple's (by replacing the DNS server) and authenticate Borodin's site with Apple's name (using Borodin's CA certificate).

What Apple should have done is make the receipts unique, preferably by including a device unique identifier (such as the iOS UDID or a derivative thereof). If they deemed this problematic due to privacy (which it isn't) then they could had at least included a time stamp to limit the amount of time the receipt could be used or even just a cryptographic nonce [Wikipedia] which could be used by the application server to identify and prevent attempted re-use of an In-App Purchase receipt.

So why didn't Apple do this? My guess is that the Apple engineers who developed the In-App Purchase solution assumed that their connection to the Apple domain is protected (thanks to TLS) and didn't consider the fact that iOS allows users to add CA certificates. The Apple engineers who designed the certificate system which allows this were trying to protect the user from hackers - not to protect Apple from users. This is not the first time Apple have been hit by this mistake.

But even if it weren't possible for users to add CA certificates, using a fixed receipt for multiple devices is just bad security. If you have input on why Apple did this - please comment below.

Flaming headlines

Readers of this blog know that I can't miss a chance to ridicule hyperbolic headlines. Mocana has a great blog on the "Security news for the Internet of things" but they sometimes overstate the case.

The headline of today's Mocana post is "Researcher: Flame’s Crypto Collision Discovery Cost At Least $200K". The source Mocana gives for this assessment is an Ars Technica post. Reading that post one finds the following statement:

Sotirov said the $200,000 estimate is likely the maximum cost of the computing power that would have been required when Flame was likely being designed. He held out the possibility that the collision attack may have cost much less if the researchers figured out techniques that were less computing intensive.

Notice how Sotirov's "maximum cost" of $200K became "At Least $200K"? Nuff said.

Video Turing tests and face recognition

This post starts off topic, but does get back on topic in the end. Please bear with me.

I assume the readers of this blog know what the classic Turing test [Wikipedia] is. To pass the Turing test a machine must be able to impersonate human responses to such a degree that a human can't distinguish between the machine and a human based on their responses.

The original Turing test is meant to test artificial intelligence. Similar tests could be used to test other artificial entities - such as video.

A Video Turing test (TM) could be defined as follows. Set up a wall with a window and with a video monitor that displays a stream captured by a camera on the other side of the wall.To pass the Video Turing test (VTT), it needs to be impossible for a human to distinguish the window from the monitor.

There are various levels of VTTs. A 2D VTT assumes a static one-eyed viewer. A 3D VTT would also work with a two-eyed viewer, but still static. A virtual reality VTT would also work with a moving viewer.

We are the 99.8%: Premature report of RSA demise

If you haven’t read the paper itself [PDF], you've probably seen the NY Times article. A group of researchers led by Arjen Lenstra analyzed a few million RSA public keys and found that some 0.2% of these keys share at least one prime factor with another public key and can thus be factorized. This is due to a random number generation flaw in the process used to choose primes during the generation of these public keys.

I don’t know if their analysis technique is novel, but it’s definitely interesting. Instead of identifying some weakness in a specific key generation library, or analyzing each key separately, the team analyzed pairs of keys to see if they share a common factor. This is done by finding the GCD (Greatest Common denominator) of each pair. If a pair of keys doesn't share a prime they will have a GCD of 1. By working with a very large number of keys the researchers were able to identify a large number of faulty keys.

So is this a big deal? Not as big as you might think from reading the NY Times article.

Obligatory PHD comic

Things I haven't been writing about

Due to a hectic period at work (I'm currently trying to patch a cracked standardized security scheme) I haven't managed to post anything lately.  So here's a list of subjects I wanted to write about and a short summary of my thoughts.

Iranians capture of US military drone
I like Richard Langley's theory (quoted by Wired) regarding how the Iranians may have captured the US military drone. Langley proposes that perhaps the Iranians jammed the drone's secured GPS signal which in turn caused the drone to fallback to the generally used clear GPS signal which in turn the Iranians spoofed.
If Langley's theory is correct this is yet another case of functionality (ensuring drones can find their way home) trumping security. A more secure solution would be to rely on the last secure GPS reading and using on-board hardware (e.g. an accelerometer) to estimate a delta on that. Sooner or later the secured GPS signal will come back to correct any navigation errors made due to the estimates.

Android approved by Pentagon
This misleading headline appeared on many sites, including Slashdot. This is of course nonsense - Android as a standardized security system is a security nightmare. A specific device which happens to use Android was approved by the Pentagon. The above headline is equivalent to saying that Linux was approved by the Pentagon ...

Counterfeit chips in US military hardware
If you're interested in this subject, which has come up several times over the last last few years, make sure to read Bunnie's blog post. I have a feeling that a lot of the noise on this subject is coming from western vendors who simply can't compete with the Chinese vendors.

Upcoming posts
I have two big posts that I need to complete - so stay tuned. These are:

• A summary post on why standardized security systems fail and what needs to be done to make a truly secure standard.
• An announcement on the publication of version 0.01 of the security failures database. Of course, I need to build the database first :-) Any help would be greatly appreciated - if you can contribute please send a message to my dedicated gmail account (security.fails.db).

History of Security Failures 101: Crypto Flaws

While going over various examples of failed standardized security systems I realized it would be very useful to have an open online database of security system failures that could be used by security professionals to analyze the root cause of such failures and learn how to prevent them in the future. I was thinking "Someone" should build such a database. Not knowing who this "Someone" could possibly be I left it at that.

Thankfully, Matthew Green has prepared a short list covering a subset of such failures - specifically cryptography flaws that were exploited by non-government attackers.

The following is from Matthew Green's blog: