SuperFish 2.1: Dell System Detect’s "trusted site" makes users more vulnerable to exploit-based attacks

The recent SuperFish 2.0 incident has told us OEM machines are really bad on security. Today I finally got time to play into the issue and around. I happened to find that there is actually another problem, this time it is not about pre-installed root certificates, but a configuration problem which makes the user more vulnerable to targeted or drive-by attacks.

If you are using a Dell laptop, you probably know the "Dell System Detect" tool, it is a tool allowing you to install and update all the drivers as well as other Dell software automatically.

I've found that after we install the Dell System Detect, a specific domain name, "*.dell.com", will be added into the Internet Explorer's "Trusted sites". See following figure captured on my pretty old Dell laptop. The installed version is believed to be 6.11.0.2.

So, this is the problem I’ve found. But what does it mean? Why it is bad?

I’ve spend couple hours looking into the security problems such a “trusted site” may bring. Here is what I’ve found so far.

1. All webpages hosted at “*.dell.com” will be opened out of the Sandbox on IE (known as Protected Mode or Enhanced Protected Mode).

It means that a simple IE-based (say Flash exploit) hosted anywhere at “*.dell.com” will gain the same privilege of the current user immediately, because there is no IE Sandbox when you browsing these urls. Following figure shows the point.



According to my test, the same "no Sandbox" issue also exists on the "Metro Style" IE.

2. All the Office documents hosted at “*.dell.com” will be opened by Office out of the Office Sandbox (the Sandbox for Office is known as Protected View).

Usually, when a user downloads and opens a Word/PowerPoint/Excel document from internet, the document will be opened in Office with the Protected View mode. This is a very effective and important feature developed by Microsoft to help protect Office users. For example, we've known that attacking groups such as the Hacking Team use Flash-embedded Word documents to attack people, however, if the attacker hosts the malicious Word document on Internet, normal users won't be actually attacked because when they open the document the document will be opened within the Office Protected View Sandbox. But, if the attacker hosts the document somewhere on the “*.dell.com” domain, the document will be opened without the sandbox, and the Dell laptop user will be pwned right away.

Note that this not only affects users who use IE to download documents, but also for users using other browsers, such as Google Chrome. I've tested and found that when users use Chrome to download a “Dell-hosted” Word document, the document will also be opened without the Sandbox on Microsoft Word.

You may test it right away by downloading and opening this document released by Dell for “SuperFish 2.0”.
https://dellupdater.dell.com/Downloads/APP009/eDellRootCertRemovalInstructions.docx

Here is how it looks like when you are from a non-affected machine, all the Office documents we downloaded from Internet should act like this.

And here is on an affected machine, note there is no sign of “Protected View”, means there is no Sandbox.

Exploitation
So, the problem is clear now. Because of the "Dell System Detect" tool adds the "*.dell.com" into the Trusted sites, all the webpages hosted at “*.dell.com” will be opened out of the Sandbox on IE (both Desktop IE and Metro IE), and all the Office documents hosted at “*.dell.com” will be opened out of the Sandbox on Microsoft Office.

Readers may argue, hey, this is dell.com so it must be safe, right? well, it might be true if we agree all of the dell.com contents can't be hacked, but more obviously, the attacker can just use some tricks to host his/her malicious webpages or documents on somewhere on the *.dell.com and send the link to the victim. I’m not a XSS guy but I’ve heard of some tricks of “stored XSS” might help here. However, there’s an easier way - here is one of the tricks I found in couple minutes.

The Dell forum site (http://en.community.dell.com) is a sub-domain of dell.com, the forum allows registered users to publish their posts asking questions or opening discussions, it also allows users to attach files. So I made a test, I created one test account, made a post with a Word document attached, and see what happened then? My document is now being hosted on the *.dell.com domain.

Here is the link of my test document.
http://en.community.dell.com/cfs-file/__key/telligent-evolution-components-attachments/00-4674-01-00-20-84-98-02/dell.docx

In short, the attacker may use some trick to host their malicious exploit - such as a zero-day Flash exploit or a Word exploit - on the *.dell.com domain. Then, the attacker may send the link to the victims who have the Dell System Detect installed, in such a way the attacker "bypasses" the IE/Office Sandbox because there is no Sandbox at all.

Solution

First, I hope Dell to fix this security problem as soon as possible.

Users who have concerns about this issue are recommended to simply remove the "*.dell.com" in the IE's "trusted sites" window. Please note that according to my test, removing the "Dell System Detect" won't remove the trusted site setting, but I personally suggest you to remove the tool anyway in case it adds the trusted site back in future.

Conclusion
When we look back to the whole issue, all is because of a trusted site is added into IE's trusted zone. However, such a "trusted site" will surely lower user's security - specifically it makes users more vulnerable to exploits hosted at the "trusted site". For vendors who have a hobby to add "trusted site" - not just Dell, if you are not able to make %100 sure that all the contents hosted on your "trusted site" are harmless, please don't do it.

* Declaration: this post as well as other posts on this blog site reflect the author's personal opinions only.

Watch your Downloads: the risk of the "auto-download" feature on Microsoft Edge and Google Chrome

Probably it's commonly known that when you try to download something on your modern browser e.g. Google Chrome or Microsoft Edge, the file will be downloaded automatically to your local system with just a simple clicking - no need for additional confirmations. With default settings, the file will be downloaded to your "Downloads" folder ("C:\Users\<username>\Downloads").

Personally, I have worried about this feature quite some times, now I finally got some time on highlighting the risk for the public. (Please tell me if there's someone already talked about this, I quickly googled around and wasn’t able to find an appropriate one, I think it should be known by many ppl).

The "auto-download" feature is good from “user experience” perspective, but obviously it's not good for security, as the downloading could also be started by Javascript (<iframe src="url">). The attacker may just place a malicious DLL with a specific name into the "Downloads" folder when the victim visits a webpage he/she controls. In future, when the victim tries to download/install good programs (executables) from legitimate websites - of course, the good executable will be downloaded, and will be launched from the "Downloads" folder as well - then the installation/execution progress could be hijacked.

This is because that in the real world, most executables rely on dlls. The "application directory" is the very first place in the search order when searching/loading for a dll (you may want to check this paper I released years ago). So, probably, most of dlls even the system dlls could be hijacked when you place a same-named dll in the executable’s directory, and that's not for the situation that the searched dll doesn't exist anywhere on the system.

Usually, the "Downloads" folder is a place with massive downloaded files, so the victim probably never get a change to realize there is a malicious DLL sitting in his/her "Downloads" folder. I’d also doubt that even if a normal user notices a strange dll sitting in his/her "Downloads" folder, will he/she really delete it immediately? People may think that DLLs won’t be executed by themselves anyway, right?

Anyway, in the real world, for most people, who really check their "Downloads" folder every time when they try to install something from internet? Instead, most people just click the "Run" button directly when installing something (see following figure).



I have quickly made a video showing this risk. The test environment is Windows 10 Pro, with Microsoft Edge and Google Chrome, fully updated as of Oct 2nd, 2015, all with default settings. Check it out here.



As you may have noted, a modified “VERSION.DLL” will be dropped into the “Downloads” folder when visiting the webpage https://dl.dropboxusercontent.com/u/14747595/auto_download_test/test.html. Then, when the user tries to install Adobe Reader from the official adobe.com website, the installation process of Adobe Reader will be hijacked - the modified “VERSION.DLL” will be loaded and my shellcode will be executed.

There’s one small thing, the code execution should be run out of the browser sandbox, but unluckily the tested shellcode I copied from internet runs calc.exe, and because there’s no calc.exe anymore on Windows 10, what you’ve seen it’s just a Calculator App which runs within the App Container sandbox. Other shellcode, for example, running notepad.exe, will be run out of the App Container sandbox and give attacker the control of your system. #BringTheLovelyCalcBackMicrosoft!

Also note that with default setting, the Microsoft Edge will promote a warning dialog saying the DLL is dangerous, offering the user an option to delete the file.

But:

1) Anyway, the DLL has been already dropped into the "Downloads" folder, if the user chooses not to delete the file or just do nothing, future execution will still be hijacked.

2) I also guess this Microsoft Edge warning could be bypassed if the DLL is a signed DLL, but I don't have a certificate to test.

On Google Chrome, as you have seen, there's no warning at all.

[Updated on Oct 3rd, 2015 for Mitigations]
There's actually an option on Google Chrome (Settings => Show advanced settings => Ask where to save each file before downloading). As the name suggests, if you enable this, you will have a chance to check before every downloading. If you see some website asking you to download especially a DLL, you'd better DON'T ALLOW.

I haven't figured out a way for similar mitigation on Microsoft Edge, have pinged Microsoft, will updated if I find any.

Also please note that just changing the default "Downloads" folder to other folder does NOT mitigate this risk.

Thanks,

Haifei

Quick post: ASLR in China

The recent XCodeGHost incident tells how insecure it is for Chinese software. Personally I've been long-time aware of the huge problem in Chinese software, but I was still surprised that even the core developers from software giants enjoy such a terrible hobby: downloading 3rd-party development tool (or using p2p-based downloading tool to download development tool) - what business secrets you can hold if you fail to protect your core development environment? IMO the security of Chinese-based software is still in the Stone Age - They have gone so far and are still running so quickly while (unfortunately) there is no serious security review/process taken in place.

Here I'd like to quickly go through the most obvious issue: ASLR. What I have chosen here are the most popular software used in China, I think each of them enjoys hundreds of millions –level users. As you will find, none of them fully enables ASLR in their processes. Even ASLR have been introduced by Microsoft since 2007 and has been proven an effective mitigation to stop exploits and it's quite easy for developers to enable it.

This is what I saw on the latest Tencent QQ 7.6.

And here you go Baidu YuanGuanJia (百度云管家) .

The previous two are relatively good, I’d guess they know ASLR but failed on some of the DLLs. However, the following Xunlei (Thunder, 迅雷) is pretty bad: look at the dlls they shipped, almost all of them are non-ASLR (including 3 main programs), have they even heard of ASLR?

The Alibaba’s AliWangWang (阿里旺旺) (their popular tool for online purchasing and chatting) is also not good.

In the security world, ASLR is now a baseline for software security or in any software development – even Microsoft has started to credit findings of non-ASLR issues in their software. In this quick post we showcased the most obvious non-ASLR ones in the most popular Chinese software, this could be considered as a side view reflecting how bad it is for China's software security. However, their problem is far more than this, hopefully I will be able to contribute more time on them and write something down.

Thanks,
Haifei

Integrating Outdated Flash is a Bad Idea, Even Worse Running It Without a Sandbox

Shining the Light on the Security of Customized Browsers Used in China

When I traveled in China last time, I was quite surprised that the landscape of the software installed on Chinese PCs is quite different than what people have in the west, it looks like a different world. Usually, you will find a "central" tool that manages all the things for users, such as installing additional applications, installing security updates for the OS and applications. IMO all the things on the computer are "customized", a typical example is the browsers. People don't use the original Internet Explorer or Google Chrome, instead, they use the customized IE or Chrome, which is basically the IE/Chrome core plus a customized UI and additional features.

Here and here are 2 studies on the statistics about the customized browsers used in China.

As we know, building a secure browser is not an easy work, in fact, it's probably one of the most tough work in the security world (if you don't agree, try to find how many vulnerabilities have been patched in IE and Chrome). Thus, I was interested in how they can handle the security in their customized browsers. Some days ago, I decided to download the browsers and take a look, not surprised, a serious problem was identified in just few minutes.

The example I used is the Qihoo 360 Secure Browser, I found it's integrating a quite old Flash Player (specifically, the version is 11.6.602.180, about 2 years old). Even worse, the Flash plugin is running outside of a Sandbox. Following figure will show you the details.

What does this mean? Well, the most obvious scenario is that bad guys can use (any) previous (within 2 years) Flash exploits to attack the browser and gain the same privilege as the current user. You may have heard that Flash is really bad on security, you get it right. There are quite a lot of Flash working exploits out there for use to attack an outdated Flash Player.

I've made a video here demonstrating that an old Flash exploit (CVE-2015-0311) can still work perfectly on the latest (prior to my report) browser.

I have almost no words to say how bad it is. Think about it, hundreds of millions* are under the risk, while the attackers don't even need a zero-day to perform the attack - they can simply use a previous Flash exploit to take control of hundreds of millions of computers.

I've identified this problem on the Qihoo 360 Secure Browser as well as the Baidu Browser. I reported my finding to their product security teams immediately after my finding considering the seriousness of this issue, they took the issue very quickly and have already mitigated the issue within few days. For 360 Secure Browser, users are recommended to update their browser to 7.1.1.580.

Please note that this post is released with the pure purpose** of raising the awareness of this security problem in Chinese customized browsers. The theory is simple: if I could have found this security problem in minutes, it's highly likely that this problem has been well known by bad guys already. Moreover, the author hopes to inspire more whitehats to join the party to help secure all the Chinese software, most of these software are used by hundreds of millions but (unfortunately) their security are still at a pretty low level comparing to the software from international giants (e.g. Google, Microsoft). The author believes that Chinese computer users deserve the same security as others around the globe.

[Update on October 1, 2015]
As of October 1, 2015, The 360 Secure Browser is still running outdated Flash (specifically, 18.0.0.209) out of the Sandbox, see following figure. Basically it means that an old exploit (e.g. this one http://malware.dontneedcoffee.com/2015/08/cve-2015-flash-player-up-to-1800209-and.html) can be used to pwn any PC running the 360 Secure Browser easily. They seem to have fixed this (up-to-date Flash, running in the Sandbox) after I reported in April, but now rolled back, pretty bad idea from security point of view.



[Update on October 8, 2015]
After the Oct-1st update, researcher "mj0011" of Qihoo 360, has reached me about the Oct-1st finding on behalf of the vendor. They claimed that:

The browser could load 2 types of Flash runtimes when handling Flash contents: it will first detect if the computer's hardware supports WebGL, if it does, the browser will load the "pepperflash" - a Chrome-supported Flash runtime running inside the Chrome Sandbox. As the pepperflash runs inside a Sandbox, even the version is a little outdated, the impact of an exploitation could be mitigated.

On the other side, if the computer's hardware does not support WebGL, it then loads the NPAPI Flash, which runs outside a Sandbox. Unfortunately, due to compatibility issues of the newest Flash Players, they had to integrate the outdated Flash version. This is the situation I saw in the Oct-1st update.

While the outdated NPAPI Flash does introduce a immediate security risk, since most of the computers support WebGL - the pepperflash will be loaded instead of the NPAPI Flash, the overall security impact of the Oct-1st finding is limited.

Thanks,
Haifei

* According to http://se.360.cn, the 360 Secure Browser has a 400-million user base.
** Future explanations of this post, such as trying to embarrass any vendor, are not welcomed.