Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Internet Storm Center Internet Storm Center

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Internet banking sites and their use of TLS... and SSLv3... and SSLv2?!

Published: 2019-12-13
Last Updated: 2019-12-13 07:26:47 UTC
by Jan Kopriva (Version: 1)
2 comment(s)

Although SSLv3 has been considered obsolete and insecure for a long time, a large number of web servers still support its use. And even though the numbers are much lower, some servers on the web support SSLv2 to this day as well. And, as it turns out, this is true even when it comes to web servers hosting internet banking portals…

Tests of SSL/TLS configuration are usually conducted as a normal part of a vulnerability scan or penetration test of TLS-enabled servers. But even when done as a stand-alone activity, they can provide us with very interesting information, especially when the targets are highly-sensitive servers, such as the ones used to provide internet banking services. That is the reason why many people and organizations have published analyses and statistics of TLS configuration of banking sites over the years[1]. I’ve actually done so myself a couple of times[2]. Most, if not all of such analyses have however been limited in scope and covered only a specific country or region.

For a long time, I’ve wanted to try to do a similar analysis on a global scale and when a colleague of mine provided me with a list of nearly 1,500 unique internet banking sites from all around the world earlier this year, I couldn’t let the opportunity pass. Even though 1,459 unique internet banking domains might not sound like much, when one considers that there appear to be between 25,000 and 85,000 banks overall[3], and not all such institutions provide internet banking services, it is actually not a bad sample size.

Before we get to the analysis and its results, let’s take a short look at TLS.

At this point in time, SSL and TLS have been used to secure communication over untrusted networks for almost 25 years[4]. The protocols, as well as the cipher suits which they use, have evolved significantly over time in reaction to discovered vulnerabilities and weaknesses. This cycle has led us to the current state of affairs, when, according to the current best practices[5], it is advisable to use TLSv1.2 and TLSv1.3 only, unless there is a special reason to use/support an older version or the protocol. But even though TLSv1.0 and TLSv1.1 are now considered outdated and will probably stop being supported by browsers in the near future[6], these protocols still provide a significantly higher level of security then SSLv3 (which was itself a notable improvement over SSLv2).

A large number of tools can determine which protocols and cipher suites a server supports[7]. In this case, I’ve decided to use Nmap, since its scans are fairly quick and it has couple of scripts (ssl-enum-ciphers.nse and sslv2.nse), which can provide us with almost all the information we might want with regards to SSL/TLS. The only drawback is that SSL/TLS enumeration capabilities of Nmap currently lack support for TLSv1.3[8], which is the reason why you won’t find statistics for use of the latest version of TLS protocol mentioned bellow.

After deciding to use Nmap, I fed the list of internet banking domains to it and had it output the results to XML. The ssl-enum-ciphers script gives us – among other data – information about all the protocols and cipher suits used by a server and marks them on a scale A to F, based on the security they provide, using a slightly modified version of the SSL Server Rating Guide methodology[9,10]. Since this script can however only identify use of SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2 and I wanted to identify SSLv2 support as well, I’ve used it in a tandem with the sslv2 script, which provides this functionality. Once the scan was done, I generated a CSV from the resulting XML using a quick-and-dirty Python tool I wrote for parsing outputs of both Nmap scripts and I delved into analyzing it.

Due to several servers being unreachable, broken DNS records and other error conditions, Nmap didn’t manage to get data for all domains from the original list, but for “only” 1375 domains from 143 TLDs. The information I was most interested in for each server was a list of supported protocols and a mark for the weakest cipher suite, along with data about vulnerabilities and weaknesses related to SSL/TLS which Nmap managed to identify (specifically SWEET32, POODLE and use of RC4).

Given how sensitive the communication sent to internet banking servers is, the results were quite surprising – one server was actually affected by POODLE, 4 servers managed to hit the worst mark (F) for the weakest supported cipher suite, more than 3% of the servers supported SSLv3 and almost 1% (11 servers) still even supported SSLv2. Since there hasn’t been a reason use SSLv3 for a long time (barring exceptional cases), one might not expect to find it – not to mention SSLv2 – supported on any web server that provides a service for which ensuring confidentiality of its network traffic is paramount…

As you may see, the results didn’t look especially good – they were notably worse than I would have expected for internet banking servers. I wasn’t sure, however, whether they were on average worse or better than results for any other high-profile sites. I therefore decided to look for a “baseline” I might be able to compare the results against. I ended up choosing the Top 1000 Sites from Alexa, as – although most of these are not as sensitive as the internet banking sites – they are high-profile enough so that we might expect that reasonable security standards are enforced on them.

Scan of the 1000 sites resulted in only 921 results from 78 TLDs. The reason was that some of the second-level domains which were present on the Alexa list didn’t have any DNS records set (i.e. cloudfront.net, twimg.com, etc.). As you may see bellow, in some areas the banking sites did better than our baseline, while in others they did worse. On average it seems that while the Alexa Top 1000 sites are all over the map when it comes to SSL/TLS configuration, it appears that while most banking sites are configured very well, a notable minority seems to be configured quite badly.

The following chart shows overall support for all protocols. It should be mentioned at this point, that although support for TLSv1.2 was generally quite high in both samples, only 23.7% of banking sites and 14.7% of Alexa sites supported only TLSv1.2 (and possibly TLSv1.3) and were therefore configured according to the current best practices.

When it comes to vulnerabilities, the internet banking servers seem to be better configured then the “Top 1000” sites (although even one vulnerable internet banking server would seem one too many). Almost half (49.19%) of the Alexa sites and almost one third (30.55%) of the internet banking servers were vulnerable to SWEET32, 7 banking sites (0.59%) were found to still support RC4 while there were 12 such sites (1.30%) on the Alexa list. On the same list were also 5 sites (0.54%) still affected by POODLE, while – as was mentioned above – there was “only” 1 such site (0.07%) among the internet banking servers.

While the most common SWEET32 vulnerability isn’t that bad, POODLE and the continued use of RC4 are definitely worrisome (for more information, see Bojan’s webcast at https://www.sans.org/webcasts/111400).

Although the above mentioned statistics definitely don’t give us the entirety of the situation and should not be taken out of context, they are quite unsettling. They seem to indicate that even when it comes to internet banking sites, security doesn’t always get the attention it should. This is especially well illustrated by the continued support of deprecated SSL protocols on several of the sites. Which – from a purely technical standpoint – is actually quite interesting, given that most browsers today have support for SSLv2 and SSLv3 turned off by default…

 

[1] https://www.scmagazineuk.com/uk-high-street-banks-accused-shockingly-bad-online-security/article/1477266
[2] https://www.systemonline.cz/clanky/ne-bezpecnost-internetoveho-bankovnictvi-v-cr.htm
[3] https://www.linkedin.com/pulse/how-many-banks-globally-david-gyori
[4] https://en.wikipedia.org/wiki/Secure_Sockets_Layer
[5] https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
[6] https://www.thesslstore.com/blog/apple-microsoft-google-disable-tls-1-0-tls-1-1/
[7] https://isc.sans.edu/forums/diary/Verifying+SSLTLS+configuration+part+1/25162
[8] https://github.com/nmap/nmap/issues/1348
[9] https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
[10] https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide

-----------
Jan Kopriva
@jk0pr
Alef Nula

Keywords: Alexa Banking SSL TLS
2 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Code & Data Reuse in the Malware Ecosystem
Dec 12th 2019
1 day ago by Xme (0 comments)

German language malspam pushes yet another wave of Trickbot
Dec 11th 2019
3 days ago by Brad (0 comments)

Microsoft December 2019 Patch Tuesday
Dec 10th 2019
3 days ago by Renato (0 comments)

(Lazy) Sunday Maldoc Analysis
Dec 9th 2019
5 days ago by DidierStevens (0 comments)

Wireshark 3.0.7 Released
Dec 8th 2019
5 days ago by DidierStevens (0 comments)

Integrating Pi-hole Logs in ELK with Logstash
Dec 7th 2019
6 days ago by Guy (0 comments)

View All Diaries →

Latest Discussions

"slow" half open tests (preparation for attacks?)
created Oct 28th 2019
1 month ago by Anonymous (0 replies)

Recommended Desktop Antivirus to use?
created Oct 21st 2019
1 month ago by Anonymous (0 replies)

Suspicious Domain Scoring
created Oct 4th 2019
2 months ago by Luke (1 reply)

SANS ISC InfoSec News RSS Feed broken?
created Aug 29th 2019
3 months ago by Adi (2 replies)

Attack
created Aug 14th 2019
4 months ago by Anonymous (0 replies)

View All Forums →

Latest News

Top Diaries

An infection from Rig exploit kit
Jun 17th 2019
5 months ago by Brad (0 comments)

Wide-scale Petya variant ransomware attack noted
Jun 27th 2017
2 years ago by Brad (0 comments)

Using a Raspberry Pi honeypot to contribute data to DShield/ISC
Aug 3rd 2017
2 years ago by Johannes (0 comments)

Second Google Chrome Extension Banker Malware in Two Weeks
Aug 29th 2017
2 years ago by Renato (0 comments)

Detection Lab: Visibility & Introspection for Defenders
Dec 15th 2017
1 year ago by Russ McRee (0 comments)