{"id":2737,"date":"2012-07-22T20:33:10","date_gmt":"2012-07-22T23:33:10","guid":{"rendered":"http:\/\/brockerhoff.net\/blog\/?p=2737"},"modified":"2012-07-22T21:47:43","modified_gmt":"2012-07-23T00:47:43","slug":"checking-receipts-on-os-x","status":"publish","type":"post","link":"https:\/\/brockerhoff.net\/blog\/2012\/07\/22\/checking-receipts-on-os-x\/","title":{"rendered":"Checking receipts on OS X"},"content":{"rendered":"

Recently someone figured out an attack against in-app purchasing on iOS<\/a>. Only a few days later Apple, with commendable speed, put up a page detailing how to counter this crack by implementing better receipt checking<\/a>.<\/p>\n

Now there’s news that a similar attack also works on OS X<\/a>. For this, users have to install two bogus certificates, point their DNS at the cracker’s server, and run an auxiliary application while making the in-app purchase; this builds an apparently valid receipt inside the application bundle. (Of course this means that the user is trusting those certificates, that server and<\/em> that application to be otherwise innocuous – not a good policy! And it asks you for your admin password while you’re connected to that server, too…)<\/p>\n

So how to implement better receipt checking on the Mac? The details are different, in that OS X in-app receipts are stored inside the application bundle, inside the application’s original receipt from the Mac App Store. Furthermore this receipt has a known format and is signed by 3 certificates:<\/p>\n