Anatomy of OpenSSL and Penetration Testing - Breaking Benjamin

SSL is one of the most attractive and shocking protocol in myriad of ways. There is always something different about this protocol. Considering the real time security testing, you might encounter tricky scenarios while handling sessions with the SSL. OpenSSL is widely used to deploy the SSL as a open source platform. Apache configured with mod_ssl is used heavily for this purposes. During open research and technical verification, we (me and my friends) came across a domain (www.ebay.in) having bad SSL implementation. So I thought to write a detailed post on this issue. The aim of this post is to understand the unexpected variance in the responses of the remote server when SSL connection is initiated using different OpenSSL versions

Target check : www.ebay.in [ For educational purposes only].

A simple host discovery gives the following information which suggests that DNS load balancer is in place. Since it is a heavy eCommerce website, one must expect this.

root@bt:~# host ebay.in
ebay.in has address 66.135.200.23
ebay.in has address 66.135.215.61
ebay.in mail is handled by 10 data.ebay.com.
ebay.in mail is handled by 10 gort.ebay.com.
ebay.in mail is handled by 10 lore.ebay.com.

root@bt:~# host www.ebay.in
www.ebay.in is an alias for ebay.in.edgesuite.net.
ebay.in.edgesuite.net is an alias for a142.g.akamai.net.
a142.g.akamai.net has address 204.245.162.34
a142.g.akamai.net has address 204.245.162.59

This website is accessible over HTTP and HTTPS, this gives a straight forward information regarding the open ports 80/443. One can expect redirection parameters defined on server side to automatically redirect the incoming HTTP requests to HTTPS.
Further, when a simple GET request is issued to the server, it responds back with the following HTTP responses

(Status-Line) HTTP/1.0 200 OK
Server Apache-Coyote/1.1
Content-Encoding gzip
Content-Type text/html;charset=UTF-8
Content-Length 9986
Vary Accept-Encoding
Expires Fri, 05 Aug 2011 18:08:39 GMT
Cache-Control max-age=0, no-cache, no-store
Pragma no-cache
Date Fri, 05 Aug 2011 18:08:39 GMT
Connection keep-alive
Set-Cookie ebay=%5Esbf%3D%23%5E; Domain=.ebay.in; Path=/
Set-Cookie dp1=bu1p/QEBfX0BAX19AQA**501d6527^spref/20351fe98a7^; Domain=.ebay.in; Expires=Sun, 04-Aug-2013 18:08:39 GMT; Path=/
Set-Cookie cssg=9b21f5741310a02652e39d83ffdf018c; Domain=.ebay.in; Path=/
Set-Cookie s=CgAD4ACBOPYMnOWIyMWY1NzQxMzEwYTAyNjUyZTM5ZDgzZmZkZjAxOGPrM83K;Domain=.ebay.in;Path=/; HttpOnly
Set-Cookie nonsession=CgADKACBXojMnOWIyMWY1NzQxMzEwYTAyNjUyZTM5ZDgzZmZkZjAxOGYAywABTjw4rzGpIP/j; Domain=.ebay.in; Expires=Sat, 04-Aug-2012 18:08:39 GMT; Path=/

The Server header points to the Apache-Coyote/1.1 which may be running this flavor of Apache. Usually, it is true in number of cases.

The first three tests are conducted using OpenSSL, cURL and SSLScan in general. This host is a backtrack machine with an OpenSSL 0.9.8k 25. In this , the aim is to verify the presence of SSLv2

root@bt:~# openssl version / OpenSSL 0.9.8k 25 Mar 2009

root@bt:~# curl --version
curl 7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

Test 1: Using OpenSSL, following response is detected which shows the acceptance of SSLv2.
root@bt:~# openssl s_client -connect www.ebay.in:443 -ssl2
CONNECTED(00000003)
subject=/C=US/O=Akamai Technologies, Inc./CN=a248.e.akamai.net
issuer=/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
---
No client certificate CA names sent
---
Ciphers common between both SSL endpoints:
RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5
EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5
---
SSL handshake has read 995 bytes and written 236 bytes
---
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
Cipher : DES-CBC3-MD5
Session-ID: E03D2C3CCD43347B13383DA55F2FD326
Session-ID-ctx:
Master-Key: 16011C613D2E862A91FD0A069AF1FFAE5058F0BFEADB87F0
Key-Arg : A9D372330CD89517
Start Time: 1312569173
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)


Test 2: Using cURL to verify the state.
root@bt:~# curl -v -2 https://www.ebay.in -k
* About to connect() to www.ebay.in port 443 (#0)
* Trying 204.245.162.34... connected
* Connected to www.ebay.in (204.245.162.34) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv2, Client hello (1):
* SSLv2, Server hello (4):
* SSLv2, Client key (2):
* SSLv2, Client finished (3):
* SSLv2, Server verify (5):
* SSLv2, Server finished (6):
* SSL connection using DES-CBC3-MD5
* Server certificate:
* subject: C=US; O=Akamai Technologies, Inc.; CN=a248.e.akamai.net
* start date: 2010-10-06 16:41:56 GMT
* expire date: 2011-10-06 16:40:47 GMT


Test 3: Using SSLScan to verify the state.
root@bt:~# sslscan www.ebay.in
Version 1.8.2
Testing SSL server www.ebay.in on port 443

Supported Server Cipher(s):
Accepted SSLv2 168 bits DES-CBC3-MD5
Accepted SSLv2 56 bits DES-CBC-MD5
Accepted SSLv2 40 bits EXP-RC2-CBC-MD5
Accepted SSLv2 128 bits RC2-CBC-MD5
Accepted SSLv2 40 bits EXP-RC4-MD5
Accepted SSLv2 128 bits RC4-MD5

It has been verified that this particular domain is accepting SSLv2 and all the testing output has confirmed this. Note , in this OpenSSL version 0.9.8k is used.

Now moving on to second set of tests with same tools having updated version of OpenSSL as follows

user@ubuntu:~$ openssl version / OpenSSL 0.9.8o 01 Jun 2010

curl 7.21.3 (i686-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

The versions are different. In order to conduct security testing of SSL, the same tests are conducted again.

Test 4: Verifying the SSLv2 (updated OpenSSL)
user@ubuntu:~$ openssl s_client -connect www.ebay.in:443 -ssl2
2543:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453:

The connection over SSLv2 fails. Let's move on to next case

Test 5: Verifying the SSLv2 (updated cURL)
user@ubuntu:~$ curl -s -v -k https://www.ebay.in -2
* About to connect() to www.ebay.in port 443 (#0)
* Trying 204.245.162.34... connected
* Connected to www.ebay.in (204.245.162.34) port 443 (#0)
* SSL: couldn't create a context!
* Closing connection #0

cURL also fails for the SSLv2. Jumping on to next and final test

Test 6: Verifying the SSLv2 (SSLScan)
user@ubuntu:~$ sslscan www.ebay.in
Version 1.8.2

ERROR: Could not create CTX object.

Testing SSL server www.ebay.in on port 443

Supported Server Cipher(s):
Rejected SSLv3 256 bits ADH-AES256-SHA
Rejected SSLv3 256 bits DHE-RSA-AES256-SHA
Rejected SSLv3 256 bits DHE-DSS-AES256-SHA
Accepted SSLv3 256 bits AES256-SHA
Rejected SSLv3 128 bits ADH-AES128-SHA
Rejected SSLv3 128 bits DHE-RSA-AES128-SHA
Rejected SSLv3 128 bits DHE-DSS-AES128-SHA

In this test, no SSLv2 output (rejected/accepted) is there. However, one can see that "ERROR: Could not create CTX object" notification which primarily is an outcome of the fact that SSLScan fails to instantiate context for SSLv2.

As it is known in the wild that all the newer version of browser hardly initiate connection using SSLv2. It looks like OpenSSL 0.9.8o 01 is doing the same way. Hardening the client straight away so that only updated version of protocol are used to do that.

Note: for penetration testing, my personal advise is to use OpenSSL 0.9.8k 01 or any version less than <= k for strong testing. It is also a good choice to use <=k versions and also > k versions to differentiate the output.

Giving a final check on the certificates (www.ebay.in), it has been noticed that certificate is already expired


and the amazing result is also presented below



So overall, this situation is really bad for an eCommerce website. For verification tests of SSL one should not rely on single tool. It is preferable to use OpenSSL, cURL and SSLScan as an overall tool set and the protocol should be fuzzed appropriately. Be sure of the OpenSSL version you are using.

NOTE: Additionally, declarative security can also be used to prevent MITM attacks. I will be releasing Mozilla Firefox addon soon (under review). This addon is capable of detecting Strict-Transport-Security parameter in HTTP response header and notify the penetration tester about the usage of declarative security (whether the server wants to harness the browser protection)



Stay tuned. Enjoy !

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.top.location = window.self.location;
setTimeout(function() {
document.body.innerHTML = '';
}, 0);
window.self.onload = function(evt) {
document.body.innerHTML = '';
};
}
if (window.top !== window.self) { // are you trying to put self in an iframe?
try {
if (window.top.location.host) { // 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)
{
setTimeout(function()
{
new Image().src="http:\/\/error.facebook.com\/common\/scribe_endpoint.php?c=si_clickjacking&t=8340"+"&m="+m;
},5000);
}
if(top!=self)
{try{if(parent!=top)
{throw 1;}var si_cj_d=["apps.facebook.com","\/pages\/","apps.beta.facebook.com"];

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 Facebook.com\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.

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: http://fb.me/p3p"
Pragma no-cache
Set-Cookie reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2F; path=/; domain=.facebook.com
Set-Cookie wd=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com; httponly
Content-Encoding gzip
Content-Type text/html; charset=utf-8
X-FB-Server 10.54.249.30
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

https://www.facebook.com/login.php?login_attempt=1
X-FB-Server 10.36.129.112

http://www.facebook.com/home.php?sfrm=1
X-FB-Server 10.36.252.123

http://static.ak.fbcdn.net/rsrc.php/v1/yn/r/l2REPOIm5eD.css
X-FB-Server 10.138.17.184

http://static.ak.fbcdn.net/rsrc.php/v1/yp/r/uRff5za-w5e.css
X-FB-Server 10.138.64.186

http://static.ak.fbcdn.net/rsrc.php/v1/yT/r/cWd6w4ZgtPx.png
X-FB-Server 10.30.147.194

http://www.facebook.com/ajax/chat/buddy_list.php?__a=1
X-FB-Server 10.42.74.73

http://www.facebook.com/ajax/chat/buddy_list.php?__a=1
X-FB-Server 10.43.50.79

http://www.facebook.com/ajax/hovercard/user.php?id=1036258667&__a=1
X-FB-Server 10.42.174.47

http://www.facebook.com/ajax/ufi/modify.php?__a=1
X-FB-Server 10.42.108.21

http://www.facebook.com/?ref=logo&__a=20&ajaxpipe=1&quickling[version]=412753%3B0
X-FB-Server 10.42.118.79

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.

Malvertising Paper - Elsevier CFS Journal

Malvertising - Exploiting Web Advertising | Elsevier Computer Fraud and Security Journal

View more documents from Aditya K Sood

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 1.0.154.43 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

Responsible Disclosure - Oracle.com Redirection Vulnerability Video

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

ISSA Journal - JavaScript Infection Model

Check out my paper on JavaScript Infection Model published in November issue of ISSA journal.

https://www.issa.org/Members/Journal/

HackInThe Box EZine - DataCenter Hacking Paper / My Interview

Check out my interview and our paper on data-center hacking through helpdesk support systems.

http://magazine.hitb.org/issues/HITB-Ezine-Issue-004.pdf

ECCouncil Botnet Briefing Slides

EC Council - Botnet Briefings

View more presentations from Aditya K Sood.

HackerHalted Miami 2010 - Slides

Hacker Halted Miami , USA 2010

View more presentations from Aditya K Sood.

OWASP AppSec USA - Slides and Presentation

OWASP App Sec US - 2010

View more presentations from Aditya K Sood.

Aditya K. Sood, Bug-Alcoholic 2.0 - Untamed World of Web Vulnerabilities from AppSec USA 2010 on Vimeo.

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