4

During a pentest engagement, I found a blind SQLi and I can read all tables and data in them. There is just one problem. They are using a static AES key (defined in web.config and I don't have access to it) and all CMS login credentials are encrypted. All critical data are encrypted at cell level, even first name, last name, email, etc,

Although client accepted the finding, they say its not too critical as I couldn't really get access to anything, I couldn't even login to CMS, I couldn't really do "anything" other than reading encrypted BLOBs. I know finding is enough, I just want to be able to prove my point and take it to the next level.

The server is MSSQL 2012 and Win server 2012, web app is written in C# / ASP.NET. I read everything in DB, but the web app's SQL user is low privilege, I only have blind SQLi (time based, slow and no stacked queries, just reading data) and MSSQL port is not open to internet.

Am I missing something here? Can I do more here? Can I get more access than I got? I just want to prove a point and don't like how client downplayed my finding by (rightfully) claiming that my finding didn't really amount to "something". Please advise. I have full sqlmap sql shell here, I even ran custom queries, got stored procedures list, got list of all DBs, all tables, etc but as I said, they wrote some code and using a static (unknown to me) key, everything is encrypted at cell level.

Improve this question
2
  • 2
    Firs off, if you can exfiltrate the encrypted data you can bruteforce it at your leisure. "It's not leaking anything useful" is a bloody stupid statement to make by the client. Second off, if that's a true blind SQLi, can you delete as well as select? Insert new information?
    – Shadur
    Apr 9, 2018 at 7:30
  • @Shadur, a) Don't think I can really "crack" potentially 32-byte AES key. b) as I said, its a non-stacked SQLi, can't run separate queries, just select
    – GMX Rider
    Apr 9, 2018 at 10:50

1 Answer 1

Reset to default
4
  • You already cracked half their defenses. Now all that's left is a compromise of the AES key. That should be a reason to worry. Especially because changing that key won't be trivial, because they would have to re-encrypt the whole database to do that.
  • Symmetric encryption with a static key on cell level means that duplicate values stay duplicate values. This can give you a hint about the content of some fields. For example, if you know that a certain database row has the value "HIV positive" in a specific field, you can now identify all other rows which also have that value.
  • When you have a blind SQL injection, you might be able to destroy data using UPDATE or DELETE. You can also INSERT data, but without the encryption key you can only insert gibberish. This might still cause trouble, though.
  • You said you can get the stored procedures. Those might do something useful even without having to encrypt or decrypt anything.
Improve this answer
1
  • Thanks for the answer. I can guess partial fields, maybe some field, but even with full known plaintext, you can't really recover AES key. As for DELETE, INSERT etc, as I said, its non-stack SQLi, can't run separate queries, just union select stuff to existing query ran by CMS where I found the bug. I checked stored procedures just for finding the decryption routine, but unfortunately nothing...
    – GMX Rider
    Apr 9, 2018 at 10:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .