Some time ago, I bumped into a few Android applications which use Airpush. Airpush is an advertisement SDK developers can add to their application to generate some revenue: for every thousand ads displayed via their application, the developers gets a few dollars in return. In the case of Airpush, the ads are pushed in the mobile phone’s system tray, i.e they do not appear in the application itself, but generally at system level. The ads stand higher chances of being read/clicked on, but many end-users complained this system was really too intrusive.
See the illustration on the left: this is a demo application for AirPush. An AirPush ad is displayed at the top, in the Android system tray. Click on the image to enlarge it.
As a consequence, Airpush decided to mandate opt-in for its ads: end-users explicitly need to agree to receive ads before any ad gets pushed to the device. At least, I like this.
But Airpush’s FAQ got me really angry:
- MD5 is a hashing function. I might be touchy, but it does not “encrypt” anything. It digests or it hashes.
- For a given IMEI, the hash is always the same. So, this does not ensure any privacy at all, as one can track my IMEI hash instead of my IMEI.
- MD5 is broken, obsolete for years. How is this supposed to secure my IMEI? If Airpush was really taking my “privacy” seriously, they would not be using MD5.
Reversing the hashed IMEI is a matter of seconds if you are lucky on an online MD5 reversing engine. I reversed Android Emulator’s fake IMEI (000000000000000) within seconds.
With a real IMEI, it might be longer, but feasible as IMEI follow a strict format (15 or 16 digits, first few digits being the TAC Type Allocation Code with only a few valid possibilities).
Additionally, Airpush forgets to talk about another private data it uses: my location. Indeed, some airpush application request the ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permission. According to Airpush SDK installation instructions, those permission are “optional but highly recommended to enhance your revenue stream”. Shouldn’t that be mentioned in the FAQ as part of personally identifiable information Airpush stores?? Actually, Airpush memorizes plenty of information on my device (phone model, carrier, manufacturer, IMEI) and my location (longitude, latitude) in a file named dataPrefs.xml.
I am also uneasy with the different kinds of ads Airpush can deliver and would definitely recommend users to be cautious. Airpush implements several “delivery receivers”. It looks like delivery receivers are actions to perform when the end-user clicks on the ad. Airpush implements a web delivery receiver, a market delivery receiver, a phone delivery receiver and a SMS delivery receiver. Each delivery receiver is attached to a set of parameters, potentially used when you click on the ad.
For instance, with the web delivery receiver, ads are attached to a URL. When you click on the ad, the URL automatically opens. How secure is that with regards to phishing?
With the phone delivery receiver, will airpush automatically call a given phone number when we click on the ad? and for the SMS delivery receiver, is it automatically sending an SMS? I haven’t been able to confirm those actions as I did not receive such ads, but this would certainly be dangerous.
Finally, I really like the opt-in method for ads, but it does not seem to be fully out yet and I wonder how they intend to enforce its use. As a matter of fact, I spotted a file named dialogPref.xml which contains interesting parameters:
<?xml version=’1.0′ encoding=’utf-8′ standalone=’yes’ ?><map> <boolean name=”ShowAd” value=”true” /> <boolean name=”ShowDialog” value=”true” /></map>
The ShowDialog parameter refers to the opt-in dialog, meant to ask the user for his/her permission to receive ads. As such, it seems so easy for an application to disable the opt-in dialog (ShowDialog to false) and push ads (ShowAs = true) without user’s consent.
– the Crypto Girl
Leave a reply