1

The homepages of several banks are available over http. Some have search engines linked to http.

This, it seems to me, makes their users trivially vulnerable to MITM attacks if they visit the bank over e.g. public wifi.

This, it further seems to me, means that bank account security is depending on “I hope they only access their bank accounts from secure home networks” <crosses fingers>.

It looks to me that for an outlay of (1) a wifipineapple or other Evil AP device and (2) a $fewhundred to pay someone to customise SSLStrip with fake versions of 3 or 4 specific bank sites, I can:

  • Go sit in a shopping mall for a couple of days with the pineapple
  • Collect entire traffic user<->bank
  • Take over sessions and start making payments

i.e: easy-to-mitm-public-wifi + easy-to-spoof-http-homepage => easy to hack.

What have I missed—it can't be that easy and cheap to hack bank accounts, can it?

————————————————————————————————————————

PS I raised a complaint with my bank and they called back to point out that the login page asks me to install https://www.trusteer.com/ProtectYourMoney (an IBM product) which apparently addresses this kind of attack by closing down the browser.

Also that I should not use the search engine to find their website. But I suppose once you've stolen a public AP, DNS poisoning is simple too

  • Bad, but normal for a bank - mine even has a big banner about fraud and how to stay safe on an HTTP site. Just be sure that the actual page where you log into your accounts is over HTTPS. Fortunately things are changing - here's a new UK bank that actually cares about UX and even has an API. – André Borie Jan 25 '17 at 22:48
  • nb I added detail after your comment – Chris F Carroll Jan 25 '17 at 22:50
  • It is indeed that "cheap" to obtain bank credentials - however for important things there is often 2FA (using a phone call, SMS or even an EMV-CAP card reader) so the credentials alone won't give you the money. – André Borie Jan 25 '17 at 22:55
  • I acknowledge that the one bank account I've had which doesn't issue an OTP device does use my mobile. So I guess they've all got 2FA. – Chris F Carroll Jan 26 '17 at 17:15
6

On websites that experience large amounts of traffic (e.g. consumer sites, like banks) administrators have decided to use mixed plaintext HTTP and HTTPS implementations. Typically, HTTP is used for public information, and the switch to HTTPS occurs when accessing private resources such as a login screen.

This practice largely came from the days when SSL (now TLS) encryption/decryption was costlier (1990s and early 2000s) from a CPU perspective, and could severely slow down page load times.

Now, with faster CPUs more adept at using hash algorithms like SHA256 and encryption ciphers like AES, this problem is less obvious. However, if you're running a large-scale web server receiving thousands of hits a minute, the administrator will surely notice TLS traffic vs non-TLS traffic in terms of CPU utilized. The plaintext site will require less CPU and IT maintenance overhead, and in turn cause a savings to the organization in terms of hosting expense. Additionally as pointed out in a comment by @mgjk, the costs of certificate management between bank IT departments (business versus personal, trading vs other commerce, WAF and DDoS mitigation layers that need to be able to do SSL decryption, etc) is also significant and cumbersome in a large organization, and can lead to a reluctance on the part of management to roll out a TLS-only site.

Thus many banks continue to leverage mixed HTTP and HTTPS web sites. New best practices are being developed to control for problems and attack vectors present in this setup, notably "SSLStrip" style MiTM attacks. Control measures include use of HSTS headers, and are making headway to banks -- but have yet to achieve wide-scale commercial implementation from these large, generally risk and change averse entities.

As far as the specific situation you describe with a WiFi Pineapple as an Evil AP, this would be possible if you stage an "SSLStrip" attack, or another man-in-the-middle attack.

However, many banks take measures to protect against session hijack attacks -- notably expiring the session quickly. If the device had visited the site before and it sent HSTS headers, an error (perhaps enough to scare the average user) would surely result. So, the attack scenario you describe is a bit simplistic and would require a bit more sophistication before being viable against modern bank web site implementations.

However, yes, when banks don't force the use of TLS with HSTS and certificate pinning, a large attack vector is opened up similar to what you describe -- and this practice should be phased out!

2

While I consider the bulk of Herringbone Cat's answer to be very misleading, he/she is correct in saying that the situation you describe is far from ideal. But there are steps which a site provider can take to mitigate the attack in other ways.

SSLStripping has been a well known attack method since 2009. The most effective solution to date is HSTS where a capable browser will remember (or be told) which sites exclusively use HTTPS. However:

  • this is keyed to the domain name - you can't mix HTTP and HTTPS on the same domain name
  • it is only very recently that MSIE (Edge 11) has implemented HSTS support (a long time after Chrome, Firefox and Opera)

There are other solutions based on detecting the connection type in the browser at run time using server-supplied logic - but the obvious limitation is that this logic is more susceptible to tampering.

There are also other more subtle methods for detecting fraud which can be implemented server-side and are applicable to other types of attack; split sessions, unusual navigation patterns, bot detection, patterns of transactions... The secrecy of such methods is rather important to their efficacy - hence the banks will not be publishing information about what these controls are.

But we don't know if the sites in question are using such protections.

Another point to bear in mind, is that the attack need not be initiated on the bank's website itself (nor is the attack restricted to bank websites) but on any web page which has links to the site you wish to strip. Microsoft's bing.com site is still served up over HTTP by default. IMHO this is dereliction of their duty of care to their customers.

However, even in the absence of any protection, for your attack to be successful you would need to be MITM'ing a device at the same time as the user happened to log into their bank. I suspect that a shopping mall would not give a particularly good yield.

So, yes, it may be that easy.

  • "you can't mix HTTP and HTTPS on the same domain name" Not with HSTS, true enough, but you can easily have www.example.com without HTTPS and HSTS, and secure.example.com with HTTPS and HSTS. Mixing HTTP and HTTPS is not a problem when you aren't using HSTS, so without HSTS you can have both HTTP and HTTPS on www.example.com. – a CVn Jan 26 '17 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.