Hey guys, this year Black Hat Europe is happening at Barcelona, Spain and I will be presenting there for the first time. The topic that I'm speaking on is "Attacking JAVA Serialized Communication". You can read the abstract here. There is an interesting aspect behind this topic. To give you a short background, I usually conduct trainings on Secure Code Development for JAVA developers and Security Testing for QA testers. During one of the lectures, while I was explaining parameter tampering on web applications using interception proxies, one of the developers asked me how I can accomplish the same on thick clients which normally transfer data as serialized objects. At that moment, I could only show how to modify hex bytes for simple strings. But then he started arguing that usually in large enterprise applications the variables themselves are complex objects and not simple strings.
I was stumped. I did not have a clear-cut solution (though I knew it is possible) to explain to him that this can be done. I started searching the internet for articles explaining this, but couldn't find anything conclusive enough. I have been working on this since December last year and finally perfected the concept and wrote a plug-in for BurpSuite as a PoC to explain how easy it is. I would like to thank Eric and Shay for some wonderful work they have done which has helped me in achieving this goal.
At Black Hat I will be explaining how this can be achieved and what are the various problems currently faced by pentesters while testing applications using serialized communication. If you are visiting Black Hat this year at Barcelona, I would be happy to meet you and share some thoughts on similar topics. Looking forward to socializing with some great people there and gaining some new insights on current security trends.
Thursday, March 4, 2010
Tuesday, March 2, 2010
Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
This idea occurred to me a few weeks back when discussing the potential impact of ClickJacking attacks with Luca. Submitting forms using ClickJacking is hard work and is only successful in very rare scenarios. The Twitter ClickJacking attack was one famous instance where form submission was involved, but it was a form that was submitted over ‘GET’ request.
In this post I will discuss a technique that can be used to bypassing any CSRF counter measures and submit POST method -based forms with attacker controlled data using ClickJacking. This works on JSP applications and partially on ASP.NET applications.
Let us take the case of a simple primary Email ID update form. Such forms are common in many web applications. They are simple but extremely important, if an attacker manages to force a victim to update his primary Email ID with that of the attacker’s ID then the attacker can perform a password reset and compromise the victim’s account.
A sample Email ID update form is given below, this contains a ‘csrf-token’ parameter for CSRF protection:
Let’s say this form is available at 'www.example.com/updateEmail.jsp'
Since this form does not contain an ‘action’ attribute, on submission the form will be submitted to the current URL in the address bar, which will be ‘www.example.com/updateEmail.jsp’.
The source code of 'updateEmail.jsp' would typically look like this:
The application checks if the request contains a valid CSRF token, if not it displays the form to the user.
Now to submit our sample form using ClickJacking the attacker can include an iframe like this
'<iframe src=”http://www.example.com/updateEmail.jsp?email=evil@attackermail.com”>'
When this request goes to the server the application would display the update form. When this form is submitted by the victim using ClickJacking the request that is sent to the server is like this:
Since the form was not filled by the victim, the email parameter in the POST body is blank. However since the action attribute of the form was empty the form is submitted to www.example.com/updateEmail.jsp?email=evil@attackermail.com. Now the QueryString contains the attacker entered value for the ‘email’ parameter.
This request contains two values for the ‘email’ parameter, one in POST body and one in QueryString. Enter HTTP Parameter Pollution, when the server side JSP code calls request.parameter("email"), the value that is returned is the one in the QueryString and not the POST body. Since this value can be controlled by the attacker he can trick the victim in to updating his account with the attacker’s mail ID.
This attack can also work in cases when the form is submitted with JavaScript like this:
Apart from JSP applications, this attack can be extended to ASP.NET applications as well.
However since ASP.NET appends a ‘,’(comma) between duplicate parameters, it not as clean. But there are plenty of areas where having a trailing ‘,’ won’t hurt. In ASP.NET applications the form action is always set by the framework because of the 'runat="server"' attribute. The only requirement now is that the application should make use of Request.Params. Even if the application does not use Request.Params, forms submitted over 'GET' are still vulnerable. So all ASP.NET application using Request.Params or submitting forms over 'GET' are vulnerable to this attack!
Similar attack is also possible on ASP applications where the form element is of the form described earlier and if it is submitted over 'GET'. Like ASP.NET application a trailing comma is introduced here as well. A more detailed description of HTTP Parameter Pollution on ASP and ASP.NET applications and the significance of Request.Params is explained here. This whitepaper discusses how HPP can be used to bypass WAF.
In this post I will discuss a technique that can be used to bypassing any CSRF counter measures and submit POST method -based forms with attacker controlled data using ClickJacking. This works on JSP applications and partially on ASP.NET applications.
Let us take the case of a simple primary Email ID update form. Such forms are common in many web applications. They are simple but extremely important, if an attacker manages to force a victim to update his primary Email ID with that of the attacker’s ID then the attacker can perform a password reset and compromise the victim’s account.
A sample Email ID update form is given below, this contains a ‘csrf-token’ parameter for CSRF protection:
<form method="POST">
<input type="text" name="email" value=””></input>
<input type="hidden" name=”csrf-token” value="a0a0a0a0a0a"/>
</form>
Let’s say this form is available at 'www.example.com/updateEmail.jsp'
Since this form does not contain an ‘action’ attribute, on submission the form will be submitted to the current URL in the address bar, which will be ‘www.example.com/updateEmail.jsp’.
The source code of 'updateEmail.jsp' would typically look like this:
if ( request.parameter("email").isSet() && request.parameter("csrf-token").isValid() )
{
//process the form and update the email ID
}
else
{
//display an empty form to the user (CSRF token included)
}
The application checks if the request contains a valid CSRF token, if not it displays the form to the user.
Now to submit our sample form using ClickJacking the attacker can include an iframe like this
'<iframe src=”http://www.example.com/updateEmail.jsp?email=evil@attackermail.com”>'
When this request goes to the server the application would display the update form. When this form is submitted by the victim using ClickJacking the request that is sent to the server is like this:
POST /updateEmail.jsp?email=evil@attackermail.com HTTP/1.1
Host: www.example.com
email=&csrf-token=a0a0a0a0a0
Since the form was not filled by the victim, the email parameter in the POST body is blank. However since the action attribute of the form was empty the form is submitted to www.example.com/updateEmail.jsp?email=evil@attackermail.com. Now the QueryString contains the attacker entered value for the ‘email’ parameter.
This request contains two values for the ‘email’ parameter, one in POST body and one in QueryString. Enter HTTP Parameter Pollution, when the server side JSP code calls request.parameter("email"), the value that is returned is the one in the QueryString and not the POST body. Since this value can be controlled by the attacker he can trick the victim in to updating his account with the attacker’s mail ID.
This attack can also work in cases when the form is submitted with JavaScript like this:
<form onSubmit=process()>
<input type="text" name="email" value=""></input>
<input type="hidden" name="csrf-token" value="a0a0a0a0a0a">
</form>
<script>
function process()
{
//check if email is set
form.action = document.location; //document.location will give out the entire URL with parameters
form.method = "post";
form.submit();
}
</script>
Apart from JSP applications, this attack can be extended to ASP.NET applications as well.
However since ASP.NET appends a ‘,’(comma) between duplicate parameters, it not as clean. But there are plenty of areas where having a trailing ‘,’ won’t hurt. In ASP.NET applications the form action is always set by the framework because of the 'runat="server"' attribute. The only requirement now is that the application should make use of Request.Params. Even if the application does not use Request.Params, forms submitted over 'GET' are still vulnerable. So all ASP.NET application using Request.Params or submitting forms over 'GET' are vulnerable to this attack!
Similar attack is also possible on ASP applications where the form element is of the form described earlier and if it is submitted over 'GET'. Like ASP.NET application a trailing comma is introduced here as well. A more detailed description of HTTP Parameter Pollution on ASP and ASP.NET applications and the significance of Request.Params is explained here. This whitepaper discusses how HPP can be used to bypass WAF.
Imposter and Whitepapers released
This is it folks! Finally Imposter is available for download. I have put up a short tutorial on how to use it along with some videos of the attacks.
I am also releasing two white papers:
Flash+IE=Prison Break – Explains the File Stealing attack against Internet Explorer in detail.
Google Gears for Attackers – Explains the different browser phishing attacks that can be performed against user of Google Gears.
Source code of the File Stealing exploit is also online for the sake of the more curious amongst us.
Would love to hear your feedback on the tool and the papers.
I am also releasing two white papers:
Flash+IE=Prison Break – Explains the File Stealing attack against Internet Explorer in detail.
Google Gears for Attackers – Explains the different browser phishing attacks that can be performed against user of Google Gears.
Source code of the File Stealing exploit is also online for the sake of the more curious amongst us.
Would love to hear your feedback on the tool and the papers.
Thursday, February 11, 2010
The Goan NullCon Hangover
Just back from NullCon 2010 which happened in Goa. Can’t say which was better the conference or the beaches. It was a very relaxed affair with plenty of familiar faces. My talk was on Imposter, the idea was to explain how it works and what its various features are and also announce the public release of the tool. But my talk had to be cut short because the Gears database stealing attack didn’t work onstage. Not wanting to miss out this part I decided to go backstage and fix the bug and then continue my talk later in the day. Turned out that some insignificant change that I made in code before the talk broke the Gears stealing feature, never expected that. Got it fixed in about 15 minutes but unfortunately I could not continue with my talk, the other talks were already running late and there was no slot available. I was disappointed but hey, atleast I announced the release of the tool. Coming to the other talks, there was a very interesting talk from Veysel Ozer, it was on how the update feature of softwares can be comprised by an attacker. I had read about this attack in the past but it was really interesting to see it in action. He has discovered vulnerabilities in the update feature of different software and has extended karmetasploit with exploits to attack these vulnerable software. Interestingly he also spoke about instances where he was not successful in compromising the update feature and explained why. I met him backstage, showed him a demo of Imposter and explained how the attack modules from Imposter can fit in to Karmetasploit and how his update attack can fit in to Imposter. He liked the idea, so we exchanged code. Hopefully he will find time to build this in to Karmetasploit, that must be pretty cool. Until then Imposter remains the best browser phishing tool ;)
Thursday, December 10, 2009
The ClubHack 2009 hangover
ClubHack is India’s first and oldest hacking/security conference. Started in 2007 by Rohit Shrivatsav, it happens in Pune every year. This year was special because Imposter was going to be there ;). I presented the same content as SecurityByte and OWASP AppSec Asia but this time around I had more time. I was able to explain all the attacks along with the demos. The audience were great and had very interesting questions, the most common of it was "Where can I get Imposter from?". I promised them it was going to be available for download very soon. There was a very interesting session by Kursev Singh of McAfee, he was demonstrating Mobile Application Testing, liked the way he presented his talk. Team ClubHack was a young and fired up group and they did a very good job. Once the sun went down all the speakers headed over to the bar and there was a surprise waiting for us. The beer served in the bar was coming straight from a brewery built right into the bar itself. It was just fresh pure beer with no additives or preservatives. This was a brainchild of a couple of IIM grads, one of them took us on a tour of the brewery and explained the entire process. I have become a fan already and hope ClubHack 2010 happens in the same place ;)
Sunday, November 29, 2009
Stealing Databases and Setting Backdoors on Google Gears
Google Gears has two important modules, the LocalServer and the Database. The Database module is used to store data in a relational database stored on the user’s hard disk and accessible via JavaScript. The LocalServer is like an advanced cache, where files can be stored and served locally.
In a browser phishing attack the attacker might be able to serve content as an 'http' site that is permitted by the victim to use Google Gears. By running JavaScript as mail.google.com for example, an attacker can read the entire inbox of a Gears enabled user, same goes for MySpace private messages as well. Both these sites use ‘http’ for Google Gears which makes these kind of attacks possible. The Google Gears implementation of MySpace is flawed, the data stored in the Google Gears database is returned to the user without proper encoding, resulting in a persistent XSS. This is probably the first publicly disclosed vulnerability where Google Gears is involved in a XSS.
The LocalServer allows an attacker to cache any file on the browser of the victim for a specific site. For example he could cache a file like 'http://mail.google.com/gearsBackdoor.html' in the LocalServer of the victim with malicious content. The attacker can call this page either by sending a link to the victim or by loading it in an iframe when the victim visits his website. When that happens the page is served from the LocalServer and the malicious content is executed in the context of mail.google.com. A more advanced attack would be to place a backdoor in the same name as a file that is part of the website. This way every time the user logs in to the website the backdoor would be called automatically. Obviously this kind of an attack can have serious consequences for the victim.
I have enumerated seven different types of backdoors that can be placed with Google Gears. Details of these techniques will be available in a whitepaper that I would release soon. Imposter can be used to both steal database contents and place backdoors.
In a browser phishing attack the attacker might be able to serve content as an 'http' site that is permitted by the victim to use Google Gears. By running JavaScript as mail.google.com for example, an attacker can read the entire inbox of a Gears enabled user, same goes for MySpace private messages as well. Both these sites use ‘http’ for Google Gears which makes these kind of attacks possible. The Google Gears implementation of MySpace is flawed, the data stored in the Google Gears database is returned to the user without proper encoding, resulting in a persistent XSS. This is probably the first publicly disclosed vulnerability where Google Gears is involved in a XSS.
The LocalServer allows an attacker to cache any file on the browser of the victim for a specific site. For example he could cache a file like 'http://mail.google.com/gearsBackdoor.html' in the LocalServer of the victim with malicious content. The attacker can call this page either by sending a link to the victim or by loading it in an iframe when the victim visits his website. When that happens the page is served from the LocalServer and the malicious content is executed in the context of mail.google.com. A more advanced attack would be to place a backdoor in the same name as a file that is part of the website. This way every time the user logs in to the website the backdoor would be called automatically. Obviously this kind of an attack can have serious consequences for the victim.
I have enumerated seven different types of backdoors that can be placed with Google Gears. Details of these techniques will be available in a whitepaper that I would release soon. Imposter can be used to both steal database contents and place backdoors.
Breaking the Browser Sandbox and stealing some files
If you are using Internet Explorer and if it has the flash player plug-in installed then an attacker can steal files from your local file system through the browser. For this attack to be performed the victim and attacker should be part of the same private network, the best candidate for this is unsecured WiFi hotspot.
The attack is possible because of some unique characteristics of Internet Explorer and Flash player which in isolation don’t create so much of a problem. But you put them together and you end up with a real killer.
Internet Explorer will automatically load any resources from network shares with anonymous read access, it does not prompt the user for permission. If any website includes an iframe to a resource from a network share then it is loaded.
Flash files loaded from network shares can read files from the local file system even if they run within the browser. Such files must have the "Access local files only" setting for "Local playback security".
Though they can read files all networking capability for these files are restricted, well almost. Since the flash player considers network shares as local file system, flash files can read files placed in network shares as well. Reading a file from a network share requires making a SMB request over to the server containing the share. This request carries the name and location of the file to open, this can be of a maximum length of 259 bytes.
This feature can be used to send data as well by putting the data in the SMB request. For example a flash file from an anonymous share on the attacker's computer loads in the victim's browser in an iframe. This reads files from the victim's local file system and breaks down the file contents in to smaller chunks less than 259 bytes each. Now the flash file attempts to read files from the attacker’s anonymous share but instead of specifying a valid filename it gives one of the chunks as the filename. Now this chunk goes to attacker's system in a SMB packet. The attacker can sniff these packets, extract the chunks and assemble them together to get the entire file content out. It is possible to transfer data at the rate of 234.24 kbps using this technique.
Imposter can perform this attack but it has a slightly lower transfer rate since it includes some metadata in the request to help in reassembly. The whole attack is silent with no user interaction or alert. I would be giving more details on this attack in a whitepaper, should be out soon.
The attack is possible because of some unique characteristics of Internet Explorer and Flash player which in isolation don’t create so much of a problem. But you put them together and you end up with a real killer.
Internet Explorer will automatically load any resources from network shares with anonymous read access, it does not prompt the user for permission. If any website includes an iframe to a resource from a network share then it is loaded.
Flash files loaded from network shares can read files from the local file system even if they run within the browser. Such files must have the "Access local files only" setting for "Local playback security".
Though they can read files all networking capability for these files are restricted, well almost. Since the flash player considers network shares as local file system, flash files can read files placed in network shares as well. Reading a file from a network share requires making a SMB request over to the server containing the share. This request carries the name and location of the file to open, this can be of a maximum length of 259 bytes.
This feature can be used to send data as well by putting the data in the SMB request. For example a flash file from an anonymous share on the attacker's computer loads in the victim's browser in an iframe. This reads files from the victim's local file system and breaks down the file contents in to smaller chunks less than 259 bytes each. Now the flash file attempts to read files from the attacker’s anonymous share but instead of specifying a valid filename it gives one of the chunks as the filename. Now this chunk goes to attacker's system in a SMB packet. The attacker can sniff these packets, extract the chunks and assemble them together to get the entire file content out. It is possible to transfer data at the rate of 234.24 kbps using this technique.
Imposter can perform this attack but it has a slightly lower transfer rate since it includes some metadata in the request to help in reassembly. The whole attack is silent with no user interaction or alert. I would be giving more details on this attack in a whitepaper, should be out soon.
Subscribe to:
Posts (Atom)