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@xxxxxxxxxxxxxxx
> 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 i
s 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 specifi
ed, then it won’t run them and will default to the desktop. But I c
an 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 ho
st 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 i
t 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. De
ploying RDP to untrusted users or malicious users is not good policy
; as such, you need to take extra care in securing RDP hosts by usin
g permissions and other restrictions.
I think you need to relax a little and think about what you post – s
aying 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 takea
way from that is to apply more due diligence to securing RDP deploym
ents as one would with any asset you give users local access to. R
DP should not be viewed as a security mechanism, but rather, an acce
ss mechanism. There are MANY ways to secure RDP, limit access, publ
ish 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
> 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 stud
y 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] On Behalf Of wicked clown
Sent: Friday, March 26, 2010 3:33 AM
To: 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> 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
To: 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 e
xecute the application if the user logs on normally. This doesn’t wo
rk with cmd.exe but I have been able to execute internet explorer, d
own a modified cmd version, modify the RDP profile to execute the ne
w 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/