Message-ID: <e172cd090710111536i43527d0due6593d78df80b5cb@mail.gmail.com>
Date: Thu, 11 Oct 2007 17:36:49 -0500
From: "John C. A. Bambenek, CISSP" <bambenek.infosec@...il.com>
To: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	"Thor \(Hammer of God\)" <thor@...merofgod.com>
Subject: Re: Remote Desktop Command Fixation Attacks

Security in depth is a tactic, not a process or definition.  And it works
for what it's designed to, which is the same thing most security solutions
are designed to.  That is, they raise the bar of entry.  Ideally, it makes
it hard to find the one-kink in the armor to bring it all down and makes the
bad guys have to go through effort to penetrate many layers.  In so doing,
they become easier to detect and ultimately stop.  No system is perfect, you
can only maximize your chances to defeat the attack and identify the
attacker.

On 10/10/07, pdp (architect) <pdp.gnucitizen@...glemail.com> 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
> >
>
>
> --
> 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/
>

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