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!