Date: Fri, 30 Dec 2005 21:18:02 -0600
From: Gandalf The White <gandalf@...ital.net>
To: BugTraq <bugtraq@...urityfocus.com>
Subject: Mapping and Remote manipulation of databases


Greetings and Salutations:

I am requesting discussion on the below idea.  I have seen this (in a very
crude way, see bottom) work.  I suspect, however, that this idea could be
fine tuned to produce specific results.

Abstract:
As company partnerships increase, networking, databases and information
sharing also increases.  Data from directly connected (and presumably
trusted) partners is automatically combined or integrated into the existing
database.  The data from the "trusted" partner, however, may have come from
other connected partners and may have not been as thoroughly vetted as it
should have been

Problem:
How to map and manipulate the database(s) of company(ies) that is/are read
only from the outside world.

Solutions:
We see from the below that we use all the usual methods (Reconnaissance,
Scanning, Exploiting The System, Network Diagram, Keeping Access, Covering
Tracks)
1) Reconnaissance - All the usual suspects --> Google, DNS lookups (to see
if you can find access to the database(s)), connections to the target
company.

2) Scanning - This is not a layer 3 (IP) attack, so scanning here is a
little bit different context.  Think layer 7, connections between databases
and what database engine / software version (MySQL, Oracle, Etc.)
manipulates the database.  Find a piece of data in the database from the
site you are trying to focus on that is "unique".  By unique I am referring
to a strange spelling, incorrect spelling, etc.  Take this unique data and
try it in the databases that you suspect connect to your target site.  Query
using that data and see if they also have that data.

3) Exploiting the system - Assume that you can find a downstream partner
with weaker security on their database.  A database that is either writable
(naw ... it couldn't be that easy).  The database could also reside on a
server that has a vulnerability so that you can either attach to the
database or take over the server itself.  The database query strings from
the Web might not be correctly parsed / sanitized so that you can remotely
change that database.  Introduce your own "very unique data" into this
database to be used as a tracer, just like putting dye in a stream and
seeing where it flows.

4) Network Diagram - Now using your "very unique data" start building your
"network" diagram of interconnected databases.  If the process can be
automated so much the better, then you can note for each database the time /
date when the data appeared (propagation delay).

5) Keeping Access - Self explanatory for the system exploited in (3), but
the information in (4) gives you additional data / other systems that you
can explore to see whether or not they are also vulnerable.

6) Covering tracks - Should be self explanatory.  Don't use your home
machine to access other machines.  Don't write scripts that are so noisy /
make so many queries that they attract attention.  S-L-O-W queries (Think
Nessus sneaky scans).

Additional notes:
Since the target database is getting information from presumably "trusted"
partners, the programmers may not sanitize / do sanity checks on the data
itself.  This may open the database to nastiness such as HTML / scripts
inside the database that are executed when a particular query is run by a
unsuspecting customer (customers who "trust" this site and will click "yes"
to popups), buffer overflows, data that is itself a query that is executed
when you query for a particular piece of "very unique data", the sky is the
limit.  Any standard database hacking techniques.  You are just able to
introduce the data through a backend method.

What got me started on this:
I recently received my credit report and my name was incorrect.  An
incorrect credit item from a partner of the Credit Reporting Bureau had been
put on my report and that item changed my name in the database.  If someone
had been "smart" enough they could have changed my name and address on my
credit report, used it for identity theft and I would have had a huge
headache trying to get it all corrected.

Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@...ital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html
Woodworking For Geeks - http://digital.net/~gandalf/woodmain.htm

Powered by blists - more mailing lists