The Scenario
You find yourself in a situation where you KNOW you have command injection / command execution, but a WAF or the code itself is stripping a subset of characters. In my situation, I was having all forms of slashes (/ and \) being removed from my request. At the same time, ModSecurity was blocking obnoxiously long payloads as well. So, why was this a problem? In order to bump the severity of the command execution, I NEEDED a reverse shell. No one cares if you can inject a boring sleep 99 command, and I realized this.
Fun fact, a lot of reverse shells rely on slash characters. And when you're a useless hacker like myself, you have a go-to cheatsheet: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet
Shout out to pentestmonkey for keeping that reference alive. It has given me so many reverse shells in the past that I can't thank them enough.
The Exploit
I spent quite a bit of time trying whip out my bash-fu and do some in-line slash replacement. Turns out this is messier than some of those reverse shells (looking at you PERL). Also, it never worked. In fact, never ever try it. It's just a bad idea. But that in-line slash replacement did lead me down an interesting path that created the AHA moment. That AHA moment was when I found myself base64 encoding the slash character to perform that nasty in-line replacement junk.
It took a second of screwing about until I realized, why not just base64 encode the bloody reverse shell payload?!?!?! Needless to say, this worked quite elegantly. I did realize after the fact that I got lucky my payload didn't contain a slash as base64 can contain slashes, but you can also hex encode your payload as well. Shown below is my multiple hours of fumbling about and the payload that ended up working.
If base64 is not available for whatever reason, you can also use xxd with a hex-encoded payload to the exact same effect.
Hope someone found this interesting and potentially helpful. Feel free to post questions below!
No comments:
Post a Comment