Re: Securing from MITM attack
Date: February 17, 2007 10:53AM
IDS and HTTPS do not prevent any type of MITM attack specifically. IDS only detects attacks, but it normally does not detect the presence of sniffers. In fact, many sniffer/MITM tools such as Ettercap have plugins to defeat IDS through isolation. Funny thing is that you can use Ettercap to find other Ettercaps on your local network (which can also be defeated/obfuscated further if necessary).
HTTPS is usually referred to as SSL. SSL does not always stop MITM and can be vulnerable to replay in some situations. However, it can also stop MITM if used properly, and assuming the encryption standards it supports are strictly enforced - it is not vulnerable to replay. These days, both ECC and DHE are in use by security professionals "in the know" when using SSL and worrying about replay attacks.
DHE = Ephemeral Diffie-Helman keys, which have perfect forward secrecy (PFS).
ECC = Elliptic Curve Cryptography. You might want to look some of these terms up on Wikipedia or by using Google.
ECC, RSA, DSA, and El-Gamal are the preferred cryptographic methods for security professionals to protect data in transmit over hostile networks.
There is no way to prevent the MITM attack if done properly. MITM can occur anywhere in the application path. As an example, it could be system call or library call tracing on the client OS (or maybe on the server). This sort of sniffer is impossible for any network method to locate, and may even be nearly impossible for host intrusion-protection to expose.
Also - IDS and SSL are never fail-proof. Both have implementation and design issues just like any application or protocol does. For example, the Homograph attack against SSL is devastating, although fixed in most modern-day browsers.
One of the basic attacks on SSL is to perform MITM with either
a) ARP poisoning, or
b) DNS hijacking, DNS cache poisoning, or
c) DHCP message subversion/take-over, or
d) gateway take-over with GARP, HSRP, VRRP, IRDP, STP, EIGRP, ICMP redirects, etc
Tools such as Ettercap, Cain&Abel, and dsniff can demonstrate the first two types of MITM attacks well (ARP poisoning and DNS hijacking).
Amazingly enough, there are protections against these. DNSSEC for DNS as a major example. Cisco has a few advanced layer-2 protections available with a combination of port-security (no more than 1 static and 1 dynamic should normally be allowed per-port), DHCP Snooping (required for the next two protections), IP/MAC Source-Guard (required for the last protection), and (my personal favorite) Dynamic ARP Inspection - also known as Cisco DAI. Cisco DAI will make even modern-day hackers and pen-testers confused as to why their ARP-poisoning MITM attacks fail to work. Of course, static ARP entries work about just as well.
However, Cisco routers also need many other mechanisms in place. They shouldn't accept or process gratuitous arps or CDP messages from access ports. They shouldn't allow HSRP, VRRP, GLBP, IRDP, ICMP redirect, Spanning-tree protocol, routing protocol (EIGRP, OSPF, ISIS, BGP, RIP) or other gateway/layer2-to-layer3 attacks to occur. Usually this is best done by encrypting HSRP traffic with IPSec, although there are many other protections available. Administrators will also need to configure BPDU-Guard/BPDU-Filter, as well as Root-Guard and probably something else I'm missing here in order to protect Spanning-tree from access ports. What's worse is that along with physical access, an uplink port or root switch could always be taken-over by unplugging the unprotected port into a rogue device. The tools IRPAS and Yersinia can perform vulnerability assessments on layer-2/3 attacks such as these. Finally, management of the Cisco devices could be compromised in any standard network or system vulnerability which isn't limited to anything in particular and includes all aspects of buffer overflows (heap corruption works particularly well against Cisco IOS PowerPC and MIPS based routers), password guessing via Telnet/SSH/TFTP/SNMP/HTTP brute-force, sniffing of cleartext Cisco management protocols (including anything mentioned so far), etc.
Please don't make me go into Wireless layer-2/3 threats/protections... let's just pretend that Wireless is completely insecure (because it is) and leave it at that.
As for MITM... like I mentioned before - it could be anything in the application path. Thus, it could be an XSS-proxy (XSS is talked a lot about in these forums). An XSS-Proxy wouldn't be affected by SSL protections, as it works in the browser and can control any elements the browser controls. Obviously, the browser converts SSL back-and-forth from viewable cleartext protocol (what you see in your browser) to crypto on the wire (what you see with a network sniffer). If XSS controls the browser, it can also control these aspects.
SSL with DHE strictly set on both client and server should stop 99% of MITM attacks from a network perspective. All network sniffers should be prevented in this way under common ideal conditions. However, cookies should also be set as secure - and passwords are still required and must be protected.
If SSL user authentication is used - it should be done with multi-factor authentication, and it should follow the authentication guidelines made by OWASP and WASC as much as possible.
Now, user protections become a lot more complicated once you start talking about an XSS-proxy that is doing MITM. Older malware in this class (i.e. web application-based malware) is usually referred to as "form-grabbers". XSS-proxies can do a lot more than just form-grabbing. They can enable other web application attacks, including many logic-flaws. It's best to stop XSS if possible, thus avoiding any additional interactions between other web application threats.
Preventing XSS is what we're all trying to figure out. It seems it's easier to find universal XSS injection points and new universal methods for injection than to come up with any particular protection mechanism that universally works.
I would say you are "more protected" as a user if you use a web browser that does not support: ActiveX, Java, JavaScript, Ajax, plugins (some examples: Acrobat Reader, QuickTime, Flash), or images. If your web browser doesn't support any of those things, that's great. If it does support any one of them - you could be hit by XSS. Sounds nasty, huh?
The only "real" way to prevent XSS is on a per-application basis through input validation. This means billions of applications need to be fixed. Input validation guidelines are also provided by OWASP and WASC. Some of the best input validation routines are provided in frameworks that provide security - such as the Anti-XSS work for Microsoft Visual Studio 2005.
RSnake is working on getting those same Anti-XSS protections put into IE7 with that same Microsoft team. Many others are working on promoting httpOnly and content-restrictions as additional methods to protect browsers. Netcraft has a toolbar that helps prevent XSS, and the NoScript plugin for Firefox can help turn-off unwanted Javascript and Flash.
Many "just-in-time" patching efforts by Web Application Firewall (WAF) solutions can prevent most XSS through either checking the input validation before passing client communication to the application... or by preventing servers from sending the script code on the way back to the client via output filtering.
Also - as a user you can also use Tor or CGIProxy (or combination) to encrypt your local traffic to a remote webserver (even if that server does not support SSL). However, unless you control your Tor exit node, traffic leaving that node will be unencrypted (unless it is already SSL), leaving you vulnerable to attack from that exit node, and anything between it and the webserver you are attempting to access.
Probably the best method would be to access a CGIProxy over SSL (you have to set it up to support this separately) over Tor, especially if the webserver you are trying to access does not support SSL. Some of us on these forums do not consider this ridiculous or overkill.
