Re: exploiting BID 529

[H D Moore <fdlist () digitaloffense net>]

On Saturday 04 December 2004 13:49, m a wrote:
> Some were verified to have RDS version is 1.5 thus:
> http://10.1.1.1/msadc/readme.txt
The readme.txt file is not updated when a newer version of the JetDB or 
MSADC components are installed. 

> I have tried unicode directory traversal which doesn't work.
...as it shouldn't if the system has been patched in the last two 
years :-) I assume you also tried the WebDAV ntdll.dll overflow as well 
as the PCT bug on any exposed SSL services...

> Running msadc works
> $ ./msadc.pl -h 10.1.1.1 -N
> -- RDS smack v2 - rain forest puppy / ADM / wiretrip --
> Machine name: NT2
>
> I am trying to execute some cmd /c commands, however just trying to
> echo >xxx a file to the default path of msadc and the wwwroot does not
> yield anything I can open. I am largely trying to verify that the
> commands work.tem

More than likely the version of JetDB in use does not allow command 
execution via the shell() trick. The MSADC interface allows you to make 
arbitrary ODBC connections AND queries, all you need is some creativity.
The script below uses an unsecured RDS install to attack a SQL Server 
database on the local system (via "sa" account with a blank password). 

 - http://www.digitaloffense.net/csw/sqlrds.pl

This just the tip of the iceberg though, there are all sorts of things you 
can do with the right driver / DSN combination. We have used RDS to 
perform portscans on the internal segment, read local text files, test 
the outgoing firewall rules, and exploit internal database servers (of 
all sorts). 

For a complete listing of all of the ODBC drivers (and some information 
about them), check out this page:

 - http://www.able-consulting.com/ADO_Conn.htm

Even if you can't find something useful inside the network, you could try 
exploiting a client-side driver bug (such as the SQL Server hello one), 
by forcing the RDS component to establish and ODBC connection to a 
hostile, external database server that you control.

> Even if this does work (and the default paths are changed) I am nost
> sure what else I can do with it considering the firewall is filtering
> out everything apart from 80 and 443 (some host probably just one)
> inbound. I could potentially try killing the inet process and then
> implant nc.exe and have it take over on 80 or 443 but that would be to
> intrusive.

Is it filtering outbound connections as well?

> Here's some more reading on this (this guy had the benefit of unicode):
> http://www.honeynet.org/scans/scan14/rfp.html

The guy successfully exploited the unicode bug and then spent all of his 
time cracking in via RDS...

-HD