WeatherFist
WeatherFist, the harmless proof-of-concept application featured in the MOBOTS presentation, is a quick app we wrote for displaying weather information. In order to know what location to pull weather information for, the program uses a phone home technique to submit the user's current GPS coordinates in return for the local ZIP code. Phoning home is a typical way for a botnet to get in contact with a command and control server, so we wanted to see whether this technique would be allowed to slip through into the iPhone/Android marketplace via popular repositories like ModMyI and SlideMe. WeatherFist is not in any way a trojan or a backdoor and can easily be uninstalled via regular uninstallation mechanisms. No functionality or data will persist once the uninstall takes place. It is simply a proof-of-concept that allowed us to collect statistics for the case study. We submitted WeatherFist to the ModMyI (iPhone) and SlideMe (Android) repositories, where users downloaded and ran the application from their own phones. We currently have ~8400 unique downloads of WeatherFist (7700 iPhone and 700 Android) with 22000 hits with statistical data in our database. Even though WeatherFist did not collect any personally identifiable information, our research database will not be available to the public, nor do we have any plans to make it so.We first decided to the take a run at this project last summer, while we were both enjoying the honeymoon with our respective smartphones. It took us a couple of months to dive into the different smartphone programming languages, but we were able to produce a multi-platform weather forecast display application. We split the development duty evenly - Derek wrote the Android application and I wrote the iPhone application. The purpose of the application is straight forward: deliver relevant demographic information to our host server and return relevant meteorological information to the client. Of course, this is nothing novel or particularly interesting; even as we employed the ubiquitous HTTP query string convention that you've all come to know and love. Google, for example, loves to stuff demographic data into their search query strings:
http://www.google.com/search?q=RSA+Conference&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a
In this case, Google is packing the query string with information pertaining to my search request, "RSA Conference." The tokens break down thusly:
q=the+thing+i+searched+for
ie=input encoding
oe=output encoding
aq=used firefox toolbar for search ((t)rue or (f)alse)
rls=location information from source
client=brand of web browser
Well, this is pretty much the type of information that we decided we would need to have in our possession in order to substantiate our claims as proof, rather than purely conjecture. Since we were seeking to demonstrate the feasibility of deploying a mobile botnet, we opted to send the following statistically germane demographics to our server with each request:
http://weatherfist/gps2zip?lat=10.101010&long=20.1234&d=a&n=abcdef12345678900987654321fedcba
For our purposes, the query string breaks down thusly:
lat=current latitude
long=current longitude
d=device type ((a)ndroid or (i)phone)
n=phone number MD5 hash
The latitude and longitude values serve two purposes. Firstly, the values are passed to a reverse geocoding method in order to obtain a ZIP code for the weather forecast request. Secondly, it provided us with data points with which to populate a distribution map. The device type data is used in precisely the way Google's "client" parameter is used: in order to track market share between our available application platforms. Finally, we opted to utilize an MD5 hashing algorithm with the client device's phone number (hence the "n") so that we would have a unique, but otherwise meaningless, device identification token. It would be very difficult for us to reverse the standard hashing algorithm to get the number back, and honestly, we have better things to do with our time.
Once we had the demographic data in our hands, we gave the client what they asked for: their local weather forecast. That is, the nice folks over at Weather Underground provided the client with the local weather after we populated the request string with the ZIP code we calculated from the "lat" and "long" query string parameters.
When we pushed the applications out for consumption a couple of months ago, we were mostly interested in discovering which avenues brought users to our door. We quickly discovered that the alternative application markets were bringing in volumes more traffic than our shameless self-promotion via social networking sites. In fact, merely placing our application in one of the alternative repositories effectively subsumed our previous efforts. Within hours of publishing the WeatherFist applications we saw tweets, retweets and various hashtag postings on several social networking sites. The Social Media Machine was doing our work for us; huzzah! In truth, I think we were both surprised by how quickly our download volume increased while the application was still fresh meat.
WeatherFistBadMonkey
It goes without saying that the only interesting things we got out this particular endeavor are the usage statistics. We didn't want to do anything particularly "interesting" to our loyal user base, either. For that we wrote the WeatherFistBadMonkey version and tested it on our own smartphones for this experiment.WeatherFistBadMonkey is an extension to WeatherFist that allows us to take complete control over the userÃs phone. WeatherFistBadMonkey was not distributed publicly, it only serves as proof that it is possible to convert a mobile phone into a bot. To the user, there would be no difference between WeatherFist and WeatherFistBadMonkey. Behind the scenes, however, there is a substantial difference between the two. The malicious version will first submit the user's entire address book to our simulated command and control server including the contact's first name, last name, all email addresses, and all physical addresses. The functionality of the MOBOT includes polling our command and control server every five minutes for instructions. The instructions currently supported are: send an email, perform a DDoS of a website, and give us a reverse shell. The first two are pretty standard botnet functionality, while the third is the one that is most interesting. Opening a reverse shell gives us direct remote control over the phone. We are able to browse the entire file system, steal personal data (SMS text messages, browser cookies, etc), as well as deny access to vital applications such as "Phone" or "Messages". The possibilities are pretty much only bound by how malicious we intend to be. Since this happens over the Internet, both 3G and Wifi connectivity would satisfy our connectivity needs.
