Break things, write reports

XSS in the trusted zone is drive-by RCE

Seemingly everyone has forgotten how internet explorer works

Tags — | internet explorer | Categories: — windows |
Posted at — Oct 24, 2020

Tl;dr

<script>
      var ws = new ActiveXObject("WScript.Shell");
      ws.Exec("c:\\windows\\system32\\calc.exe");
</script>

Find some webapp in the trusted zone, get XSS in it, pop calc on all visitors using IE.

Trusted Zone

For those who have worked in corporate, you’ve probably needed to use Internet Explorer for something that’s both critical to not getting yelled at by your boss, and also critical that you use so you get paid. Normally, these are things like Payroll, Timesheets, or Mandatory training nonsense, which meets the above two criteria nicely. If you work in Security, and in more of the offensive side, you probably probably don’t like using IE for a few reasons:

I suspect everyone’s aware of the first 3 points, but the third point seems to be a little less-known, even though it’s been previously reported by places like:

This is to exclude things like pro-hackers.com (https://pro-hackers.com/get-access-when-people-visit-website/), which appears to be some auto generated garbage using the metasploit module built in 2008 but not explaining how or why it’s important. Continuing to shit on someone elses “content”, it was “written” in 2019 but describes using “BackTrack 5”, which was replaced by Kali in 2013, and says “root” access even though we know the targets are Windows boxes.

Anyway.

Intenet Explorer has a few different “zones”, which other browsers don’t really have a concept of. IE breaks it down into:

These basically end up being a list of different origins and have different rules applied, things like allowing kerberos auth or relaxing the same origin policy.

For an actual breakdown, I’d recommend reading the source materials (https://support.microsoft.com/en-us/help/182569/internet-explorer-security-zones-registry-entries-for-advanced-users)

The big scary one is 1201 ActiveX controls and plug-ins: Initialize and script ActiveX controls not marked as safe for scripting, which is normally enabled for the Trusted Zone, and allows the browser to automatically execute ActiveX controls without user input or a prompt.

Consider the following script:

<script>
      var ws = new ActiveXObject("WScript.Shell");
      ws.Exec("c:\\windows\\system32\\calc.exe");
</script>

If you are able to get this into a site within the trusted zone, either through reflected or worse, stored cross site scripting, visitors using IE to browse the site (i.e. users on the corporate network, using the corporate SOE, with said configuration), are going to have a big fat calculator pop up when they browse the site.

Obviously, this isn’t ideal as a defender, but is pretty top tier as an attacker!

What’s in the trusted zone?

Good question. If your target uses Dynamix CRM, it’s likely quite a few websites (KB 2655102, https://support.microsoft.com/en-us/help/2655102/internet-accessible-urls-required-for-connectivity-to-microsoft-dynami). Notably, this includes things like:

Notably, these are websites that you can just host content on as a regular user, *.windows.net is just azure blob storage (https://azure.microsoft.com/en-au/services/storage/blobs/), so anyone can sign up and host content, which will give you a lovely foothold in an environment.

There’s also some indications these might just be needed for O365 bits in general (https://techcommunity.microsoft.com/t5/deployment/trusted-sites-and-local-intranet-assigment-for-office-365/m-p/127034), which doesn’t seem to list windows.net, but a lot of unofficial guides seem to include weird domains. These are probably the guides your target are following, as sysadmin documentation seems to be easier to find on Reddit than on MSDN.

Unsure about some of the other domains in there like *.crm9 (Is that also user hosted content? Probably a good TODO, for anyone with a Dynamics CRM).

Addendum - Crappy phishing

Most of the lame phishing seems to be aware of windows.net, but not that it’s probably RCE in most cases for organisations using Dynamics CRM. This hasn’t been unnoticed (https://www.bleepingcomputer.com/news/security/phishing-attack-uses-azure-blob-storage-to-impersonate-microsoft/), but no one’s seemed to put two and two together that they could just be getting RCE on an endpoint and getting a lovely foothold in an environment, instead of just crappy credential phishing.

A lot of these seem to be added to the trusted zone for things like Kerberos auth (https://blog.peterdahl.net/2017/09/12/login-windows-net-still-needs-to-be-added-to-trusted-sites-in-internet-explorer/), so a lot of orgs are going to just have this set without much further insight.

Addendum - Legacy applications

Normally, having to use IE is horrid by itself - The trusted zone is going to have Legacy Applications(TM), which roughly translates to “Things we need but don’t want to upgrade because it’s expensive”. Legacy is also anotehr word for ‘probably insecure’, and is commonly riddled with things like cross site scripting - which if it’s in the trusted zone, you now get drive-by RCE on endpoints that browse it with Internet Explorer.

The best bit? If it’s in the trusted zone, it’s probably because the webapp needed some silly feature, so people who browse it are likely to be running IE when using it - you’re going to end up with RCE :)

Alternatively, there’s the local intranet zone, which is almost the same except you’ll get an awful prompt asking if you want to run ActiveX objects, and lots of things get put here automatically. User interaction is a kind of lame thing to rely on, but they’re probably going to click yes anyway, and if you get stored XSS on some app everyone uses, it’s just going to be a numbers game anyway.

Enjoy!