[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
>> BSIMM"
>>
>>
>>
>> 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: 
http://www.webappsec.org/lists/websecurity/archive/

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

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list