[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Possible RDP vulnerability
- To: wicked clown <wickedclownuk@xxxxxxxxxxxxxx>, "Full-Disclosure@xxxxxxxxxxxxxxxxx" <Full-Disclosure@xxxxxxxxxxxxxxxxx>
- Subject: Re: [Full-disclosure] Possible RDP vulnerability
- From: "Thor (Hammer of God)" <Thor@xxxxxxxxxxxxxxx>
- Date: Fri, 26 Mar 2010 21:29:03 +0000
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@xxxxxxxxxxxxxxxxx
[mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of wicked clown
Sent: Friday, March 26, 2010 8:31 AM
To: Full-Disclosure@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx<mailto:Thor@xxxxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxx<mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx>
[mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx<mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx>]
On Behalf Of wicked clown
Sent: Friday, March 26, 2010 3:33 AM
To: Full-Disclosure@xxxxxxxxxxxxxxxxx<mailto:Full-Disclosure@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx<mailto:dink@xxxxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxx>
To: Full-Disclosure@xxxxxxxxxxxxxxxxx<mailto:Full-Disclosure@xxxxxxxxxxxxxxxxx>
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/