Tag Archives: OpenSSL

Google offers financial and technical support to open source projects

Early last week Google shared their results after beginning a project to fuzz (defined) test open source software (defined). Their project is currently processing 10 trillion test cases per day. Open source projects involved in this initiative include GNUTLS, BoringSSL, FFMpeg, JSON, Libpng, LibreOffice, LibSSH, OpenSSL and Wireshark (among many well-known others).

What is the purpose of their project?
The purpose of fuzzing is to repeatedly and thoroughly test how robust/secure the code of the enrolled open source projects is. More than 1000 bugs have found so far (approximately264 of which were potential security vulnerabilities).

As Google points out, this also helps to increase the reliability of the software being created since regressions (defined) are fixed within hours before they ever affect a user. Another aspect of this is other software bugs e.g. logic errors can be detected and corrected sooner.

In return for a project signing up to this initiative, Google have pledged to provide extra funding:

$1,000 USD for initial integration of the OSS-Fuzz tests into their development process

Up to $20,000 USD for ideal integration (an itemised list of how this figure is obtained is detailed here).

How this project become to be developed?
I have mentioned the Core Infrastructure Initiative (CII). on this blog before. This fuzzing project was created with assistance from the CII to benefit projects critical to the global IT infrastructure. This project is in progress alongside Project Wycheproof (with its objective to strengthen cryptographic implementations by having new implementations pass a series of tests to verify they are not affected by these particular implementation issues being checked for).

How does this project help the wider industry/community?
With projects such as those mentioned above used by large corporations, small business and consumers alike; the regular feature/security updates we all receive make these projects more stable and secure than they otherwise would be. The outcomes will be very similar to that of Pwn2Own.

With these benefits for the projects as well as all of their users, I hope projects such as this continue and expand in scope as time progresses.

Thank you.

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: 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.

The DROWN Attack: What You Need To Know

With the release of scheduled security updates for OpenSSL earlier today details of a new high severity cryptographic vulnerability were disclosed.

This weakness relies upon an outdated encryption protocol namely SSLv2 (Secure Sockets Layer version 2). SSLv2 does not have the ability to defend against a known cryptographic attack specifically the Bleichenbacher attack. Using this method an attacker could obtain the RSA private key used to secure the connection between a client (usually a user/consumer) and the server (e.g. a website). If a server that uses a modern protocol such as TLS (TLS/SSL are discussed in a previous blog post and within this Sophos podcast) also uses SSLv2 this attack could be used to obtain the RSA private key (defined) used to secure the connection even when the user’s session is using TLS.

While the original Bleichenbacher attack would still take an impractical amount of computing power to complete; the researchers who responsibly disclosed (defined) this issue to the OpenSSL project (and others) have further refined the attack so that a much smaller number of secured connections would be needed to be set up in order to attempt to brute force (defined) the RSA private key. As OpenSSL explained in their blog post this attack could be completed in several hours using $440 USD of cloud computing power from Amazon’s EC2.

Why Should These Issues Be Considered Important?
It’s estimated that up to 3.5 million servers on the internet are vulnerable to the more general form of DROWN attack disclosed today. A further 2.5 million servers are vulnerable to a specific form of the DROWN attack (that was patched/addressed in March 2015).

This means that some of your favourite websites that use secured connection may be vulnerable to this issue and your private data being exchanged with that website has the potential to be no longer private.

Further technical details of this attack are available on the specifically created website detailing the attack. Background information and high level explanations of the attack are available from Matthew Green’s blog post, OpenSSL’s blog post and from Kaspersky ThreatPost. Very clear but short explanations are available from this Trend Micro blog post and this Sophos Security blog post.

How Can I Protect Myself from These Issues?
The DROWN attack can be further broken down into both general and special cases (thus my use of “These” in the above headings) described in Matthew Green’s blog post.

Update: 3rd March 2016:

With regard to the website vulnerability checker (mentioned below) that the DROWN attack website provides, you may want to read the explanation provided at the end of this Sophos Security blog post for an important clarification/explanation of how that tool works.

To check if your favourite websites are vulnerable you can review a compiled list here or enter the domain of the website you visit to test it e.g. example.com into the “Check for DROWN vulnerability” box found on the DROWN attack website. This blog hosted on WordPress.com is not vulnerable.

You should also review the Q&A page of the DROWN attack website and if you administer a webserver e.g., Apache you should follow the steps within OpenSSL’s blog post to resolve these issues. Steps are also provided for nginx and Postfix users. If you are using any version of OpenSSL prior to 1.0.1s or 1.0.2g, please strongly consider upgrading to the most appropriate updated version of OpenSSL for your environment as soon as possible. OpenSSL’s security advisory for these versions is available here.

Update: 6th March 2016:
Further information on the specific versions of Nginx, NSS, Postfix and Apache versions affected by DROWN are listed in Symantec’s blog post including further advice specific to those products. Qualys also provides insights on detecting/tracking the progress of patching your servers against this attack.

Update: 12th March 2016:
The Symantec link provided above also references Symantec’s CryptoReport tool which can be used to test your website or any website that you visit to check if it is affected by this vulnerability. This tool from Qualys offers similar functionality.

Moreover; U.S CERT provides comprehensive mitigations steps/advice in their vulnerability note on this attack.

Please note that the OpenSSL updates today address 7 other security issues (excluding DROWN) (CVEs, defined) of the following severities:

====================
1x high severity
1x moderate severity (assigned CVE-2016-0704: which also relates to the DROWN attack)
5x low severity
====================
To resolve these issues please update your OpenSSL installations to 1.0.1s or 1.0.2g (as appropriate).

  • FTP mirrors to obtain the necessary downloads are available from here.
  • Downloadable Tarballs (compressed/packaged code made for distribution) are available from here.
  • It should also be possible to use the package manager of a Linux/Unix operating system to update your OpenSSL installation as mentioned within the section titled “Installing updates for Linux distributions” on the “Protecting Your PC” page of this blog.

    I hope that the above advice assists you in securing your servers and computer systems from this new attack. I will update this post as more information become available.

    Thank you.

    =======================
    References:
    Cellos: [2016/03/02] On the announcement of DROWN attack and CacheBleed

    ThreatPost: DROWN Vulnerability Remains ‘High’ Risk, Firms Say

    OpenSSL Releases Security Updates January 2016

    Last week the OpenSSL project made available security updates to address 2 security issues (more formally known as CVEs (defined)) and to provide further hardening against the Logjam attack. The updates are available for the following versions of OpenSSL:

    • OpenSSL 1.0.2f: 2x CVEs resolved: 1x high severity, 1x low severity
    • OpenSSL 1.0.1r: 1x CVE resolved: 1x low severity

    Why Should These Issues Be Considered Important?
    OpenSSL version 1.0.2e and earlier are vulnerable to a high severity vulnerability in the generation of safe prime numbers used within X9.42 style Diffie Hellman (DH) parameters. This vulnerability could allow information disclosure specifically disclosing the private DH exponent (the essential component underlying the encryption provided by the DH algorithm). More information on private and public keys is available here.

    For the remaining low severity issue it corrects an issue that could have allowed an attacker to use an older cipher (in this instance SSL v2) for the purpose of securing a connection which would be benefit the attacker since SSLv2 is a weaker cipher (it’s use was prohibited in March 2011).

    Finally, a further hardening against the Logjam attack was added by the OpenSSL team in the form of increasing the accepted minimum number of bits used in DH key exchange to 1024 bits. As reported in an earlier post this was previously increased from 512 to 768 bits in June 2015.

    How can I protect myself from these issues?
    For any server that you manage that uses OpenSSL, please update your OpenSSL installations to 1.0.1r or 1.0.2f (as appropriate).

    • FTP mirrors to obtain the necessary downloads are available from here.
    • Downloadable Tarballs (compressed/packaged code made for distribution) are available from here.

    It should also be possible to use the package manager of a Linux/Unix operating system to update your OpenSSL installation as mentioned within the section titled “Installing updates for Linux distributions” on the “Protecting Your PC” page of this blog.

    Thank you.

    OpenSSL Releases Security Updates December 2015

    On the 3rd of December the OpenSSL project made security updates available for the following versions of OpenSSL:

    • OpenSSL 0.9.8zh: 1x CVE (defined) resolved: Moderate severity
    • OpenSSL 1.0.0t: 2x CVEs resolved: 1x moderate severity, 1x low severity
    • OpenSSL 1.0.1q: 2x CVEs resolved: 2x moderate severity
    • OpenSSL 1.0.2e: 3x CVEs resolved: 3x moderate severity

    Why Should These Issues Be Considered Important?
    OpenSSL versions 1.0.1 and 1.0.2 are vulnerable to a moderate Denial of Service (DoS)(defined) attack which can affect both client and servers which perform certificate verification.

    OpenSSL versions 1.0.0, 1.0.1 and 1.0.2 are vulnerable to a low severity race condition (see Aside below for a definition) which can result in a double free (use after free issues are defined here) of the identity hint data.

    Moreover, all versions of OpenSSL are vulnerable to a moderate issues resulting from a memory leak when a malformed X509_ATTRIBUTE structure is presented.

    Finally, and most importantly it should be noted that OpenSSL 0.9.8 and 1.0.0 will no longer receive security updates after the 31st of December this year. As mentioned by the OpenSSL team in the absence of significant security issues with the most recent updates for these versions, those updates will be the last to be created for them.

    If you or your organization, make use of any software that uses these older versions of OpenSSL you are strongly advised to upgrade to the newer versions 1.0.1 (which will be supported until the end of 2016) or 1.0.2 (will be supported until the end of 2019). These dates were provided by the OpenSSL team within their Release Strategy page.

    How can I protect myself from this issue?
    For any server that you manage that uses OpenSSL, please update your OpenSSL installations to 0.9.8zh, 1.0.0t, 1.0.1q or 1.0.2e (as appropriate).

    • FTP mirrors to obtain the necessary downloads are available from here.
    • Downloadable Tarballs (compressed/packaged code made for distribution) are available from here.

    It should also be possible to use the package manager of a Linux/Unix operating system to update your OpenSSL installation.

    Thank you.

    =======================
    Aside:
    What is a race condition?

    If two or more applications/entities try to complete/carry out a task or make a change to the data contained within one object at exactly the same time; an unusual/invalid outcome can happen if the task/change does not happen in the correct order.

    My thanks to Shon Harris for inspiring this definition from her book “CISSP All-in-One Exam Guide, 6th Edition” (McGraw-Hill Osborne, 2013).
    =======================

    OpenSSL Releases Security Updates

    Yesterday the OpenSSL project made available updates for version 1.0.2c and 1.0.1o of its OpenSSL cryptographic library. The updates bring the version numbers up to 1.0.2d and 1.0.1p respectively. These updates resolve a critical issue that was introduced inadvertently in the June 2015 security updates for the above mentioned OpenSSL branches.

    The security issue CVE-2015-1793 (definition of the term CVE) involves a check by the OpenSSL library to verify the authenticity of TLS certificates. If the first attempt to locate a certificate validation chain is not successful the code will look elsewhere to verify authenticity and it is a bug in how this alternative certificate validation chain is verified where this security issue could occur.

    If an attacker could convince you to visit a malicious website, this website could be signed using a fake certificate but due to this bug in OpenSSL this fake certificate would appear to be legitimate and thus would not cause any suspicion (namely that the green padlock icon would still appear in your web browser). This malicious website could be used in a phishing attack to make a fake site appear like the real site it’s impersonating and thus you may be inclined to enter your login credentials for the legitimate site but actually be providing these details to a person with malicious intent. For this attack to occur, the attacker must already be on the network path between the client and the server i.e. a man in the middle attack (MITM, MITM defined) thus reducing this attacks feasibility.

    How can I protect myself from this issue?
    If you don’t manage a web server/website that uses the OpenSSL library you are not affected by this issue. Web browsers such as Mozilla Firefox, Google Chrome, Apple Safari and Internet Explorer are not affected by this issue since they don’t use OpenSSL. In addition, where 2 servers running OpenSSL communicate with each other they are not affected by this issue (this issue occurs only in a client and server interaction and not server to server).

    =======================
    Aside:
    Google Chrome since version 38 actually uses a custom code fork of OpenSSL known as BoringSSL. The OpenSSL project attributed the discovery of the security updates being discussed in this post to the BoringSSL team. Further information on BoringSSL is available in this blog post.
    =======================

    For any server that you manage that uses OpenSSL, please update your OpenSSL installations to 1.0.1p or 1.0.2d (as appropriate). FTP mirrors to obtain the necessary downloads are available from here. Downloadable Tarballs (compressed/packaged code made for distribution) are available from here. It should also be possible to use the package manager of a Linux/Unix operating system to update your OpenSSL installation.

    OpenSSL also took the opportunity to re-iterate that versions 1.0.0 and 0.9.8 will cease to receive security updates from the 31st of December 2015. Users of these versions should upgrade before this deadline.

    We can expect many more of these updates from OpenSSL as the year progresses. This is good news since everyone that uses OpenSSL (either on their web server or within their software) benefits from the fixes that are released. The frequency of updates has increased since the OpenSSL project received funding last year from the Core Infrastructure Initiative which supports critical open source projects upon which the internet and the global information infrastructure relies on. In addition, an audit and code clean up of the OpenSSL project is taking place which should also improve the projects security and long term stability/maintainability.

    Thank you.