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
