Tuesday, September 5, 2017

Re-enjoying the ActiveX (and others) Fun in Chinese Customized Browsers

TLDR: Running Chinese customized browsers could be like running IE6 on Windows XP (from security point of view), lots of proven-effective exploit mitigations could be disabled by simple tricks e.g. hosting webpage via IP address.


Background

When I was just jumping into vulnerability research many years ago, I had quite a lot of fun in ActiveX. For example, I found a remote code execution vulnerability (w/ working exploit) in the very-popular Alibaba's Alipay ActiveX control, among many others. I found them mostly through HD Moore’s AxMan fuzzing tool, I'm sure many security researchers had similar fun in the old days.:-)

Today, ActiveX isn't a hot security topic, mostly because the modern Internet Explorer  (IE11) has put several security enhancement features which limit the attack surface of ActiveX - the most significant one in my opinion is the “ActiveX preapproved list”, as it allows only a few number of “pre-defined” ActiveX objects to be loaded without user's permission. Another one is the IE sandbox (Protected Mode or Enhanced Protected Mode), the IE sandbox was not designed for ActiveX but as a generic solution it mitigates all code execution issues inside the browser’s rendering process.

Months ago, I “re-researched” the ActiveX stuff while digging into Microsoft Office (in case you don’t know, ActiveX is still very much supported on Microsoft Office). I thought it's better to understand the whole ActiveX attack surface on browsers first. However, as said, IE11 has a “preapproved list” so it makes not that convenient for testing, instead, I found it might be interesting to try a Chinese customized browser which usually comes with the IE engine.

The 360 Browser

I chose the 360 Browser since it’s the most popular one in China ((PS: Back to 2015, the author disclosed that the 360 Browser and the Baidu Browser had a significant security risk in its way of running Flash content)). The 360 Browser is basically a dual IE + Chrome engine with a customized UI among other features. When the user visits a webpage, the 360 Browser's main process will determine which engine to load but usually it will try using the Chrome engine first (since the Chrome engine is more secure and faster). However, there’re few interesting tricks I’ve seen which are able to “force” the 360 Browser to run with the IE engine. One trick is that if we use IP address (rather than domain name) to access the webpage, the 360 Browser will run in IE mode.

When running in IE mode, users may think they are just like using IE to browser the web, enjoying the same level of security of IE. However, it’s totally (unfortunately) not the case. Let me explain one by one.
  • The first, there isn't the “ActiveX preapproved list” feature, which is very important to limit the ActiveX attack surface. Without such a feature, almost all COM dlls on your system could be loaded in the 360 Browser process (360se.exe) (except those are in the IE killbit list, of course). If the ActiveX control is marked as "safe for initializing " and/or "safe for scripting", the ActiveX control could be initialized and/or run in the 360 Browser process.

    It means that the ActiveX attack surface is back to *that big* like the old days (think about that you’re using IE6 on Windows XP). How big it could be? For example, a clean Windows 10 OS could have as many as 5300 CLSIDs which means quite a lot of ActiveX object could be exploited, even, it doesn't consider third-party software which usually register many new ActiveX controls.

  • The second (and it actually surprised me), is that the DEP is in fact not set correctly for the content process of 360 Browser. If you look at the Process Explore screenshot later, the content 360se.exe process is NOT set to “DEP permanent”, which means the DEP status could be changed during runtime. And indeed, a simple “ActiveX loading” html page is enough to disable the DEP. I specifically put a debugger attaching on the content process and confirmed that all the heap bytes are executable even the memory page is not marked as executable.

  • The third "crazy" thing is that the IE sandbox (PM/EPM) is totally disabled. It means if the attacker get code execution in the content process (and who would think it’s hard to get code execution when you have a pretty wide ActiveX attack surface and DEP+ASLR is totally not working?), it’s basically a “game over”.

The following screenshot shows all the crazy things. The “DEP” but no “permanent” suggests the DEP isn’t working well. The Integrity level of the content process is “Medium” (as well as the webpage property showing “Protected Mode: Off”) shows the IE sandbox is disabled.


Tested on 360 Browser 8.1.1.250 running on Windows 10 64bit, full updated as of March 22, 2017.

The QQ Browser

Even I used the 360 Browser as a main testing target, this is a generic (and serious) problem in most (if not all) Chinese customized browsers when they turn to the IE mode. Similar problems could be easily identified on other Chinese customized browsers. For example, the Tencent’s QQ Browser, is also a dual IE + Chrome engine browser, and when you visit an URL where the server is IP address, the QQ Browser will also turn to IE mode. The author has identified the similar problems when the QQ Browser is running in IE mode:  1)the ActiveX “preapproved list” is not enforced 2)also the IE sandbox is disabled (showing in the following screenshot).



As far as I have seen, different than the 360 Browser, the DEP of QQ Browser’s content process is set correctly. However, it really doesn’t make much difference considering there’s no ActiveX “preapproved list” - an attacker could easily find a non-ASLR COM dll to defeat ASLR+DEP.

For example, if the victim has the QQ installed (which is also very popular in China), the attacker could host a webpage containing the following line:

<html><object classid="clsid:03766B5E-BD09-44db-8F92-510517AC2155"/></html>

When the QQ Browser visits the webpage, a non-ASLR dll named “RICHED20.DLL” will be loaded at a fixed address 0x3970000, which allows the attacker to easily defeat ASLR+DEP.



The issues were tested on QQ Browser version 9.5.4 (10632), full updated as of March 22, 2015.

Conclusion

As we have seen, the Chinese customized browsers basically disabled all the important/effective security features on IE when they’re running in IE mode. They didn’t enforce the ActiveX “preapproved list”. On 360 Browser, DEP is not working correctly, while on QQ Browser it’s easy to find a non-ASLR module to defeat ASLR+DEP due to the ActiveX “preapproved list” is not enforced. Also, they all disabled the IE sandbox.

It’s like the users (of the browsers) are running IE6 on Windows XP.

Disclosure & Vendor Solutions/Mitigations

After noting the issues in March, the author has worked with the 2 leading vendors in China, Qihoo 360 and Tencent, helping them resolve or mitigate the issues described above in the last several months (the author would highlight that the issues are common in other Chinese customized browsers as well but let's try address them for the leading ones first). The issues are reported to Qihoo 360 and Tencent on the same day, March 23rd, 2017. Following are solutions/mitigations I received from their security response teams (please note the author didn’t test or verify the solutions).

For 360 Browser, I was told that they have quickly addressed the “DEP disabled” issue. For the other 2 issues, in their “se8” version, they have added 2 setting options, to control enabling the IE Protected Mode and receiving promoted warnings when ActiveX control is loaded. They have provided me the following screenshot.


For their new “se9” version, the setting options look like the following.



Users should be noted that the offered options are not enabled by default, users who have concerns about the issues need to enable the options by themselves.

For Tencent QQ Browser, according to their feedback, they quickly addressed the “ActiveX control loading” issue with some Cloud technology, they haven’t addressed the “no Protected Mode” issue (they did mention they plan to address it in future releases). 

Future Thoughts

I could understand a bit that these terrible “security feature disabling” decisions are due to compatibility considerations in order to make the browsers work well when visiting Chinese legacy websites, I still remember that one of the popular banks in China requires users to use IE and install their ActiveX control in order to login their online bank service. But, certainly, as the leading vendors in China, there are pretty a lot of things to do to put security first while also handling compatibility issues well.

Disclaimer: this blog post serves as the pure purpose of raising awareness of security issues and it represents the author’s personal views only.