Windows Scripting for Security

Windows scripting is a very powerful security (and administration) tool. It strikes me, however, that not many system administrators or security experts realize its potential.

This article tries to illustrate that potential with a sample script I wrote to obtain the list of wireless card drivers installed and their versions, from a local or remote Windows system. The script can be found here. (Note: The script has been renamed to .txt to make it harder to execute it inadvertedly. You'll have to rename it back to .vbs to run it).

In the Unix world it is just common standard knowledge that if you are going to perform a task more than once or twice you may want to write a simple script (e.g. a bash or perl script) to do it for you. This way you will be able to repeat the task effortlessly as many times as it is necessary, in as many systems as needed, and at any time it is required (just schedule the script to run with cron).

In Windows environments, by contrast, I find most people normally use GUI tools, only some people use their command-line equivalents from time to time, and almost no one will even consider the possibility of writing a script to perform a particular task if there is no tool available to do it. They will rather say "it can't be done".

In the old days it was true that we only had .BAT files for scripting and very few managament tools had a command line version so trying to solve a problem by writing a script was probably not the way to go. Today, however, we have Windows Script Host (WSH) included in all modern versions of Windows. WSH provides an interface to almost every object in the system and exposes it to several scripting languages like Visual Basic Script (included in Windows), perl and others. With WSH, scripts can interact very easily with entities as complex as the registry, or Active Directory, or the file system and perform very advanced tasks.

I'll give you an example. You may have heard of the vulnerabilities that were discovered on many wireless card drivers a few months ago. Most vendors, if not all, issued patches for their drivers. Now, let's say you read on a web page the versions of the vulnerable drivers. How can you know which version you have installed on your system(s)?

One way would be going to control panel > system > hardware > device manager > select wireless card > right click > properties > driver > details; then take note of the version number and repeat for each wireless card on the system. However, there are two problems with this approach: one, not all wireless cards configured in the system are shown in Device Manager by default (only those currently connected); and two, it doesn't scale. Or would you repeat this process on 100 systems? And what if those systems were remote?

A different approach would be writing a script to check this information for you. Actually, it was pretty easy to write such script: all the required information (number and type of wireless cards installed on the system, their drivers and their drivers' versions) is in the registry and the registry can be accessed from visual basic scripts through WMI (Windows Management Instrumentation) with a simple call to GetObject().

I will not go into the details of the source code of the script because it would make this post too long and I'm not sure it would be interesting for everyone. Instead, I'll show you an example of usage:

C:\tmp>cscript /nologo WMIGetWirelessDriversVersion.vbs localhost

I use cscript.exe because the default WSH executable to kick in, if I didn't explicity specify cscript.exe, would be wscript.exe, which would show the text messages in popup windows instead of a in a text console, which would be annoying (you can try, though, there is no
harm).

The output should look similar to this:

================
Found wireless card at:
HKLM\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{7C1F7564-C990-420E-A4D6-F54092764DF9}\Connection
Name: Wireless Connection 1

Found corresponding driver data at:
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\0011
NetCfgInstanceId: {7C1F7564-C990-420E-A4D6-F54092764DF9}
DriverDesc: Intel(R) PRO/Wireless 2200BG Network Connection
DriverVersion: 9.0.3.9
Service: w29n51
ImagePath: system32\DRIVERS\w29n51.sys
================

Instead of localhost you can specify the name or IP address of a remote system. The only requisites are that your current user must have administrative access to the target system and that RPC communication must be allowed between the systems.

Now suppose you manage a Windows OU (organizational unit), domain or a whole forest and you want all systems under your control checked. Could you schedule it to run automatically and collect the results, all from a central location? Oh, yes! That's what Active Directory, Group Policy and network shares are for (among other things), but that's another story.

David.

<plug>
I will be teaching "SEC505: Securing Windows" at SANS Prague 2007 (Feb. 12-17). If you want to discover how a Windows network can be made really really secure (for those of you chuckling... Yes, it can!) come and join me there!
</plug>

PS: Thanks to Joshua Wright, for an interesting challenge, an to Jason Fossen, for sharing his knowledge (he is the author of "SEC505: Securing Windows") and his scripts.

PS: The code in the script is not optimized in any way and it does not do proper error checking. Please don't flame me for that. Instead, feel free to improve it and send me a copy back ;-).

<stats>
The smiley (image) at the end of this sentence has been included to track statistics about this Blog/post. Believe us, it is not a WMF exploit!
</stats>

Auditing Wireless Networks from Windows using VMware and BackTrack 2.0

One of the major constraints to Windows-based wireless network auditing is the lack of open-source wireless security tools and advanced wireless drivers for this OS; however, this is not the case with Linux.

Although in other security fields, this limitation can be easily avoided by running Linux inside a VMware (or other virtual) environment executing on Windows, when talking about wireless technologies, this is a problem because VMware doesn't provide PCMCIA native support yet. A PCMCIA wireless card is mapped in VMware as a standard PCnet-II Ethernet wired card. This means that you cannot manage the wireless card settings, and even worst, configure it in monitor mode or enable its traffic injection capabilities.

Fortunately, here is the VMware USB native support to the rescue!! You can buy a USB wireless dongle, such as the Conceptronic C54RU (available for around 20€), and get access to all wireless features from inside the virtual machine.

The main Live CD Linux-based distribution for wireless testing nowadays is BackTrack v2.0 Public Beta. Unfortunately, it doesn't provide support for the Ralink RT73 chipset that lives inside the C54RU v2. You can check if your C54RU has the RT73 chipset by running the following command:

# lsusb
Bus 001 Device 002: ID 14b2:3c22

If it finishes in "22", it is v2, thus chipset RT73. If it finishes in "02", it is v1, thus chipset Ralink RT2570. BackTrack v2.0 provides support for the RT2570 chipset by default through the rt2500 driver. BTW, other wireless Live CD distributions, such as Wifislax (Spanish), provide support for the Ralink RT73 by default.

How to setup the Ralink RT73 driver (Conceptronic C54RU v2) in BackTrack v2.0?

Step 1. Download the latest RT73 driver source code from http://rt2x00.serialmonkey.com/rt73-cvs-daily.tar.gz.

Step 2. Download and review this basic setup.sh script.

Step 3. Copy both files, the shell script and the tar.gz, to the same directory.

Step 4. Turn on the setup.sh script read and execute permissions (chmod 500 setup.sh).

Step 5. Run ./setup.sh (as root).

Once the script finishes, you can configure your C54RU in monitor mode:

# iwconfig rausb0 mode monitor

And, enable the C54RU injection mode (in monitor mode):

# iwpriv rausb0 rfmontx 1

<plug> Interested in advanced wireless security training? I will be teaching SANS SEC617, Assessing and Securing Wireless Networks, in Prague on February, 12-17. Updated to BackTrack v2.0!! </plug>

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:

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"
SULLY   File 1   KB914388
SULLY   Security Update for Windows XP (KB914388)   Update   KB914388
SYSTEM       7/31/2006          SP3
C:\>

To test the patch installation remotely, you can use the following command just changing the "/node:" argument to check all your Windows boxes :

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"
TCP    0.0.0.0:17503            0.0.0.0:0              LISTENING       1493

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.

1.5) [Optional] Get basic information about the process (binary name, options...):

C:\> wmic process where processid=1493 get processid, name, commandline
CommandLine   Name    ProcessId
nc -l -p 17503  nc.exe  1493

2) Map the process to the service:
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>

The Beauty and the Beast

The Chaos Computer Club (CCC) is a very well known European hacker team. And their last congress, that took place last December in Berlin, has provided us with a lot of interesting material that is worth viewing.

The paper that attracted me the most was one about AJAX, that could be previously found here (this one doesn't work now) and it is still available from here. The name of the paper was Subverting AJAX and is written by Stefano di Paola and Giorgio Fedon. They talk about a very powerful technique to attack an AJAX application that they call XSS Prototype Hijacking. Believe me, there is beauty in this attack.

Prototype Hijacking consists in overwriting the methods of the XMLHttpRequest object, that is the one that takes care of the asynchronous communications with the server, actually intercepting the calls to those methods and, thus, being able to do things such as reading all the private information before it is encrypted by the TLS layer or replacing the information that is send. This is new but the results are similar to the DLL injection: the attacker becomes a dangerous beast.

In order to overwrite the methods, they use Cross-Site Scripting (XSS) and even explain some advanced techniques to do so. The basic idea is quite simple though: you force the application to run the code that is needed to overwrite the methods.

This is quite powerful, let me give you a couple of examples where this attack could be used:

• A webmail application that doesn't control the contents of each mail to filter out XSS attacks. With the overwritten methods every communication with server can be eavesdropped (that means having access to every mail received or sent).
  
• An Internet shop, preferably one that allows its users to review the products. Payment information can be intercepted and used on line.

My recommendation: try this and keep it in your pentest toolbox.

Wireless Forensics - Tapping the Air

My new two-part SecurityFocus article called "Wireless Forensics - Tapping the Air" has been published today. Part I is already available and part II will be most probably next week.

Wireless is one my preferred security fields, as being the SANS instructor for the wireless security course in Europe denotes. I was doing some Wi-Fi research around September 2006 and I found by chance the WLAN-14 device from Aircapture. I was very interested on getting more details about it (and the idea of being able to capture ALL the 14 802.11b/g channels simultaneously), and finally, I had the opportunity of playing with it after its first product launch in Europe, Madrid. Although the current version is not very portable (4U rack server), I had lot of fun installing it on my car and testing its capabilities.


What I figured out at that point was the lack of security literature covering wireless forensics, so I decided to research and get more involved on it, and as a result, the article was born. It focuses on the technical issues and challenges associated with collecting and analyzing wireless network traffic for forensic purposes.

Please, do not hesitate to let me know your comments (and experiences) about the wireless forensics security field and, specifically, about the article itself. Thanks!