This post is about one of those vulnerabilities that you don’t envisage seeing again for some time but, nevertheless, still contains some valuable lessons, especially when it comes to how vulnerabilities can combine to produce different attack scenarios. While the scenario is rare for Internet-facing websites, developers and architects responsible for internal applications, especially legacy systems, may find the results of interest.
In the zone
The first alarm bell rang when we were told users were advised to make the website a Trusted Site within IE and, furthermore, to relax the Trusted Sites zone thus:
Initialize and script ActiveX controls not marked safe for scripting: Enable Access data sources across domains: Enable
Okay, not only are the alarm bells ringing but now the fire brigade is on its way. Such a configuration is (thankfully) very unusual for an Internet-facing web site, it’s more likely to be a prerequisite for an internal website, but that brings into play IE’s Local Intranet zone. What’s interesting about this point is that an internal web application may not require a relaxed security environment but it may be operating in one just because of where it is (i.e. intranet versus Internet).
This post doesn’t cover how IE decides under which zone a website falls (read this instead), nor does it wade through the myriad of zone settings; instead it just illustrates the impact of such a configuration in one particular case. The TL;DR if you need one is that a website in one of these zones (whether it’s there by design or accident) can significantly increase the impact of other vulnerabilities, putting users at increased risk.
Beyond the browser
The website under the magnifying glass was vulnerable to cross-site scripting (XSS) of both the reflected and stored variety, as well as an insecure file upload that accepted HTML files (with the same impact as stored XSS). Exploiting the upload flaw, a malicious HTML file was created that instantiated an ActiveX Data Object (ADO) Stream object, which can read and write files. When a user visited that page, it was possible to read a file from the victim’s hard disk without any user interaction, due to the relaxed security settings:
It would also be possible to write malicious files to the user’s computer, subject to that user’s permissions on the machine.
Another finding was that the file upload function worked unauthenticated. Realistically, however, the insecure upload could only be found by authenticated users of the application, as only they would know the URL of the upload function. Nevertheless, unauthenticated upload would allow a malicious user to upload documents anonymously, thereby making it more difficult to trace the source of an attack. The fact that uploaded files could also be accessed by unauthenticated users assists with exploitation, as victims would not need to be logged in to the website in order for an attack to succeed.
From bad to worse
A further impact scenario was demonstrated by changing a single line in the payload to read files so that the file being read was:
var file = "\192.168.33.133a.txt";
When this page was loaded, the victim’s machine tried to authenticate to the server at 192.168.33.133 using the Microsoft SMB protocol:
The authentication attempt was based on the user’s Windows operating system account – in this case, a test user whose password was set such that it would be simple to crack as a proof-of-concept:
In reality the success of this particular attack would not only depend on the strength of the user’s password but also the local environment, most notably whether the SMB connection from the user’s machine would reach the attacker’s server. If the attack was conducted within an organisation, it would be much more likely to succeed.
Another vulnerability that added an interesting twist to this tale was that the website could be framed. The ability to frame a site’s pages is typically exploited by clickjacking. Here, it could be combined with the unauthenticated access to allow payloads to be included in a third-party page (which the attacker has set up, compromised or altered in transit); for example:
A user of the application visiting the unrelated third-party site would be victim to the above attack against the user’s Windows credentials, silently executed in the background.
Lastly, a different payload was demonstrated that abused WScript.Shell to run executable content. In the example below, a user visiting a crafted HTML page previously uploaded by the attacker would be horrified by the Windows calculator launching (again without any user action):
If an arbitrary file could be pulled from a network share, or saved to disk (as suggested above) and then executed, this could lead to the installation of a remote access Trojan (RAT) to compromise the user’s machine.
And finally
In this post we’ve seen how the impact of simple web application vulnerabilities was made substantially worse by the site being in a relaxed IE security zone. We’ve also noted that internal web applications may be running in such a zone unexpectedly because, for example, they’re accessed by domain-less URLs like https://intranet/. Lastly, we’ve seen how vulnerabilities (some of which may be “low risk” when taken individually) can be used in combination to make exploitation easier.
Let’s close with some good news from Microsoft: “the need for ActiveX controls has been significantly reduced by HTML5-era capabilities”. This was the explanation behind Microsoft’s decision to drop ActiveX in their latest browser, Edge. Support for IE versions less than 11 was dropped in January 2016: when Microsoft does the same for IE11 itself, pages that rely on ActiveX will fail. So it’s in everyone’s interest to rewrite functionality dependent on ActiveX with code that uses HTML5 and JavaScript. In doing so, there should be no reason for websites to live anywhere but the Internet zone.
Written by Jerome Smith
First published on 02/06/16
