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.

HTTPS: (Sub)Standard Security pt.3

In the first post in this series on the deficiencies of standardized security systems I promised a post on "X.509 certificates". By this I intended to discuss the commonly used system for authenticating and securing communications with web sites, widely known as SSL. As SSL (or to be precise, TLS) is just one component of this system (and is also used for other purposes) I will use the term "HTTPS system", though in fact the same system is used for more than just the HTTPS protocol.

DigiNotar: When is a secure network not secure?

The Dutch government report (PDF) on the DigiNotar hack has confirmed what I suspected:

The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN.

These guys at DigiNotar are living in the nineties. These days the most important attack vector by far is through the network and not physical access. DigiNotar, like many others, invested more effort in defending against the less important attack.

But don't mock them. If you use a disk encryption technology like PointSec or PGP Disk and think it gives you any signficant protection, you may be making the same mistake - assuming an attack involving physical access. It's quite likely hackers already have control of your computer even though it's physically in your possession. You should do what you can to prevent network-based attacks (firewall, anti-virus), but even then you must not assume you're 100% secure. If you have anything that is truly secret just don't put it on a computer you connect to the Internet.

There's been a paradigm shift in the world of corporate security. Instead of traveling and trying to physically access the information of a single company, hackers can use technologies like Remote Access Trojans to attempt attacks on hundreds of companies from the comfort of their own home and with less risk of getting caught by law enforcement. Too many security teams, not just RSA and DigiNotar, haven't yet fully adjusted to this situation.

BTW, the full paragraph in the report begins with another sentence:

The most critical servers contain malicious software that can normally be detected by anti-virus software. The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN.

Which reminds me yet again of this XKCD classic:

DigiNotar: Intruder issued fake certificates

Dutch certificate authority DigiNotar revealed that the fake Google certificates signed by them were due to an intrusion into their system. The didn't give any details on how this was done.

I would assume the attacker didn't physically enter DigiNotar's facilities but instead accessed their network through the Internet. If so, this is yet another case of a security system being breached because the owner did not keep highly sensitive assets properly segregated from computers with access to the open internet.  RSA are not alone.

Or as Randall Munroe of XKCD puts it: