We take a brief detour here to discuss the happy eventuality that no easily guessed pass- words are found on the target systems. Attackers have few options at this point. One is lo- cating some inherent flaw within the NT architecture that can be exploited remotely to gain access. The other is the last refuge of the defeated attacker, denial of service (DoS).
] Remote Buffer Overflows
Popularity: 3 Simplicity: 2
Impact: 10
Risk Rating: 5
The existence of numerous secret holes that grant Administrator status on a remote system is a persistent myth about NT. Only a few such conditions have been revealed to date, and all of them exploited flaws in application programs, not NT itself. It’s debatable whether this is due to NT’s relative immaturity or solid design on the part of Microsoft.
The most dreaded types of these flaws are buffer overflows.We talk in detail about buffer overflows in Chapter 14, but for the purposes of this discussion, buffer overflows occur when programs do not adequately check input for appropriate length. Thus, any unexpected input “overflows” onto another portion of the CPU execution stack. If this in- put is chosen judiciously by a rogue programmer, it can be used to launch code of the pro- grammer’s choice. One of the defining papers on buffer overflows is Aleph One’s
“Smashing the stack for fun and profit” in Phrack 49 (http://phrack.infonexus.com/
archive.html). Several Win32-oriented buffer overflow papers include Dildog’s “Tao of
Windows Buffer Overflow” at http://www.cultdeadcow.com/cDc_files/cDc-351, Barnaby Jack’s “Win32 Buffer Overflows” in Phrack 55, and papers by members of Cer- berus Information Security (CIS) at http://www.cerberus-infosec.co.uk/papers.shtml.
Buffer overflows can be roughly segregated into two classes: remote and local. Local overflows require console access to exploit and are typically only available to interac- tively logged-on users. Remote buffer overflows are much more dangerous; these can be exploited with zero privilege on the target system from any node on the network. Exploi- tation of a remote buffer overflow will typically detonate a “payload” (the code forced into the CPU’s execution pipeline) that can perform just about anything the attacker de- sires. Some examples are shown in Table 5-3, which lists some of the more famous pub- lished buffer overflows in NT or other Microsoft products.
In theory, the size and complexity of the code that comprises Windows NT should produce many such conditions for malicious hackers to exploit. However, between the publication of the first and second editions of this book, as demonstrated by Table 5-3, few if anyremotebuffer overflow exploits in the NT/2000 operating system itself have been publicly announced. Table 5-3 does indicate that Windows-based services (IIS) and
Exploit URL Damage Caused
Netmeeting 2.x,by Cult of the Dead Cow (cDc)
http://www.cultdeadcow.com/
cDc_files/cDc-351
Proof-of-concept that downloaded harmless graphic from cDc web site
NT RAS, by Cerberus Information Security (CIS)
http://www.infowar.co.uk/
mnemonix/ntbufferoverruns.htm
Opens a command prompt with System privileges
winhlp32, by CIS http://www.infowar.co.uk/
mnemonix/ntbufferoverruns.htm
Runs a batch file with System privileges IISHack by eEye http://www.eeye.com Executes arbitrary
code on an NT IIS web server
Oracle Web Listener 4.0, by CIS
http://www.cerberus-infosec.co.uk/
advowl.html
Remote command execution with System privileges
Outlook GMT token overrun by Underground Security Systems Research (USSR)
http://www.ussrback.com/
labs50.html
Execution of arbitrary code upon parsing of email message
Table 5-3. Selected Published Windows Buffer Overflow Exploits
applications (Outlook) may be following a different trend, however. As clearly demon- strated by the growing body of research into Win32 buffer overflows, this precedent for resistance to such attacks may end at any time, however.
U Remote Buffer Overflow Countermeasure
The best short-term answer to buffer overruns is good coding practices. The papers cited earlier should give the experienced programmer some idea of what to avoid when writ- ing applications (some knowledge of C and low-level assembly language will help with the reading). Since coding of products like Windows is largely out of the hands of users, the vendor must play a critical role in addressing these problems as they are identified.
Various products are available to address buffer overflows. One of the more recent NT-oriented tools is BOWall by Andrey Kolishak, available with full source code at http://developer.nizhny.ru/bo/eng/BOWall/. BOWall protects against buffer over- flows in two ways:
▼ Replaces DLLs with binary copies that include routines to monitor calls to potentially vulnerable DLL functions (for example, strcpy, wstrcpy, strncpy, wstrncpy, strcat, wcscat, strncat, wstrncat, memcpy, memmove, sprintf, swprintf, scanf, wscanf, gets, getws, fgets, fgetws). These calls are then checked for the integrity of the stack return address.
▲ Restricts execution of dynamic library functions from data and stack memory.
Replacing system DLLs is an intrusive approach to preventing buffer overflows, but intriguing nonetheless.
eNTercept from ClickNet Software Corp. (http://www.clicknet.com) is a signa- ture-based intrusion prevention application that wraps the NT kernel and monitors all calls. It is thus well situated to recognize and preventknownbuffer overflow attacks.
Immunix.org’s StackGuard (http://immunix.org/) takes the compiler approach to blocking buffer overflow attacks. It is an enhancement to the GNU C Compiler (gcc) that produces binary executables that are more resistant to stack smashing than normal pro- grams. It does this by placing a token (called acanary word) next to the return address when a function is called. If the canary word has been altered when the function returns, then a buffer overflow attack has been attempted. The StackGuard-compiled program re- sponds by emitting an intruder alert to syslog, and then halts. Since it uses the gcc com- piler, it’s not applicable to NT, but maybe someone will get inspired after reading this…
In the long run, fundamental changes to programming models (for example, Java, which lacks many of the internal structures leveraged in buffer overflow attacks) or CPU architectures themselves will be required to stomp out such problems.
] Denial of Service (DoS)
Popularity: 6 Simplicity: 7
Impact: 5
Risk Rating: 6
DoS attacks became extremely popular in 1997–1998 with the release of many mal- formed packet exploits that blew up TCP/IP stacks on various platforms. Other attacks were Windows specific. We don’t want to spend a lot of time here talking about these vul- nerabilities, because they have all been patched and we have dedicated an entire chapter to discussing DoS (see Chapter 11, as well as the discussion of Win 9xDoS fixes in Chapter 4).
Denial of service isn’t always just an annoyance—it can be used as a tool to force a sys- tem reboot when certain booby traps have been set to run upon restart. As we’ll see later, stashing code into the various NT startup nooks and crannies is an effective way of re- motely exploiting a system.
U NT DoS Countermeasures
Application of the latest Service Pack (6a at this writing) should defend NT against most known denial of service (DoS) attacks. Also keep up with post-SP hotfixes, especially those that affect NT/2000’s TCP/IP stack,tcpip.sys(and of course, upgrading to Win 2000 does the same). Most of the serious TCP/IP DoS attacks likeland,newtear, and OOB were dealt with ages ago by post-SP3 patches. Of course, upgrading to Win 2000 is the ultimate service pack and encompasses all of these fixes.
For more information on Registry settings that will help protect Windows-based Internet servers against common DoS attacks, see the discussion of DoS in Chapter 6.
We also recommend investigating the many perimeter security products that have the ability to recognize and blunt common TCP/IP DoS attacks like teardrop, land, OOB, SYN flooding, and so on. See Chapter 12 for more information about these.
Non-IP DoS attacks, includingsnorkandnrpc, were also fixed post-SP3 (these two require access to ports 135–139 to work).
OK, the detour is over. Let’s get back to our methodical climb to Administrator status.