Tag Archives: OpenSSL Heartbleed

OpenSSL Heartbleed persists on 200,000 systems/devices

April 2014 saw the worldwide public disclosure of the Heartbleed vulnerability (a difficult to detect and easy to exploit information disclosure issue) within the open source OpenSSL encryption library. Almost 3 years on, approximately 200,000 servers/devices remain vulnerable.

Shodan, the search engine that can detect vulnerable devices connected to the internet released these findings in their Heartbleed report during the weekend of January 21. The report highlights approximately 52,000 Apache web servers with version numbers 2.2.2 and 2.2.15 remain critically vulnerable. Amazon Web Services and Verizon Wireless were the largest hosts of these vulnerable systems with the United States being the location for the most vulnerable internet service providers (ISPs). Another significant finding of the report is that many organizations/businesses are unware their physical and virtual servers are vulnerable.

How Can I Protect Myself from This Vulnerability?
If you or someone in your organisation uses physical or virtual servers, please ensure these servers have all vendor security updates installed, specifically updates from OpenSSL. Unsupported web servers (physical or virtual) or software (which uses the OpenSSL libraries) should be upgraded/replaced. Moreover, OpenSSL versions prior to 1.0.2 are no longer supported; please upgrade to version 1.0.2 or 1.1.0.

Due to the increasing numbers of devices connected to the internet, organizations and individuals need to be aware if their devices or software are vulnerable. For example, earlier this month vulnerable MongoDB, Elastic Search, Hadoop and CouchDB servers. Any software that connects to the internet especially VPN (Virtual Private Network) (defined) software may be vulnerable to the Heartbleed vulnerability.

Thank you.

=======================
Aside:
=======================
What is Shodan?
Shodan was originally created as a project in 2003 by a computer programmer John Matherly who launched the Shodan website in 2009. It is named after the enemy AI of the System Shock series of video games.

It is a search engine like Google, Bing and Yahoo but it isn’t searching for websites that best match the text that we enter. Instead it indexes and categorizes all devices connected to the internet. It does this by searching for and interpreting their banner e.g. Apache 2.4.3, OpenSSL/1.0.1c PHP/5.4.7

It is usually webservers that use such banners but many devices (e.g. FTP and mail servers) use banners to describe the services they offer, what operating system they are using e.g. Red Hat/Linux and the ports they have open e.g. 80 for HTTP, 443 for HTTPS, 21 for FTP, 25 for SMTP, 23 for Telnet, 22 for SSH etc. For example, we use ports 80 and 443 everyday as well port 25 for email.

What can it be used for?

  • Shodan can be used to detect the types of devices on your network and what types of ports (entry points to and from those devices) they are using. This is good to know since you can then better secure them against possible attack. Shodan can also be used to look for and access any device that is poorly configured namely that it allows access to it’s configuration/admin page from the Internet.
  • You can also use it to check if there are any unknown devices on your devices that arrived through social engineering e.g. a new router/access point in a conference room or shadow IT (devices installed by staff without the knowledge of the IT team).

OpenSSL 1.1.0 Adds Partial TLS 1.3 Support

====================
Update: 1st April 2018:
====================
With the approval of TLS 1.3 by the IETF after 28 drafts (at the time of writing their February 2018 blog post OpenSSL had implemented draft 23) of the now completed standard.

This approval brings the upcoming implementation of TLS 1.3 one step closer. As noted in the news article I linked to above; it will take time before we begin to see websites migrating to it and may be some years before it becomes an everyday protocol.

As highlighted in that article, the transition won’t be straightforward but, in my opinion, will be more than worth our efforts.

Thank you.

====================
Update: 14th February 2018:
With the publication of the first alpha of OpenSSL 1.1.1; OpenSSL is moving closer to a release version with full TLS 1.3 support.

Thank you.
====================
Update: 17th November 2016:
Since publishing this blog post, the OpenSSL Foundation have provided more information on their timetable for implementing TLS 1.3. They intend to have full TLS 1.3 support in the next feature release of OpenSSL 1.1, namely 1.1.1. Further details are available within OpenSSL’s blog post.

Moreover, in late October Mozilla announced that the upcoming version of Firefox 52 set for release in March 2017 will come with TLS 1.3 enabled by default. Firefox 49 was the first version to have this feature built-in but it needed to be enabled within the about:config page of the browser’s settings by setting security.tls.version.max version to value of 4 Firefox 52 will have this setting enabled by default.

Thank you.

====================
Original Post:
====================
On the 25th of August the OpenSSL Software Foundation released OpenSSL 1.1.0 which brought partial support for a working IETF draft of TLS 1.3. OpenSSL 1.1 is one of the largest version changes to have occurred in the history of OpenSSL which is now better funded, has more developers and follows an improved code development process following the discovery of the now well-known Heartbleed vulnerability.

What is TLS 1.3?
Transport Layer Security (TLS) version 1.3 is the most recent version (currently in draft form) of the cryptographic protocol originally based on SSL (Secure Socket Layer) version 2 (from 1995) and v3 from 1996. This is the protocol that protects us when we see the HTTPS displayed in our web browsers address bar. More information on TLS/SSL is available in this podcast, this page and this blog post.

Why Is TLS 1.3 an advancement over TLS 1.2 or 1.1?
TLS 1.3 removes support for known insecure ciphers such as RC4, DES, 3DES and export grade ciphers as well older hashing algorithms e.g. SHA-1 and MD5. These are welcome changes that should help to reduce the possibility of further vulnerabilities such as SWEET32 and FREAK being present within the code of TLS libraries e.g. OpenSSL.

This reduces the attack surface (defined within the second paragraph of this blog post) of TLS 1.3 but the improvements don’t stop there. Cipher suites such as NIST P-256 and AES-GCM are being removed as primitives with only x25519, ChaCha20 and Poly1305 remaining developed by Dan Bernstein (who uses the handle djb).

X25519 is a key exchange protocol (with a similar purpose to Diffie Hellman), ChaCha20 is a stream cipher (a more secure alternative to the older RC4) and Poly1305 is used as a message authentication code (defined) with a view to replacing GCM.

In addition to improved security TLS 1.3 will offer improved performance but protection against reply attacks was still being finalised in the closing months of 2015.

Conclusion
With the many implementation vulnerabilities that have been uncovered in recent years within SSL and TLS the upcoming TLS 1.3 standard is a significant step in the right direction. With web browsers such as Mozilla Firefox, Google Chrome, Microsoft Edge (in progress) and other implementations adding support for TLS 1.3, the new standard is off to a promising start.

Thank you.