Hackers Beware

the program, your system might become unstable or possibly lock up. After rebooting the system, you will see that the non-administrative user now belongs to the Administrators group. This means that the user has complete administrative control over that machine. For instance, the user will now be able to run programs, such as windisk, create new users, delete existing users, install drivers, and even format hard disks.

Running SecHole

SecHole is a DOS-based program and, therefore, must be run from a DOS window. Because of this, there is not a Graphical User Interface (GUI) window to use. Type the name of the program and when it is done, you are returned to a DOS prompt. On most systems, you get an error message when the program is run. In this case, I received an “Unexpected Failure in Debug Active Process” error, which is shown in Figure 12.1. It is recommended that you reboot the system when you receive an error such as this. These errors can cause the OS to become unstable. The following is the output from running the SecHole program and the corresponding error messages:

Figure 12.1. Error message received when running the SecHole exploit.

C:\sechole>sechole

C:\sechole>

Expanding SecHole

SecHole takes advantage of a generic weakness in NT and, therefore, can be expanded to create additional exploits by replacing the NT DLLs, which cause the program to have different functionality. The functionality can be whatever the attacker thinks of. It can upgrade a user’s access, like it does with SecHole, or it can create a backdoor on the system. The following are the main areas where it can be expanded:

•It can attach to a service other than the local system.

•It can replace the dll.

•It can obtain a domain user password.

•It can invoke through a Web page.

The SecHole exploit is local in scope, unless there is a service running on the system, which is running under a domain account. If it can attach to a service running under a context other than the local system, the code can

be executed as that user. It is fairly easy to replace the DLL, which comes with the exploit, and cause it to take other actions. However, if the lsa2fix is not applied, the local user, who has just become the local administrator, can obtain the password of the domain user for the service and obtain the rights of the domain user. The lsa2-fix makes this more difficult (but not impossible).

Another area where SecHole can be used to cause problems is if ordinary users are allowed to place HTML content directly onto the web server. The #exec directive causes an HTML page to execute a command and direct the output to the client; #exec is enabled by default in IIS 4.0. If a user were to place SecHole.exe, the DLL, and a web page (which invokes SecHole onto a web server), then the IUSR_Machine account would become administrative. I would recommend disabling #exec for any web site directories where non-administrative users are allowed to place files.

Additional Information

The following sites contain additional information on the SecHole exploit:

•http://www.microsoft.com/security

•http://www.microsoft.com/ntserver/security/default.asp

•http://www.infowar.co.uk/mnemonix/utils.htm

•http://www.ntshop.net

•http://www.ntsecurity.net

Red Button

Red Button was created to exploit the vulnerability of having the default settings of the Windows NT Everyone Group on a system. Red Button works against Windows NT version 3.5x and 4.0. Red Button works by remotely logging onto the target machine, without authentication, and using NetBIOS ports 137, 138, and 139. By default, Windows NT grants the Everyone Group full control. The Everyone Group includes, literally, every user of a Windows NT machine, including Internet users. After Red Button has compromised a system, it provides the attacker with the name of the administrator account and a list of all shares on the target machine.

Exploit Details

•Name: Red Button

•Operating System: Microsoft NT Server

Running Red Button

After Red Button has been installed on the target machine, the attacker launches the application from the Windows NT Start button. Under Programs, the Administrator Assistant menu option is available. By

selecting the Administrator Assistant, the Red Button application can be launched. Red Button provides a simple to use GUI. This GUI allows the attacker to select the target of the attack by hostname. After the target machine is identified, the attacker simply presses the GO button to launch the attack. After Red Button compromises the system, it displays system information, such as the name of the administrator account and a list of shares. The administrator account is displayed even if it has been renamed.

Figure 12.2 is a screen shot of the initial interface that Red Button presents to the attacker.

Figure 12.2. Initial screen displayed when the Red Button program is started.

To begin the attack, the user clicks the Select Server button to the right of the big, red GO button. After clicking the Select Server button, the Select Server dialog box is displayed. To select the target machine for the attack, the attacker simply types the target machine’s hostname, and clicks OK, as shown in Figure 12.3.

Figure 12.3. Selecting a Target to Attack with the Red Button Exploit.

After selecting the target of the attack, the attacker clicks the large, red GO button to compromise the target machine.

The screen shown in Figure 12.4 is temporarily displayed while Red Button is compromising the system. This screen only appears for a moment, and then the information screen is displayed.

Figure 12.4. The screen displayed while Red Button is trying to compromise the machine.

Figure 12.5 shows the information screen Red Button displays after a successful attack, which consists of the information it was able to obtain. This screen shows the name of the administrator account, even if you rename the administrator account. In addition, this screen lists all shares on the target machine. Red Button only displays information—an attacker cannot actually interact with the compromised machine—he can only gather information on the target machine.

Figure 12.5. Shows the results displayed after Red Button is successful.

Signature

There are really no signatures that will alert someone of a Red Button attack. The target machine does not have any noticeable degradation of performance or other signs of the attack. A network administrator may be

able to detect Red Button using UDP ports 137 and 138, as well as TCP 139. However, this could be interpreted as regular remote access traffic, so it would not raise the attention of the network administrator.

Protecting Against Red Button

There are several ways to stop Red Button. You could deny access to UDP ports 137 and 138, and TCP port 139 at the router or firewall. These are the NetBIOS ports, so this may not be practical for organizations that have a requirement for remote users. Microsoft has released a hotfix for Red Button, and by installing this hotfix, you can eliminate the Red Button exploit. If a machine does not require a network connection, unbind the NetBIOS and TCP/IP protocols. Another technique is to disable the Server service on machines that do not provide file or print services. Finally, tightly control the access privileges granted to the Everyone Group.

RDS Security Hole in Microsoft IIS

RDS is a vulnerability that is used to exploit IIS (Internet Information Server), which is Microsoft’s web server. This exploit uses IIS to take advantage of a vulnerability in Microsoft Data Access Components to remotely execute arbitrary commands on the target without user validation.

Exploit Details

•Name: Microsoft IIS RDS Vulnerability

•CVE Number: CVE-1999-1011

•Variants: msadc.pl version 2

•Platforms Affected: Systems that have Microsoft Internet Information Server (IIS) 3.0 or 4.0 and Microsoft Data Access Components (MDAC) 1.5, 2.0 and 2.1.

•Protocols/Services: HTTP

•Written by: Charles Pham and Rick Thompson

The Microsoft IIS RDS Vulnerability exploit takes advantage of the security flaw in the following software:

•The Remote Data Service (RDS) DataFactory object, a component of MDAC. When installed on a system running IIS 3.0 or 4.0, it enables implicit remote access to data by default. As a result, an unauthorized Internet client is allowed access to OLE DB data sources available to the server.

•Microsoft JET 3.5 OLE DB provider enables calls to Visual Basic for Applications (VBA)’s shell() function to run shell commands.

Protocol Description

RDS enables end-users to bring one or more disconnected ActiveX Data Object (ADO) record sets from a remote server to a client computer using the HTTP, HTTPS, or DCOM protocols. However, we will focus on HTTP because this is the protocol used for this exploit.

In order for RDS to work properly, it must have the following key components installed:

•On the client, RDS DataControl and RDS DataSpace are installed when you install Microsoft Internet Explorer 4.0 and higher.

•On the server, RDS DataFactory, Custom Business Objects, and ASP web pages are installed as part of the NT 4 Option Pack, or through the MDAC redistribution file MDAC_TYP.EXE or base Windows 2000 Server.

•Microsoft Jet Database Engine, a required component for database access to data stored in an Access back-end database (.mdb), is installed when you install MDAC.

Description of Variants

Currently, there is one known variant of this exploit, and that is msadc2.pl. This is an updated version of the original msadc1.pl script to work on Windows95 and UNC, and it has various other enhancements. However, it is possible that there are other variants, which may include modifications to identifying characteristics of the original script that were made to avoid detection. These modifications may include, but are not limited to, the following techniques:

•Using HEAD or POST request rather than GET request to /msadc/msadcs.dll

•Hex-encoding the URL calls

•Removing script dependency on ‘cmd /c’ or ‘command /c’

•Changing the default MIME separator string of ‘!ADM!ROX!YOUR!WORLD!’

•Creating a randomly named table within the .MDB instead of the default name of ‘AZZ’

How the Exploit Works

Upon execution, the msadc1.pl script sends a raw GET request to /msdac/msadcs.dll through HTTP/1.0 on the victim’s web server. If this file does not exist, the script prints the following message and exits:

Looks like msadcs.dll doesn't exist

However, if the file exists, the script asks the user which command to run. By default, the script pre-appends ‘cmd /c’ to the command. This default setting can be easily changed within the script.

After the user types the command, the script proceeds to search for the existence of the btcustmr.mdb database using a set combination to locate the correct drive and directory. If this is successful, the script saves the true path to a file named rds.save on the local computer and proceeds with creating a new DSN through /scripts/tools/newdsn.exe. By default, the DNS name of “wicca” is attempted and, if successful, this is the name used to create the table. If it is not successful, the script processes a list of default DSN names in hope of creating a table. In addition, the user has the option of using her customized dictionary of DSN names by using the –e switch during runtime. Once successful, the script creates a table named AZZ within the .mdb file. This has changed with version 2 of the script.

Next, the script tries to make a query to the RDS DataFactory (also known as AdvancedDatafactory) with the shell() function encapsulated and posted through HTTP. The user command is encapsulated within the shell() function. If successful, it saves the DSN name to the rds.save file on the local computer and exits.

The last logical step is an attempt at guessing the existence of a .mdb file based on a list of known system and program .mdb files hard-coded in the script. The process of creating table entry AZZ is again attempted along with the shell() function encapsulated in the query to the RDS DataFactory using guessed .mdb filenames. Again, the user command is encapsulated within the shell() function. If the result is successful, it saves the name and location of the .mdb.

The query packet to the RDS DataFactory object can be thought of as the following:

Query ( | shell ( unauthorized user's command ) | )

The actual exploit is the query to the RDS DataFactory object where the two flaws actually work together hand-in-hand and allow the injection of privileged commands by an unauthorized user. The first flaw is with the line of defense at the RDS DataFactory because the query should not have been allowed without proper authentication. The second flaw is with the Jet database engine to properly evaluate the content enclosed within the pipe or vertical bar character. Once again, a lack of error checking leaves the door open for a system to be compromised.

Subsequent user commands will go through the same process, however, execution will be quicker because the content of rds.save is used to bypass the brute force attempt of guessing either the DSN or location of a

.mdb file.

Failing in both attempts, the script exits with the following message:

Sorry Charley…maybe next time?

How to Use It?

The script can be run under any system with a Perl interpreter installed. Script execution can be as simple as the following:

perl msadc2.pl –h www.victim.com

msadc2.pl is the name of the script and -h specifies the host to attack. This can be the fully-qualified hostname or an IP address.

If our hypothetical site www.victim.com is vulnerable to a Microsoft IIS RDS Vulnerability attack, the script will print the following:

Please type the NT command line you want to run (cmd /c assumed) : \n

cmd /c

At this point, if defacing the web site is the cracker’s objective, he can execute:

echo some message > C:\Inetpub\wwwroot\index.html

This replaces the existing start page for the web server with “some message.” Of course, this only works if this is a default web server installation. Otherwise, more sophisticated methods must be used to overwrite the web site start page. Please note that a brute force attempt is always an option—trying every possible option until you are successful.

If the cracker’s intent is malicious, he could always format the drive using the format command.

Signature of the Attack

Detection of this attack by someone using the original scripts by RFP can be done with the following methods:

•Intercepting HEAD, POST, or GET request to ‘/msadc/msadcs.dll’ without any parameters.

•Scanning for a query string containing ‘cmd /c’ or ‘command /c’.

•Scanning for a query string to ‘/msadc/msadcs.dll/VbBusObj.VbBusObjCls.GetRecordset’

•Scanning for a query string to ‘/msadc/msadcs.dll/VbBusObj.VbBusObjCls.GetMachineName’

•Scanning for a query string containing ‘AZZ’

•Scanning for a MIME separator string of ‘!ADM!ROX!YOUR!WORLD!’

It is possible to scan for other strings contained within the script as an alternative detection mechanism. However, this would only be necessary if the installation of the operating system and software are not in the regular standard drives or directories.

Note that it is quite possible for a knowledgeable user to modify the script to the point where standard detection mechanisms are no longer effective.

How to Protect Against It

The best way to protect against this exploit is to upgrade to a patched version of the following software:

1.Upgrade from MDAC 1.5 to 2.1.2.4202.3

This upgrades the Jet engine 3.5 to 4.0 SP3, which is not vulnerable to the VBA shell() exploit. In addition, you will need to set the Customer Handler Registry key to a value of 1 to address the RDS exploitation.

2.Install Jet35sp3.exe (MS99-030) and remove RDS support.

Jet35sp3.exe is a modified Jet 3.5 SP3 engine with the ability to prevent exploitation through the VBA shell() exploitation.

In both upgrades, the VBA shell() function exploit was addressed through a Sandbox mode for non-Access applications. Setting the following Registry key also eliminates the exploit:

\\HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\engines\Sandbo xMode

Set it with a value of either:

•2—Sandbox mode is used for non-Access applications, but not for Access Applications. (This is the default value.)

•3—Sandbox mode is used at all times.

Note: The permission for this key should be changed from ‘Authenticated users’ to ‘Read Only.’

Another way to protect against this vulnerability is to remove RDS support, which can be done by performing the following steps:

1.Remove /msadc virtual directory mapping from IIS. To do this, open the Internet Service Manager and:

1.Click ‘Internet Information Server’.

2.Select the system.

3.Select ‘Default Web Site’.

4.Select ‘msadc’.

5.Click ‘Delete’ and confirm.

2.Remove the following Registry key:

3.

4.\\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W 3SVC\

Paramenters\ADCLaunch

5.Delete all files and subdirectories in: C:\Program Files\Common Files\System\Msadc

Note: Replace the C: drive with the drive where the files were installed.

Source Code/Pseudo Code

The exploit code works basically as follows:

1.Contacts target through HTTP

2.Ensures that target is running IIS and MDAC

3.Tries to query (with embedded command) using btcustmr.mdb:

1.Formats a database query with the embedded shell command

2.Wraps it into a standard HTML POS

3.Sends the POST to the target

4.Checks for success

4.Tries to create a dummy database of its own using makedsn.exe and runs a query against that

5.Tries requests in DSN=mydsn format using common DSN names to run a poisoned query against

6.Cycle through common DSN locations:

1.Tries to create a dummy table

2.Formats a database query with the embedded shell command

3.Wraps it into a standard HTML POST

4.Sends the POST to the target

5.Checks for success

7.Tries requests specifying .mdb files using common .mdb names