Paid Advertising is
ha.ckers sla.cking
This group should mostly be dealing with how web applications enable networking security issues that are otherwise not there. Everything is being tunneled over port 80 now so what does that enable and how do we fix it? 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Securing from MITM attack
Posted by: iota
Date: February 17, 2007 07:53AM

Dear Mr. RSnake && other web security gods

I'm always concerned with my everyday logging to site without https.
Please grant me your idea to protect network snippers from users' point of view.
How can a web developer proect those snippers for his members if his site doesn't have https.
I have also learnt that https is also vulnerable to Replay attack.
Vigilent network admins can know those snipping with IDS but not users?
How can users know they are safe?
How can a web develop make secure?

Thank you so much.

Please correct my ideas/knowing if they're wrong.

Edited 1 time(s). Last edit at 02/17/2007 07:57AM by iota.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: ntp
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.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: iota
Date: February 18, 2007 05:52AM

so thanks, ntp for detailed explantion.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: hackathology
Date: March 17, 2007 01:04AM

Thats was a detailed explanation. Nuff said

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: FR3DC3RV
Date: March 17, 2007 04:51PM

Very Good explanation.
It was very useful to me.


Edited 1 time(s). Last edit at 03/17/2007 04:53PM by FR3DC3RV.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: hackathology
Date: March 18, 2007 01:45AM

same here. :)

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: ash
Date: July 11, 2007 07:22AM

Great post ntp could almost compile that into an article.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: ntp
Date: July 11, 2007 10:10PM

MITM and XSS has become even more of a synergy since I wrote that blurb.

what can easily happen now is something similar to what is described on pages 252-256 in the "XSS Attacks" book.

using airpwn, injection of attackapi (the book uses BeEF in the example) would be trivial. even using noscript, it is likely that the client will allow at least one url for a period of time. even one simple http get could allow the injection to occur. if the wifi user was using a browser that did not support javascript, they could avoid this sort of attack, but unless all browser traffic is encrypted (ssl would suffice), this attack vector remains extremely critical.

what's worse is that the same airpwn+attackapi concepts can be applied to regular ethernet lans. using ettercap as described on this website
it is possible to perform a simple airpwn-style injection using arp poisoning.

previously, i was thinking of using karma to do this. airpwn is much more simple, as is the ettercap filters method. however, the karma method would also work extremely well for injection on many clients/browsers at once. additionally, there are advanced karma techniques described in the Hacking Wireless Exposed book by johnny_csh and vliu.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: ma1
Date: July 12, 2007 05:49AM

ntp Wrote:
> even using noscript, it is likely that the client will
> allow at least one url for a period of time. even
> one simple http get could allow the injection to occur

Since you wrote your great blurb, a couple things have changed about NoScript:
1) Unconditional Anti-XSS filters strip away any potential XSS payload from requests from untrusted to trusted sites.
2) HTML/JavaScript Injection checks are applied to every cross-site request landing on a trusted site, no matter if the origin is trusted or not.

This should raise a bit the bar against NoScript users.
You still need to spoof a whitelisted site, but you also need to evape Injection Checks and Anti-XSS filters.
So far, they performed considerably better than PHPIDS*, if this means anything at all.

*comparison is admittedly unfair, since NoScript syntax-checks data fragments using SpiderMonkey, while PHPIDS (still?) sticks with RegEx only.


There's a browser safer than Firefox... Firefox, with NoScript

Edited 2 time(s). Last edit at 07/12/2007 07:26AM by ma1.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: Anonymous User
Date: July 12, 2007 10:22AM


while PHPIDS (still?) sticks with RegEx only.

Giorgio - we had this discussion already and I think the reasons were pretty clear why we can't and won't use Spidermonkey or a Rhino derivate now. We need to have a complete (X-)browser emulation layer to make use of a solution like that. Stuff is currently being coded by people like eJohn but it's still way to immature to be used in PHPIDS.

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: ma1
Date: July 12, 2007 11:51AM

.mario Wrote:
> while PHPIDS (still?) sticks with RegEx only.
> Giorgio - we had this discussion already

My "still" didn't imply that I pushed an immediate turn around, nor that I didn't understand your points, but I happened to see this right before posting and I thought the discussion about a 3rd party tokenizer in PHPIDS was still open (as a theoretical path, at least).

Thanks for clarifying.
BTW, another "unfair" advantage is that I need to code just for one platform (thus SpiderMonkey is optimal), while you need to be x-browser, as you said.


There's a browser safer than Firefox... Firefox, with NoScript

Options: ReplyQuote
Re: Securing from MITM attack
Posted by: Anonymous User
Date: July 12, 2007 12:53PM

Sorry - didn't wanna sound rough. As soon as a real parsing engine will bring advantages for the PHPIDS we will think about how to build it in - the idea is not buried. But as said - at the moment neither the team nor me see a real benefit.

Options: ReplyQuote

Sorry, only registered users may post in this forum.