Message-ID: <20071011094951.GD5206@irena.obscure.ws>
Date: Thu, 11 Oct 2007 11:49:51 +0200
From: Obscure <lists@...cure.ws>
To: gjgowey@....blackberry.net
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	"pdp \(architect\)" <pdp.gnucitizen@...glemail.com>,
	"Thor \(Hammer of God\)" <thor@...merofgod.com>
Subject: Re: Remote Desktop Command Fixation Attacks

At the risk of going off topic - this kind of approach makes end users to get really used to entering their username and password in the web browser. Guess what happens when a (possibly malicious) website asks for credentials (using basic auth/whatever)?

These kind of solutions not only limit usability, but they also run the risk of creating security holes. 


Sent from my vi friendly email client 
:P

On Thu, Oct 11, 2007 at 12:27:48PM +0000, gjgowey@....blackberry.net wrote:
>Not to step in to the middle of this, but I once worked for an employer with what I considered the best way of stopping attacks cold: a proxy server that prompted you for your credentials when you went to an external web site and gp settings that disabled the ability to save your username/password locally as well as tight settings on the systems to prevent pretty much anything from being installed or modified.  So everytime you opened up a brand new session of ie and tried to access an external site you were prompted for your username/password.  Somehow I doubt there's any malware around that is designed to survive in that type of an environment.
>
>Geoff
>
>Sent from my BlackBerry wireless handheld.
>
>-----Original Message-----
>From: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
>
>Date: Thu, 11 Oct 2007 01:17:16 
>To:"Thor (Hammer of God)" <thor@...merofgod.com>
>Cc:full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
>Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
>
>
>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
>>
>
>
>--
>pdp (architect) | petko d. petkov
>http://www.gnucitizen.org
>
>_______________________________________________
>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/

-- 
Sandro Gauci
MaltaInfosec - http://maltainfosec.org/
SIPVicious - http://sipvicious.org/

_______________________________________________
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