DOJ Keeps Low Profile on Curador; Protect Your IIS Server Today!

Event Summary

It was only a month ago that U.S. Attorney General Janet Reno insisted that the perpetrator of the February 9th Distributed Denial of Service (DDoS) attacks would be caught and punished. Though the FBI was able to track down a New Hampshire teenager for defacing a couple of websites, there is no indication that the perpetrator of the widespread February 9 Denial of Service attacks is even close to being identified. These attacks, which interrupted- at Amazon.com, Buy.com, E*Trade and others by preventing would-be customers from connecting and proceeding with legitimate transactions, are not nearly as serious as the credit card theft being perpetrated by Curador.

Not having come through on their earlier ultimatum, this time around the Department of Justice is making no claims to its ability to track down and catch Curador, a cybercriminal who has not only stolen credit cards from at least eight e-Commerce sites, but has actually made purchases with them, including the purchases of several websites. Curador has purchased www.e-crackerce.com and www.free-creditcard.com with stolen credit cards both of which were originally hosted by www.xoom.com. Since then, both sites have been taken down.

Market Impact

What happened in the February DDoS attacks is akin to jamming up traffic to the extent that no one can get to the store. What Curador is doing is actually slipping inside the Internet stores, stealing credit cards, making charges, and taunting law enforcement officials on top of it. Curador infiltrated his first website on January 31st - www.shoppingthailand.com. Since then he (or she) has compromised www.promibility.net, www.ltamedia.com, www.ascp.org, www.ntd.co.uk, www.visioncomputers.com, www.salesgate.com, and www.feelgoodfalls.com.

Curador has been consistently taking advantage of some out of the box weaknesses in Microsoft IIS. There is a module of Microsoft IIS that is called Remote Data Services (RDS). The best way to explain the importance of RDS is to understand the data manipulation limitations that occur without RDS in place. Once data has been retrieved from a webserver by a client, it becomes static and can no longer be manipulated without re-establishing a second connection to the database on the backend of the webserver. RDS fixes this limitation allowing disconnected objects to be cached, which enables the data to be dynamically updated and used for further programming. With RDS, you can move data from a server to a client, manipulate the data on the client, and return updates to the server through a single connection.

However, with RDS in place, your credit card numbers may be vulnerable to Curador, and everyone else.

User Recommendations

Since there is no indication that Curador is going to be identified and halted anytime soon, it would behoove all administrators of Microsoft IIS Servers to take the necessary steps to prevent this credit card exploit from being possible. There are many ways to do this. We urge any service providers who are housing credit card numbers, or other confidential data on their IIS server to take protective actions. Note that the following recommendations require administrator access, and should only be performed by senior systems administrators:

If you do not need RDS, then your best bet is to remove or disable it by deleting the following file:

<drive>:\Program Files\Common Files\System\Msadc\msadcs.dll

To delete the msadcs.dll through the User Interface, take the following steps:

1. In the IIS Server, select "Default Web Site"
   
   
2. Then select "Msadc"
   
   
3. Click on "Delete"
   
   
4. Answer "Yes" to "Are you sure?"

Make sure you have a recent backup of your Registry. Use REGEDIT to delete the following Registry Key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch

For the sake of completeness, delete all files in the following Msadc directory:

<drive>:\Program Files\Common Files\System\Msadc

If you do need RDS, then the safest way to use RDS is by using Custom Handlers and not installing the RDS sample files.

To ensure that Custom Handlers are being used, system or database administrators should make sure that the following entry:

HandlerRequired=1

is inserted in the appropriate Registry key which is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataFactory\HandlerInfo

As early as April 1998, Microsoft began publishing extensive information on how to safely implement Custom Handlers in RDS2.0. Any site that plans on using RDS should make sure that the administrator of the RDS system is intimately familiar with all advisories concerning RDS on the Microsoft website.

If youR organization does not have a support contract in place with Microsoft, further support on the RDS features can be obtained through a Microsoft Certified Support Center (MCSP). The following MCSP's are available to help:

Last, keep in mind that many database security problems can be avoided by running SQL server as a low-privileged user account.