Two Carleton University 4th year computer science students, Michael Nemat and Matthew Ng, starred in a story shown February 14, 2011 on Global National, the national newscast of Canada’s Global Television Network. They were interviewed by their Ottawa correspondent Shirlee Engel on the rogue access point and web hijacking attacks. Click on the following image to wiew the video of the interview.
The participants and their relationships in the attacks demonstrated in the interview can be pictured as follows:
It involves two aspects: luring a victim with a free insecure WiFi access point and hijacking its web traffic when the victim starts using the rogue access point. Traffic may be hijacked by the adversary running an attack called SSL Strip. Credentials of the victim can be intercepted and saved, for future malicious uses, when the victim starts visiting theoretically secure web sites.
When the victim is about to enter its user name and password, its web browser is normally switched to a secure web connection. The adversary intercepts the procedure and breaks the connection into two segments. The first segment is a secure connection between the adversary and web server. This is required for normal operation with the web site. The second segment is an insecure connection between the adversary and victim. The adversary sits in the middle and bridges the two connections while copying in clear all the information typed by the victim.
Truly, the problem is not that the web server is insecure, but the failure to establish an end-to-end, browser-to-server, web connection. You may read the technical details about the SSL Strip attack by following this link.
Detection of the attacks by the victim requires recognizing a few differences in the presentation of the web pages. Look first at the following web page (you may double click on it to make the picture bigger):
Now look at the corresponding true web page:
The browser is Internet Explorer. With a secure end-to-end connection from the browser to the web server (second picture), the web site name is prefixed by “https:”. Moreover, the web site’s legitimate favicon (the company logo) is placed to the left of the name. A padlock is placed to the right. With an insecure connection (first picture), the name is prefixed by “http:” with a fake padlock placed to the left. No padlock is displayed to the right. Here are two more examples.
Fake web site:
True web site:
This time, the browser is Chrome. With a secure end-to-end connection, the “https:” part of the web site name is highlighted in green with a green lock displayed to the left. In the absence of a secure end-to-end connection with the web site, there is no “https:” prefix shown in the name (not even a “http:”). There is no green padlock to the left of the name.
Fake web site:
True web site:
The browser is Safari. With a secure end-to-end connection from the browser to the web server (second picture), the web site name is prefixed by “https:”. This is it! Safari is the worst among all three browsers for security awareness.
The three bank web sites are compromised in a similar fashion. There are noticeable visual differences similar in nature for all of them. In the fake cases, the web site’s favicon may be replaced by a picture of a padlock that mimics the one the browser uses to indicate a secure connection with the web site. The prefix used for the web site name is “http:” instead of “https:”. The the absence of the “https:” prefix is the main indicator of an insecure connection.
Users can protect themselves from this attack by bookmarking the “https:” version of their bank web site name, as opposed to navigating their way from the unsecure page of the bank (the “http:” version) to the secure login page. The browser will initiate all communications through a secure connection and the adversary will have no chance to tap in. There are, however, web sites that do not redirect to a secure page before logging in (such as Facebook, Twitter, and many others). They are the most vulnerable as there are no visual clues that a secure connection is not present:
Fake web site:
True web site:
The browser is Internet Explorer. There are no visible differences. The user would have to look a the source code of the web page to observe replacement of “https:” (the true case) by “http:” (the false case) in the web site name.
To be fair with Facebook, if you fail to login from the main page, then you are redirected to the following login page with the security awareness features such as the padlock and “https:”
My advice, before you are about to enter any personal data on a web page, look for the true indicators of an end-to-end secure connection with the server such well-placed padlocks and web site names stating with the “https:” prefix. They should remain for the whole duration of your session with the web server. Avoid using the same password across different web sites. If your password for one web site has been exposed to an unauthorized person, then the door is opened to your other accounts because of an identical password. You may read the newspaper or check weather forecast using free public WiFi access points.
Acknowledgements: Thanks to Michael Nemat for providing me input and visual material for building this post.
Posted by ve3emb 
PowerSDR
