Re: Remote Desktop Command Fixation Attacks
ok, I am not questioning whether it is needed or not... anyway,
instead of mailing a huge chunk of text again and clogging everyones
email account, I decided to post my thoughts on the blog where they
should be anyway, here is the link:
http://www.gnucitizen.org/blog/clear
On 10/12/07, Thor (Hammer of God) <thor@xxxxxxxxxxxxxxx> wrote:
> CIL:
>
> > 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.
>
> No disrespect taken - we're all just people here ;)
>
> Thing is, in a "perfect world" we wouldn't need security at all (well,
> depending on your definition of "perfect world" is of course) - it's
> "real world" issues that require we build multiple layers of defenses to
> ensure that assets are protected when other layers, mechanisms, or
> policies fail. And not being able to predict the future is *precisely*
> why security in depth is required. For example-- Back in January of
> 2003 (where has the time gone?) I published an article on Security Focus
> discussing how to secure Exchange Server deployments.
> (http://www.securityfocus.com/infocus/1654 if you want to check up on
> me). I would draw your attention to this excerpt in regard to using
> ISA's SMTP application filter to inspect SMTP traffic:
>
> "Though we are filtering the command set through the ISA server, it is
> the element of the unknown that concerns me: we just don't know what
> vulnerabilities the future may present, and the possibility of a
> compromised Exchange server is just too much of a risk."
>
> Fast forward to April of 2005 where Microsoft published "MS05-021:
> Vulnerability in Exchange Server Could Allow Remote Code Execution" (The
> XLINK2STATE overflow). If one had followed the deployment example in
> the paper and practiced security in depth by implementing an SMTP
> application filter as described, they would have been completely
> protected against the XLINK2STATE issue years before it was exposed.
> *That* is security in depth, used in the real world, working both in
> principle and in practice.
>
> Not knowing "what kinds of attack will surface next" is the core concept
> that drives security in depth, not what obviates it. Security in depth
> coupled with "least privilege" WORKS. It's really the *only* thing that
> works. It is the foundation for dictating the logic of "allow what you
> need" as opposed to "block what you think is bad." So, in that respect,
> the goal is not to be in a reactionary position when you post "if I send
> attachment X, and the user opens it and connects with protocol Y, and
> then enter their credentials in server Z" but rather to deploy an
> infrastructure that, by its own design, protects against the entire
> class of attack.
>
>
> > 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?
>
> The tools are not turning against us at all-- this requires that you
> email a target, and not only get them to open your attachment (against
> warnings), but to then click "connect," and finally, to actually enter
> their username and password into your host (where you still have to get
> them, btw). *SO* much more has to happen beyond the "tool" that it
> doesn't matter. Besides, I don't think users know anything about .rdp
> files -- I can say that I've never, ever, been emailed an rdp file.
>
> > 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.
>
> I looked at what you posted, but there is no info. And you say that you
> are "witholding the PoC" so there's no way I can begin to comment on
> what you say you can do. If you are saying that if I visit a site, you
> can inject whatever commands you want into an RDP session I have open
> (in regard to MSFT RDP, not Citrix) then I challenge you to post that
> information.
>
> Regardless, even in the presence of that type of attack, it still does
> nothing to degrade the value of security in depth; it only further
> illustrates the need.
>
> t
>
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org