Penetration Testing of Windows

Penetration Testing of Windows Servers should be started with looking for null sessions via the IPC$ share that permit connections to servers for gleaning user IDs, passwords policies, etc. as well as missing patches and other vulnerabilities in running processes and services that a remote attacker or malicious insider can use.

If you're not sure what purpose a particular Windows server is serving, you can run NetViewX, an executable tool in the public domain, as shown in Figure 1.

Figure 1

The services running are listed between the % signs. You can also search for specific server types such as dial-in, domain controller and others using various command-line options. It's a neat tool -- that I highly recommend -- that'll help you better target your tests.

Remember that there are literally thousands of possible Windows hacks given all the different applications and services that could be running across all versions and patch revisions of your servers. The key is to go for your highest payoff tasks. What's going to give you (or a malicious attacker) the most bang for the buck? It might be a dial-in server or maybe a workstation -- it just depends. Again, use NetViewX if you're unsure what purposes your target systems are serving.

I also believe strongly that you'll never find all vulnerabilities every time you test. That's why it's important to test your systems on a consistent and ongoing basis. You cannot let up.

When it comes to finding and exploiting security vulnerabilities in Windows, you need two things. The first is knowledge of new security vulnerabilities issued via vendors' and researchers' bulletins. You can subscribe to numerous vulnerability lists including Microsoft's own Security Update Alerts as well as the VulnWatch Vulnerability Disclosure List. By knowing that certain Windows server-centric vulnerabilities exist, you'll know what to be on the lookout for.

Second, you need the right security tools to complement the knowledge factor. You cannot depend on them completely, but they do serve an important purpose in testing for vulnerabilities. Speaking of that, one interesting thing I'm finding of late is that many of the highly visible exploits integrated into tools such as Metasploit and CORE IMPACT often are not tested for by various freeware and commercial vulnerability scanners -- at least after the first several days of release. An example of this is the recent Windows Routing and Remote Access remote code execution vulnerability (MS06-025). Currently, it does not show up using several well-known vulnerability scanners but yet can be easily compromised using Metasploit as I'll demonstrate below.

This underscores the fact that up-to-date information is highly-beneficial and not all security tools are going to test for the latest and greatest exploits.

To start testing, you could look for a vulnerability as basic as a Windows null session. Figure 2 shows the results of a basic SuperScan null session scan of a Windows 2000 Server.

Figure 2

Notice that the enumeration was successful -- something that comes as a default "feature" in Windows 2000. Figure 3 shows how Qualys Inc.'s QualysGuard vulnerability scanner can root out missing patches and other issues from a server it knows nothing about otherwise.

Figure 3

Note the various issues with Windows server processes and services such as RPC and the TCP/IP stack -- a couple of which I find very often on even the most "currently patched" servers.

Now that you've found some potential issues (again, this is just the tip of the iceberg), you can run off to patch and harden your systems, but that's no fun if system penetration is your ultimate goal.

Here are a few examples of what you can do with the vulnerabilities I've already mentioned. Often, screen shots such as these help bring things full circle to obtain much-needed attention from upper management.

Figure 4 shows how QualysGuard can exploit a null session vulnerability to glean all user IDs off a system. Talk about getting a leg up on attacking other processes and services!

Figure 4

Now, all an attacker has to do is to run a few brute-force or dictionary password attacks against Windows, Outlook Web Access, SMTP/POP3 email accounts, etc. to discover these account passwords. Heck, you don't even need to spend that much time -- some simple network sniffing using ARP poison routing via Cain and Abel or even some wireless sniffing using CommView for WiFi or WEP/WPA-PSK cracking using Aircrack might be all it takes to glean such information.

Now, let's look at how a malicious insider with a standard user account (i.e., not administrator-equivalent) or an external attacker who has compromised an account can use Metasploit. Both the insider and external attackers can exploit the recent MS06-025 vulnerability. The following figure shows the basic Metasploit commands in preparation of carrying out this exploit.

Figure 5: Metasploit commands.

Once you enter exploit at Metasploit's MSFConsole prompt, boom -- you've now got full command line access to the remote Windows server as shown in Figure 6. Imagine the possibilities -- the server is yours (or the attacker's) at this point.

Figure 6

Other attacks to carry out
Now that you have access to the system, it helps to look at the big picture to see what else can be exploited. You can perform other attacks to further demonstrate that a security problem exists. Other attacks include:

• Rooting out other non-Windows processes, services and applications that may have been installed on top of the OS -- such as Firefox, Apache, various media players, backup software and more. They can be just as vulnerable and create just as many holes in the system as any Microsoft code
• Using the Windows regedit tool's Connect Network Registry feature to connect and edit the server's Registry
• Enumerating all running processes on the remote server using PsList to see what else can be gleaned, captured or otherwise exploited
• Using a hex editor such as WinHex to analyze running processes and glean passwords and other sensitive information currently stored in memory
• Performing DNS zone transfers using nslookup (via the ls --d domain_name command) or Sam Spade for Windows

Keep in mind that there are tons of variables involved here, so you may or may not be able to successfully execute these tests -- depending on your Windows versions, patches applied, system configuration, and so on. I'll bet, though, that if you look long enough and hard enough though, you'll hit pay dirt.