I’m in ur 4sq, snarfin ur password — Part I

Hi, my name is Zach, and I’m a Foursquare user. If you’re not familiar with Foursquare, it’s a location-based social network and game (of sorts). Users “check in” to venues and, based on their activity, unlock “badges” and/or become “mayor” of that particular venue. Opinions of the service aside, I’m here today to highlight some issues pertinent to security (and possibly privacy) discovered in the official Foursquare mobile applications, including those running on the Android, iPhone, and BlackBerry platforms. These findings are, to some degree, part of the larger picture of mobile application security, especially with the <marketspeak> rapid convergence of mobile and web technologies. </marketspeak>

One day, during the course of continuing my Foursquare mayorship of the local bagel shop, I decided I’d go ahead and casually glimpse at what Foursquare was doing on my Android handset. I nohup’ed tcpdump in a terminal session, “checked in” to said bagel shop, and enjoyed my breakfast. Upon returning home, I copied the packet trace from my handset and analyzed it in Wireshark. Amidst the XML flying back and forth between the client and server, I noticed this:

GET /v1/checkins?geohacc=10000.0 HTTP/1.1
User-Agent: com.joelapenna.foursquared 2010011401
Host: api.foursquare.com
Connection: Keep-Alive
Authorization: Basic emFjaEBzb21lLnRsZDpteXBhc3N3b3Jk

What’s troubling here is the “Authorization” header, and the first parameter, “Basic”. In the case of “Basic” authentication, the client typically provides its credentials in the form of a username and password, which are concatenated together, separated by a colon, then encoded using Base64. For example, a username of “jrhacker” and a password of “secret” becomes “jrhacker:secret”. This is then Base64 encoded, resulting in “anJoYWNrZXI6bXlwYXNzd29yZA==”. Of course, Base64 encoding is only that — encoding. Using the Base64 encoded string from snippet above, it’s quick and easy to get credentials:

quine@durandal% echo "emFjaEBzb21lLnRsZDpteXBhc3N3b3Jk" \\
| openssl enc -base64 -d
zach@some.tld:mypassword

So, effectively, the official Foursquare application for Android utilizes HTTP Basic Authentication over a plaintext transport (HTTP). Attacks against the cellular network notwithstanding, the credentials are still fairly safe so long as they’re not going over WiFi. However, most WiFi enabled handsets will give priority to WiFi connections when they’re enabled, meaning the user’s credentials would be exposed to trivial sniffing attacks. I’ll recreate this simple Foursquare scenario and dive just a bit deeper after the bump.

(Note: image annotations in yellow)

I start by gathering a bit of information about my current connectivity. Only the cellular radio is enabled (WiFi is disabled):

And, after firing up a shell to the device, using the Android Debug Bridge, I verify that rmnet0 (the cell radio adapter), has address information:

Next, I run tcpdump, listening on the rmnet0 interface, and filter for the IP address 174.129.33.12 (which is the address of api.foursquare.com):

Finally, I open up the Foursquare application and login:

Returning to the tcpdump session, I see the Foursquare client using HTTP Basic Authentication (click for larger size):

Once again, the Base64-encoded string is easily decoded:

quine@durandal% echo "ZXZpbHNxdWFyZUBuMHdoZXJlLm9yZzpnb29kdmlzaW9u" \\
| openssl enc -base64 -d
evilsquare@n0where.org:goodvision

As mentioned previously, WiFi connections are often given priority over cellular connections, so it’s time to verify whether the Foursquare app for Android will follow this logic. First, I enable WiFi and check that I’ve got proper addressing:

Repeating the steps from before, I start up tcpdump, this time listening on tiwlan0, and login to Foursquare:

Inspecting the second tcpdump session, I see that Foursquare gave preference to the WiFi adapter, and, of course, sent credentials using HTTP Basic Auth:

Should this exchange have occurred over a publicly-accessible WiFi network such as a cafe or, say, a hacker con, that Base64-string (and the credentials it’s “hiding”) would be up for grabs. And who knows what sort of venues I’d be checked into after that? <g>

In Part II, I’ll go a bit more into the code side of things, a root cause of this discovery, and remediation.

Post a comment or leave a trackback: Trackback URL.