Wednesday, May 30, 2012

Traversing Trace.axd and Miconfiguration Glitch

Recently, I was going through attack research's blog post on trace.axd. Refer here The information present in trace files is always important and sometimes reap additional benefits from pen tester's perspective. There is some additional info I want to add because of misconfiguration in web server setup. Some simple information but worth while.

During my testing, I have seen that redirection misconfiguration of port 80  to port 443 including path entries can cause serious implications. I am taking a simple example of trace.axd. Triggering a google dork as (inurl:trace filetype:axd site:com),  results in several targets. Here is an interesting case study.

1. On accessing through browsers, the target results in following information

The response headers are:

(Status-Line)    HTTP/1.1 403 Forbidden
Cache-Control    private
Content-Type    text/html; charset=utf-8
Server    Microsoft-IIS/7.5
X-AspNet-Version    2.0.50727
X-Powered-By    ASP.NET
Date    Wed, 30 May 2012 18:41:24 GMT
Content-Length    2062

 The metasploit  produces the similar result.

2. This is not an end. Due to inappropriate configuration, the server can be accessed over HTTPS. Really, let's see.

The response headers for this request are

(Status-Line)    HTTP/1.1 200 OK
Cache-Control    private
Content-Type    text/html; charset=utf-8
Content-Encoding    gzip
Vary    Accept-Encoding
Server    Microsoft-IIS/7.5
X-AspNet-Version    2.0.50727
X-Powered-By    ASP.NET
Date    Wed, 30 May 2012 18:40:59 GMT
Content-Length    1322

In reality, the misconfiguration results in different results. By default, the content should not be allowed over both ports or similar error message should be displayed.

Use metasploit auxiliary module to extract all information or surf directly through browser.

The overall aim is to check all the entry points while doing penetration testing. 

Enjoy !

Thursday, May 24, 2012

Responsible Disclosure - XSS in ZScaler Gateway Application

Updated: I mentioned this issue to the Securityweek's author Steve Regan after reading his story here: He
quoted this blog past as an addition to the story.

Some of the XSS bugs were responsibly disclosed to the security team at ZScaler. Thanks to Michael Sutton for responding quickly. The vulnerability is patched now.

Proof of Concept is here:

We stick to responsible disclosure to build the community more secure.

Enjoy !

Sunday, May 20, 2012

McAfee or is it - Interesting !

Update: Seems like a legitimate service by McAfee. The geek-mode functionality  raised a suspicion. Thanks to anonymous for pointing this out.

I was looking for some interesting malware samples and came across with hilarious but rogue domain using McAfee name. It is actually a URL shortening service hosted on this domain. If you want to try, do it here by clicking this

Typically, the shortening and expansion process work as presented below>  s
> The shortened url is >> << [Copy]> e > The expanded url is >> << [Copy]>

Following URL's are accessed by this service for primary actions.

[1] hxxp://

[2] hxxpp://

The analysis of ZeroClipboard10.swf is present here :

Other interesting links are as follows:


The domain still up as for now. You might want to take a look :)