Major Swedish bank SEB serves their public site HTTP, with no HTTPS version available. The front page http://www.seb.se has a big Login button that then takes the user to the secure HTTPS part of their site, where the user then logs in. I hope to be able to explain why this is bad for users because it gives Attackers more opportunity. I hope to convince SEB to acknowledge this and stop serving their public site over HTTP, going HTTPS only. I started noticing this problem a few years back, contacted them a year ago or so for deaf ears, contacted them again recently and kindly got a person listening to me but I failed to get an acknowledgement of any sort. I proposed that I write something up instead.
Victim normally logs onto internet bank by typing www.seb.se into URL bar in web browser, either typing it out fully or just part of it and selecting the auto-completed URL. Alternatively, Victim has put a bookmark on http://www.seb.se, and clicks that bookmark to come to the front page. Alternatively, Victim logs in by searching for “SEB” in their favorite search engine and is taken to http://www.seb.se that way.
Victim is connected through a public network, say a WiFi network called “SJ” while going on train with the company SJ. [That wifi network is controller by Attacker but Victim does not know that. Since Attacker controls the network they control DNS, unencrypted HTTP traffic and so on. HTTPS in the safety-net for this scenario and the browser will display scary warnings if Attacker tries to intercept it]. Victim logins to SEB using the normal procedure. Front page is shown identically to what Victim is used to.
Victim clicks the Login-button and is taken to a login form (with social security number and PIN code) that looks identical to what Victim is used to. Victim does not notice that the URL is different from what Victim is used to, because it all looks pretty legit. The URL for the login-page says http://www.seb.se/login and there is no green lock icon.
Victim logs in. Victim starts doing their banking as usual and does not notice that the site asks Victim to input numbers on their security dongle differently than what Victim is used to.
Finally, Victim notices that money is missing on their account.
If SEB would have all their public pages served over HTTPS only, and a small HTTP => HTTPS redirect (301 Permanently Moved) proxy on top of that, then this attack vector would be greatly reduced.
Let’s go through the different login-options. If user types the URL in location bar, either full www.seb.se or part of it an then selects the completed value, the browser is likely to perform the request straight over HTTPS because it remembers the 301 Permanently Moved redirect. If user clicks bookmark (that is https://www.seb.se) then again the browser goes straight to HTTPS. If user searches Google then the first result will still be https://www.seb.se, straight to HTTPS. With all three login-options, Attacker has much, much less opportunity of a MITM and this is the whole point of this text.
While Attack surface is reduced, it’s not bullet proof of course. If the Victim have cleared the cache recently, the 301 Permanently Moved redirect may not be remembered by the Browser and the first request may be sent over HTTP, so MITM opportunity. If Attacker manages to intercept the Google search in a situation where the Victim searches by typing www.google.com in address bar then again MITM opportunity. The latter case is not too likely because browsers nowadays have built-in support for searching, sending the query over HTTPS. Also, modern browsers implement HSTS which Google is configured for, in preloaded lists. See Bonus points for more info.
I suggest that SEB makes their entire site HTTPS by default (with a HTTP => HTTPS redirector), hopefully within a reasonable timeframe.
If SEB registers for HSTS in modern browsers preload list, in addition to going HTTPS only, then they further reduce attack vectors by fixing the “user types www.seb.se into address bar but has recently cleared its cache” weakness in many browsers. They could also use make use of Strict-Transport-Security header.
Q: But if serving the public site over HTTPS is not bullet-proof then why bother? A: Because it reduces the attack vectors.
Q: But HTTP is so fast. A: Properly configured HTTPS does not have to be super-slow. Also, what customer trades a speed improvement for reduced security? Also, that was not a question.
Q: This gist contains obvious information and hardly nothing new. Any security engineer knows 10x more than you. A: Yes I agree.
Q: You're wrong in this and that. A: Thanks for pointing it out!
Q: But other banks to this too, why are you picking on SEB? A: Because I'm a SEB customer, and I don't know if I have the patience to wait another year or two for them to fix this. Also, SEB does worse in terms of HTTPS than any of the major Swedish banks SEB. For example, both www.nordea.se and www.swedbank.se defaults to HTTPS via a redirect, which is what I suggest that SEB should do, too (they are not in HSTS so no bonus points though).
Q: But the user should have noticed that there were no green lock icon on the login page! A: One would hope so. I think some users would.
Q: But the user should have noticed that the procedure for entering numbers into their security dongle is different. A: One would hope so. I think some users would.
Q: If Victim logins via a bookmark to https://privat.ib.seb.se/wow/1000/1000/wow1020.aspx then they are not affected by this attack. A: Correct.
Q: You're using totally wrong security speak nomenclature and your English is terrible. A: Sorry about that.
Q: So what did SEB tell you? A: They disagree that their preference of HTTP is problematic from a security standpoint and makes it easier to do a MITM.
Q: No matter what you're saying attacker could always try to lure Victim into http://www.1seb.se or https://www.1seb.se with a phising mail or something similar. A: Yup. That's a different attack vector.
https://www.facebook.com/phellqvist/posts/10153115308222916