Easy Brute-Force Web Password Cracking with HTML Applications

#1 2008-06-18 by Awesome AnDrEw

Unfortunately your blog does not want to allow my comment (perhaps it's too long). Being that I've just done quite a bit of experimentation with the HTA file over the past hour I have concluded that while it's not bound by the cross-domain policy and the rest of the security features as the browser normally is third-party resources within elements such as the IFRAME are. In other words the HTA document has access to the IFRAME and the DOM within it, but not vice versa. This makes it difficult to detect if the content is being accessed from an HTA file, because the clientWidth returns a value greater than 0, the parent location is not accessible, and unlike Microsoft Internet Explorer 7's MHT file local file system paths are not inadvertantly leaked to remote servers (HTTP GET requests made from MHT files to third-party images appear with a referrer pointing to the file:// protocol). Any ideas as to how it would be possible to prevent such an attack?

#2 2008-06-19 by Johann

Andrew,

thanks for the extra test. I did find that clientWidth was 0 in my tests. What version of Internet Explorer were you using?

If clientWidth doesn't work anda there's no other property that has an unusual value, it's going to be hard to detect this.

#3 2008-06-20 by Awesome AnDrEw

Since the contents of the IFRAME fall within the context of the browser's normal security policies Javascript "frame-busters" will not work, because they cannot access anything outside of themselves. The value returned by parent.frames.length is a constant 0, and so the rest of the statement never executes, and neither will code following "if (self.location != top.location){}". So as far as I can tell we've hit a roadblock, but I am willing to test whatever anyone can come up with.

#4 2008-06-25 by Awesome AnDrEw

I used Microsoft Internet Explorer 7 to perform each of the trials using the HTA file. Running the first few sets of tests I examined the possibilities created due to the application's elevated privileges. As you stated it completely circumvents the cross-domain policy in addition to other ActiveX security settings, which allow methods such as window.close() to execute without a confirmation prompt. All inline, or remote client-side scripts embedded within the page being loaded into the HTA's IFRAME however are bound by the cross-domain restriction, cannot access the parent document, and instead throw a "Permission Denied" or "Access Denied" error.
The HTTP GET request generated by the IFRAME is no different than if it had been created by a normal webpage, and the User-Agent does not provide any additional parameters to hint that the resources are being viewed using the file. Any images hotlinked from a remote server, and placed directly in the file drop the referrer header as well. So I am pretty much out of ideas as to how this would be possible to detect, and mitigate :-[.

#5 2008-06-25 by tm

try this it used to work if (self.parent.frames.length != 0)
self.parent.location="test2.html"