[WEB SECURITY] Database tools required

Arian J. Evans arian.evans at anachronic.com
Thu May 13 12:37:24 EDT 2010

Ah, nice include.

So no SQL Injection? Bummer. With SA account you have a good shot at
getting to sprocs and extended sprocs that can give you the keys to
the kingdom.

Unless you find a hole I mentioned in the app - you probably cannot
log in using SA.

However - if they use SA for ASP classic apps here, good chance they
do it other places. It's a terrible practice. If there are other web
applications, I would look for SQLi on them and see if they have
shared databases. At a minimum you know they do not take steps to
restrict privilege to the DB, so if you get SQLi, you essentially have
a remote CLI-processor on their network.

Have you tried testing for BlindSQLi? ASP Classic apps are typically
(infamously) vulnerable. If not, it might be worth reading/brushing up
on your Blind SQLi techniques. No offense if you are already skilled
in this area and have exhausted testing here.

Good luck,

Arian Evans

On Thu, May 13, 2010 at 4:35 AM, Parmendra Sharma <s.parmendra at gmail.com> wrote:
> Hi
> This is what i got from the vulnerable application.
> Below given is the file with the sanitised credentials.
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> <%
> '---------------------------------------------------------------------------
> ----------------------------------
> ' Name : DBConnection-Include.asp
> ' Developer Name : ABC
> ' Purpose : Provides Database connection string, which
> can be included
> ' in all the ASP files that require Data
> Base connection.
> ' The Connection string content can be
> modified as on when required
> ' like when uploaded to Web server
> ' Date : 22-Nov-2003
> '---------------------------------------------------------------------------
> ---------------------------------
> 'This is an Include file to establish Database connectivity
> 'Create Connection Object
> Dim MyConn
> Set MyConn=Server.CreateObject("ADODB.Connection")
> ''For Local SQL Server Connection
> 'MyConn.Open "dsn=ABC;uid=sa;pwd=;database=ABC"
> ''Online
> MyConn.Open
> "dsn=DSN;uid=ABC;pwd=ABC;database=ABCDB"
> %>
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Now i cannot talk to the database directly and i found no SQL Injection
> vulnerability in the application.
> Any idea on how to make the use of these credentials to extracts information
> from the database.
> On Wed, May 12, 2010 at 10:54 PM, Arian J. Evans
> <arian.evans at anachronic.com> wrote:
>> Clarification will help. Did you find a function inside of a web
>> application -- like a debug function that dumps connection strings,
>> and hence you accessed the DB credentials through connection string
>> info? Or something like default framework connection-string files
>> (global.asax, etc.)?
>> A) Are you asking how to connect *through* the web application running
>> over HTTP to the back-end database?
>> B) Or do you have raw sockets/TCP connectivity directly to the database?
>> These are two very different scenarios.
>> If B) many of the responses already provided will help you.
>> If A) then using the credentials to gain elevated access to the
>> database could be tricky or impossible, depending on how the
>> application is built.
>> Here are the things I would look for, if you are limited to HTTP-based
>> web applications for attempting access:
>> 1. "Debug" or administrative functions in the app that allow you to
>> access the database impersonating the application. (these aren't very
>> common)
>> 2. Operating-system level exploits, shell access (like php_shell
>> files), or command injection via the web application (most likely on
>> the web server).
>> Exploiting this level of access will allow you to connect and create
>> arbitrary queries at the level of privilege of the credentials, since
>> you know the appropriate DB drivers are already installed. If the
>> application uses a middleware or managed-code abstraction layer (like
>> .NET), then command injection/shell exploits at the web-server level
>> could be of limited use. Your worker-threads (you gain shell with) are
>> usually lower-privilege too.
>> 3. RFI or LFI (file include) vulnerabilities. Upload your own
>> script/SWF/etc. and plug directly into the DB.
>> 4. Other vulnerable web applications. If you find other vulnerable web
>> applications on the same network that have any of the above issues, up
>> to and including OS Command Injector or SQL Injection, you may be able
>> to connect to the database from the web/app server of another
>> vulnerable web application in the same DMZ/LB pool. (Often you find
>> it's the same DB cluster in production environments. :)
>> --
>> Even if you cannot exploit this finding, it is still valuable.
>> In and of itself - this information can be a vulnerability on
>> production systems. If network access to the DB is not segmented
>> internally...anyone on the internal network can impersonate the
>> application provided they have access to the database, which is a
>> significantly concerning situation.
>> Most organizations do not perform network-access layer logging on
>> their databases, trusting the connection strings, so there is no
>> repudiation for actions taken by any arbitrary entity with access to
>> these credentials.
>> Good luck,
>> ---
>> Arian Evans
>> "If you really want to make things complicated - look no further than
>> On Mon, May 10, 2010 at 10:37 PM, Parmendra Sharma
>> <s.parmendra at gmail.com> wrote:
>> > Hi All,
>> >
>> > While performing a VA / PT exercise of an application i got the database
>> > credentials. Kindly suggest any tool which connects me to the database
>> > through the application.
>> >
>> > --
>> > Thanks and Regards:
>> >
>> > Parmendra Sharma
>> > Computer Security Analyst
>> >
> --
> Thanks and Regards:
> Parmendra Sharma
> Computer Security Analyst

Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn

More information about the websecurity mailing list