Page 1 of 1
Protecting from man-in-the-middle attacks & identifying user
Posted: Wed Sep 10, 2008 11:58 am
by kaisellgren
Hi,
I am working on a PHP project. So far I have taken care of XSS, SQL injections, SQL truncation attacks, CSRF, Chain attacks, Header injections, Session fixation, Session hijacking, Session poisoning, Cookie forging, Session forging, Register globals, Remote code attacks, Brute Force attacks and I have some other security features such as Installer lock, Data hashing, Session management, CAPTCHA, IP banning, Advanced hidden/logged error reporting, Magic Quotes are being handled, etc.
But one thing that I am not sure about is the man-in-the-middle type of attacks. How would you protect from those type of attacks?
I would like to discuss seriously with Security professionals about this issue.
Also I have a couple of questions if anyone might know the answer:
1) Is it ok to block all proxies from logging in? I think that some people might get in trouble, like in the work if they have a one big proxy system or something like that? Isn't AOL also some sort of 'proxy' type? I do not know about this especially since I'm east european I never really knew about AOL much.
2) Many scripts have a IP detection like:
Code: Select all
if (isset($_SERVER['HTTP_X_FORWARDED_FOR']))
$ip = ...
But isn't X Forwarded For untrustable?
Looking forward to some talk

Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Wed Sep 10, 2008 10:38 pm
by josh
Well do you mean ARP poisoning? man in the middle is too broad ( at least from my understanding ).
http://www.darknet.org.uk/2008/06/arpon ... gspoofing/
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Thu Sep 11, 2008 4:41 am
by kaisellgren
Well yes. In general, when someone else (a black hat hacker) is getting the same data as the user, he will get login credentials and such details.
Let's say a customer is using your script. He has the admin login information. He is using a WiFi connection and someone is reading the same data and even using the same WiFi to achieve the same IP? Can he 'achieve' the same IP? If he can not, I could check against the IP, but is it wise since the IP might still change often for the real user? How about checking against xxx.xxx.xxx.anything so that the last part of the IP is not taken, can the user's IP still change somehow so much that the IP check would log out him?
Do you have any kind of protection against this? Or do you just go for "nothing to do, so I'll ignore it" -mode?
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Thu Sep 11, 2008 4:51 am
by josh
Well theres many ways someone could listen in on info
http://www.corecom.com/external/livesec ... ishing.htm
If a user's network is vulnerable to ARP poisoning, I could in theory make all the devices on the network think I am the router, and requests outside the network would still come from the same IP address. If the "man in the middle" is outside the user's network, it is something you can detect.
I wouldn't know exactly what to recommend unless I knew exactly what kind of attack you're trying to protect against.
http://dnsstuff.com has the capability to check if the user's DNS has been poisoned, you could implement something like that scripting side.
If the attack was very basic, they may just be functioning as a standard http proxy and you could check the http_forward_for header, but any hacker that knows his stuff is going to be doing it in the TCP/IP layer not in the HTTP layer.
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Thu Sep 11, 2008 5:04 am
by kaisellgren
I would like to be able to stop or at least detect possible user's poisoned/spoofed DNS with PHP. Do you have any ideas on this? Also, if the "man in the middle" is outside the network, but is able to read the data sent by the server to the user, I would like to somehow prevent any access by this "man in the middle".
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Thu Sep 11, 2008 7:33 am
by josh
SSL should provide enough security for standard purposes. Never been too concerned with personally
Here's a resource that provides more info on how the attacks wuold work, which should help you go int he right direction to find more info:
http://www.ddj.com/windows/184416896
A dynamic URL is necessary to decrease the likelihood that an authorized friendly proxy server between the client and server will serve the URL out of cache when the client requests it. To simplify deployment of this defense, the server that generates the dynamic URL can embed the client’s IP address, or an encoded form of it, in the URL path. The server must also process the response dynamically so that it can parse out the encoded IP address and match it against the IP address from which the request arrived at the server. If a malicious MITM relays the request for the dynamic URL from the client, the MITM will expose its IP address to IIS. The simple fact that the client IP address is different in the request to the dynamic URL than it was in the request to the initial URL is proof that two network nodes were involved in making the request rather than just one.
This wouldn't stop phishing though.
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Fri Sep 19, 2008 7:39 pm
by allicient
Hi kaisellgren,
You've really asked an involved question(s) there... but here's a terse answer:
1) No its not a good idea to blindly try and block proxied/forwarded connections, and is a futile enterprise - if you could actually perform this feat of the impossible, what actually would you gain... nothing.
2) You cannot rely on a simple HTTP Header, if its got something like X-Forwarded-For then its probably a legitimate proxy like squid serving for a company or academic institution. The truely "anonymous" proxies are working lower down on the network stack, at the TCP level (the Tor project is a good example here).
Onto you're main question, how to protect against MITM attacks, your only option is to use SSL/TLS; just make sure you do it properly as its easy to screw-up... check my recent blog post for a brief intro into how you can avoid really making a mess of things:
http://www.allicient.co.uk/2008/09/15/https-stupidity/. I'm betting unless you've coded a *very clever* client-side Javascript library, your site is currently vulnerable to session hijacking - you'll *have* to use SSL/TLS if you want to avoid this.... which probably means buying a cert. In theory, SSL/TLS (make sure that's SSL3 only, SSL2 is vulnerable) should ensure your site's security as the user's browser will check your site's certificate chain against the domain name used in the request. In practice things are slightly more complicated, but that's the theory and the only real protection available to you. Rely on SSL/TLS - do NOT try and "roll-your-own", you'll make a mistake(s).
Regards,
Peter
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Fri Sep 19, 2008 8:18 pm
by josh
You could also use a password salt and hash client side, so theres nothing to hijack, as long as the cookie stays protected
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Sat Sep 20, 2008 6:05 am
by kaisellgren
Okay guys thanks for the help. I have a SSL certificate now and my site is operating under SSL if I enter the page with the 's' in the http protocol of the URI.
The proxy question, I got the answer
The MITM attack, SSL protects, right?
I'm currently only worried about a few things:
A) How and when do these "Some parts of this page are not fully SSL protected" -messages appear? I think if you have a SSL protected page and you have an image there and the browser loads the image without SSL, then this message could appear depending on the browser. How to stop it?
B) Does HTTP_X_FORWARDED_FOR return the orginal IP of the proxy user? (in general, I now it could be different if the proxy wants as it is changable.).
C) If an authenticate user suddenly has different IP, I could log him out, but on some ISPs or situations their IP might change. So, what if I check against the first three parts of the IP? (6.6.6.x)
D) User agent string never changes during web surfing? Any other unchangable strings that I may use to detect a hacker?
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Sat Sep 20, 2008 6:35 am
by josh
A) Use https:// for all images, and content. Including flash movies you may have on the page.
B) Always assume the IP spoofed
C) You can definitely check based on subnets
D) I wouldn't rely on any of the user provided strings. use print_r( $_SERVER ) to see everything at your disposal though
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Mon Sep 22, 2008 1:47 pm
by allicient
In reply to jshpro2's post:
You could also use a password salt and hash client side, so theres nothing to hijack, as long as the cookie stays protected
Sorry, but I'd have to point out that this advice is pretty much useless. There are two scenarios to consider:
i) If you've already sc*ewed things up by using a mixture of HTTP and HTTPS, but think that a client side script that does either challenge-reponse authentication or sends a hash of the password will fix it - wrong. The initial login form was probably loaded via plain HTTP, and so your fancy javascript is modifiable in transit, which totally breaks your security. Secondly *ANY* HTTP request sent during in that session (say to load a session related page after login) will transmit the session cookie, which enables and attacker to hijack the session anyway, regardless of any initial login security.
ii) If you're loading everything over HTTPS, including the initial login form and all images, static pages, applets, the lot - then as long as the way the web server generates session cookies is good (i.e. its cryptographically unpredictable) then you're pretty much sorted anyway. You don't need to do any fancy client side scripting.
Considering a fair proportion of past browser vulnerabilities involved javascript in some way, why would you want to shovel on an additional possible attack vector (especially when it involves more coding)? Remember, with security simplicity is best!
Regards,
Peter
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Mon Sep 22, 2008 5:24 pm
by josh
a salt prevents a capture and playback scenario, it doesn't replace encryption. Security is relative, the more you do to prevent it the safer you are, each time you add a layer of protection your security levels go up exponentially, so why not take every preventative measure within reason?
a salt won't stop an experienced determined hacker, then again neither will SSL
Re: Protecting from man-in-the-middle attacks & identifying user
Posted: Tue Sep 23, 2008 3:29 am
by Maugrim_The_Reaper
The best approach with security isn't just simplicity, it's depth

. You know the medieval guys had it spot on - overlapping armour plates are far more effective than linked plates.
I'm all out of analogies now...
