Grey bar Blue bar
Share this:

Thu, 14 Feb 2013

Adolescence: 13 years of SensePost

Today was our 13th birthday. In Internet years, that's a long time. Depending on your outlook, we're either almost a pensioner or just started our troublesome teens. We'd like to think it's somewhere in the middle. The Internet has changed lots from when SensePost was first started on the 14th February 2000. Our first year saw the infamous ILOVEYOU worm wreak havoc across the net, and we learned some, lessons on vulnerability disclosure, a year later we moved on to papers about "SQL insertion" and advanced trojans. And the research continues today.


We've published a few tools along the way, presented some (we think) cool ideas and were lucky enough to have spent the past decade training thousands of people in the art of hacking. Most importantly, we made some great friends in this community of ours. It has been a cool adventure, and indeed still very much is, for everyone who's has the pleasure of calling themselves a Plak'er. Ex-plakkers have gone on to do more great things and branch out into new spaces. Current Plakkers are still doing cool things too!


But reminiscing isn't complete without some pictures to remind you just how much hair some people had, and just how little some people's work habit's have changed. Not to mention the now questionable fashion.



Fast forward thirteen years, the offices are fancier and the plakkers have become easier on the eye, but the hacking is still as sweet.



As we move into our teenage years (or statesman ship depending on your view), we aren't standing still or slowing down. The team has grown; we now have ten different nationalities in the team, are capable of having a conversation in over 15 languages, and have developed incredible foos ball skills.


This week, we marked another special occasion for us at SensePost: the opening of our first London office in the trendy Hackney area (it has "hack" in it, and is down the road from Google, fancy eh?). We've been operating in the UK for some time, but decided to put down some roots with our growing clan this side of the pond.



And we still love our clients, they made us who we are, and still do. Last month alone, the team was in eight different countries doing what they do best.


But with all the change we are still the same SensePost at heart. Thank you for reminiscing with us on our birthday. Here's to another thirteen years of hacking stuff, having fun and making friends.

Mon, 11 Feb 2013

Poking Around in Android Memory

Taking inspiration from Vlad's post I've been playing around with alternate means of viewing traffic/data generated by Android apps.


The technique that has given me most joy is memory analysis. Each application on android is run in the Dalvik VM and is allocated it's own heap space. Android being android, free and open, numerous ways of dumping the contents of the application heap exist. There's even a method for it in the android.os.Debug library: android.os.Debug.dumpHprofData(String filename). You can also cause a heap dump by issuing the kill command:

kill -10 <pid number>

But there is an easier way, use the official Android debugging tools... Dalvik Debug Monitor Server (DDMS), -- "provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more." Once DDMS is set up in Eclipse, it's simply a matter of connecting to your emulator, picking the application you want to investigate and then to dump the heap (hprof).


1.) Open DDMS in Eclipse and attach your device/emulator


* Set your DDMS "HPROF action" option to "Open in Eclipse" - this ensures that the dump file gets converted to standard java hprof format and not the Android version of hprof. This allows you to open the hpof file in any java memory viewer.


* To convert a android hprof file to java hprof use the hprof converter found in the android-sdk/platform-tools directory: hprof-conv <infile> <outfile>


Using DDMS to dump hprof data


2.) Dump hprof data


Once DDMS has done it's magic you'll have a window pop up with the memory contents for your viewing pleasure. You'll immediately see that the applications UI objects and other base classes are in the first part of the file. Scrolling through you will start seeing the values of variables stored in memory. To get to the interesting stuff we can use the command-line.


3.) strings and grep the .hprof file (easy stuff)


To demonstrate the usefulness of memory analysis lets look at two finance orientated apps.


The first application is a mobile wallet application that allows customers to easily pay for services without having to carry cash around. Typically one would do some static analysis of the application and then when it comes to dynamic analysis you would use a proxy such as Mallory or Burp to view the network traffic. In this case it wasn't possible to do this as the application employed certificate pinning and any attempt to man in the middle the connection caused the application to exit with a "no network connection" error.


So what does memory analysis have to do with network traffic? As it turns out, a lot. Below is a sample of the data extracted from memory:



And there we have it, the user login captured along with the username and password in the clear. Through some creative strings and grep we can extract a lot of very detailed information. This includes credit card information, user tokens and products being purchased. Despite not being able to alter data in the network stream, it is still easy to view what data is being sent, all this without worrying about intercepting traffic or decrypting the HTTPS stream.



A second example application examined was a banking app. After spending some time using the app and then doing a dump of the hprof, we used strings and grep (and some known data) we could easily see what is being stored in memory.

strings /tmp/android43208542802109.hprof | grep '92xxxxxx'

Using part of the card number associated with the banking app, we can locate any references to it in memory. And we get a lot of information..



And there we go, a fully "decrypted" JSON response containing lots of interesting information. Grep'ing around yields other interesting values, though I haven't managed to find the login PIN yet (a good thing I guess).


Next step? Find a way to cause a memory dump in the banking app using another app on the phone, extract the necessary values and steal the banking session, profit.


Memory analysis provides an interesting alternate means of finding data within applications, as well as allowing analysts to decipher how the application operates. The benefits are numerous as the application "does all the work" and there is no need to intercept traffic or figure out the decryption routines used.

Appendix:


The remoteAddress field in the response is very interesting as it maps back to a range owned by Merck (one of the largest pharmaceutical companies in the world http://en.wikipedia.org/wiki/Merck_%26_Co.) .. No idea what it's doing in this particular app, but it appears in every session I've looked at.