Memcached Remote Denial of Service PoC

A long time ago, in 2011, a rather serious vulnerability was reported in Memcached. It is now 2013, and the vulnerability still exists in the latest version on the memcached Google Code page.

The report is here: https://code.google.com/p/memcached/issues/detail?id=192

Now, as you can see, by sending a specially crafted packet, we can cause Memcached to segfault, and essentially die. Memcached is used by a lot of high profile sites to speed up page load times, and killing it would impact a bit on site performance, so I was rather curious as to why this bug had not yet been killed.

As you can see from the report, the vulnerability is trivial to exploit. Just send the magic packet of death and it kills the memcached service. I tried to get remote code execution from it, but had no luck at all. Perhaps one of you might have more luck!

memcached dead

memcached ded

Exploit code available to download here: killthebox.py

As always, responsible use is encouraged. Killing $(big website) memcached might get you in trouble, so don’t do it.

As for the memcached devs: You have known about this for two bloody years and never fixed it. This is terribly irresponsible of you. Fix it.

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!