Security holes in the iTunes Music Store
While inspecting the iTMS protocol with sniffers and PyMusique, I have found
what appear to be three security issues:
1) Although signup/user info, authorization, shopping cart and purchase
transactions are all sent via SSL, other transactions (such as searches and
album info requests) are not. These requests are in fact sent in the clear,
and the responses are either encrypted with a static key (prior to 4.7) or a
key that's included in the HTTP headers (with 4.7). This means that anyone
can sniff this information.
2) Worse, it means that a man in the middle can alter the response. It may
not be obvious why this is bad, so I'll explain. Search results and
viewAlbum responses include a field called "buyParams" which contains the ID
of the item to purchase. This information is never displayed to the user;
nor would they know what it means. Changing it means that the user will in
fact purchase the wrong item. (Note that it has to be an item with the same
price*.) If you have the shopping cart enabled, or you wait for your
purchased track to download, you will probably notice immediately that you've
been screwed, but in the latter case the purchase has already happened.
3) There is a specific transaction, sent via SSL, that informs the store that
you've finished downloading a track, so it can be removed from your pending
song list. This is what prevents you from downloading a track multiple
times. If you can blackhole this transaction somehow, items will remain in
your pending song list forever, allowing you even to download them to
multiple machines. I presume it is implemented this way so that the client
can automatically retry downloads as many times as necessary. As such, it
might be hard to "fix" this without making the protocol flaky.
* The price is displayed to the user (of course), and is echoed back to the
server, over SSL, during the purchase process. If they do not match, the
server returns an error asking you to "try again later". This is most likely
to make it impossible for a user to get screwed by buying something like a
"free" track while its price is being updated. (This is a good idea.) In
this attack scenario, you'd want to substitute something with the same price,
or else you'd have to change the price field and the user would probably
notice.