Targeted Attack on a Network Device

Company has been contracted to conduct a penetration test against [Organization] external web presence. The assessment was conductedin a manner that simulated a malicious actor engaged in a targeted attack against the company withthe goals of: Identifying if a remote attacker could penetrate [Organization] defenses. Determining the impact of a security breach on:

The confidentiality of the organization’s customer information. The assessment was conducted in accordance with the recommendations outlined in NIST SP 800-115 (Technical Guide to Information Security testing and Assessment). The results of this assessment will be used by [Organization] to drive future decisions as to the direction of their information security program. All test and actions were conducted under controlled conditions. (Security O. , 2012) Summary of Results

Network reconnaissance was conducted against the address space provided by [Organization] with the understanding that this space would be considered the scope of this engagement. It was determined that the organization maintains a minimal external presence, consisting of an external web site and a hosted mail service. This constituted a small attack surface, necessitating a focus on the primary website. While reviewing the security of the primary [Organization] website, a serious vulnerability in the popular OpenSSL cryptographic software library was discovered.

This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. The vulnerability was compromised, and in doing so, allowed [Company] to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users. (Security O. , 2012)

Details on the Attack
The attack used in the above scenario is the Heart Bleed Bug. This section will give the details on this attack. Name of the Attack
It is called the Heart Bleed Bug because Bug is in the OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server. (Codenomicon, 2014) Attack Discovery and Resolution Dates

This bug was independently discovered by a team of security engineers (Riku, Antti and Matti) at Codenomicon and Neel Mehta of Google Security, who first reported it to the OpenSSL team on April 3 2014. Codenomicon team found Heartbleed bug while improving the SafeGuard feature in Codenomicon’s Defensics security testing tools and reported this bug to the NCSC-FI for vulnerability coordination and reporting to OpenSSL team. (Codenomicon, 2014) It was posted on CVE on April 4 2014 and revised on April 24 2014. Synopsis of the Attack

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs). The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users. (Codenomicon, 2014) Vulnerable Target(s) for the Attack and Likely Victims

OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used to encrypt traffic on the Internet. Your popular social site, your company’s site, commerce site, hobby site, site you install software from or even sites run by your government might be using vulnerable OpenSSL. Many of online services use TLS to both to identify themselves to you and to protect your privacy and transactions. You might have networked appliances with logins secured by this buggy implementation of the TLS. Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services. (Codenomicon, 2014) Probable Motivation(s) of the Attack

This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users. (Codenomicon, 2014)

Probable Creators of the Attack

This is an implementation problem, i.e. programming mistake in popular OpenSSL library that provides cryptographic services such as SSL/TLS to the applications and services. (Codenomicon, 2014) Deployment, Propagation or Release Strategy of the Attack

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug. The vulnerable versions have been out there for over two years now and they have been rapidly adopted by modern operating systems. A major contributing factor has been that TLS versions 1.1 and 1.2 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due to earlier attacks against TLS (such as the BEAST). (Codenomicon, 2014) Published Countermeasures against the Attack

Exploitation of this bug does not leave any trace of anything abnormal happening to the logs. Although the heartbeat can appear in different phases of the connection setup, intrusion detection and prevention systems (IDS/IPS) rules to detect heartbeat have been developed. Due to encryption differentiating between legitimate use and attack cannot be based on the content of the request, but the attack may be detected by comparing the size of the request against the size of the reply. This implies that IDS/IPS can be programmed to detect the attack but not to block it unless heartbeat requests are blocked altogether. (Codenomicon, 2014)

Published Recovery Techniques used to return to Normal Operations after the Attack Fixed OpenSSL has been released and now it has to be deployed.
Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use. Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS. (Codenomicon, 2014) Recommended Incident Reporting Measures

Exploitation of this bug does not leave any trace of anything abnormal happening to the logs. (Codenomicon, 2014) Summary

In summary, The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug. (CVE, 2014) (Database, 2014)

Reference

Codenomicon. (2014, April 04). Heart Bleed. Retrieved from Heart Bleed: http://heartbleed.com/ CVE. (2014, April 07). Common Vulnerabilities and Exposures. Retrieved from CVE.org: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 Database, N. V. (2014, April 07). National Cyber Awareness System. Retrieved from http://web.nvd.nist.gov/: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160 Security, O. (2012, February 28). Penetration Testing Sample Report. Retrieved from Offensive Security: http://www.offensive-security.com/