bugtraq - Security holes in the iTunes Music Store

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <200503310340.26046.abuse@spamalicious.com>
Date: Thu, 31 Mar 2005 03:40:25 +0000
From: "Charles M. Hannum" <abuse@...malicious.com>
To: bugtraq@...urityfocus.com
Subject: 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.