Date: Thu, 11 Oct 2007 16:01:02 +0300
From: Xo Plague <dusty.sploit@...il.com>
To: thor@...merofgod.com
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: Remote Desktop Command Fixation Attacks

pdp (architect) wrote:
> Thor, with no disrespect but you are wrong. Security in depth does not
> work and I am not planning to support my argument in any way. This is
> just my personal humble opinion. I've seen only failure of the
> principles you mentioned. Security in depth works only in a perfect
> world. The truth is that you cannot implement true security mainly
> because you will hit on the accessibility side. It is all about
> achieving the balance between security and accessibility. Moreover,
> you cannot implement security in depth mainly because you cannot
> predict the future. Therefore, you don't know what kinds of attack
> will surface next.
>
> Security is not a destination, it is a process. Security in depth
> sounds like a destination to me.
>
>   
>> However, for the record, this is not an "attack."  You might as well
>> just email the target and ask for their password.  Or if you can get
>> them to open files, just send off a rootkit.  But let's ignore that for
>> now- let's pretend that somehow this is a magic attack--  This is where
>> security-in-depth comes in, and where the overall context of your post
>> is incorrect:
>>     
>
> It is not the same. We educate users not to open .exe files but RDP
> and ICA are just pure business tools. Users are familiar with them and
> their purpose. Therefore, they are more trusted. And what happens when
> the tools that you trust turn against you?
>
> And how come it is OK for a simple text file be able to ride your
> session and execute commands on behalf of you? I think that this is a
> problem. CSRF is a well known, widely acknowledged problem. The client
> should at least warn you that you are about to start an alternative
> shell. That's not the case though.
>
> BTW, I am not sure if you stumbled across the other post I released on
> FD and BUGTRAQ which is closely related to this one. Well, here is the
> situation: if you visit a remote page that happens to be malicious,
> attackers can inject any commands they wish into your remote desktop
> without any visible notice. No interaction is required. And the attack
> is super generic btw, and probably 100% wormable.
>
> So, I believe it is an attack. Yes, it is not stack, heap overflow, or
> some null pointer dereference issue, but it is an attack that we
> cannot simply ignore it, mainly because it is a problem with a feature
> rather then a bug. Features cannot be easily eliminated. Bugs will be
> fixed!
>
> One thing that I am always trying to do with the GNUCITIZEN sessions
> is to educate developers as well system administrators that attacks
> succeed when they are unexpected. At the end of the day, the trick is
> simple.
>
> On 10/10/07, Thor (Hammer of God) <thor@...merofgod.com> wrote:
>   
>> Security in depth is alive and well, thank you.  In fact, it is security
>> in depth that allows administrators to prevent this type of "attack" (if
>> we can actually make the stretch to call it that).
>>
>> However, for the record, this is not an "attack."  You might as well
>> just email the target and ask for their password.  Or if you can get
>> them to open files, just send off a rootkit.  But let's ignore that for
>> now- let's pretend that somehow this is a magic attack--  This is where
>> security-in-depth comes in, and where the overall context of your post
>> is incorrect:
>>
>> First off, you block .rdp files at the SMTP gateway (that by itself is
>> security in depth). Secondly, normal domain users don't RDP to external
>> hosts, so there would never be an allow rule for outbound RDP.  Even if
>> there was some need for off-lan RDP traffic from users, it would be on a
>> host-by-host basis and managed by the firewalls.  That, again, is
>> security in depth.
>>
>> If your users are running XP, then the admin would prevent them from
>> updating to the 6.0 client anyway.  All you have to do in this case is
>> configure your RDP hosts to require TLS encryption based on a
>> certificate, and the client will not be able to connect at all if the
>> certificate is not in the trusted root certificates store.  Done.  If
>> you've got advanced users or have allowed 6.0 clients, then you ensure
>> that the client is set not to connect if authentication fails against
>> TLS secured hosts - of course, these people would be educated against
>> lame attacks anyway, so, done.  If you are running Win2k8, then you use
>> group policy to disable clients opening un-signed RDP files in the first
>> place, and again, be done.  Or just use TSGateway and require
>> certificates to log on - heck, they'd never make it past the gateway if
>> you didn't allow them.  Done part IV.  If you've got Vista clients, then
>> you'd also be using egress firewall rules in the "public" network
>> context blocking the outbound traffic, all configured with a single GPO.
>> I could go on, and on.
>>
>> The point is that just because you have (amazingly enough) qualified
>> this attack as "highly successful" and "vicious" does not, in any way,
>> degrade the value of security in depth.  In fact, it is a perfect
>> example *for* security in depth in that regard:  if this "attack"
>> succeeds against anyone, it is not because security in depth does not
>> exist, it is because security in depth was not practiced.
>>
>> t
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: pdp (architect) [mailto:pdp.gnucitizen@...glemail.com]
>> Sent: Wednesday, October 10, 2007 4:15 AM
>> To: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
>> Subject: Remote Desktop Command Fixation Attacks
>>
>> http://www.gnucitizen.org/blog/remote-desktop-command-fixation-attacks
>>
>> Security in depth does not exist! No matter what you do, dedicated
>> attackers will always be able to penetrate your network. Seriously!
>> Information security is mostly about risk assessment and crisis
>> management.
>>
>> When it comes to exploitative penetration testing, I relay on tactics
>> rather then exploits. I've already talked about how insecure Remote
>> Desktop service could be. In this post I will show you how easy it is
>> to compromise a well protected Windows Terminal or CITRIX server with
>> a simple social engineering attack and some knowledge about the
>> platform we are about to exploit.
>>
>> The attack is rather simple. All the bad guys have to do is to compose
>> a malicious RDP (for Windows Terminal Services) or ICA (for CITRIX)
>> file and send it to the victim. The victim is persuaded to open the
>> file by double clicking on it. When the connection is established, the
>> user will enter their credentials to login and as such let the hackers
>> in. Vicious!
>>
>> I have a more detailed explanation about the tactics behind this
>> attack. Because I don't want to spam people with tones of text, I just
>> included a link which you can follow. Hope that this is useful and at
>> the same time eye opening, not that it is something completely
>> amazing. But it does work and it works well.
>>
>> cheers.
>>
>> --
>> pdp (architect) | petko d. petkov
>> http://www.gnucitizen.org
>>
>>     
>
>
>   

and I am not planning to support my argument in any way

ha.
nice.

_______________________________________________
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