The PRIVATICS Inria team – July 2nd, 2013 – https://team.inria.fr/privatics/

(this blog has been modified on July 5th, 2013 upon request of FaberNovel)

The RATP Android App

This post is follow-up of our previous post about private data leakage by the RATP’s iOS App. To make our study complete, we also analyzed the RATP Android App (version 2.8), once again developed by FaberNovel as mentioned in the screenshot below. We also see the same privacy policy as that of the iOS version: “The services provided by the RATP application, like displaying geo-targeted ads, do not involve any collection, processing or storage of personal data” (translated).

So we wanted to know if this Android version differs from the iOS version with respect to personal information collection. And here are our findings…

Below is what we captured being sent to the network in cleartext by the RATP’s Android App (you can see that our curiosity didn’t go into vain 😉 ):

{"user_position":"45.2115529;5.8037135", "ugender":"", "test":"", "uage":"0", "imei":"56b4153b8bd2f6fd242d84b3f63e287", "napp":null, "uemail":"", "pid":"4ed37f3f20b4f", "alid":"114", "uzip":"", "osversion":"3.0.31-g396c4df-dirty", "lang":"en_En", "sal":"", "network":"na", "adpos":null, "time":"Tue Jun 04 12:05:39 UTC+02:00 2013", "sdkversion":"3.2", "ua":"Mozilla\/5.0 (Linux; U; Android 4.1.1; fr-fr; Full AOSP on Maguro Build\/JRO03R) AppleWebKit\/534.30 (KHTML, like Gecko) Version\/4.0 Mobile Safari\/534.30","udob":"",
"carrier":"Orange F","longitude":"0.0","latitude":"0.0","freespace":null,"unick":null}]

Above data contains some very sensitive info about the user, in particular:

• the exact location: Scary… hmmm?
• the MD5 hash of device’s IMEI: researchers are working on quantifying out how easy it is to get back the IMEI from its hash given some info about the device. For example, if the smartphone manufacturer and model are known, it only takes ~1 second to get back the IMEI of the device! Said differently, one could send the IMEI directly, it wouldn’t change so much the security level achieved in front of a motivated attacker;
• the SIM card’s carrier/operator name.

This is certainly not acceptable in any case that the App is sending this data in cleartext (no matter to whom or for what matter the info is being sent!). To App developers: for God’s sake, please, don’t make easier the life of a user’s spy or anyone for that matter who can intercept the traffic (ISPs, WiFi AP Owners, Governments etc.). We don’t see any point not to use secure connections!

Now the next question is: Where is this info sent? The answer is: to the 88.190.216.131 IP address. We  now need to know which entity/organization this IP address belongs to, for instance to infer the reason why the info might be collected… Whois and other web services (like infosniper, DShield) reveal so-par-onl-vip01.sofialys.net as the hostname of the machine. Second levels domain sofialys points to sofialys as the company this machine belongs to. And finally, the icon almost confirms this as it’s the same on sofialys webpage [Courtesy to Vincent Maugé for his help in IP address analysis; updated July 4]!

It is even more disturbing that RATP still keeps continuing these bad practices whereas it has already been highlighted in the past (later, our google search revealed that it’s already known). This is not acceptable.

Then, in order to know if A&A libraries are being used by the App, we decompiled the App’s dex file executed by Dalvik Virtual Machine. We found two third-party packages: Adbox (with package name com.adbox) and HockeyApp (with package name net.hockeyapp). See screenshot listing class descriptors. Adbox is clearly a company that could be interested by these private data.

Also, to our surprise, RATP’s Android App (version 2.8) requires permissions far more than it requires. Why would it need to access the user’s contacts? Here is the list:

com.fabernovel.ratp.permission.C2D_MESSAGE;
com.google.android.c2dm.permission.RECEIVE;
android.permission.READ_PHONE_STATE;
android.permission.VIBRATE;
android.permission.INTERNET;
android.permission.ACCESS_FINE_LOCATION;
android.permission.ACCESS_COARSE_LOCATION;
android.permission.READ_CONTACTS;
android.permission.ACCESS_NETWORK_STATE;
android.permission.READ_CALL_LOG

A final comment: the RATP App asks for permission to access the user exact position and the user has no other choice than agreeing in order to install and use the App. This is acceptable for an application meant to facilitate the use of public transportation. However, even if the user grants this permission to the App, does it imply that the user also accepts this information be sent to a remote, unknown server, with no information of who will store and use this data, and to what purposes? Certainly not. The Android permission system cannot be interpreted as an informed end-user agreement for the collection and use of personal data by third-parties.

Back to the RATP iOS App: does it leak something else?

Let’s come back to the iOS world. Did we miss anything in Part 1 of this blog? Did the iOS App leak more private information than previously mentionned? The answer is Yes! RATP’s iOS App also sends the same info (see below) as its Android App to the ip address 88.190.216.131 in cleartext. The machine corresponding to this ip address belongs to sofialys. The Adbox library from sofialys is included in both Android and iOS versions of RATP App (See screenshot listing headers from Adbox library in RATP’s iPhone App).

"UTFStringOfDataSent": "{\"uage\":\"\",\"confirm\":\"1\",\"imei\":\"9c7a916a1703745ded05debc8c3e97bedbc0bcdd\" ,\"osversion\":\"iPhone 6.1.2\", \"odin\":\"1b84e4efaf650cb9a264a2ff23ca7a67b9bd72f6\" ,\"umail\":\"\", \"carrier\":\"\", \"user_position\":\"45.218156;5.807636\", \"long\":\"\", \"ua\":\"Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Mobile/10B146\", \"footprint\":{\"v1\":{\"i\":\"3739335834508445\", \"b\":\"c5kkekILx11ghUfu3Ht43bUZWcHHBNbR09AO4it+ wtPPCBJagCIo7tgBdMlq6T244EwHnKRzeh1ybrMhKy2SztEU5tD5u5Q7HAis R57BYIun9aQdp0NsXwp7BXhohS92daScYcMDALqK QhYKZDriEjqWwtjvR9MrIKfE52EwNcA9CJJkUIT9q7sXkqkvaloOM7tMrNdMiIQYyH0tdNJ + ax7Ujau/IQ4pPasSXk/m6BIFsAFhjFOng0NuSwtL7e7r95s8wQhWy + EvJUChPIvIRXZYldCbjfdkrkvNgHZcH59Fj0dBz9Ugbyoj4a/Z60SlU + EatvNswORMQqdE8djVJmXkGCmwoheU10uQatr4pqA =\"}}, \"ugender\":\"\", \"os\":\"iPhone \", \"adid\":\"496EA6D1-5753-40B2-A5C9-5841738374A2\", \"uphone\":\"\", \"sdkversion\":\"5.0.3\", \"test\":\"\", \"lat\":\"\", \"udob\":\"\", \"pid\":\"4ed37f3f20b4f\", \"lang\":\"fr_FR\", \"network\":\"wifi\", \"time\":\"2013-05-30 15:45:04\", \"alid\":\"186\", \"sal\":\"\", \"uzip\":\"\"}",

Here, the IMEI is replaced by the UDID (Unique Device Identifier) of the iPhone. Otherwise the precise geolocation of the user is also captured and sent, and all of this happens in addition to the private data sent to Adgoji as we mentioned in our first blog post.

To Conclude…

The RATP App, both the iOS and Android versions, is a good illustration of bad privacy practices of some companies, in particular A&A companies:

• many kinds of private data are collected and sent, and in this example, even if the “legal terms” of the RATP App claims the contrary;
• A&A companies have found ways and started using techniques to bypass the restrictions imposed by Apple. The fact that the user can reset the Advertising ID as often as he wants is annoying from a tracking point of view (that’s the goal), and as a result, certain tracking companies started using permanent (or at least long-term) identifiers to track the user;
• the Android permission system does not help so much in controlling what information is captured and sent: it’s a coarse grain system that often cannot tell the difference between what is legitimate and not. And we have the feeling these authorizations are interpreted by trackers as an implicit authorization of the end-user to do whatever is technically possible;
• the Apple privacy dashboard added in iOS6 does not help so much either:
  • items are missing (for example, Device Name, Internet usage) and techniques exist to bypass some of the limitations imposed (for example WRT the Advertising ID restrictions). Fortunately, the access to the MAC address seems to be banned from the new iOS7 version, but what about the rest?
  • A&A libraries included by the App developer have access to the same set of user’s private data as the App itself. However, a user accepting that an App has access to his or her Contacts doesn’t necessarily indicate consent for this data to be shared with third parties. Whether and where personal information is sent is not under the user control via the privacy dashboard;
  • is an authorization system that does not consider any behavioral analysis sufficient? For instance, accessing the device location upon App installation to enable a per-country personalization is not comparable to accessing the location every five minutes. That’s a fundamental limit of the privacy dashboard system (and the Android authorization system too);
• all this happens without the user knowledge…
• …and probably without the App developer knowledge. The A&A libraries are often included by App developers without knowing their exact behavior. And if App developers get money by including these libraries in their App without being afraid of privacy-enforcement authorities (for example, if there is little or no risk of legal action), they probably won’t care too much whether these added libraries respect the user’s privacy or not.

You might also be interested in Paris Metro Tracks and Trackers: Why is the RATP App leaking my private data?

Contacts : Jagdish Achara, James Lefruit, Vincent Roca, Claude Castelluccia

The PRIVATICS Inria team – July 2nd, 2013 – https://team.inria.fr/privatics/

———————————————————————————————-

RATP wishes to reply in light of the publication of our blog with the following items of additional information:

Data exchanges with the Adgoji server

–         SDK Sofialys (the adserving company for our online advertising sales service) sends information to the Adgoji server, the Fly Targeting system that provides contextual information about the public based on the applications installed on the terminal. Information recovered by SDK is processed for analysis, but does not make it possible under any circumstances to identify the data user.

–        No data collected by Adgoji concerning users of the RATP app have been used. The Fly Targeting module was under study in Sofialys, which mistakenly implemented it in its SDK in “production” phases. We are currently removing it from SDK.

Furthermore, we confirm that no personal data are used. In accordance with Apple directives, the UDID stopped being used last year. As for the IMEI: although the ID is already hashed, we are requesting a higher level of encryption for the next revision of SDK.