Chapter 21: Writing Exploits that Work in the Wild

Factors in Unreliability

This section of the chapter will cover the various reasons your exploit may not work reliably in the wild. Keep in mind that although there are many reasons for your exploit not to work, as Anakata says, "even a blind chicken finds a seed occasionally."

Magic Numbers

Some vulnerabilities, such as the RealServer stack overflow described in Chapter 15, lend themselves to reliable exploitation. Others, such as the dtlogin heap double-free, are nearly impossible to reliably exploit. However, it's impossible to know how reliable you can make a given exploit until you try it. In addition, exploiting more and more difficult vulnerabilities is the only way in which to learn new techniques. Merely reading about a technique will never truly give you the essential knowledge of how to use that technique. For these reasons, you should always make the extra effort to make your exploits as reliable as possible. In some instances, you'll have a perfectly good exploit that works 100 percent of the time in the lab but only 50 percent of the time in the wild, and you'll find yourself having to rewrite it from scratch in order to improve its reliability in the real world.

When you create the first exploit for a particular vulnerability, the exploit might work only on your machine. If so, you probably hardcoded some important things into it, most likely the return address or geteip address. When you can overwrite a function pointer or a stored return address, you will need to redirect execution somewhere ”this location is likely dependent on many factors, only some of which you control. For the purposes of this chapter, we will call this situation a one-factor exploit .

Likewise, you may have a place in your exploit where a pointer to a string is located. The target program uses this pointer before you get control of execution. In order to effectively gain control, you may need to set that pointer (part of your attack string) to a harmless place in memory. This step would add an additional factor that you'd have to know in order to successfully exploit your target.

Most easy exploits are one- or two-factor exploits. A basic remote stack overflow, for example, is usually a one-factor exploit ”you only have to guess the address of your shellcode in memory. But as you progress to heap overflows, which are typically two-factor exploits, you must begin to look for ways to help narrow the level of chaos in the system.

Versioning

One important problem you will face when running an exploit in the wild is that you will rarely know what is loaded on the other machine. Perhaps it is a Windows 2000 Advanced Server box, just like the one in your lab, or perhaps it is running ColdFusion and moving memory all around. Or perhaps it is loaded with Simplified Chinese Windows 2000. It might have patches that are above and beyond the latest service pack; some of them might have been installed manually or even mis-installed. It is also possible that the remote system is a Linux box running on an Alpha, or that the system is an SMP box, which may affect the way in which the server you are attacking runs. Many of the public Microsoft RPC Locator exploits fail on SMP boxes, or boxes loaded with Xeon processors, which Windows thinks are dual processor boxes. These sorts of issues are very difficult to track remotely.

In addition, when you run heap corruption exploits, you will have problems keeping other people from using the service while you are corrupting the heap. Another common issue with heap overflows is that they overwrite function pointers that are dependent on a particular version of libc. Because each version of Linux has a slightly different libc, this means the exploit must be specific to certain distributions of Linux. Unfortunately, no one distribution of Linux has a majority of the market share, so it is not as easy to hardcode these values into exploits as it is with Windows or commercial Unix boxes.

Keep in mind that many vendors release multiple versions of Unix under the same version number. Your Solaris 8 CD will be different from another Solaris 8 CD, depending on when each was purchased. Your version may have patches that another CD does not, and vice versa.

Shellcode Problems

Some programmers spend weeks writing their shellcodes. Others use packaged shellcodes from Packetstorm ( http://packetstorm.org ). However, no matter how sophisticated your shellcode, it is still a program written in assembly language and executing in an unstable environment. This means that the shellcode itself is often a point of failure.

In your lab, you and your target box are located on the same Ethernet hub. In the wild, however, your target could be on a different continent , under the control of someone who has set up their own network according to their own whims. This may mean that they have set their MTU to 512, that they are blocking ICMP, that they have port-forwarded IIS to their Windows box from their Linux firewall, or that they have egress filtering on their firewall or some other complication.

Let's divide shellcode problems into the following categories.

Network-Related

MTU (Maximum Transmission Unit) or routing issues can be a problem when you run your shellcode. Sometimes you'll attack one IP, and it will call back to you from a different IP or interface. Egress filtering is also a common problem. Your shellcode should close cleanly if it cannot get back to you because of filtering. You may want to include UDP or ICMP callback shellcode.

Privilege-Related

In Windows, a particular thread can be running without the privileges it needs to load ws2_32.dll . The usual solution is to steal the thread you came in on, assume ws2_32.dll is already loaded, or call RevertToSelf() . On some versions of Linux (SELinux, etc.) you may run into the same kind of privilege issues.

In some rare cases, you will not be allowed to make socket connections or listen on a port. In these cases, you may want to modify the original program's execution flow (for example, disable the target process's normal authentication to allow yourself to manipulate it further, modify a file it reads from, add to a userlist, and so on) or find some way for your shellcode to leverage its access without outside contact.

Configuration-Related

Misled OS identification may cause to you put the wrong shellcode or return addresses into the exploit. It's difficult to remotely determine Alpha Linux from SPARC Linux; it may be wise simply to try both.

If your target process is chrooted , /bin/sh might not exist. This is another good reason not to use standard exeve(/bin/sh) shellcode.

Sometimes the stack base will change based on which processor you are attacking. Also, not all instructions are valid on every type of processor. Perhaps your target has an old Alpha chip, for example, and you tested your shellcode only on a new one. Or, perhaps the new SGI machine you are attacking has a large instruction cache that is not cleared during your attack.

Host IDS “Related

chroot, LIDS, SELinux, BSD jail() , gresecurity, Papillion, and other variations on a theme can cause problems for your shellcode at many levels. As these technologies become more popular, expect to deal with them from within your shellcode. The only way to know whether they will affect you is to install them and test them yourself.

Okena and Entercept both hook system calls and do profiling based on which system calls that application is normally seen to do. Two ways to defeat this profiling are to model the application's normal behavior and try to stay somewhat within that, or to try to defeat the system call hooking itself. If you have a kernel exploit, now is your chance to use it directly from your shellcode.

Thread-Related

In heap overflows, another thread may wake up to handle a response, try to call free() or malloc() , and then crash the process when it finds the heap corrupted.

Another thread may be watching your thread to discover whether it completes in time. Because you have taken over your thread, it may kill you off to recover the process. Check for heartbeat threads from your shellcode and try to emulate their signals if possible.

Your exploit may be relying on return addresses that are only valid for one thread, which is usually due to poor testing on your part.



The Shellcoder's Handbook. Discovering and Exploiting Security
Hacking Ubuntu: Serious Hacks Mods and Customizations (ExtremeTech)
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 198
Authors: Neal Krawetz

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net