lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5bc8bc291003270439n18290ceagd78aaaf4ed22bd68@mail.gmail.com>
Date: Sat, 27 Mar 2010 11:39:25 +0000
From: wicked clown <wickedclownuk@...glemail.com>
To: "Thor (Hammer of God)" <Thor@...merofgod.com>
Cc: "Full-Disclosure@...ts.grok.org.uk" <Full-Disclosure@...ts.grok.org.uk>
Subject: Re: 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@...merofgod.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@...ts.grok.org.uk [mailto:
> full-disclosure-bounces@...ts.grok.org.uk] *On Behalf Of *wicked clown
> *Sent:* Friday, March 26, 2010 8:31 AM
>
> *To:* Full-Disclosure@...ts.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@...merofgod.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@...ts.grok.org.uk [mailto:
> full-disclosure-bounces@...ts.grok.org.uk] *On Behalf Of *wicked clown
> *Sent:* Friday, March 26, 2010 3:33 AM
>
>
> *To:* Full-Disclosure@...ts.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@...inkydink.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 <wickedclownuk@...glemail.com>
>
> *To:* Full-Disclosure@...ts.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/
>
>
>
>
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ