Recently, I have been doing quite a bit of CTF write-ups for my blog and I’ve seen I continually need to exploit SQLi edge cases. In the “Robots Exclusion Committee Writeup” I had to do SQL injection via basic HTTP authentication which is in all likelihood not found in any tool. In “CSAW 2013 WidgetCorp Writeup” I had to do SQL injection via a serialized, base64 encoded, cookie. Again, not available on any SQL injection tool.
With a simple script however, you can exploit just about any SQLi edge cases without doing anything manually.
All you need to do to exploit these SQLi edge cases is have a custom script hosted locally that encodes the payload and mirrors the remove server’s responses. It’s important to mirror things such as HTTP status codes and other headers because many tools rely on these in order to work. If you don’t replicate them properly you may just confuse your SQL injection tool to no end and get bad results.
In this way you could very easily exploit even the most edge of cases, this doesn’t have to be a manual thing either. You can also just simply manually inject the URL of your local script just like you would on any other remote site.
Here is some example code from that problem:
While this is of course not an efficient or stealthy way to go about things but it’s still a quicker way to exploit things of this type. Perhaps not suitable on a real pen-test but it would serve very helpful for quick CTF like environments. That being said if your edge case is weird enough I doubt most IDS systems would pick up what you’re doing.
Like I said previously in my CSAW post, it’s like being a hybrid script kiddy. Little bit of scripting & a little bit of tool usage and baby you got a stew goin’
On a final note, this would apply to edge cases of other attack types as well. Perhaps you were doing a local file inclusion via some oddly encoded cookies – this technique would work there in largely the same manner.
Until next time,