Looking back this year’s RSA Conference, you might have the feeling that the current threat landscape is primarily a series of advanced attacks. This concept includes well-known advanced persistent threats (APTs) and zero-day vulnerability exploits. To respond to this trend in threats, McAfee Labs has launched several innovative projects, one of which we call the advanced exploit detection system (AEDS). The AEDS is based on our in-depth understanding of application security, which comes from our long-term cutting-edge research efforts. We have already seen some interesting results that reflect the effectiveness of the project.
Recently, we detected some unusual PDF samples. After some investigation, we successfully identified that the samples are exploiting an unpatched security issue in every version of Adobe Reader including the latest “sandboxed” Reader XI (11.0.2). Although the issue is not a serious problem (such as allowing code execution), it does let people track the usage of a PDF. Specifically, it allows the sender to see when and where the PDF is opened.
The vulnerability
When a specific PDF JavaScript API is called with the first parameter having a UNC-located resource, Adobe Reader will access that UNC resource. However, this action is normally blocked and creates a warning dialog asking for permission, such as we see below:
The danger is that if the second parameter is provided with a special value, it changes the API’s behavior. In this situation, if the UNC resource exists, we see the warning dialog. However, if the UNC resource does not exist, the warning dialog will not appear even though the TCP traffic has already gone.
The following screen capture shows the outgoing traffic:
How does this affect users?
Is this a serious problem? No, we don’t want to overvalue the issue. However, we do consider this issue a security vulnerability. Considering this, we have reported the issue to Adobe and we are waiting for their confirmation and a future patch. We will also hide the key details of the vulnerability to protect Reader users. We may update this post at some point after we see a patch from Adobe.
Some people might leverage this issue just out of curiosity to know who has opened their PDF documents, but others won’t stop there. An APT attack usually consists of several sophisticated steps. The first step is often collecting information from the victim; this issue opens the door. Malicious senders could exploit this vulnerability to collect sensitive information such as IP address, Internet service provider, or even the victim’s regular routine. In addition, our analysis suggests that more information could be collected by calling various PDF JavaScript APIs. For example, the document’s location on the system could be obtained by calling the JavaScript “this.path” value.
Who is exploiting this issue?
We have detected some PDF samples in the wild that are exploiting this issue. Our investigation shows that the samples were made and delivered by an “email tracking service” provider. We don’t know whether the issue has been abused for illegal or APT attacks.
Conclusion and protection
This interesting case highlights the point that privacy protection is a part of security. It shows that we can form different opinions depending on our goals (such as security protection vs. email tracking service).
This case also demonstrates that we need to constantly explore methods of detection because these examples won’t trigger memory corruption or code execution. Some of the most advanced detection technologies in the industry failed to detect them. We are happy to see that our AEDS is filling the gap.
Until Adobe creates a patch, Reader users should consider disabling JavaScript in Reader.
Thanks to my colleagues Bing Sun, Xiaobo Chen, and Chong Xu for their help with this investigation.