2013年10月15日星期二

Document Tracking: What You Should Know

Back in April this year, I found a PDF tracking issue at my daily work. While obviously the issue was due to a security flaw - Adobe has confirmed that as they patched it as security vulnerability CVE-2013-2737*, the story didn't stop there. I looked into this type of issues in a matter of wider way in my free time, the result kinda surprised me: actually almost all the popular document types we are using nowadays have the problem.

The affected document types include PDF on the latest Adobe Reader 11.0.5, Word, PowerPoint as well as Excel documents on the latest Microsoft Office 2010, also it should be the same thing on other Reader and Office versions. I am not able to go every piece of technical details right now, instead, I’d go a quick explanation.

Usually, in my conservative mind, I think a "document" should not connect to any unauthorized address without my permission, the “authorized address” could mean a domain or IP address owned by the vendor, or a domain/IP that is authored by the vendor. Specifically, I don't want the document I received via email to “phone back” to a server that is controlled by the document sender, when I open the document. If so, I think there is a “document tracking” issue, no matter what the original purposes the “phone back” communications would be. The sender controls the server, so he/she is able to collect information about readers’ activities, which includes (at least) when (time) and where (IP address) reader opened the document.

Unfortunately, based on my research, the documents are not those "simple" documents anymore that we thought in old times. With a great number of features added to the applications, there are various ways to achieve the "document tracking".

The Issues
So, let’s talk about the issues I found. The new PDF tracking issue is obviously because of a default feature - which allows PDF issuers to control over the document, it actually has more power – it can control who and when is able to open the PDF, with which privilege(s) (such as opening, printing and editing) the user may be granted.

The Word document will try to access a remote UNC resource, in this case the UNC resource is not correctly configured so the following “start bar” showing it’s connecting to the sever will appear, I don’t think the dialog will still be there when the resource sits correctly on that server.














The PowerPoint issue I found was a remote image access via HTTP protocol, Office PowerPoint 2010 will display a warning message to users, as being showed below. Unfortunately the traffic is still made out so I guess it's an implementation problem, probably.











The Excel issue was trying to access remote images as well, it went smoothly without any warning or hint, see the following traffic I captured.










I wanted to highlight that the above particular issues are only a part of the problems in those applications – there are actually more I’ve found, but I am not going to list each of them.

Is There Anybody Actively Leveraging the Issues?
It's not hard to find out, a simple Google search will give you the fact that there are pretty a number of "document tracking service” providers leveraging the issues as doing their businesses. In addition, I happened to learn that back to year 2006/2007, one of the service providers (readnotify.com) was hired by a well-known IT company to help them investigate a confidential information leakage. They tried to collect information about the CNET reporter who wrote the news report by leveraging the document tracking issues. It later led to a testimony at the U.S. House of Representatives, check out the story here.

The Remaining Questions
So, is this a big problem? It’s hard to say – it really depends on how much you care about privacy. As a researcher, the thing it bothers me a bit is that I couldn't find any opinion from the vendors about this kind of issue – do they really think it is a problem that they’d like to take actions? As discussed, the "zero-day" issues I found are not due to security faults (not like the previous PDF CVE-2013-2737), they are features! You can ask vendor to fix a security vulnerability but you can't ask them to remove a feature.

Finally, while I am pretty pessimistic about that the problems will be corrected in future, people should know the fact at least: when you open documents on your computer, keep in mind that you may be being tracked, no matter whether you are using the latest application or not.

I can’t give any useful mitigation or workaround since the traffics go via the most popular protocols and the destination port could vary, as we can’t block any traffic going outside.

* Though, I have no idea why Adobe didn't credit me. :P

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

2013年2月7日星期四

Strange Behavior in Windows Remote Desktop’s File-transfer Function

I am sure most of you enjoy the Remote Desktop feature on Microsoft Windows, for a typical use for people's work is they use it a lot when they need to connect to a Windows Server machine (which is in their "Labs") from their desktop. I am also a 3389 fan, and for me, one of the most convenient functions is I can simply transfer files between our desktop and remote server, you just need to "CTRL+C" and "CTRL+V".

Recently I'v been working on a project which is trying to provide some real "view" on real-world exploits, in that work I need to use some old-style OS such as Windows XP. One day, when I tried to copy some files from a remote Windows Server 2008 R2 to my local XP, some really strange things happened.

The file(s) I copied actually was changed silently, which means, it's not the same file that sits on my server! Honestly, when I first realized this, it really confused me a lot.. I tried to figure out what's going on there, and here comes more details.

The first file is a Flash sample named "AutoFitArea_Demo.swf" (SHA1: D204CFDC7DEF3D9D00B300593D67B8AB95BBB751). When you copy it from a Windows Server 2008 R2 to Windows XP SP3 (all systems are up-to-date). The file will be modified to this one (SHA1: AC3FAB01672DB24EDF3A3D7839ABCB9271C23384).

The another file is a txt file, I am not able to share with you the original file but I did some future work, here is the PoC for my environments, if you copy a simple file which has 7,533,27 (0xB7EAF) characters of 'A', you will find that it becomes to 7,536,640 (0x730000) characters of 'A', which means 3363 (0xD23) bytes of 'A' are added.

So, what happened? Let's take a look at the AutoFitArea_Demo.swf case, here is the comparison figure:










As we can see, the original file was added with 0x3867 bytes from the end of the file, future study shows that the added 0x3867 bytes are actually from the original file from the position 0x14799. The structure looks like the following:

<Data1>            length: 0x14799
<Data2>            length: 0x3867
<Data3>            length: 0xC799

So the original file comes to a total length:
0x14799 + 0x3867 + 0xC799 = 0x18000 + 0xC799 = 0x24799 (149401)

And, the structure of the modified (new) file is:

<Original Data>    length: 0x24799
<Data2>            length: 0x3867

And the new length is:
0x24799 + 0x3867 = 0x28000 (163840)

At this point, I am sure some smart readers have had some interesting findings:

1. The new length (0x28000, 0x730000, as highlighted above) are divisible by 0x28000 (0x730000 / 0x28000 = 0x2E).
2. The added data matches the ending bytes of the block whose size is 0x18000, as indicated by that the total length of "Data1" and "Data2" is 0x18000.
3. However, 0x28000 is not divisible by 0x18000.


Conclusion & Thoughts:

We are not able to know what exactly happened without REing or having the related code, but we can guess out something fairly based on our analysis above, the problem is likely caused by a loop-copying routine which is messed up, the routine uses an aligned memory block to perform the loop-copying, the memory block's size should be a common divisor of 0x18000 and 0x28000. Surely we can do future investigation to find out the actual number, but it’s not the critical thing right now..

The concern is this "copying mistake" may bring security issues, not just damage your file or confused you:), even, I would call it a security vulnerability. As the file is changed silently that the user is not able to get a chance to realize the change, when the original file is safe, we can't guarantee the modified file is safe too, especially when the added bytes are from the original file and that means they are controllable by the hacker.

Considering the following scenario..

On your remote Windows 2008 server, you received an .exe file from an unknown source you don't really trust, but luckily you have a lot of security software installed on the server so you are able to confirm that it's safe. Then, you copy the file via Remote Desktop to your local workstation which is a Windows XP and you are running the OS without any security software, since you already examined the executable file, you trust it and execute it - at this point, the new .exe may not be safe and malicious code may be executed.

Thanks,
Haifei