by RSS Axelle Apvrille  |  Dec 02, 2013  |  Filed in: Security Research

ratpappli

A few weeks ago, researchers at INRIA presented privacy leaks they had detected in the mobile RATP applications at GreHack conference (NB. RATP is the French organism that deals with subways and trains around Paris).

I wanted to check how much things had changed since their study, and downloaded the most recent application from Google Play.

First surprise: I downloaded version 2.3.3 whereas INRIA researchers mention version 2.8. I guess there is some versioning discrepancy.

Now, what privacy changes have we got? Mainly, Achara et al reported that: - location was sent in clear text to Sofialys advertisement servers - + MD5 hash of IMEI - + SIM card operator name - the application was requesting unnecessary permissions such as READ_CONTACTS, READ_CALL_LOG.


Location is now sent encrypted

I reversed the application and found that all data sent to Sofialsys advertisement servers were now over HTTPS:

I/NXM ( 1509): url de l'ad server : https://ad.addict-media.mobile-adbox.com/app_android_3_0/

However, like Samuel Tardieu, I was a bit frightened by the amount of information sent (in the form of a JSON object), in particular by the fields named ugender, uage, uemail, udob, uzip (user's gender, age, email, date of birth, zip code).

json ratp

In my test, those fields were null, but could there be situations where they'd be filled? Fortunately, currently, no. I checked the fields usage with Androguard:

androguard 34

So, user's gender is only written by setUgender(). And setUgender()...

androguard 35

... is not called by anobody (yet). Same for sal, test, udob, uage, uzip, uemail. Although of course, this might change in the future.

As for the location, it is actually not in the longitude and latitude fields, but in a user_position field.

Finally, user's location is also legitimately used by the RATP application to display traffic information or maps around your current location.

MD5 of IMEI has been replaced by MD5 of Android ID or randomly generated number

Despite its name, the "imei" field no longer carries anything related to IMEI, and as a matter of fact the application no longer calls getDeviceId() which retrieves an IMEI. Now, the "imei" contains the Android ID, unless this is invalid or corresponds to a test value, in which case it contains a random hexadecimal value.

SIM card operator name is still sent, but encrypted

In the JSON object shown above, the operator's name is put in the field named "carrier". In my test case, the operator's name was not retrievable so the default value "Android" was written instead.

READ_CONTACTS is (legitimately) used to find a route to a given contact

Androguard helps us track down who uses the READ_CONTACTS permission:

read contacts

The first use corresponds to the feature that enables the end-user to find a route to the address of a given contact. The second one is believed to be a false positive as it corresponds to image downloading.

As for READ_CALL_LOGS, this permission is no longer requested (nor used) by the application.

The application only requests: - C2DM permissions. I'll discuss that one later. - VIBRATE. This one is used for the "Shake me" feature: when you shake the phone it goes back to the previous page. - INTERNET. Obviously this one is used ;) - ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION for GPS coordinates - ACCESS_NETWORK_STATE. This is used by ads and the app to know what kind of network access we have (wifi, 3G...) - READ_PHONE_STATE and WRITE_EXTERNAL_STORAGE. Those are requested but no longer used.


Cloud to Device Messaging (C2DM) - now Google Cloud Messaging (GCM)

C2DM is used by the application for alerts, for example if you want to be notified when an issue occurs on line #1.

I was surprised to find credentials in cleartext in the app:

c2dm java

Actually, those credentials are used to compute a truncated HMAC-SHA1 (field h in the URL below).

https://www.tpcrm.fr/wv?a=mobile_alerting_android_prod&u=8f4d1ade-4c87-40cd-ae5a-3b4ec41202ac&p=APA91bHGK8raUSMynxy0aSFr6p2hXz5sisYE2KCwcSo3_eVe738NFcnArMVcW9h3P7YbXKtKuqgEJDMcr07OhjojrBTbHSWd0icQ52ARUYtjXM0RhVe24KwFgpWQjHFL2Cff1YlhVYsQO_OWdpi8wmSe8B_K6sZlS4LhHrFRXv4PojVWjZysRV4&d=Android-19&l=en&n=2013112607&h=e2c008a2

  • u is a UUID
  • p corresponds to a push identifier
  • d is the string Android followed by the value of Build.VERSION.SDK_INT
  • n is the current time


The HMAC is used to authenticate time/push id and UUID. Except of course, that if the secret is public, the authenticity is no longer guaranteed :( An attacker can probably push alerts he wants to any device provided he knows its UUID and push id. However, if we insist on seeing things positively, this is not a privacy leak ;)

Conclusion

So, can we use this RATP application? Yes, I think so. I am not saying it represents the best coding practices ever seen, but most of the privacy issues have been addressed and the intent is clearly not malicious. By the way, Alligator flags it as non suspicious.

Fortinet blocks every day FAR more nefarious Android applications.

It is however a pity RATP felt it necessary to incorporate an advertisement SDK in their app, and thus put us at risk of selling bits of our private lives at each new application update. Luckily, I don't live in Paris ;)

-- the Crypto Girl.

by RSS Axelle Apvrille  |  Dec 02, 2013  |  Filed in: Security Research