NT IIS MDAC RDS Vulnerability

msadc.pl exploit written and posted to bugtraq by Rain Forest Puppy.
RDSExploit.zip exploit written and emailed to SecurityFocus by Wanderley J. Abreu Jr

--msadc.pl explanation: (RDSExploit explanation is after this)
msadc.pl looks for a common file to exploit, namely btcustmr.mdb .
msadc.pl instructions:
run perl -x msadc.pl
Command line switches (copied from rfp's post):

-h <ip or domain> this is the host to scan. You MUST either
use either -h or -R.

-d <value 0-?> this is the delay between connections.
Value is in number of seconds. I added
this because hammering the RDS components
caused the server to occasionally stop
responding :) Defaults to 1. Use -d 0
to disable.

-V Use VbBusObj instead of DataFactory to
run the queries. NOTE: please read the -N
information below as to suggestions for
checking if VbBusObj exists. VbBusObj
does not give good error reporting;
therefore it is quite possible to have
false positives (and false negatives).
Consider VbBusObj support 3 stages before
beta. Don't say I didn't warn you.

-v verbose. This will print the ODBC error
information. Really only for
troubleshooting purposes.

-e external dictionary file to use on step
5--the 'DSN dictionary guess' stage. The
file should just be plaintext, one DSN
name per line file with all the DSN names
you want to try. Quite honestly a normal
dictionary file won't do you much good.
You can probably do pretty damn well with
a few dozen or two good ones, like 'www',
'data', 'database', 'sql', etc.

-R resume. You can still specify -v or -d
with -R. This will cause the script to
read in rds.save and execute the command
on the last valid connection.

-N Use VbBusObj to try to get the machine's
NetBIOS name. It may return no name
if the VbBusObj is unavailable. I suggest
you use -N to see if VbBusObj exists (a
NetBIOS name will be returned if so)
before you use -V.

-X perform an Index Server table dump instead.
None of the other switches really apply
here, other than -v (although -d still
works, there's no need to slow down one
query). This dumps the root paths from
Index Server, which can be rather lengthy.
I suggest you pipe the output into a file.
Also, if there is a lot of return
information, this command may take a while
to complete. Be patient. And I don't
suggest you use this command more than
once a minute...it caused my P200 w/
128 RAM to stop answering requests, and
in general borked inetinfo.exe. If you do
decide to CONTROL-C during the middle of the
data download the script will save all
received data into a file called 'raw.out',
so you don't loose everything you've
already received. NOTE: this is the raw
data, which is in Unicode.

rfp submitted a version 2 of this exploit on October 10, 1999. New features include:

- UNC support. This has only been tested with Windows 95 shares...NT may
cause authentication wackiness. Use -u \\server\share\file.mdb.
Also, on unix boxen, don't forget you have to escape the '\', so
would look like \\\\server\\share\\file.mdb. Also have not tested
with Samba. Let me know if you have good/bad results.

- Win 95 support. Use -w to use command /c instead of cmd /c.

- Slimmed down the query process. Before it would query to determine if
it was using Access driver, then create a table called 'AZZ', and
then try to use this 'AZZ' table for the exploit. This left
obvious leftovers (tables named 'AZZ') on the server. Now it just
queries MSysModules firsthand, which cuts down the steps and stops
leaving evidence. However, this may not always work. Use the -c
switch for backwards compatibility (3 step process). I would run
normal, and if nothing works, try it again with the -c switch.

- Only run a certain step. Use the -s switch to specify which step to
run. For those of you itching to try the new UNC support, you
can run it immediately (normally it's step 5), by running:

./msadc.pl -h <host> -u <unc path> -s 5

NOTE ON SUCCESS: The script reports 'Success!' when it has issued a valid
SQL statement. 'Success!' does *NOT* mean that your command worked. If
they have MDAC 2.1+ shell commands are worthless, so the script will
report 'Success!' (it went through) but your command didn't run (MDAC 2.1
didn't interpret it). There's no return indication to know whether your
command worked or not. As with the ODBC commands, you're flying blind.

--RDSExploit information:
How it Works:
        The Intent of RDS Exploit is Deliver Shell comands into the machine or Retrive some DATA from a ODBC valid conection.
1. Seting ODBC Conection:
First of all you will need to know some valid DSN, the UID (User ID) and Password.  Put the information about the conection into "Connection Properties":
Data Source: The DSN Conection Name (it MUST be a registered DSN)
User ID: Login (it can be null sometimes)
Password: Password (it can be null sometimes)  
Mode: The way you want to open the Table (Read Only or Read and Write)
You must follow the order above and don't forget the ; to separate the options
 It can be for instance a line like this:
"Data Source=AdvWorks;User ID=;Password=;Mode=Read|Write;"
2. SQL Comands:
Put into the "SQL Parameters" box the command line you want to deliver for example:
"SELECT * FROM Products"

3. Host:
 You MUST Enter the host like this http://server  DON'T FORGET HTTP:// or it'll not work.
After all done, just click in the button "Retrieve Data" and see what happens =)


Privacy Statement
Copyright 2010, SecurityFocus