If at first you don't succeed; call it version 1.0
Tuesday, 27 March 2007

Version 3.0 of the exploits framework, Metasploit, is now officially released:

"...The Metasploit Framework ("Metasploit") is a development platform for creating security tools and exploits. Version 3.0 contains 177 exploits, 104 payloads, 17 encoders, and 3 nop modules. Additionally, 30 auxiliary modules are included that perform a wide range of tasks, including host discovery, protocol fuzzing, and denial of service testing..."

Now that Metasploit 3.0 is out, you can expect a first alpha version of VoMM very soon.

Tuesday, 27 March 2007 08:08:24 UTC | Comments [0] | Security#
Sunday, 18 March 2007

One of the comments for my post on the phishing hole in IE7 was that the anti-phishing tool of the browser will detect scams exploiting this vulnerability, because it will check the external javascript reference (e.g. In my PoC - http://www.raffon.net/research/ms/ie/navcancl/phish.js). I’m not an IE7 anti-phishing  internals guru, so I’ve decided to test it.
I’ve searched for a list of live phishing sites and found millersmiles.co.uk anti-phishing service. From the list I chose http://pqpal.com/cgi-bin/index.htm, which is a paypal phishing page.  IE7’s anti-phishing tool reports this as a phishing website.
To be able to use this phishing URL in my test, I’ve created a local DNS entry for pqpal.com and set it to my local web server.
To verify that the anti-phishing tool actually works with this local DNS entry, I’ve loaded the phishing URL in IE7, and got the phishing warning page again.
Next, I’ve created index.htm file under cgi-bin directory on my local web server. This file simply contains: alert(“Hello from phishing site!”);
For the proof-of-concept, I’ve created a HTML file with a reference to the external script - http://pqpal.com/cgi-bin/index.htm. When I’ve loaded this HTML file in IE7,  I got the “Hello from phishing site!” alert box, and no indication that this comes from a phishing URL.
This means that IE7 anti-phishing tool DOES NOT block pages with external scripts that points to a flagged URL. So, unless Microsoft will flag the navcancl.htm local resource as a phishing page, I see no other way for IE7 anti-phishing tool to detect phishing scams exploiting this vulnerability.
Again, until this vulnerability is fixed by Microsoft, do not trust any link in the “Navigation Canceled” page.

The proof-of-concept HTML file can be found here.

Sunday, 18 March 2007 08:39:12 UTC | Comments [2] | Security#
Wednesday, 14 March 2007

Internet Explorer 7.0 is vulnerable to cross-site scripting in one of its local resources. In combination with a design flaw in this specific local resource it is possible for an attacker to easily conduct phishing attacks against IE7 users.

Affected versions
• Windows Vista - Internet Explorer 7.0
• Windows XP - Internet Explorer 7.0

Technical Details
The navcancl.htm local resource is used by the browser when for some reason a navigation to a specific page is canceled.
When a navigation is canceled the URL of the specific page is provided to the navcancl.htm local resource after the # sign. For example: res://ieframe.dll/navcancl.htm#http://www.site.com.  The navcancl.htm page then generates a script in the “Refresh the page.” link in order to reload the provided site again when the user clicks on this link.
It is possible to inject a script in the provided link which will be executed when the user clicks on the “Refresh the page.” link.
Luckily, Internet Explorer now runs most of its local resources (including navcancl.htm) in “Internet Zone”, so this vulnerability cannot be exploited to conduct a remote code execution.

Unfortunately, there is also a design flaw in IE7. The browser automatically removes the URL path of the local resource and leaves only the provided URL. For example: when the user visits res://ieframe.dll/navcancl.htm#http://www.site.com, IE7 will show http://www.site.com in the address bar.

To perform a phishing attack, an attacker can create a specially crafted navcancl.htm local resource link with a script that will display a fake content of a trusted site (e.g. bank, paypal, MySpace).
When the victim will open the link that was sent by the attacker, a “Navigation Canceled” page will be displayed. The victim will think that there was an error in the site or some kind of a network error and will try to refresh the page. Once he will click on the “Refresh the page.” link, The attacker’s provided content (e.g. fake login page) will be displayed and the victim will think that he’s within the trusted site, because the address bar shows the trusted site’s URL.


A CNN.com article spoofing proof-of-concept can be found here.
If you are not using IE7, you can watch a demonstration video here.

Workaround / Suggestion
Until Microsoft fixes this vulnerability, do not trust the “Navigation Canceled” page!


Wednesday, 14 March 2007 11:47:09 UTC | Comments [20] | Security#
Saturday, 10 March 2007

Whether the vulnerability is cross-site scripting, cross-domain scripting or cross-zone scripting, sooner or later an attacker will need to inject a code in order to exploit it. The difference between each of these types is the context.

When we talk about a cross-site or cross-domain scripting vulnerabilities, we mean that an attacker can execute the injected code within the context of a different internet site or domain. However, when an attacker exploits a cross-zone scripting vulnerability, the context is now changed from an internet site to an intranet site, or even worse - pages in local zone.

Intranet sites and pages running in local zone are often and by default run with less security restrictions than internet sites. This means that if an attacker can execute his own code in intranet site or local zone, he will eventually be able to execute malicious code on the victim's machine.

A good example for the difference between those vulnerability types is the quicktime vulnerability that was found by pdp. When this vulnerability was exploited by the Myspace worm, this was a cross-site vulnerability. Only internet sites were involved, and it was used to steal MySpace accounts information. In MoAB#3, I've introduced a way to exploit this vulnerability in the context of local-zone. This means, that it is now a cross-zone scripting vulnerability, and an attacker can use quicktime to execute malicious code on the user's machine.
MoAB#3 also used another vulnerability found by hdm in one of the local resources of Win2k. As Internet Explorer restricts linking to local resources (res:// files), I used quicktime to do it.

Lately, I've found that it is possible to open a local resource in Internet Explorer without the need for any additional plug-in (like quicktime). By using a simple redirection header, an attacker can link and open a local resource and bypass Internet Explorer's restriction. I've tested this on IE6 SP2, IE7 and IE7 on Vista.
Now, this alone might not be a big issue, as Microsoft now runs most of the local resources in the Internet Zone, but it might be used to perform other types of cross-site scripting attacks.


Saturday, 10 March 2007 23:26:18 UTC | Comments [1] | Security#
Send me an Email
Follow me on Twitter
RSS Feeds
Admin Login
Sign In
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.