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
Both versions of the source code for this exploit are available at RainForestPuppy’s web site, www.wiretrip.net. Due to its length, the actual code can’t be included in this chapter, but it can be downloaded from www.wiretrip.net/rfp.
Additional Information
Additional information on this exploit can be found at the following web sites:
• Microsoft Universal Data Access Download Page http://www.microsoft.com/data/download.htm
• Installing MDAC Q&A
http://www.microsoft.com/data/MDAC21info/MDACinstQ.htm
• Microsoft Security Advisor Web site
http://www.microsoft.com/technet/security/default.asp
• IIS Security Checklist
http://www.microsoft.com/technet/security/iischk.asp
• ACC2000: Jet 4.0 Expression Can Execute Unsafe Visual Basic for Applications Functions
http://support.microsoft.com/support/kb/articles/q239/4/82.asp
• Jet Expression Can Execute Unsafe Visual Basic for Applications Functions
http://support.microsoft.com/support/kb/articles/q239/1/04.asp
• Microsoft Security Bulletin MS99-030: Frequently Asked Questions http://www.microsoft.com/technet/security/bulletin/fq99-030.asp
• Microsoft Security Bulletin MS99-025: Frequently Asked Questions http://www.microsoft.com/technet/security/bulletin/fq99-025.asp
• Advisory RFP9907 by RainForestPuppy
http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface=2
• 1999-07-23: RDS/IIS 4.0 Vulnerability and Script by RainForestPuppy / ADM / Wiretrip posted to NTBugTraq
http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind9907
&L=NTBUG-TRAQ&P=R3981
• 1999-05-25: NT OBDC Remote Compromise Advisory by Matthew Astley and Rain Forest Puppy
http://www.wiretrip.net/rfp/p/doc.asp?id=3&iface=2 Microsoft Shares
One of the most widely publicized Microsoft security vulnerabilities is Shares. Although Microsoft may have made their products easier to use, they have also made their products’ out-of-the-box configuration wide open to exploitation.
Exploit Details
• Name: Microsoft Shares
• Variants: Null session
• Operating System: Any Microsoft Operating System running Microsoft networking
• Protocols/Services: NetBIOS and NetBEUI
• Written by: Nathan J. Martz
Just to clarify, because most of the other exploits covered in this chapter deal with specific vulnerabilities, this exploit description is going to be more general. Because shares are very popular on Microsoft platforms, and because there are a variety of ways they can be used by an attacker, this section takes a generic look at the security issues associated with shares on a Microsoft platform.
Protocol Description—NetBIOS and NetBEUI
NetBIOS was originally developed for IBM in the 1980s, and it became widely used as Microsoft Windows for Workgroups and LAN Manager (Lanman) became popular. IBM developed it for its token ring products.
Technically, NetBIOS is a session layer protocol, although it doesn’t fully comply with the ISO OSI model. NetBIOS does not use an actual address for locating resources, but instead it uses the NetBIOS name of the
resource. Because it is actually a session layer protocol, NetBEUI
(NetBIOS Extended User Interface) is used for transport. NetBIOS over NetBEUI relies on broadcasting, and although it is fairly fast and small, it can eat up a lot of bandwidth, especially as more workstations are added.
The biggest drawback is that it is not routable.
On LANs using NetBIOS, each computer must have a unique name of 16 alphanumeric characters or less. (Microsoft’s implementation allows for up to 15 characters with the 16th used as a NetBIOS suffix that specifies the function of the device or service.) These NetBIOS names identify network resources after they have registered their names on the network. A client advertises its name after it becomes active. If it is able to successfully advertise itself without another client claiming the same name, the
registration is successful. Group names do not have to be unique—many unique names can belong together to one Group. All processes that have the same Group name belong to the same Group.
Microsoft’s answer to the problem of NetBIOS not being routable was to support NetBIOS over TCP/IP. NetBIOS has to resolve the NetBIOS name into an IP address using a NetBIOS to TCP/UP interface before the normal TCP/IP process can take place. There are several ways to do this. One way to do it is to have the interface broadcast the NetBIOS names to the
TCP/IP network and wait for the response. However, this would be unworkable in a large network. Another way of doing it is to use an
LMHOSTS file to associate NetBIOS names to an IP address. This has been a very popular way to solve the problem, but it can be difficult to manage.
Microsoft’s newer TCP/IP stacks allow the DNS service to be used for resolving NetBIOS names. For this to work, the NetBIOS name must be the same as the DNS hostname. None of the three methods work with dynamically assigned IP addresses, so Microsoft created the WINS service to help solve this problem. Although this helps to resolve NetBIOS names, WINS still needs to be implemented with Microsoft’s version of DNS to effectively resolve NetBIOS names to IP addresses.
NetBIOS over NetBEUI is installed by default when you configure Windows 9.x/NT for networking. NetBEUI is also installed for Microsoft file and
printer sharing. Microsoft keeps these technologies around to provide backward compatibility with its old LAN Manager products.
Protocol Description—Server Message Blocks (SMBs)
Server Message Blocks (SMBs) can be transported over NetBEUI or NetBIOS, over both IPX or TCP/IP, and they are used to communicate between Windows 3.X, Windows 9.X, and Windows NT clients. SMBs allow for remote access to shared directories and files. Default installation of Microsoft file and print sharing on Windows 3.x/9.x allows any user to share any directory or file on his computer. A system administrator with a few hundred Windows 9.x systems on her network will have a tough time preventing unauthorized file sharing unless each and every workstation is locked down. Remote access to user-defined shares and to default
operating system hidden shares (in the case of Windows NT) is done through ports 137, 138 and 139.
How the Exploit Works
Given the background of this exploit, how would an attacker go about trying to exploit a computer with a Microsoft operating system? The first step would be to find the IP and name of a possible target. There are numerous free tools out there, but the one we will use is called NetInfo, which is available at PacketStorm (http://packetstorm.securify.com/), and is shown in Figure 12.6.
Figure 12.6. The initial screen for NetInfo.
In Figure 12.6, NetInfo was used to ping a web server, obtain its IP
address, and then ran for an additional few seconds as it continued to ping IP numbers one-up from the web server. In this fashion, an attacker can pull out machine names and IP addresses.
Although there are numerous programs available to detect operating systems, such as nmap (www.insecure.org) and queso
(www.apostols.org/projectz), the unwitting system administrator will often make things easy by using a naming scheme, such as “NTServer1” or
“NT40WINS”. These IPs and machines can be added to the attacker’s LMHOSTS file to access these machines. It is amazing the number of computers that are named in this fashion, and some companies would rather be tarred and feathered before they would consider renaming their corporate servers.
After the attacker has added some likely suspects to the LMSHOST file, it is rather simple to run the net view command from a DOS prompt to gather additional information. net view can be run from any Microsoft operating system that has Microsoft networking installed, and it shows all the computers running Microsoft networking. Figure 12.7 shows how much information is available from a simple net view command. Keeping in mind that the source of many compromises are internal, system
administrators want to keep comments in the “remarks” section to a minimum. Even with a naming scheme that doesn’t give away the farm, some people still make the mistake of adding something like “Primary Domain Controller” or “Exchange Server” to the remarks section.
Figure 12.7. DOS window showing the information available by running net view.
How to Use It
The next step is to establish a null session. A null session is an anonymous connection to a Windows NT system that does not require a user ID or password. It is used by NT systems to communicate with each other, but it can also be used by an attacker to gather information. Null sessions can be established with Windows 9.X/NT and Windows 2000. Again, there are numerous automated programs available to establish null sessions and to pull out as much additional information as possible, but in its most basic form, the null session can be established by using the net use command.
Net use \\xxx.xxx.xxx.xxx\IPC$ ""/user:""
Figure 12.8 shows the output from running this command.
Figure 12.8. The output from running the net use command.