How the hack works
Without any security and third-party validation, it would obviously be very easy to corrupt the IAP process. All that needs to be done is to trick a device into contacting a server other than Apples real ones, and then respond to IAP requests with receipts that contain plausible, but fake, information.
To alleviate this problem, Apple uses the industry standard SSL/TLS protocol to secure its communications. This both encrypts the data so that a third party cannot intercept it and uses digital certificates to positively identify Apples servers; if the digital certificates can be trusted, the device can be sure that it is, indeed, communicating with the Cupertino giants real servers.
The validity of digital certificates is assured by so-called Certificate Authoritiesbasically, third parties that validate the identity of a company and countersign its certificates. Some authorities are normally hard-coded in the operating system, but others can be configured manuallya process that is supported by Apple and is, indeed, very useful in many scenarios, including enterprise deployment.
The in-app purchase hack currently making headlines takes advantage of this capability by installing custom, forged certificates and using a custom DNS server. That results in successfully redirecting all the traffic that would normally go to Apples IAP servers to a different address, while the faked certificate makes the device believe it is still talking to Apple, when in reality its communications are going to a server that is under the hackers control.
With this fairly easy one-two punch, the entire security around the IAP process is breached; if the hacker can produce believable receipts, it is essentially impossible to tell these apart from real ones just by looking at their contents. As an added bonus, it appears that iOS sends both your iTunes username and password in clear textmaking it possible for the hacker to collect those as part of the fake purchase process.
Oh, so simple
If this sounds a little too simplewell, it is. The hacker is performing a classic example of something called a man-in-the-middle attackthe Internet equivalent of listening in on a phone call, and then pretending to be one of the two callers at a later point.
Apple is perfectly aware of this limitation, and strongly recommends that developers use their own mechanism to validate IAP receipts. Typically, this involves setting up a separate server, sending the receipts over to it, and then validating them against Apples servers. Because the server is entirely under the developers control, a man-in-the-middle attack is much harder to pull off.