With this large amount of utilities, it is sometimes hard to pick the correct one for the job. At Shmoocon 2008, a BackTrack representative gave a talk which was good, but focused on exploiting a Windows binary using Olly, not on showing off the features of the distribution. So I took it upon myself to click on every single link and find the awesome and the less awesome tools among the bunch. Note that the work that I did was for a presentation. There are videos which are self-explanatory but at times need commentary. I will provide some explanation in writing.

1. CREDITS

BackTrack3 – www.remote-exploit.org
Tactical Exploitation – H.D.Moore & Valsmith (Defcon 2007)‏
Metasploit Videos – learnsecurityonline.com

2. RECORDING

BackTrack comes with a video recording utility, recordmydesktop. You can either record the whole desktop or just one window using a window id. Some useful commands are:

recordmydesktop –no-sound -o out.ogg
xwininfo |grep “Window id:”|sed -e “s/xwininfo\:\ Window id:\ // ;s/\ .*//” #gives you a window id
recordmydesktop –nosound -windowid 0×0442 -o out2.ogg

3. INFORMATION GATHERING

In this category, the focus is on information aggregators, network discovery tools and OS and application vulnerability scanning tools.

3.1. Maltego – Personal Discovery

This is a tool from www.paterva.com that can be used for personal discovery. It has been in development for a while now and switched from a web version to a standalone binary version. It is a total information aggregator. It can search social networks such as LinkeIn, public PGP key servers. It can pull down various information from inside documents and other aggregators such as serversniff.de and robtex.com. It offers services such as geoip resolutions, email verification. The tool has a graphical interface and you can start your search by domain, IP address, website, email, person, phone number etc. The information is presented as a directional graph and any results can be further interrogated producing new results. You can use this to do various things such as profiling users of a certain server, searching for groups of people, determining relationships between websites, building PGP trees etc.

Maltego commonly finds phone numbers, addresses, names, personal sites, resumes, newsgroup postings, usernames, email addresses.

3.2. Nmap and Websites – Network Discovery

While doing network discovery, you are looking for variety of things such as MX records, internal networks, outsourced services, important server and open ports. The number one tool for this is still Nmap. A lot has been written about nmap, so I will just share my favorite usage and leave it at that:

nmap -sS -P0 -O -T Sneaky -p 445 -D 64.233.169.99 <ip_to_scan>

The above command initiates a stealth scan (-sS) which does not complete the TCP connection. This is fairly fast and unobtrusive. The -P0 flag tells nmap not to ping the IP which adds to stealth. The -T is a timing flag that can be set from Sneaky to Insane and determines the speed of packet generation. The -p flag specifies the port or a port range. You can use this flag either to add to stealth by specifying one or few ports, or add to thoroughness by providing a range of 1-65535. And last but not least, the -D flag allows you to specify a number of decoys. I usually put googlebot’s IP address. This makes nmap generate packets from your IP address and googlebots IP address (the response to which will go to google). This has an effect of confusing the target.

I would also like to share with you 2 less known network discovery tools. Two websites, www.domaintools.com and centralops.net provide nmap-like services. You can use these to create a domain dossier on any website that will include things like popular port scan, ping, traceroute, nslookup and whois. And best of all, the traffic is not going to come from you.

3.3. OS & Application Vulnerability Scanning

GFI LANguard is a tool I found as a useful replacement for Nessus (BackTrack does not include Nessus). It is only free with this BackTrack distribution. I found this tool to be a slightly slimmed down version of Nessus. On the other hand it was incredibly easy to use and it provides a wealth of information. It can scan a range of IPs to determine open ports, operating systems, common vulnerabilities, users, shares, running processes, security policies, missing patches, SNMP devices and functions they provide. This demo shows a limited use of its features and the results are more glorious on a larger network.

video

4. WIFI WEP Fun

BackTrack has an excellent collection of various wireless tools. I will present some of these here. I will use them to defeat WEP protection of my home router.

4.1 WEP Overview

WEP weakness stem from frequently repeating 24-bit IVs (initialization vectors) and the use of weak RC4 algorithm for keystream generation. This knowledge has been used to create a brute force attack. In this attack, you need to only capture a single encrypted packet and apply enormous amount of computing power to try all possible keys. This is possible due to the fact that the real key length is 40 for 64-bit keys and 104 for 128-bit keys. It has been shown that a weak key can be brute-forced in a manner of minutes. Another type of attack is FMS attack which is a statistical attack on known weak keys. You need to capture a lot of traffic to collect these keys, apply little CPU power and perform this attack. The tools that I describe below use the FMS attack.

4.2 Airo Tools

Below is a sequence of commands to use. I will not post the video due to its large size. You have to first bring up an interface in monitor mode. Then, you have to find a target with a command like “ wlanconfig ath0 list scan“. Then, use airodump-ng for collection of IVs, aireplay-ng for speedup of collection of IVs, and aircrack-ng for cracking of the key. In general, you need about 60KB of IVs before you should attempt to crack a 128-bit key. I waited until my filesize was a few megabytes. Depending on how fast the packets are flowing, the attack can take a few minutes or much more.

ifconfig wifi0 up
wlanconfig ath0 create wlandev wifi0 wlanmode monitor
ifconfig ath0 up
wlanconfig ath0 list scan
airodump-ng –ivs -c 6 –write dump –bssid <AP’s_MAC> ath0
aireplay-ng -2 -b <AP’s_MAC> -d ff:ff:ff:ff:ff:ff -m 68 -n 68 -p 0841 -h <Innocent_computer’s_connected_to_AP_MAC> ath0
aircrack-ng -f 2 -a 1 -b <APs_MAC> -n 128 dump-01.ivs

4.3 Wesside-ng Demo

This is a tool that automates WEP cracking. It is still in early stage of development and I could only get it working with an atheros chipset. It is simple to use and does everything on its own. It finds a nearby vulnerable network, collects traffic and cracks the key.

wesside-ng -i ath0

video

5. Other WIFI tools

5.1 WifiZoo

This is the most useful tool that I found. I believe it comes from the CoreImpact toolkit. It is used primarily for cookie stealing on unencrypted and possibly encrypted (untested) networks. On my test network I managed to steal Facebook cookies. I had unlimited control of the Facebook account of the “victim” and could do anything up to changing the password. I also managed to steal Gmail cookies. Pretty much the only things I could do was read email and set a forwarding email. I could not change the password.

I am not posting a demo of this due to size limitations and privacy issues. I am posting a screenshot. As you can see the tool also automatically collects FTP data and SMTP data. What you have to do to get it working is:

1. nano /pentest/wireless/wifizoo/wifizoo.py and change conf.iface=’eth0′ to you monitor interface
2. ./wifizoo.py to start the tool
3. Start Firefox and change its HTTP proxy to 127.0.0.1:8080
4. Point the browser to 127.0.0.1:8000 which is WifiZoo’z webinterface

5. After that, it’s smooth sailing – click on the cookies link, click on a captured cookie, select “Set Cookie” and it will take you to the IP address of the website. You usually have to change the IP address to the name manually (e.g. change 69.63.176.140 to www.facebook.com in the browser location bar).

5.2 MDK3

I don’t know if this stands for “Murder Death Kill 3″ but it sure looks like it. I could not fully test this tool as I did not want to attack a large network and this is mainly where it would shine. This tools allows you to deploy a 3-part attack. First, you can deauthenticate clients from all nearby or a selected Access Point thus providing a denial of service. Second, you can flood the nearby APs with authentication requests. This can lead to a situation where some APs will need to be restarted or the become full and will not accept any new users. Third, you can create a beacon flood of fake APs specifying some ssid or generating random ssid names. After this step, the legitimate clients that were booted from their APs in step 1 will have a lot of problems reconnecting. This sounds like it could create some major havoc on unsuspecting networks. Most of this can probably be mitigated by a combination of MAC filtering and good firmware. The commands are:

mdk3 eth0 d # deauthentication attack
mdk3 eth0 a -a <AP_MAC> # authentication flood
mdk3 eth0 b -n MyEssid -w -c 11 # beacon flood mode

6. EXPLOITATION FRAMEWORKS

Backtrack comes with Metasploit, Inguma, W3AF and a few others. I have tested Metasploit and W3AF and will present my results here.

6.1 Metasploit 3 – unlocking a workstation

The problem is simple, I have a Windows 2000 VMware workstation that I don’t know the password to. Since it turns on, it probably goes online and gets an IP address. A nmap scan reveals that to be true. After that, I take a random exploit for windows 2000 and throw it at the box. This one happens to be a Net32Api CanonicalizePathName() stack overflow. The payload is set to vncinject. By default, it provides a “Courtesy Shell”. Typing “explorer.exe” in that shell bypasses the authentication window and allows the change or Administrator password. Note that I am using the Windows GUI Metasploit. I had to do this due to my need to start a VM.

video

6.2 Metasploit 3 – SMB Relay Attack

Multiple videos already exist for this attack elsewhere and while doing this I used a tutorial from learnsecurityonline.com. The attack mechanism is described nicely here and here. In a few words, whats going on here is – a man in the middle reflection attack based on the weakness of the Microsoft SMB file sharing authentication protocol. Note that I am using a web interface this time.

video

7. PENTESTING A WEBSERVER

The tools that you want to use for this are: webspiders, webserver vulnerability scanners, exploitation frameworks for web, credential brute-forcing utilities.

7.1 Nikto

This is web server scanner which performs tests against web servers for multiple items, including over 3500 potentially dangerous files/CGIs, versions on over 900 servers. It commonly finds outdated software versions (SSL, Apache, PHP), allowed HTTP methods, and various directories that are missing index files.

7.2 W3AF

This is a web application attack and audit framework. I have not experimented much with it. I used its webSpider to collect all the links of a webserver. Then I wrote a script to extract the users of the server by searching for “~”.

Summary: Using the information collected from just the above two tools, we can now go ahead and try to exploit the server by looking for existing vulnerabilities for the outdated software, examining the files in directories that are missing index files to try to find .htpasswd files or embedded passwords in PHP files. We can also try to bruteforce the accounts of the users we collected from the webspider. The tools to use for bruteforcing are Hydra, Medusa, and SSHater. They come with modules that allow you to attack most popular protocols (ssh, ftp, telnet, imap etc).

8. TOOLS I DIDN’T LIKE

There were a few that I didn’t like but others I just didn’t find useful. The list would be too long if I had to list it here. I will mention the fact that THC-Hydra and Medusa, both online password brute forcers, core dumped when I tried to use them.

Let me just say this: it seemed like a good choice at the time, and, if I could have trusted the vendor to deploy the software on it properly, it might still be. Here is a short summary of some of the issues I found:

You can skip to the full report here: A Security Audit of the Synology Disk Station Manager (DSM) v2.0-0590 Firmware.

What follows is a complete retelling of how I got here, sort of a lesson in vulnerability disclosure (not so much discovery, you’ll see why). It’s not pretty, I didn’t do all the right things, and it’s kind of long.

I had a lot of free time over Spring break (read: no money to travel anywhere) and so I decided to start “kicking the tires” of the Synology CS407 I owned. My jaw dropped when I got this first nmap scan back:

PORT      STATE SERVICE     VERSION
80/tcp    open  http        Apache httpd 2.2.3 ((Unix) mod_ssl/2.2.3 OpenSSL/0.9.7e PHP/5.2.0)
139/tcp   open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
443/tcp   open  http        Apache SSL-only mode httpd
445/tcp   open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
515/tcp   open  printer
548/tcp   open  afpovertcp?
3306/tcp  open  mysql       MySQL (unauthorized)
3493/tcp  open  tcpwrapped
3689/tcp  open  http        mt-daapd httpd 0.2.4
5000/tcp  open  http        Apache httpd 2.2.3 ((Unix) mod_ssl/2.2.3 OpenSSL/0.9.7e)
5001/tcp  open  http        Apache SSL-only mode httpd
5432/tcp  open  postgresql  PostgreSQL DB
50001/tcp open  tcpwrapped

It only got worse when I ran Nessus. And then worse when I got a shell and started poking around the filesystem. Get this: every application on the box is running as root! And all the web apps are written as compiled binaries running in CGI… with root privileges! As a friend in the lab described it, “1996 called, it wants its web technology back!” They weren’t even making it difficult.

This is where things got interesting. I looked around and there isn’t any formal security contact or even a public bug tracker (and they call themselves a Linux vendor!). I’m thinking maybe I can save myself some trouble and get this solved informally, so I made this really scary sounding post on their user support forums with just the results of that nmap scan. I also submitted a technical support request at the same time, pointing to the forum post. Best idea? No. But it was easy. I really didn’t want to write a formal report and submit it. I’m not getting paid for this, and frankly, I’m kind of pissed off that I bought this thing and that I’m stuck with it now.

Two moderators immediately replied to my forum post claiming that there were no security vulnerabilities and that security vulnerabilities were the price we pay for having the coolest NAS out there. I thought these were official representatives of Synology at first and was ready to make a post to full-disclosure after reading their replies.

Then an official response came back from their tech support: log in to the box over SSH (which they don’t provide, I had to hack it to turn it on) and turn off the affected services. They also recommended I put the box behind a firewall… This is why you’re supposed to have a security@ contact, so people like me don’t get stuck with non-tech and sales staff. I said a few specific things in my reply to get my concerns in front of the right people:

1. Ask for this issue to be escalated to a product manager
2. Explain the risks they were putting themselves and their customers under
3. Explain what would happen if they didn’t respond to my concerns (full-disclosure)
4. Included a PDF of a very early draft of my report

That worked. 3 days later I got a response from Synology (still their sales staff) indicating that more than half of the vulnerabilities I pointed out would get fixed in a new release of the firmware due out in 60 days. They denied a number of vulnerabilities, which I explained further and sent back to them.

Then I didn’t hear from them for 9 days. Apparently, my emails were getting stuck in their spam filter (again, vendors, please set up a security@ e-mail)! This went back and forth for a bit and I’ve moved about 90% of the issues into the next release! A handful of more architectural issues were pushed back until a release 6 months in the future. You can’t win them all, but at least they are aware of the issues now.

Back on the forum, I had been getting fairly actively involved by answering security questions from other users. Some intelligent people saw what I was saying and came to my defense when the fanboys attacked what I was saying about their precious devices. Two people even posted that they had delayed or reconsidered buying Synology products because of this discussion! It was really great to hear that, both as vindication that what I was saying was important and that Synology’s management had to take me seriously now. They were actively losing customers due to poor development practices.

How they reacted to this really isn’t surprising in hindsight: they moved all my posts to a separate, special forum, away from potential and current (but mostly potential) customers. Then their moderators started getting fed up that people were still talking about security issues they thought were irrelevant and resorted to character attacks and flaming. I sent an e-mail to my contact on the sales staff that someone representing their company was acting inappropriately and their behavior might be tied back to the company. Synology responded by locking my post.

And that’s the end of that mess.

If you have a Synology product… well good luck! All the problems I found won’t be resolved until 09/2008! And even then, I’m sure there will be more security vulnerabilities. Those compiled binary CGIs are a ticking timebomb. If you don’t already own a Synology product, I suggest FreeNAS. You can install it in a VM and try it before you “buy” it. I’d really like to get my hands on one of NetGear’s ReadyNAS products… anyone with one want to let me poke around it for a bit?

Keeping this in mind, I realized that almost every single UNIX binary gets its arguments from the shell in a standard, POSIX-compliant way. The getopt libc function call parses the input from the shell in to usable internal flags. If one were to peek inside what each binary gives to getopt(), one would find out all arguments it is expecting to take and provide more insight about the executable! This is what I have done and what the remainder of the post is about.

This is what my previous post related to. Now I realize this is a slightly silly goal. My primary reason for doing this is to learn the techniques I’ve used to get there, which I simply could not learn without experimentation and a concrete goal in mind. The way this problem was attacked as follows:

Each step has an explanation of it below it:

How this works

1. I use libelf(3) to open the binary, and read its sections.
• Most UNIX binaries are in the ELF format. The official draft is included in the tarball at the end of this post. ELF (or Executable and Linkable Format) is a file format that most UNIX systems today understand.
2. The sections I care about are the PLT and the dynamic symbols section.
• An ELF file contains information in sections. The two sections I mentioned are the section that contains the dynamic symbols and the procedure linkage table
• Dynamic symbols – When you write a program that uses a shared library, libc being the prime example. One copy of libc is shared among many processes, and when you compile a program, the actual code from libc does not get compiled into the binary. What happens is that your compiler leaves a little note to your operating system (or the operating system loader [Not the boot loader! ]) saying “Here I call some functions that should be in a shared library that you might have loaded, and if not you can load it as you need it. I will be calling printf and getopt, so I will reference to them as if I have them. Please fill in those references as you find your own copy of libc”. That list of functions is called the dynamic symbol table. Each process that utilizes shared libraries (which is almost all of them) has a GOT (or a Global Offset Table) which is a table that maps those symbols to the locations in the library where the code actually is. So when you call printf() in your code, in the compiled instructions, the code actually looks at the printf() entry in the GOT and jumps to whichever address it points to. When you leave those references ‘open’ as I mentioned earlier, those entries are simply not filled in. When the loader resolves those references, it fills in the proper address of the shared library. So to picture it, the flow of execution is as follows: printf() –> GOT –> actual printf code. Now for reasons outside the scope of this post, there is yet another level of indirection. So in reality the flow is: printf() –> PLT –> GOT –> actual printf(). The PLT is a series of jump statements that go to the GOT. This jump table is what we focus on.
3. I then extract the position of the getopt symbol and look it up in the PLT.
• From the information I retrieved using libelf, I check at which address the PLT table gets loaded (section ‘.plt’), then I check the index of the getopt symbol in the symbol table, and I obtain the address of the PLT entry by simply performing: .plt + (getopt position + 1) * 0×10 (0×10 is the size of a plt entry as far as I know, and +1 because I want to skip the 0th entry of the PLT table)
4. I start the binary, overwrite the proper address, set a breakpoint, and extract the arguments.
• I now have the jump that gets taken every time when getopt gets called. I now fork() and before I execv() the process, I enable the process to be traced with the ptrace(3) interface. This is the same method that debuggers use to attach to processes. The parent gets notified once the child is finished being loaded if it is being traced. Once I get notified that it is created, with the proper address of getopt in hand, I overwrite that jmp instruction with a int3 instruction (or 0xCC assembled. Something to note, in my code I overwrite it with 0xcccccccc, which is just four int3 instructions. I didn’t want to bother with byte-ordering or alignment issues, so I just overwrote the entire word. Since the instruction is only one byte, it works just fine.) This instruction will trap into the parent once reached. This is also how debuggers set breakpoints, with a slight difference: They save the original instruction they overwrote so they can restore it on the next execution, but since I simply don’t care for it to continue running I can just go walking all over it. Now I continue the child process.
• All my child interaction and prodding was done with the ptrace() system call.
• Once the parent gets trapped again, I now know that I am at the point where getopt() was JUST called. If you remember, the standard C calling convention is to push all the arguments to the stack and then call the function. I now know that %esp points to the first argument passed, so I know that at a certain offset will be the last argument, which is the string of every argument that a binary is expecting, which is what I care about.
• I now know where the string of arguments is in the child’s address space, at which point I can safely extract it, then kill the child process before it does anything. How mean.
5. I can now rinse+repeat for other binaries in which I’m interested.

Why this works

1. More programs call getopt() as one of the absolute first things they do. This means that there is a very low chance that any side-effects will come up.
2. This is fast since the OS only loads the pages of code that are being executed, and there is a very high chance that getopt will live in the first page of code, making it pretty fast.

Something to note here: Not all binaries use getopt. This is a problem, but not one that I care about to fix. This took a little over three weeks to complete due to the lack of material about the matter on the Internet, and the slightly esoteric nature of the solution. Check out the ltrace utility if you want something like what I wrote on steroids (outlines every single library call with all arguments).

I originally attempted to read ltrace source to figure out how to solve the problem, but it confused me more than it helped me. In the end a sit down with the ELF spec and some time is what it took.

If you have any questions, comments, additions or critiques, please either comment on the post or send me an email.

The code I wrote and used can be found here: http://isis.poly.edu/~yan/readgo.tbz (You’d need libelf installed to get it to compile/run). This only works on FreeBSD/i386. Linux has a slightly different ptrace() interface, so porting will be trivial, but existent.

Since everyone loves some sample output:

yan@tissue$ ./readgo /bin/ls /bin/rm
/bin/ls: 1ABCFGHILPRSTUWZabcdfghiklmnopqrstuwx
/bin/rm: dfiIPRrvW

edit: Fixed a lot of grammatical mistakes thanks to Kurt.

Thanks for reading,
Yan

The tool in question is ltrace, which I believe is a doing of mostly the Debian project (I can be wrong), with a port to FreeBSD which is what I have been using. I have spent enough hours trying to just read source code, using grep to look for where to look for my next step.

Read on for descriptions!

GNU gprof, or GNU profiler, is a tool used to typically measure the performance and runtime (not algorithmic) of components. When using gprof, compile your target program with flags ‘-g -pg’. That will compile the program with debugging symbols, and add extra code that can generate profiling information. If you need to use gprof on a port or an existing application that uses the standard GNU building toolchain, just add ‘-g -pg’ to CFLAGS inside the Makefile. Also, look for lines where the program gets linked, as that needs ‘-g -pg’ as well. Then, use gprof to execute the program with the arguments that you will want to profile, e.g. ‘gprof ./ltrace /bin/ls 2>/dev/null > ltrace_gprof.out‘. That will create a file, ltrace_gprof.out that will contain all procedures that were executed, and all called from them. This simplifies tracing of code for specific execution of binaries. By passing the required arguments, you are crafting the execution thread to your liking. While I did not use gprof to profile, I did use it to trace the execution in a more-or-less high-level fashion.

The second tool I want to write about is GNU cflow. cflow, which I’m sure everyone except me knew about, takes a number of C files, and generates a graph of the function call hierarchy. It is very useful to see how a program executes, in a static fashion. One can just call ‘cflow -X *.c‘ and look at a pstree-like representation of the call graph. In my opinion, very useful in understanding the flow of a program. Here is some sample output:

77                      fopen {}
78                      fgets {}
79                      process_line {read_config_file.c 112}
80                              debug_ ... {62}
81                              eat_spaces {read_config_file.c 70}
82                              str2type {read_config_file.c 55}
83                                      strlen {}
84                                      strncmp {}
85                                      index {}
86                              start_of_arg_sig {read_config_file.c 81}
87                                      strlen {}
88                              output_line ... {66}

Why am I playing with these tools? To complete a piece of code that has stagnated at being at 80% completion, or so I think. More info on the tool along with complete source as I get it to some working state.