Build Your Own Botnet with RDP
Justin Seitz (jms) <jmsbughunterca> Monday, December 3 2007 12:03.20 CST


This might not be a novel thing, but I couldn't find any references to someone who had taken a look at this already. If there is prior art, then please send it to me!

So one day I was helping out a friend, let's call him Bob, and he was having a problem with a remote Windows machine. After watching him fire up his remote desktop client and enabling the sharing of "Disk Drives" (so that he could pull a log off the remote machine), I wondered what the implication was of actually setting up a file share between the two machines.

The question I had was: "What if someone owned the remote machine? What can they do from there?"

The first step was to see how the operating system reacts to a user connecting with this option enabled. The only noticeable difference between enabling the share and not enabling it was the "rdpclip.exe" process gets fired up when a share has been enabled. Let's start there.

I first attached to rdpclip.exe with a debugger, and trapped the CreateFileW() call exported from kernel32.dll. You can learn a lot about an application by just trapping this call, and monitoring the handles it returns (handles can be used for IOCTLs, files, named pipes, etc.). I then right clicked on a file on the remote machine's desktop, chose "Copy" and low and behold I got a hit in my hook.



0007EEBC   7C835B74  t[�|  /CALL to CreateFileW from kernel32.7C835B6F
0007EEC0   010100D2  �.  |FileName = "\\tsclient\C\DOCUME~1\Owner\LOCALS~1\Temp\_TS7.tmp\_TS1.tmp"
0007EEC4   80000000  ...�  |Access = GENERIC_READ
0007EEC8   00000000  ....  |ShareMode = 0
0007EECC   00000000  ....  |pSecurity = NULL
0007EED0   00000001|Mode = CREATE_NEW
0007EED4   00000080  �...  |Attributes = NORMAL
0007EED8   00000000  ....  \hTemplateFile = NULL



Hmmmm...what is "\\tsclient\"? On the remote machine, if you enter that path into Windows explorer, you will see ALL of the disk drives on the remote client machine. Not only that, you are able to write to the remote drive with the permissions of the logged in user. The other interesting thing is that it rides across on the established remote desktop connection, so it won't trip a firewall on the client-side when you connect back.

So what are some of the things we can do with this?

If the remote user (the RDP client) is "Administrator":

a) Overwrite anything in C:\WINDOWS\system32\ say the next time they fire up calc.exe they get compromised.
b) You could search the remote machine for vulnerable versions of say Adobe Acrobat, and then replace all of the pdf's on the filesystem with malformed files.

If the remote user is a limited account:

a) Parse all of their shortcuts on the Desktop, replace them to point to a binary that you push across the share.
c) Use the b) step above to change all of their "My Documents" to contain bad files that will ultimately compromise the system.

All of these things can easily be automated with CANVAS or other penetration testing frameworks, or even a Python interpreter and PyDbg for that matter can do this easily.

This is particularly troubling, if an attacker compromises a Windows server machine, they can lie in wait for an administrator to login and then ride back into the local administrators network without them really knowing.

So how can you build a botnet using this information?

Well, Google hackers for some time have known about people storing RDP connection files on a public webserver (bad idea). But we can leverage this; all you need to do is post a link to RDP connection file that points to a VMWare'd Windows machine that has the remote desktop service running. Everytime someone connects to your machine (presumably to steal stuff from you), you are able to ride back the channel to ultimately drop whatever binary you want on their machine.  You could also easily social engineer someone into connecting to your machine, because psychologically if I am giving you access to my Windows server, I am showing you that I have some implied trust in you. It puts me in a position of vulnerability, and people will generally accept that they are the ones who hold the power, not really thinking about the implications of accessing my trusted environment.


Again maybe this is a lame hack, but HD Moore's (and Valsmith) recent works on hacking without exploits shows that these subtle architectual flaws can create useful attack vectors.


Mitigation: don't turn the option on :)


Comments
PSUJobu Posted: Monday, December 3 2007 13:12.34 CST
Very interesting - thanks for sharing!  I was about to give thought to this for some remote admin of a family member's PCs...  I know how I'll configure it now!

c1de0x Posted: Wednesday, December 5 2007 00:52.59 CST
Great work JMS...

Do you have a working POC script? I've been trying to convince some of the network security staff at my company that RDP is dangerous for ages ;)

This exploit-less attack is just the kind of thing that I was talking about!

jms Posted: Wednesday, December 5 2007 01:38.33 CST
I do have some POC but I didn't really want to release it for some weird reason. But what I can say is: enumerate the system processes in a tight loop, check for rdpclip.exe, read/write files from \\tsclient\\C\\ for as long as the rdpclipe.exe process is alive.

Simple PyDbg script as I said in my post.

ricky0 Posted: Friday, May 2 2008 17:05.24 CDT
Has anyone else actually tried this?  I RDP'd to a server, allowed access to my local drive, and verified rdpclip.exe was running on the server.  I logged into the server and typed \\tsclient\ in an explorer window and immediately got "windows cannot find \\tsclient".  

frankboldewin Posted: Saturday, May 3 2008 07:21.30 CDT
@ricky0: try \\TSCLIENT\C

thierryzoller Posted: Wednesday, May 7 2008 19:27.31 CDT
Similar trick works for Citrix ICA

AlexIonescu Posted: Saturday, May 10 2008 19:17.09 CDT
\\tsclient isn't undocumented -- it's part of the RDP disk sharing functionality.

If you enable disk sharing, *you are getting exactly what you deserve*.

There's a large warning about it (did you read it?) when you connect to a machine with your drives shared.

This is a complete non-issue... the option isn't enabled by default, and the user basically has to accept a message that states "if you do this, you can be owned."

TheInsider Posted: Wednesday, June 4 2008 06:08.46 CDT
i knew of \\tsclient, but i never thought of this idea :)
great idea!!!!
FINALLY someone is showing logical/design bugs!

You should make a P.O.C, its would be cool
Design bugs are much more interesting than buffer sizes :)

jms Posted: Wednesday, June 11 2008 16:55.55 CDT
Alex et. al. if you re-read the more interesting vector is that people who are Googling for these RDP files WANT to be able to move files back and forth off of the remote client.