pdp (architect) 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) <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] >> Sent: Wednesday, October 10, 2007 4:15 AM >> To: full-disclosure@lists.grok.org.uk; [EMAIL PROTECTED] >> 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 >> >> > > >
and I am not planning to support my argument in any way ha. nice. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
