Monday, August 01, 2011

Framebusting - The Dual Protection Core

Since the outcome of ClickJacking attacks, framebusting has become the unavoidable part of web application security. Considering the real world scenario, it has been noticed that still the appropriate protections have not been placed in the plethora of websites. Seclab guys conducted the study on framebusting. They raise a point on the right way of implementing the framebusting code. However, a similar protection features have been implemented in the famous websites such as Twitter, Facebook etc. However, my personal opinion is to use the dual protection which includes the implementation of declarative security as well as framebusting code. No doubt, only new versions of certain browsers such as Internet Explorer, Firefox etc support some of the declarative security features. Deploying declarative security feature is a good additional point. I have written Firefox addons that detect the presence of declarative security headers that are coming from servers. In this post, I am using X-Frame-Options detector hosted here

Lets see how the twitter implements the framebusting code

========================= TWITTER ======================================
function bust () {
document.write = ""; = window.self.location;
setTimeout(function() {
document.body.innerHTML = '';
}, 0);
window.self.onload = function(evt) {
document.body.innerHTML = '';
if ( !== window.self) { // are you trying to put self in an iframe?
try {
if ( { // this is illegal to access unless you share a non-spoofable document domain
// fun times
} else {
bust(); // chrome executes this
} catch (ex) {
bust(); // everyone executes this

========================= TWITTER =====================================

This works very well. The beauty of this protection is even if the webpage is framed using advanced techniques, the twitter displays the white page thereby dethroning the success rate of successfully framed web page. Give a shot yourself. Apart from this, twitter also throws X-Frame-Options header which adds another protection layer to use the inbuilt browser protection mechanism

Let's have a look at the Facebook

========================= FACEBOOK ==============================

function si_cj(m)
new Image().src="http:\/\/\/common\/scribe_endpoint.php?c=si_clickjacking&t=8340"+"&m="+m;
{throw 1;}var si_cj_d=["","\/pages\/",""];

var href=top.location.href.toLowerCase();

for(var i=0;i<si_cj_d.length;i++)

{if (href.indexOf(si_cj_d[i])>=0){throw 1;}}si_cj("3 ");}

catch(e){si_cj("1 \t");window.document.write("\u003cstyle>body * {display:none !important;}\u003c\/style>\u003ca href=\"#\" onclick=\"top.location.href=window.location.href\" style=\"display:block !
important;padding:10px\">\u003ci class=\"img sp_8lnh2w sx_fcd3c0\" style=\"display:block !important\">\u003c\/i>Go to\u003c\/a>");

============================ FACEBOOK ==============================

This code works appropriately and displays the small Facebook image with a link to main Facebook page in the Iframe as presented below

Facebook does not use declarative security protection feature

Google implements the code as follows

if (top.location != self.location) {top.location = self.location.href;}

It also implements the X-Frames-Options header to add another layer.

The cases discussed above are from the most explored websites. However, the normal scenarios are very bad. My suggestion is to implement both solutions collaboratively rather than sticking to one. The browser security guys are implementing inbuilt solutions and we should harness the power. The dual protection is always good.

Thursday, July 28, 2011

InfoJacking - A Walk through Social Networking Websites

Last month, I presented at Source Seattle conference. The slides are available for download from Cigital's website here. I also wrote some views about different cases of collecting information here. The detection of hidden devices such as WAF's , protection against advanced attacks are very much important. I discussed different cases in my presentation about collecting information from HTTP response headers. I thought to just move on and verify the state of some social networking websites.

The Facebook response header dump looks like as follows

(Status-Line) HTTP/1.1 200 OK
Cache-Control private, no-cache, no-store, must-revalidate
Expires Sat, 01 Jan 2000 00:00:00 GMT
P3P CP="Facebook does not have a P3P policy. Learn why here:"
Pragma no-cache
Set-Cookie; path=/;
Set-Cookie wd=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/;; httponly
Content-Encoding gzip
Content-Type text/html; charset=utf-8
X-Cnection close
Transfer-Encoding chunked
Date Fri, 29 Jul 2011 02:39:59 GMT

The highlighted part in the dump suggests that Facebook is running under the shadow of NetScaler [WAF + Load Balancer] device. On continuous observing and validating certain functions, I extracted some combinations of URL's and related HTTP header sent with it i.e. X-FB-Server

The X-FB-Server header value was changing with different responses. However, one thing remains same is the combination of X-FB-Server with X-Cnection. This simply projects that WAF + Load Balancer is playing a role.

However, Facebook does not reveal the web server information in Server header. Additionally, Facebook responses contain the "X-Backend :" header with different values. For informational purposes, the X-Backend header is sent by 3 different servers : nginx , Apache-Coyote and lighttpd primarily.

The point is HTTP response headers reveals a lot of information which can be potentially useful for testing purposes.

Tuesday, March 22, 2011

Google Chrome - Security Issues Reported So Far

I have enumerated the list of Google Chrome bugs given to Chrome security team.

Issue 2632:Google Chrome Carriage Return Null Object Memory Exhaustion Remote Dos

Issue 2877:Google Chrome Window Object Suppressing Denial of Service

Issue 4739: Google Chrome MetaCharacter URI Obfuscation Vulnerability

Issue 5978: Google Chrome FTP PASV IP Malicious Port Scanning Vulnerability

Issue 7099: Google Chrome ClickJacking Vulnerability

Issue 11158: Google Chrome document.write/throw exception DOM causes NULL ptr DoS

Issue 30972: Google Chrome XSS through MS Word Script Execution Object

Issue 53096: Google Chrome: HTTP AUTH Dialog Spoofing through Realm

Issue 75937: Google Chrome 10.0.648.133 XSS Filter Bypass

Monday, November 15, 2010

Responsible Disclosure - Redirection Vulnerability Video

The issue was reported to Oracle and was patched. This video simply shows the vulnerability.

Monday, August 23, 2010

User Interface Security - Google Chrome HTTP AUTH Dialog Spoofing through Realm Manipulation

Google Chrome ( 5.0.375.127 and previous versions) suffers from HTTP Auth Dialog spoofing vulnerability due to possible realm manipulation in the HTTP header. Previously, Google chrome has got a similar bug which can be seen HERE

This bug was actually patched. The issue mentioned in this bug was dialog spoofing due to long sub domain names. The patch worked only for that specific case which was outlined in that bug. There are number of tests have been conducted on Google Chrome
which verifies the inefficiency of Google Chrome to scrutinize the type of realm value set in the header. It can be tampered with double quotes and single quotes used in a definite manner.

Another related scenario: HERE

Note: Different variants have shown that these issues are still open and not patched yet.

As mentioned in RFC 2617: "The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge.The realm value (case-sensitive), in combination with the canonical root URL (the absolute URI for the server whose abs_path is empty;of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database.//The realm value is a string,generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realm/s"

So, realm value plays critical role in determining the framework of HTTP Access authentication for a particular resource. It has been analyzed that it is possible to spoof the HTTP Auth dialog by playing around realm values. This attack scenario
can be used to launch phishing attacks and stealing sensitive information from the legitimate websites.

As it has been released before, Google Chrome fails to sanitize the obfuscated URL and redirect it to the different domain. This potential flaw can be combined with the HTTP Auth dialog spoofing to launch attacks against legitimate websites. Looking at this particular point of time, certain solutions can be presented as

1. A new model of HTTP authentication dialog which shows the clarity between realm value and domain.

2. Setting a limit on size of strings to be passed as Realm value. This should not be applied on the string size of domain name.

3. Application of appropriate parameters in scrutinizing the strings passed in double quotes and single quotes.

Further: Tim from Vsecurity notifies about similar work related to HTTP Authentication. A very good paper has been presented HERE which covers lot of issues of HTTP authentication

The video is embedded below

Monday, August 09, 2010

Debugged MZ/PE - Holistic Approach to Analysis of Defective Threads

Threads are considered as second level structures used in the process execution. As per semantics, threads run as dynamic entities under processes. Whenever a new process is created in a system a number of threads are initialized. To understand the real cause of infection in processes, one has to traverse along the working proce­dure of a thread.

Online :

The hard cover will be release at Amazon : HERE