Re: Possible RDP vulnerability

["Thor (Hammer of God)" <Thor () hammerofgod com>]

I’m not sure what you are referring to.  I never made any recommendation to ‘sidestep’ desktop restrictions at all.   
Rather, I indicated that “desktop restrictions” (and thank you for the use of that far more appropriate term) were not 
actual security access controls, but rather UI access mechanisms, and that they should not be relied upon to enforce 
security policy and/or access authorization.

I actually recommend deploying UI restrictions in RDP environments where you must give the user direct control of the 
desktop.  To be sure, prior to deploying such solutions, I recommend that RemoteApp or similar types of 
application-specific publishing scenarios are considered first (though they also carry risks to be aware of).  So while 
not specific security controls, I do put them under the Security in Depth umbrella and recommend that due diligence in 
planning and execution of RDP access models is exercised, which would include such additional restriction mechanisms.  
I apologize if my statements were interpreted as “don’t use desktop restrictions.”

The initial recommendation was to treat the security of an RDP session as one would local desktop access; that being 
consideration of overall permissions, SAFER/AppLocker application, and other desktop-based host security measures.

t

From: Dan Kaminsky [mailto:dan () doxpara com]
Sent: Saturday, March 27, 2010 9:28 AM
To: Thor (Hammer of God)
Cc: wicked clown; Full-Disclosure () lists grok org uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

You say this, but I note with interest and approval that your recommendation was to sidestep desktop 'restrictions' 
entirely in favor of certificate based access control.

Quantization of security and all that.

On Mar 27, 2010, at 11:56 AM, "Thor (Hammer of God)" <Thor () hammerofgod com<mailto:Thor () hammerofgod com>> wrote:

No, they don’t “always” win.  Maybe back with windows 2000, or XP, but not with Windows 7 anyway.  Of course, none of 
this does anything to stop them from booting off a CD and owning the box that way.

However, I do agree that people need to fully understand exactly what they are, and more importantly, are NOT doing 
insofar as security is concerned when it comes to access to local assets.

t

From: Dan Kaminsky [mailto:dan () doxpara com]
Sent: Saturday, March 27, 2010 7:37 AM
To: wicked clown
Cc: Thor (Hammer of God); Full-Disclosure () lists grok org uk<mailto:Full-Disclosure () lists grok org uk>
Subject: Re: [Full-disclosure] Possible RDP vulnerability

So it's a super common thing for schools to have 'locked down' Windows desktops, and even more common for even slightly 
nerdy kids to take the lockdown as a challenge to be  defeated.

The point of course is that the kids always win:  At the point somebody has the set of privileges exposed by any amount 
of desktop access, constraining execution for them is similar to getting the idea that, perhaps, it would be the 
responsible thing to open discussions around managing the open state of the barn door.



On Mar 27, 2010, at 7:39 AM, wicked clown <wickedclownuk () googlemail com<mailto:wickedclownuk () googlemail com>> 
wrote:
I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a certain applications for example notepad.exe, 
the user is unable to access my computer, run or the start button or any other application. There would be a shortcut 
on the desktop for just notepad.exe for the user to execute.

The user use RDP to connect to the terminal server so they can access notepad.exe but if you change the application in 
the programs tab under the RDP client the user is now able to run any application on the terminal server, the user then 
execute internet explorer and download a modified cmd.exe and save it in the c:\windows\temp (even if you denied access 
to the hard drive users can still write to the temp folder) now I log off the rdp client change the program to point to 
c:\windows\temp\cmd.exe, I how have access to the command prompt with access to the command prompt I can run any other 
application or access other parts of the server they are not allowed to access.

That is what my video was try to demostrate that even denying access to applications on the server you can still 
execute applications from that server.

But as been mention if you put that single click in the RDP-tcp on the server then the user is unable to execute other 
applications.

I have been doing some further checks and I can confirm I have seen this affect about 90% of so called secure systems 
with group policy, but will execute normally block applications. I have even found systems on the Internet that are 
vulnerable to this.

I think we may have to agree to disagree on this subject. But thank you for you views and comments.
On Fri, Mar 26, 2010 at 9:29 PM, Thor (Hammer of God) <Thor () hammerofgod com<mailto:Thor () hammerofgod com>> wrote:
I think you still misunderstand.

The option you refer to has nothing to do with “locking down” the server.  When you say things like “a locked down 
group policy that is tighter than a ducks bum” what exactly are you talking about?

Selecting “don’t allow a startup program to be run” simply forces the desktop to be shown as opposed to an application 
one may specify.  If I initiate a session and tell it to run calc.exe, then calc.exe is what it presented upon 
connection.  It’s a shortcut for the user.  If at the server I don’t allow applications to be specified, then it won’t 
run them and will default to the desktop.  But I can still go “start, run, calc” and it will run fine if I have 
permissions to run it.  AppLocker is a great way to lock down the host environment, whether RDP or not.

And you are quite incorrect about “no user based control” stopping you.  As mentioned, AppLocker could have prevented 
it had it been deployed “properly.”  Well, it would help, anyway.   Depends on the manner in which the attack was 
carried out, of course, but that has nothing whatsoever to do with the setting in RDP.  Deploying RDP to untrusted 
users or malicious users is not good policy; as such, you need to take extra care in securing RDP hosts by using 
permissions and other restrictions.

I think you need to relax a little and think about what you post – saying things like “a GPO tighter to a ducks bum” 
and “open to total pwnage” and “nothing would stop me” sounds a bit hyperbolic (in addition to being incorrect).

To summarize, your concerns have nothing to do with RDP security settings as you have presented them.  MS10-015 is 
certainly an important issue for local-host based attacks, of which RDP is one.  One’s mitigation efforts should indeed 
include RDP hosts.  The takeaway from that is to apply more due diligence to securing RDP deployments as one would with 
any asset you give users local access to.   RDP should not be viewed as a security mechanism, but rather, an access 
mechanism.  There are MANY ways to secure RDP, limit access, publish applications in singularity, create remote 
workspaces, etc, but you need to educate yourself on these solutions.

The behavior you describe is expected, by design behavior.

t

From: full-disclosure-bounces () lists grok org uk<mailto:full-disclosure-bounces () lists grok org uk> 
[mailto:full-disclosure-bounces () lists grok org uk<mailto:full-disclosure-bounces () lists grok org uk>] On Behalf Of 
wicked clown
Sent: Friday, March 26, 2010 8:31 AM

To: Full-Disclosure () lists grok org uk<mailto:Full-Disclosure () lists grok org uk>
Subject: Re: [Full-disclosure] Possible RDP vulnerability

Thank you for your comment.

What I was referring to it being scary is that if you create a locked down group policy that is tighter than a ducks 
bum and you forget that single tick (I admit I didn't knew of that option and I bet lots of other people didn't know 
about it) you leave your system to total pwnage!! It's simple mistakes like that which compromises systems.

If I found this before MS10-015 patch was released I could of download that exploit and gain system level permission, 
so no user based permission or access control would of stopped me.


On Fri, Mar 26, 2010 at 2:13 PM, Thor (Hammer of God) <Thor () hammerofgod com<mailto:Thor () hammerofgod com>> wrote:
There’s nothing “scary” about it.   I believe you are incorrectly asserting that the inclusion of the “start the 
following program on connection” has something to do with “locking down the server” and/or “only allow(ing) users who 
connect to your server to run certain applications.”   I would suggest that you study up on what RDP is and how it 
works before posting things like this.

Consider “locking down RDP” a process similar to “locking down a local host.”  Use permissions and other host/OS based 
controls to secure what a user can and can’t do on a host.

t



From: full-disclosure-bounces () lists grok org uk<mailto:full-disclosure-bounces () lists grok org uk> 
[mailto:full-disclosure-bounces () lists grok org uk<mailto:full-disclosure-bounces () lists grok org uk>] On Behalf Of 
wicked clown
Sent: Friday, March 26, 2010 3:33 AM

To: Full-Disclosure () lists grok org uk<mailto:Full-Disclosure () lists grok org uk>
Subject: Re: [Full-disclosure] Possible RDP vulnerability

Cheers for that,

I take it back that I haven't found an vulnerability :(, but by default this isn't enabled which is scary !!
On Fri, Mar 26, 2010 at 9:57 AM, Mr. Hinky Dink <dink () mrhinkydink com<mailto:dink () mrhinkydink com>> wrote:
There is a section in RCP-Tcp Properties on the server under "Environment" for "Do not allow an initial program to be 
launched.  Always show the desktop".

----- Original Message -----
From: wicked clown<mailto:wickedclownuk () googlemail com>
To: Full-Disclosure () lists grok org uk<mailto:Full-Disclosure () lists grok org uk>
Sent: Friday, March 26, 2010 5:04 AM
Subject: [Full-disclosure] Possible RDP vulnerability

Hi Guys,

I think I possible may have found a vulnerability with using RDP / Terminal services on windows 2003.

If you lock down a server and only allow users who connect to your RDP connection to run certain applications, users 
can bypass this and run ANY application they want. You can do this by modifying the RDP profile / shortcut and add your 
application to the alternate shell and the shell working directory.

When the user connects now to the RDP server the banned application will execute upon logging on even though the user 
isn’t allowed to execute the application if the user logs on normally. This doesn’t work with cmd.exe but I have been 
able to execute internet explorer, down a modified cmd version, modify the RDP profile to execute the new cmd and it 
works like a charm.

I have only been able to tested this on windows 2003 using a local policy and works like a treat. Even in the wild!

I have done a quick basic video which can been seen here;
http://www.tombstone-bbs.co.uk/v1d30z/rdp-hack2.swf

Instead of modifying the RDP profile, I just added my application to the program tab.. I know the video is crappy but 
it’s just meant to give you an idea what I am talking about :)

So in short, if anybody can access your server via RDP they are NOT restricted by the policy. I would be interested in 
any feed back about this possible exploit / vulnerability even if you don’t think it is.. or even better if someone 
knows how to defend againest it!! LOL! :)

Cheers

Wicked Clown.
________________________________
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/