What You Need for Code

What You Need for Investigation

In order to find bugs, you'll need a good idea of what's going on in the internal structures of the application or program you are attacking. The tools listed in this section are useful in a variety of situations, such as when you're hunting for bugs , when you're developing an exploit, and when you're trying to work out what someone else's exploit does.

Useful Custom Scripts/Tools

In addition to the tools listed in this chapter, the authors use a variety of small, custom tools for various purposes. You might want to write your own scripts or tools for similar purposes.

An Offset Finder

On both Windows and Unix platforms, you will frequently need to find the address of a given instruction. For example, in a Windows stack overflow you might find that the ESP register is pointing at your shellcode. In order to exploit this, you'll need to find the address of some instruction stream that redirects execution to your code. The easiest way to do this is to find one of the following byte sequences in memory and then overwrite the saved return address with the address of one of the following sequences:

 jmp esp             (0xff 0xe4) call esp            (0xff 0xd4) push esp; ret       (0x54 0xc3) 

You should find these sequences in numerous places in memory. Ideally, you should look for them in DLLs that haven't changed across service packs. At the time of writing, Windows 2000 had a few DLLs that had not been updated since Windows 2000 was released. These DLLs contain numerous useful instruction sequences. Using one of these offsets would help ensure that your exploit worked across all Windows 2000 service packs .

The offset finder works by attaching to the remote process and suspending all its threads, and then hunting through memory for the specified byte sequences, reporting them into a text file. It's a simple, but useful, thing to have.

Generic Fuzzers

If you're investigating a given product for security flaws, you'll probably find it useful to write a fuzzer that focuses on some specific feature of the producta Web interface or some custom network protocol or maybe even an RPC interface. Again, generic fuzzers are useful things to have around. Even very simple fuzzers can accomplish much.

The Debug Trick

Reverse shells in Windows can be pretty frustrating. You can't easily upload files, and the basic scripting support is limited. There is a ray of hope in this dank and frightening world, however, which comes in the unlikely form of the old MS-DOS debugger, debug.exe .

You will find debug.exe on nearly every Windows box. It's been around since MS-DOS, and it still exists in Windows 2000 Service Pack 4. Although debug.exe was primarily intended as a tool to debug and create .com files, you can also use it to create an arbitrary binary filewith certain limits. The file must be less than 64K, and the filename cannot end in .exe or .com .

For example, take the following binary file:

 73 71 75 65 61 6D 69 73 68 20 6F 73 73 69 66 72    squeamish ossifr 61 67 65 0A DE C0 DE DE C0 DE DE C0 DE    age.@@p@@p@@p@@p@@p@@p 

Why this file? As everyone should guess, the magic words are squeamish ossifrage . You then write a script file that outputs said binary file, as follows (call it foo.scr ):

 n foo.txt e 0000  73 71 75 65 61 6d 69 73 68 20 6f 73 73 69 66 72 e 0010  61 67 65 0d 0a de c0 de de c0 de de c0 de rcx 1e w 0 q 

Then run, debug.exe .

 debug < foo.scr 

debug.exe will output the binary file.

The point here is that the script file needs only to contain alphanumeric characters , so that you can use the echo command over a reverse shell to create it. Once the script file is on the remote host, you run debug.exe in the manner specified above, and bingo, you have your binary file. You can simply rename the initial file, for example, nc.foo , and then (once you've uploaded it) rename it nc.exe .

The only thing you must automate is the creation of the script file. Once again, this is easily done in perl, Python or C. debug.exe is an exceptionally useful tool if you insist on using reverse shells in Windows.

All Platforms

Probably the single-most popular network security tool in existence that can be used on all platforms is NetCat. Its original author, Hobbit, described NetCat as his "TCP/IP Swiss army knife ." NetCat allows you to send and receive arbitrary data on arbitrary TCP and UDP ports, as well as listen for (for example) reverse shells. NetCat ships with quite a few Linux distributions as standard, and it has a Windows port. There's even a GNU version at http://netcat. sourceforge .net/ .

The original Unix and Windows versionsby Hobbit and Chris Wysopal (Weld Pond) can be found at www.atstake.com/research/tools/network_utilities/ .

Unix

In general, it's easier to see what's going on in a Unix system than it is in a Windows system; therefore, bug hunters have a slightly easier time of it.

ltrace

ltrace is a program that allows you to view the dynamic library calls and syscalls that a program makes, as well as view the signals the program receives. ltrace is exceptionally useful if you're trying to work out how a particular part of a certain string-handling mechanism works in a target process. It's also pretty useful if you're trying to evade a host-based IDS and need to work out what pattern of syscalls a program makes

For more information, simply check the man page for ltrace .

strace

strace is similar to ltrace in that it allows the tracing of system calls and signals in a given process. Again, for more information, check the man page for strace .

fstat (BSD)

fstat is a BSD-based utility for identifying open files (including sockets). It's pretty useful for quickly seeing which processes are doing what in a complex environment.

tcpdump

Because the best bugs are remote bugs, a packet sniffer is essential. tcpdump can be useful for obtaining a quick overview of what a particular daemon is doing; for more detailed analysis, however, Ethereal (discussed next ) is probably better.

Ethereal

Ethereal is a GUI-based free network packet sniffer and analyzer. It has a huge number packet parsers, so it's a pretty good first choice if you're trying to understand an unusual network protocol or if you're writing a protocol fuzzer.

You can download Ethereal at www.ethereal.com/ .

Windows

A bug hunter's life on the Windows platform is a slightly harder one. The following tools are exceptionally usefulall of them can be downloaded from Mark Russinovich's and Bryce Cogswell's excellent sysinternals site, www.sysinternals.com/ .

RegMon Monitors access to the Windows registry, with a filter so that you can focus on the processes under test.

FileMon Monitors file activity, again with a useful filter feature.

HandleEx Views DLLs loaded by a process, as well as all the handles it has open; e.g., named pipes, shared memory sections, and files.

TCPView Associates TCP and UDP endpoints with the process that owns them.

The Sysinternals site provides many excellent tools, but these four programs make up a good starting toolkit.

IDA Pro Disassembler

The IDA pro disassembler is the best disassembly tool on the market for the Windows reverse engineer. It features an excellent, scriptable user interface with easy cross referencing and search facilities. IDA Pro is especially useful when you need to establish exactly what certain vulnerable code is doing and when you're having trouble with such tasks as continuation of execution or socket stealing. IDA can be found at www.datarescue.com/ .