Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
CQ, maybe I am making a huge mistake for responding to your message, but let see. this is what I think about security in depth in a bit more detail. let say that we have a wireless network which is guarded by security in depth network administrators. the first thing they will do is to secure the actual network by some massive segmentation exercises... then the connection with enhanced privacy/encryption schemes (WPA2). They will put more layers on the top of that. For example, the users need to authenticate with client-side certificates. Now the network and the connection is secure (sort of), they enforce group policy for all laptops so that these laptops cannot connect to any other network (sending probe requests, rogue access points). Right! But now they also kill the ethernet since a laptop cannot be connected to the wireless and the wired network since it is also a risk (stepping stone attacks). Each client has a firewall on the top of that. The firewall blocks everything that comes in and lets only the browser to go out through a proxy which requires authentication (NTLM, Basic Auth, etc). The user of the laptop runs with the least possible privileges and they cannot install software. They cannot use the CD (Sonny Rootkits), they cannot use the USB (endpoint security). The laptop has a boot password as well so in case it is stolen the attackers cannot crack open the disk. My question is the following: does this sound sane to you? Do you really believe that someone will let you do all that, without causing chaos? Laptops are good because they are mobile. You are allowed to take them out and work from home. At home you have your own network which you would like to connect to. Even if you use a different account on that same laptop to connect to that network, the risk is still there. A system is as secure as the weakest link. Companies don't like to hear how you are going to solve all problems once and for all with some killer security in depth solution because it is not possible. in order to make things work you have to leave various doors open. At GNUCITIZEN we have one maxima.. Be legitimate! If the attacker try to be a legitimate user as much as possible they will stay unnoticed and they will get in. Now how do we handle security in 21st century the way I see it (btw, I am not interest in selling any services, in fact, GNUCITIZEN is not that type of organization)? First of all, careful planning - the system has to be as secure as flexible and usable even if this means that you need to have a shared key for all of your wireless networks. Second, you need a crisis management plan. Natwest got hacked by a MP3 player.. how many of you have heard of it and for how long this story was on the news? Third, you need to calculate the risk. Example? Credit card fraud! We know that cards are getting stolen but the calculated risk is %2 out of the whole, which can be easily compensated. Etc, etc, etc! As you can see it is not just technical when it comes to the real world. In the real world the management gives you instructions and you have to implement them in the best possible way. Projects stack up. People leave, new people join in and work on the networks that have been given. Chaos is the norm! How many of you have seen a network that is done right? Yeh, there are a few of you, but you are probably talking about your home network which does not exceed more then 20 machines. How come I have never seen a security in depth in practice. You guys are more experienced then me, that's for sure... but I've done quite a few tests in the past 4 years and I know what I've seen. It is bad, but it is OK, because then we can sit together and walk through the entire process. I expect more flames for which I am not planning to respond. If you think that security in depth works for you... do it! personally, I will offer something additional to my clients. something, that gives them that extra safe net, which has nothing to do with security in depth. cheers, pdp On 10/14/07, C Q [EMAIL PROTECTED] wrote: I guess there's some logic in spreading FUD about security in depth not working. It might be a nice way to scare potential customers who don't know much about security into whatever services Gnucitizen team sells. However, these kind of tricks simply won't work with any seasoned security professional. It'll actually backfire if you are not careful... because you won't be taken seriously in the industry. I'm pretty sure Pdp's rating in the books of many security professionals went down quite a few notches :-) It's a small world... and most likely it'll affect your and your company's future... because you'll need to do business with people like Thor (who gave a great and very logical description with proper supporting examples of what security in depth is and what's mean to do). The chances are that they'll simply choose to work with someone else... who betters understands the big picture in security
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
If you want my take on how to secure a wireless network I'd approach it like this: 1) wpa2 (of course) 2) mac restrictions (yes, keeping a list of legitimate mac's will be required, but if you don't have an automated inventory system in this day and age then how are you ensuring nothing goes missing to begin with?). 3) ipsec VPN connections from all systems that connect via the wireless (this is in addition to the wpa2) using a unique cert per system (not the typical shared password setup that I am still amazed passes for secure in some peoples minds). 4) all traffic must go through a proxy server that sits right behind the VPN concentrator) If you're running an MS based setup: 5) necessary GP modifications to enforce all this and more (if you study all the options available to be forced, xp, w2k, and w2k3 really can get quite secure at the protocol level). 6) force kerberos authentication everywhere possible with absolutely no client side caching of the credentials allowed. Reason: even if someone gets all the way through to the proxy server level ISA can still stop someone cold if their machine doesn't have a machine account on the domain (good luck spoofing that). Basically you're looking at layers of authentication and encryption with no way around any of them (even if you do plug in a NIC on one of the systems that's on the wireless) and this really doesn't take a lot of hardware or software to pull off. Example setup: in front would be your WAP behind that would be a Cisco pix fw with a Cisco VPN concentrator behind it and a MS w2k3 box running ISA behind that. 4 devices basically providing a very solid wireless infrastructure. If you're looking to step it up further you can go with MS SMS server and shavlik netchk to manage and audit the laptops. Geoff Sent from my BlackBerry wireless handheld. -Original Message- From: pdp (architect) [EMAIL PROTECTED] Date: Sun, 14 Oct 2007 21:59:19 To:C Q [EMAIL PROTECTED] Cc:full-disclosure@lists.grok.org.uk, [EMAIL PROTECTED] Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks CQ, maybe I am making a huge mistake for responding to your message, but let see. this is what I think about security in depth in a bit more detail. let say that we have a wireless network which is guarded by security in depth network administrators. the first thing they will do is to secure the actual network by some massive segmentation exercises... then the connection with enhanced privacy/encryption schemes (WPA2). They will put more layers on the top of that. For example, the users need to authenticate with client-side certificates. Now the network and the connection is secure (sort of), they enforce group policy for all laptops so that these laptops cannot connect to any other network (sending probe requests, rogue access points). Right! But now they also kill the ethernet since a laptop cannot be connected to the wireless and the wired network since it is also a risk (stepping stone attacks). Each client has a firewall on the top of that. The firewall blocks everything that comes in and lets only the browser to go out through a proxy which requires authentication (NTLM, Basic Auth, etc). The user of the laptop runs with the least possible privileges and they cannot install software. They cannot use the CD (Sonny Rootkits), they cannot use the USB (endpoint security). The laptop has a boot password as well so in case it is stolen the attackers cannot crack open the disk. My question is the following: does this sound sane to you? Do you really believe that someone will let you do all that, without causing chaos? Laptops are good because they are mobile. You are allowed to take them out and work from home. At home you have your own network which you would like to connect to. Even if you use a different account on that same laptop to connect to that network, the risk is still there. A system is as secure as the weakest link. Companies don't like to hear how you are going to solve all problems once and for all with some killer security in depth solution because it is not possible. in order to make things work you have to leave various doors open. At GNUCITIZEN we have one maxima.. Be legitimate! If the attacker try to be a legitimate user as much as possible they will stay unnoticed and they will get in. Now how do we handle security in 21st century the way I see it (btw, I am not interest in selling any services, in fact, GNUCITIZEN is not that type of organization)? First of all, careful planning - the system has to be as secure as flexible and usable even if this means that you need to have a shared key for all of your wireless networks. Second, you need a crisis management plan. Natwest got hacked by a MP3 player.. how many of you have heard of it and for how long this story was on the news? Third, you need to calculate the risk. Example? Credit card fraud! We know that cards are getting stolen but the calculated
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
over a proxy server, since you've said all traffic must go through a proxy server. This means one of the following things: * Only Web/FTP Traffic is allowed * You're going to allow HTTP CONNECT tunneling on all ports, obviating the proxy server entirely and making life for your users hellish as you try and force a whole load of traffic to go over a web proxy * You're going to use SOCKS (similar to the previous) * You're going to use the ISA Firewall Client, which does in effect allow you to authenticate all traffic going via your ISA Servers, but renders the VPN pointless, and is very difficult to firewall. * Only selected traffic is *actually* going to traverse the proxy server when you realise it isn't a panacea (again, obviating the need for it). Since you've specifically highlighted authentication as the main reason for the proxy server here, and you've mentioned kerberos as a protocol that is traversing your wlan, you can't simply mean application-layer firewall, and I must only assume you want to use the firewall client (or don't understand what ISA does). vii) Probably other stuff I didn't think about in the 10 minutes it took me to write this e-mail. Many elements of the policy are pretty pointless given the number of other restrictions you have in place, such as: MAC Filtering - when you consider what a tiny hurdle MAC spoofing is compared to your VPN infrastructure, proxy infrastructure, kerberos, etc and the overhead associated with this, it really seems quite pointless. The Cisco PIX - Why? To filter the one or two ports hitting the VPN Concentrator? Even if you had this after the concentrator and not before, sitting a PIX (which is a firewall) in front of an ISA Server (which is a firewall) and behind a VPN Concentrator (which probably does basic firewalling itself) is pretty redundant, especially given the bandwidth your LAN clients likely use and the cost of Cisco Firewalls. If you're going down the Firewall Client route, firewalling the traffic between ISA and the VPN Concentrator is almost entirely pointless anyway. Turning on, enabling, and implementing every possible security setting and device you think of is not defence in depth, and will probably only have two effects - your users won't use your wireless network, and you'll burn so much cash you won't have any left to spend on *useful* security measures. = Alternatively... You can do some extremely nice things with WPA2-Radius, it can be authenticated in a very similar way to VPNs, using 802.1x and EAP-TLS with certificates, and you can even dump users into different VLANs over wifi depending upon who they authenticate as. It can be implemented for the price of a $300 entry-level enterprise-grade AP such as those from HP and Cisco, using existing licensed Radius software on your Windows DCs, and an existing licensed Enterprise CA with autoenrolment. If that's not good enough, and you simply must have encryption and authentication over the top of your encrypted, authenticated wifi lan, why not use IPSec? This provides a performance benefit over a VPN (no tunneling), is far more granularly configurable (across your whole AD estate via GPOs), and won't automatically break when users roam across Access Points. It also provides security for *all* users, not just VPN users, and generally hardens the soft underbelly of your internal network infrastructure rather than relying on an overcomplex outer shell which, once breached, exposes your (probably under-hardened) internal network. This approach makes it substantially easier to provision new wireless access points too (since they no longer have connectivity requirements tied to your proxy/VPN infrastructure or carry the requirement to provision additional VPN Servers / PIXes / ISA Servers / etc). At worst you may have a few trunked vlans. There is obviously a performance and management hit associated with this approach (IPSec), but I think it's a more balanced one based on the nature of the threat, and it provides a greater return than just wifi security. If you're looking to step it up further you can go with MS SMS server and shavlik netchk to manage and audit the laptops. If you were going to take this a step further, I'd suggest using one of the many NAP-like platforms currently out there, doing some sensible application-layer firewalling, or waiting until w2k8 came out and using NAP itself. You've already got NAQC, since in your hypothetical scenario you've already bought some ISA Licenses - you may as well actually use them. - James. -Original Message- From: pdp (architect) [EMAIL PROTECTED] Date: Sun, 14 Oct 2007 21:59:19 To:C Q [EMAIL PROTECTED] Cc:full-disclosure@lists.grok.org.uk, [EMAIL PROTECTED] Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks CQ, maybe I am making a huge mistake for responding to your message, but let see. this is what I think about
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
I guess there's some logic in spreading FUD about security in depth not working. It might be a nice way to scare potential customers who don't know much about security into whatever services Gnucitizen team sells. However, these kind of tricks simply won't work with any seasoned security professional. It'll actually backfire if you are not careful... because you won't be taken seriously in the industry. I'm pretty sure Pdp's rating in the books of many security professionals went down quite a few notches :-) It's a small world... and most likely it'll affect your and your company's future... because you'll need to do business with people like Thor (who gave a great and very logical description with proper supporting examples of what security in depth is and what's mean to do). The chances are that they'll simply choose to work with someone else... who betters understands the big picture in security :-) CQ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
This wasn't a flame... It was a simple observation. Having read your reply I also see that you are trying to reinvent the wheel... when you talk about crisis management and other planning. Risk analysis, business continuity and disaster recovery planning, well prepared incident response procedures and policies, etc have been practiced by security professionals for quite a while, so they are not new concepts. There's still a lot of work to do when it comes implementing proper security and compliance solutions. Many companies either don't do it or don't do it effectively, but there has been some progress over the years. Many companies don't even have a CSO/CISO because security and compliance are only starting to gain the recognition they require. Obviously, there's much more work to do... and that's good for all of us in the information security business :-) As far as defense in depth goes, just like with everything else it can be improperly implemented to a point where it's ineffective or prohibitively disrupted to the business. Your example is a great example of that :-) However, it doesn't mean that the concept is useless. Simple analogy... Let's say I pick up a cook book to make a fancy dish, but I end up with something that can even turns my dog green :-) Does it mean that the recipe was bad or does it mean I shouldn't quit my day job to become a chef? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
Defence in depth is in question? After more than 20 years in compsec, the fallacy of the argument that defence in depth is dead is ironic. D.I.D. means that if defence A fails, B comes in. If B fails C comes in then D. etc. Though pdp is a very inventive youngster, it takes a few grey hairs to master security. Or perhaps we in the 'old scool' are deluded. Rgds Pete CUSTOMER TESTIMONIAL OF THE WEEK Claudely Penchiari, IT Manager, Comgas: We selected MIMEsweeper because of its policy-based content security, advanced threat and remote management and its ability to integrate with virtually any third-party anti-virus tool Clearswift monitors, controls and protects all its messaging traffic in compliance with its corporate email policy using Clearswift products. Find out more about Clearswift, its solutions and services at http://www.clearswift.com This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift. If you have received this communication in error, please notify Clearswift by emailing [EMAIL PROTECTED] quoting the sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain. This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including computer viruses. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
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
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
It is important to note that you can block this though a setting in the Terminal Sevices Configuration admin tool. There is a setting to not allow initial programs to be launch or to always launch a specific program. This will always override any program specified by the client. You can also configure this via group policy. It is also important to note that if you can get a user to click on an e-mail attachment you send them, you can probably do anything you want on their computer anyway. Mark Burnett http://xato.net -Original Message- From: Thor (Hammer of God) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 4:11 PM To: pdp (architect); full-disclosure@lists.grok.org.uk; [EMAIL PROTECTED] Subject: RE: Remote Desktop Command Fixation Attacks 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 ___ Full-Disclosure - We believe
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
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
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
Not to step in to the middle of this, but I once worked for an employer with what I considered the best way of stopping attacks cold: a proxy server that prompted you for your credentials when you went to an external web site and gp settings that disabled the ability to save your username/password locally as well as tight settings on the systems to prevent pretty much anything from being installed or modified. So everytime you opened up a brand new session of ie and tried to access an external site you were prompted for your username/password. Somehow I doubt there's any malware around that is designed to survive in that type of an environment. Geoff Sent from my BlackBerry wireless handheld. -Original Message- From: pdp (architect) [EMAIL PROTECTED] Date: Thu, 11 Oct 2007 01:17:16 To:Thor (Hammer of God) [EMAIL PROTECTED] Cc:full-disclosure@lists.grok.org.uk, [EMAIL PROTECTED] Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks 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
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
On Thu, 11 Oct 2007, 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. The reason for security in depth is precisely because no security controls are foolproof. The point isn't to make a system completely unbreakable, but to raise the bar for what is required in order to extend their access beyond what they already control. Lets take a webserver as an example. Your webserver only requires ports 80 and 443 listening to the world, so you deploy a firewall in front of it restricting access to just those ports. A default install of the OS may enable a few other processes bound to remote ports like a mail server, portmap, etc. These processes aren't needed on this particular system. The firewall blocks access to them, but firewalls aren't perfect. The attacker may have found a way to get behind it. So you turn off those unneeded services. Being a webserver, its running a number of web applications. Since you don't want to place more trust in those applications than you have to, you chroot apache and have it run as a non-privledged user. Hopefully this will contain a successful compromise. But still, the attacker may break out of the chroot, so you make sure that you remove setuid applications or at least keep them up to date with the latest security updates. You do your best to keep them from becoming root. But even that may fail. Assuming all else has failed, this system is completely owned. But you have other systems with even more sensitive information. So you architect your network such that this webserver does not have more network prilvedges than it needs. You filter outbound network connections to hopefully block a good portion of botnet command and control functions. You block access from this webserver to other systems unless they have a need to talk to them. You implement application level firewalls between it and services that it does need to talk to. THIS is defence is depth. Its not about perfect security. Its about containing breaches. Its about blocking unnecessary risks. Its about making sure that a small mistake that you make does not hand over the keys to the kingdom. -- Greg ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
At the risk of going off topic - this kind of approach makes end users to get really used to entering their username and password in the web browser. Guess what happens when a (possibly malicious) website asks for credentials (using basic auth/whatever)? These kind of solutions not only limit usability, but they also run the risk of creating security holes. Sent from my vi friendly email client :P On Thu, Oct 11, 2007 at 12:27:48PM +, [EMAIL PROTECTED] wrote: Not to step in to the middle of this, but I once worked for an employer with what I considered the best way of stopping attacks cold: a proxy server that prompted you for your credentials when you went to an external web site and gp settings that disabled the ability to save your username/password locally as well as tight settings on the systems to prevent pretty much anything from being installed or modified. So everytime you opened up a brand new session of ie and tried to access an external site you were prompted for your username/password. Somehow I doubt there's any malware around that is designed to survive in that type of an environment. Geoff Sent from my BlackBerry wireless handheld. -Original Message- From: pdp (architect) [EMAIL PROTECTED] Date: Thu, 11 Oct 2007 01:17:16 To:Thor (Hammer of God) [EMAIL PROTECTED] Cc:full-disclosure@lists.grok.org.uk, [EMAIL PROTECTED] Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks 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
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
Not to step in to the middle of this, but I once worked for an employer with what I considered the best way of stopping attacks cold: a proxy server that prompted you for your credentials when you went to an external web site and gp settings that disabled the ability to save your username/password locally as well as tight settings on the systems to prevent pretty much anything from being installed or modified. So everytime you opened up a brand new session of ie and tried to access an external site you were prompted for your username/password. Somehow I doubt there's any malware around that is designed to survive in that type of an environment. (This is far enough afield that I'm not cc'ing pdp or Thor or anyone else, just the lists). Actually, it's trivial for malware to survive in this kind of environment. If the proxy is HTTP-only and requires a cached http-auth header from the browser, then the malware just has to use any port that is allowed through the firewall directly that's not 80. If the proxy is used to perform client authentication (Cisco, Check Point, and other firewalls do this as well) where a browser authenticates a user and then the proxy allows other traffic from that client IP address for until the session expires or there is an idle time limit reached, the malware need only persist on whatever CC channel it uses until a user authenticates to the proxy/firewall. Then the traffic will still be allowed. In many cases, the malware will be dropped and activated *during* one of these sessions and, at least for a short period of time, will function unhindered. Unless a network can authenticate clients on a per-session on each protocol, there is still plenty of opportunity for malware to thrive. soapbox This is why monitoring and detection are key elements of Defense In Depth, whose death has been prematurely reported a lot this year./soapbox PaulM ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
Well, what is your definition of Security in Depth? On Thu, 11 Oct 2007, pdp (architect) wrote: gboyce, cheers... nice example! although I had something else in mind. maybe I shouldn't have used the term security in depth since your version differs a bit from mine. I guess different semantics. but yes, i agree that systems, processes, data, etc needs to be separated and blended into a balanced mix which as you said, while under attack, it does not give away the keys to the kingdom. thanks On 10/11/07, gboyce [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007, 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. The reason for security in depth is precisely because no security controls are foolproof. The point isn't to make a system completely unbreakable, but to raise the bar for what is required in order to extend their access beyond what they already control. Lets take a webserver as an example. Your webserver only requires ports 80 and 443 listening to the world, so you deploy a firewall in front of it restricting access to just those ports. A default install of the OS may enable a few other processes bound to remote ports like a mail server, portmap, etc. These processes aren't needed on this particular system. The firewall blocks access to them, but firewalls aren't perfect. The attacker may have found a way to get behind it. So you turn off those unneeded services. Being a webserver, its running a number of web applications. Since you don't want to place more trust in those applications than you have to, you chroot apache and have it run as a non-privledged user. Hopefully this will contain a successful compromise. But still, the attacker may break out of the chroot, so you make sure that you remove setuid applications or at least keep them up to date with the latest security updates. You do your best to keep them from becoming root. But even that may fail. Assuming all else has failed, this system is completely owned. But you have other systems with even more sensitive information. So you architect your network such that this webserver does not have more network prilvedges than it needs. You filter outbound network connections to hopefully block a good portion of botnet command and control functions. You block access from this webserver to other systems unless they have a need to talk to them. You implement application level firewalls between it and services that it does need to talk to. THIS is defence is depth. Its not about perfect security. Its about containing breaches. Its about blocking unnecessary risks. Its about making sure that a small mistake that you make does not hand over the keys to the kingdom. -- Greg -- 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/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
On Wed, 10 Oct 2007 14:05:28 EDT, [EMAIL PROTECTED] said: SHUT UP VLADIS IF ANYONE CARED THEY WOULD JUST FREQUENT YOUR BLOG GET OFF THIS LIST THIS IS FOR SERIOUS SECURITY MATTERS ONLY You seem a tad confused regarding the use of the reply button, since: On Wed, 10 Oct 2007 07:14:32 -0400 pdp (architect) [EMAIL PROTECTED] wrote: I wasn't the one who you were replying to. pgpG1OfBMCarG.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
gboyce, cheers... nice example! although I had something else in mind. maybe I shouldn't have used the term security in depth since your version differs a bit from mine. I guess different semantics. but yes, i agree that systems, processes, data, etc needs to be separated and blended into a balanced mix which as you said, while under attack, it does not give away the keys to the kingdom. thanks On 10/11/07, gboyce [EMAIL PROTECTED] wrote: On Thu, 11 Oct 2007, 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. The reason for security in depth is precisely because no security controls are foolproof. The point isn't to make a system completely unbreakable, but to raise the bar for what is required in order to extend their access beyond what they already control. Lets take a webserver as an example. Your webserver only requires ports 80 and 443 listening to the world, so you deploy a firewall in front of it restricting access to just those ports. A default install of the OS may enable a few other processes bound to remote ports like a mail server, portmap, etc. These processes aren't needed on this particular system. The firewall blocks access to them, but firewalls aren't perfect. The attacker may have found a way to get behind it. So you turn off those unneeded services. Being a webserver, its running a number of web applications. Since you don't want to place more trust in those applications than you have to, you chroot apache and have it run as a non-privledged user. Hopefully this will contain a successful compromise. But still, the attacker may break out of the chroot, so you make sure that you remove setuid applications or at least keep them up to date with the latest security updates. You do your best to keep them from becoming root. But even that may fail. Assuming all else has failed, this system is completely owned. But you have other systems with even more sensitive information. So you architect your network such that this webserver does not have more network prilvedges than it needs. You filter outbound network connections to hopefully block a good portion of botnet command and control functions. You block access from this webserver to other systems unless they have a need to talk to them. You implement application level firewalls between it and services that it does need to talk to. THIS is defence is depth. Its not about perfect security. Its about containing breaches. Its about blocking unnecessary risks. Its about making sure that a small mistake that you make does not hand over the keys to the kingdom. -- Greg -- 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/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
That may be a possible process/policy in some environments, but probably not most. Take education/academic environments for example. We really have to try to balance competing interests. For example, the very security and accessibility issues you describe on a macro scale. Not to mention other issues in these environments such as transients and devices we do not own/manage. If users around the world still visit sites to download the storm worm, is it unreasonable to assume that they may execute a rdp or citrix file? -Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 11, 2007 8:28 AM To: pdp (architect); Thor (Hammer of God) Cc: full-disclosure@lists.grok.org.uk; [EMAIL PROTECTED] Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks Not to step in to the middle of this, but I once worked for an employer with what I considered the best way of stopping attacks cold: a proxy server that prompted you for your credentials when you went to an external web site and gp settings that disabled the ability to save your username/password locally as well as tight settings on the systems to prevent pretty much anything from being installed or modified. So everytime you opened up a brand new session of ie and tried to access an external site you were prompted for your username/password. Somehow I doubt there's any malware around that is designed to survive in that type of an environment. Geoff Sent from my BlackBerry wireless handheld. -Original Message- From: pdp (architect) [EMAIL PROTECTED] Date: Thu, 11 Oct 2007 01:17:16 To:Thor (Hammer of God) [EMAIL PROTECTED] Cc:full-disclosure@lists.grok.org.uk, [EMAIL PROTECTED] Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks 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
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SHUT UP VLADIS On Thu, 11 Oct 2007 14:54:52 -0400 [EMAIL PROTECTED] wrote: On Wed, 10 Oct 2007 14:05:28 EDT, [EMAIL PROTECTED] said: SHUT UP VLADIS IF ANYONE CARED THEY WOULD JUST FREQUENT YOUR BLOG GET OFF THIS LIST THIS IS FOR SERIOUS SECURITY MATTERS ONLY You seem a tad confused regarding the use of the reply button, since: On Wed, 10 Oct 2007 07:14:32 -0400 pdp (architect) [EMAIL PROTECTED] wrote: I wasn't the one who you were replying to. -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Charset: UTF8 Version: Hush 2.5 wpwEAQECAAYFAkcOjuwACgkQ+dWaEhErNvSH/wP+OIDM7dHQMS0CGkCyKxqS7UTURari AvDPndt/tmbynO737col1TBfSbzLognqDpveQbpo0OfyHHldZagO2ulokvWURRxDQzxa rFYiV4SVSZYR69v5rwOy8tEPkb/tApXT172BmH2qqMUmPgnlF+V9EmzOOfumePnvrqZX 5QvPaws= =NO9u -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
..I am not planning to support my argument in any way.. That's a shame. If you can prove your hypothesis, it lends credibility to your claims. A refusal to do so only weakens your position. As others have pointed out, your attack only works if security in depth has been blatantly, intentionally ignored. I'll grant that it's an interesting methodology, but it assumes too much and ultimately fails to prove your claims. You're absolutely correct; Security in depth is a process; no one has argued this. What no one has stated is that security in depth has an endpoint. Not only does it require proper analysis, planning and deployment, it's greatly weakened without constant monitoring and adjustment to meet new threats. That said, nothing you have proposed in your attack methodology changes those statements. Jim -Original Message- From: pdp (architect) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 5:17 PM To: Thor (Hammer of God) Cc: full-disclosure@lists.grok.org.uk; [EMAIL PROTECTED] Subject: Re: Remote Desktop Command Fixation Attacks 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
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
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
Re: [Full-disclosure] 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) [EMAIL PROTECTED] 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
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
My employer does this, but I think its easier to fool users, say we craft a website say which again asks for username/password most users will blindly give away their credentials thinking it as a new session.. On 10/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Not to step in to the middle of this, but I once worked for an employer with what I considered the best way of stopping attacks cold: a proxy server that prompted you for your credentials when you went to an external web site and gp settings that disabled the ability to save your username/password locally as well as tight settings on the systems to prevent pretty much anything from being installed or modified. So everytime you opened up a brand new session of ie and tried to access an external site you were prompted for your username/password. Somehow I doubt there's any malware around that is designed to survive in that type of an environment. Geoff ---SNIPPED -- [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] 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 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SHUT UP VLADIS IF ANYONE CARED THEY WOULD JUST FREQUENT YOUR BLOG GET OFF THIS LIST THIS IS FOR SERIOUS SECURITY MATTERS ONLY On Wed, 10 Oct 2007 07:14:32 -0400 pdp (architect) [EMAIL PROTECTED] wrote: 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 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Charset: UTF8 Version: Hush 2.5 wpwEAQECAAYFAkcNFGgACgkQ+dWaEhErNvS4wwQAj8LqbxzIYoXodiXgspcs/YDG0/a8 oNPk3PsmOKHp7N7jVObIEDPjCgGHMRrPfHIEjys5EBTkVr/wq7/y6XPQLdyzIu5VyFE2 04q7slbdkrfImgByVX2itNYDJ5JlbzqrakxxZ9TVrNqqXtjWhw4IN90jDMo8tLoQT0V4 7xtyuiU= =mlsP -END PGP SIGNATURE- -- Click for free info on business schools, $150K/ year potential. http://tagline.hushmail.com/fc/Ioyw6h4dC6kbhaI6CLIgyWpO60jMWLXpHtbVzuYHwGilHWig7GUYZK/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
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 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
