Re: exploiting BID 529
From: H D Moore (fdlist_at_digitaloffense.net)
Date: 12/08/04
- Previous message: Eirik Seim: "Re: application security testing training"
- In reply to: m a: "exploiting BID 529"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: pen-test@securityfocus.com Date: Wed, 8 Dec 2004 13:43:38 -0600
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
- Previous message: Eirik Seim: "Re: application security testing training"
- In reply to: m a: "exploiting BID 529"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
