Thursday, December 15, 2011

Carrier IQ Subverts HTTPS Protections

There have been many recent news articles describing Carrier IQ. Carrier IQ is a piece of software that runs on mobile phones and collects information about user behaviors. According to the software manufacturer Carrier IQ does not collect sensitive data. Some have labelled Carrier IQ a "rootkit" because of its stealthy behavior ad level of access.

While watching the original demonstration of Carrier IQ, I noticed that many things were being written to the system log including web URLs (the author notes this as well). The collection of URLs may include those that use the HTTPS protocol (encrypted web traffic). The URLs may also include GET parameters (words after the question mark). GET parameters act as variables and are sent to the web server as a way to customize the resulting web page for the user. For example the following URL could be used to authenticate someone to a web service (think bank):

https://secure.foobar.com/baz?username=foo&password=bar

The intention of the HTTPS protocol is to provide transport-layer end-to-end encryption. The end points are supposed to be the web browser and the web server. HTTPS uses SSL/TLS to provide the encryption. Transport-layer encryption by nature does not protect the privacy of the source and destination ip addresses. It protects the privacy of everything in the application layer which includes GET parameters and all other HTTP data (web page contents, HTTP headers, POST parameters, etc). Once my HTTP request leaves my browser it is supposed to be encrypted until it is decrypted on the server (end-to-end!).

However, because Carrier IQ writes the URL, including parameters to the system log file they break the end-to-end encryption. This caught my attention. This is not a small matter. Now that the data is in the system log it is available to all other software on the phone! Not good.

I spent about one hour creating a proof of concept Android application that scrapes the system log and sends all HTTPS URLs, including parameters, to another computer connected to the Internet. My application also grabs the device ID and sends it along with the URL (for the demo below I used the Android emulator which has all zeros for its device ID).

The application had to request the Android "READ_LOGS" and "INTERNET" permissions. These permissions are very common. The "READ_LOGS" permission is often used by developers so that end users can send log files with bug reports. The "INTERNET" permission is used by all apps which need network access (many).

My app uses a giant user interface button to perform the log scraping. But imagine that the application ran as a service and ran without the user knowing (it is an easy change). The end result would be a hidden application that could be secretly spying on you. It could be installed as part of another seemingly legitimate application. Of course the private data being leaked isn't limited to HTTPS traffic, HTTPS is just the case that caught my attention.

I captured a screencast of my application scraping data from the logs and dumping it to an external server. This is not rocket science. For anyone with Android app development experience it would be trivial to write. My point wasn't to show off my mad hacking skills but to try to further emphasize the seriousness of this problem.

Note: I do not have a Carrier IQ plagued device. I injected similar log entries for testing my proof of concept application. I based my formatting of the log entries on the original demonstration.

Note: Quite surprisingly my log file had other HTTPS urls in it which were written by other applications. At least those applications were only leaking their own application information. For example I now have a Facebook developer key that I easily extracted from the log file. Not sure who the key belongs to. I don't think that I am supposed to have it. Come on developers, you are supposed to remove your debug messages before distributing your app!

7 comments:

Sarath Geethakumar said...

What device was this on? Was it an HTC device. I heard this is mostly applicable to HTC made devices as carrierIQ lib files only used by HTC. Wondering if this is reproducible in stock Google ROMS.

D. M. Stanley said...

@Sarath: I don't actually have a Carrier IQ plagued device. I faked the log entries for testing. The log file that I scraped is the same log file that is used by Carrier IQ.

Sarath Geethakumar said...

In my opinion.....its a really bad idea to send sensitive information as part of URL GET parameter. The only application that I see now-a-days that uses GET for sending sensitive info is Apple's AppStore. If logging url's can lead to PII leakage, then the invoking software has more serious issues to deal with than just carrierIQ. Server logs, sysadmins, SSL termination points, load balancer and the list of potential areas of interest goes on.... My 2 cents.

D. M. Stanley said...

@Sarath: The GET parameters are encrypted during transport so they are really not much different from POST parameters. If a web server, for example, is set to log the request with GET parameters included that is a bad idea. But a web server can also be set to log the request with POST parameters as well (or any other header for that matter). An attacker between the browser and the server can't intercept the GET parameters any easier than POST parameters.

Sarath Geethakumar said...

Well SSL termination usually does not happen at the server, in most cases. They are either at load balancers or SSL terminators. Applications also OFTEN log url's for multiple reasons. However, accessing data from POST body request special equest processing and is not as straight forward as logging the URL. Web servers require access to URL's for routing, request handling etc but do not need access or log POST body by default...

D. M. Stanley said...

@Sarath: In my experience I would say that SSL termination "in most cases" happens at the web server. I have been around many data centers and I have never seen SSL terminated anywhere but the web server. But in any case logging get parameters is ill advised.

Augusto González Rossi said...

Are any way to prevent this logs ?