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@xxxxxxxxxxx - 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