Re: [Full-disclosure] Possible RDP vulnerability

["Thor (Hammer of God)" <Thor@xxxxxxxxxxxxxxx>]

Well, it's not really an "agree to disagree" thing.  You are technically 
incorrect in your dissertation, whether we both agree or not.  We can agree not 
to care what each other's opinions are, but the tech is the tech.

Many people have misconceptions of how RDP "security" works and what it is; 
when I see posts like this, I think it is important to use these types of 
misunderstandings as "learning opportunities."

I've asked a couple of times now, but you've not given any details on what 
"group policy" object you are using to ensure that "only a certain application 
will run" in your "so called secure systems with group policy."

You are clearly confusing authorization to execute a program with a "start 
menu" item.   You say "the user is unable to access my computer, run or the 
start button or any other application" but you have "a shortcut to notepad."  
You are simply describing a menu system for the user to execute notepad.exe, 
and NOT anything that enforces that only certain programs run.

You are not "denying access" to any programs here.  You are just taking away 
the default menu system for the user to get to the program.  Even in this case, 
if you took notepad.exe off the desktop, all I have to do in my RDP session is 
hit CTRL+ALT+END and run Task Manager.  I can the go File, New Task, and run 
whatever I want.  You are further incorrect about "if you put a single click in 
the RDP-tcp on the server then the user is unable to execute other 
applications."  I can still EXECUTE whatever I have permissions to EXECUTE.

You really need to understand that what you are doing is just playing around 
with the windows/menu systems that the users "sees."  You are doing NOTHING to 
"secure" the box in these cases.   You keep using the words "only run certain 
programs" and "have access to other parts of the server they are not allowed 
access" and "execute normally blocked programs."  If this is the case, then you 
are obviously logging onto the box as an administrator, and/or you simply don't 
have basic security policies in place, and/or running on a FAT drive or 
something.

If you don't want them to run "notepad.exe" then deny access permissions to 
"notepad.exe" and they can't execute it.  Period.  If you allow them to write 
to windows\temp, then they can write to windows\temp; as such, you have clearly 
"allowed" that.  You somehow think that accessing the box via RDP "magically" 
protects you from what the user could do if they were sitting at the console.   
If I didn't want you to run your "altered cmd.exe" then I would use Applocker 
to only let you run the "real" cmd.exe via hash or certificate (not that 
cmd.exe has a cert ) but my point is that you have a tremendous number of ways 
to secure your installation that you are not using - instead you think that 
removing a menu items that points to the .exe someone sets security on the .exe 
itself.  It doesn't.

Menu item restriction and custom interfaces and simply user experience/ UI 
changes to make it "easy" for the user.  Do not mistake them for security 
access controls.  They are not (as you have seen).  Stop running around showing 
videos of the obvious when you COULD be actually securing the system.  You have 
to GRANT access to your RDP server. It's not by default.  You have to ALLOW 
users to do the things you want them to do.  You seem surprised that since you 
have given remote access to a computer to someone who has permissions to run 
programs that they can actually do that.  If you only wanted to allow them to 
run notepad, then giving them RDP access to that box without actually imposing 
security access controls on what they can do was, well, not really smart.

I understand the fact that you WANT there to be a vulnerability here. You want 
to be able to post videos of how you found some "hole."  Even when you said 
"looks like this might not be a vulnerability" you followed up with a frown.   
Thing is, there just isn't.  You can make it seem like there is, but there's 
not.   I suggest that you spend your time actually learning how to secure RDP 
and not looking for ways to make menu items seem like security issues.

t

From: wicked clown [mailto:wickedclownuk@xxxxxxxxxxxxxx]
Sent: Saturday, March 27, 2010 4:39 AM
To: Thor (Hammer of God)
Cc: Full-Disclosure@xxxxxxxxxxxxxxxxx
Subject: Re: [Full-disclosure] Possible RDP vulnerability

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<mailto: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 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>
 
[mailto: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<mailto: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/