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