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