Windows Command-Line Kung Fu (3): solutions
Please, find below the official solutions for the two RaDaJo WMIC challenges published at the end of 2006. Sorry but there are no winners because we didn't get any response at all :-( We will offer prizes next time! ;-)
Answer to Challenge 1:
First of all, you need to identify what was the flaw the challenge question referred to. You can use the NIST NVD advanced search capabilities querying by "DHCP" in July 2006. There is only one high severity match ;-)
This very critical DHCP flaw (CVE-2006-2372) was announced in the MS06-036 security bulletin on July 11, 2006, affecting all MS main OS; 2000, XP and 2003. An attacker could exploit this buffer overflow vulnerability by sending properly crafted DHCP responses to client's DHCP requests, and remotely execute code, 0wn1ng the client. The original report was found by CybSec and public exploit(s) are available. It specially affects clients with networking capabilities on untrusted environments (for this to work you do not require to have and IP address, yet) , such as WiFi hotspots. How long we need to wait to see this exploit within a Karma module? It is time to design layer-2 (wired and wireless) firewalls!
The simplest solution is to patch. The patch update required to fix this vulnerability is KB914388. Therefore, in order to find exposed system you can run the following WMIC local command:
Besides, there is a more effective way of running WMIC commands remotely. Using the WMIC built-in filtering capabilities you can reduce the amount of network traffic generated by the command above, because the filter is applied on the remote WMI agent:
Answer to Challenge 2:
The only info the incident handler has is the destination port number captured by the sniffer or NIDS. The goal is to find the service binded to it, following a 2-step process:
1) Check if TCP port 17503 is active and find the process associated to it:
1.5) [Optional] Get basic information about the process (binary name, options...):
There are two main ways of doing this, using the process ID (PID) or the process name. The former is more accurate (unique PID), and the later helps to identify all the services using the same binary.
- By process ID:
Although the challenges suggested to use WMIC only, it is a very good incident handling practice to double check the status of a system using multiple tools, specially when dealing with advanced malware, such as rootkits. Out of WMIC, step 2 can be accomplished in a more effective way running:
How do attackers can create a backdoor netcat service in Windows? They can use the Instrsrv.exe and Srvany.exe tools from the Windows Resource Kit or do it through the built-in sc tool.
<plug> Interested in advanced incident handling training? I will be teaching SANS SEC504, Hacker Techniques, Exploits & Incident Handling, in Dubai next March, 10-15.</plug>
Answer to Challenge 1:
First of all, you need to identify what was the flaw the challenge question referred to. You can use the NIST NVD advanced search capabilities querying by "DHCP" in July 2006. There is only one high severity match ;-)
This very critical DHCP flaw (CVE-2006-2372) was announced in the MS06-036 security bulletin on July 11, 2006, affecting all MS main OS; 2000, XP and 2003. An attacker could exploit this buffer overflow vulnerability by sending properly crafted DHCP responses to client's DHCP requests, and remotely execute code, 0wn1ng the client. The original report was found by CybSec and public exploit(s) are available. It specially affects clients with networking capabilities on untrusted environments (for this to work you do not require to have and IP address, yet) , such as WiFi hotspots. How long we need to wait to see this exploit within a Karma module? It is time to design layer-2 (wired and wireless) firewalls!
The simplest solution is to patch. The patch update required to fix this vulnerability is KB914388. Therefore, in order to find exposed system you can run the following WMIC local command:
C:\> wmic qfe | find "KB914388"If the system is vulnerable, you will get no response. If the patch had been installed you should get a similar response to the following one (local execution in "SULLY" hostname):
C:\>wmic qfe | find "KB914388"To test the patch installation remotely, you can use the following command just changing the "/node:" argument to check all your Windows boxes :
SULLY File 1 KB914388
SULLY Security Update for Windows XP (KB914388) Update KB914388
SYSTEM 7/31/2006 SP3
C:\>
C:\> wmic /user:Administrator /password:SECRET /node:10.10.10.10 qfe | find "KB914388"What about the password in the WMIC command? It belongs to the (local or domain) administrator and it'll be recorded by any command-line history tool. Oh my! Consider this risk in your IH processes! From the network perspective, you need to worry about it as much as you do with other standard Windows NetBIOS/RPC protocols, WMIC traffic uses them.
Besides, there is a more effective way of running WMIC commands remotely. Using the WMIC built-in filtering capabilities you can reduce the amount of network traffic generated by the command above, because the filter is applied on the remote WMI agent:
C:\>wmic qfe where HotFixID="KB914388"
Caption CSName Description FixComments HotFixID
InstallDate InstalledBy InstalledOn Name ServicePackInEffect Status
SULLY Security Update for Windows XP (KB914388) Update KB914388
SYSTEM 7/31/2006 SP3
C:\>
Answer to Challenge 2:
The only info the incident handler has is the destination port number captured by the sniffer or NIDS. The goal is to find the service binded to it, following a 2-step process:
1) Check if TCP port 17503 is active and find the process associated to it:
C:\> netstat -nao | find "17503"It seems there is no way to get network connections information using WMIC. For this task, netstat is the tool. If you know some VMIC tips and tricks for this, please, let me know. This can be one of the reasons why there is no "lsof -i" Linux-based functionality in Windows.
TCP 0.0.0.0:17503 0.0.0.0:0 LISTENING 1493
1.5) [Optional] Get basic information about the process (binary name, options...):
C:\> wmic process where processid=1493 get processid, name, commandline2) Map the process to the service:
CommandLine Name ProcessId
nc -l -p 17503 nc.exe 1493
There are two main ways of doing this, using the process ID (PID) or the process name. The former is more accurate (unique PID), and the later helps to identify all the services using the same binary.
- By process ID:
C:\> wmic service where processid=1493 get name, pathname, processid- By process name:
C:\> wmic service where (PathName like "%nc%") get name, pathname, processid
Although the challenges suggested to use WMIC only, it is a very good incident handling practice to double check the status of a system using multiple tools, specially when dealing with advanced malware, such as rootkits. Out of WMIC, step 2 can be accomplished in a more effective way running:
C:\> tasklist /svc | find "1493"
nc.exe 1493 Backdoor Service
How do attackers can create a backdoor netcat service in Windows? They can use the Instrsrv.exe and Srvany.exe tools from the Windows Resource Kit or do it through the built-in sc tool.
<plug> Interested in advanced incident handling training? I will be teaching SANS SEC504, Hacker Techniques, Exploits & Incident Handling, in Dubai next March, 10-15.</plug>
Labels: Incident Handling
posted by Raul Siles at 11:44 AM
0 Comments:
Post a Comment
<< Home