GuidePoint Security’s vSOC and Prelert’s AD Strike Back Against DROWN

In a recent blog article titled, Star Wars X – Attack of the DROWNs: Machine Learning-based Anomaly Detection Detects the DROWN SSLv2 Vulnerability, Prelert announced the ability to detect Decrypting RSA with Obsolete and Weakened eNcryption (DROWN) attacks using machine-based learning through the Prelert Anomaly Detective (AD) tool. The widespread nature of the vulnerabilities related to DROWN means that it is highly likely there are still many vulnerable servers in the wild that could benefit from the watchful eye of Prelert AD operated by the trained network defenders of a managed security service like GuidePoint Security’s Virtual Security Operations Center (vSOC). vSOC leverages the power of Prelert’s AD to enhance the native detection capabilities of our Splunk-centric monitoring platform. The DROWN use case, in addition to many other co-developed use cases, provides vSOC with finely tuned anomaly detection that enables us to quickly identify, validate, and report critical security incidents to our customers. Stay tuned to the GuidePoint vSOC blog for other joint efforts and collaborative projects all focused on the protection of enterprise networks and data through advanced monitoring and hunting techniques.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

The Boy Who Cried “Badlock”

Introduction

On March 11, 2016 the domain badlock.org was registered by German consultancy SerNet in order to create a brand for a series of vulnerabilities discovered by Stefan Metzmacher. 11 days later, on March 22, the InfoSec community on Twitter started to circulate the site’s ominous warnings for a “crucial security bug in Windows and Samba,” with major tech news sites such as Wired and The Register adding to the buzz shortly after. Details slowly trickled out over the following weeks, and the affected versions of Samba were listed on April 2nd. Apparently, SerNet began to feel the pushback against the over-branded hype, and they added a response to the Badlock site saying, “It is a thin line between drawing attention to a severe vulnerability that should be taken seriously and overhyping it.”

On April 12, the full details of Badlock, which are really a collection of several interrelated vulnerabilities, were released and timed specifically to align with Microsoft’s regular “Patch Tuesday” announcement. Reaction to the disclosure has been mixed. The relevant Windows patch is rated “Important” by Microsoft, not critical. That along with Badlock’s overall CVSS 3.0 score of 7.1 (high) does not reflect the three weeks of blockbuster-style marketing and PR as “crucial” that rivaled the far more critical and ubiquitous Heartbleed and Shellshock vulnerabilities.

Overview

Badlock consists of eight separate vulnerabilities, all detailed in separate CVE’s:

CVE-2015-5370 – Multiple errors in DCE-RPC code: Errors that prevent proper validation of specially crafted DCE-RPC packets can result in denial-of-service (DoS) for Samba.

CVE-2016-2110 – Man-in-the-middle attacks possible with NTLMSSP: It is possible under certain conditions to remove required encryption related flags to disable encryption and allow a man-in-the-middle (MitM) attack against the Samba service.

CVE-2016-2111 – NETLOGON Spoofing Vulnerability: When Samba is configured as a Domain Controller, it allows an attacker to spoof the computer name of a client without the need for authentication. This allows the attacker to intercept potentially sensitive information.

CVE-2016-2112 – The LDAP client and server don’t enforce integrity protection: An attacker who has already obtained MitM status can remove integrity checks that are communicated between an LDAP client and server.

CVE-2016-2113 – Missing TLS certificate validation allows man-in-the-middle attacks: While, TLS/SSL are supported in vulnerable versions of Samba, certificates are never validated, which facilitate MitM attacks.                                                                                          

CVE-2016-2114 – “server signing = mandatory” not enforced: A bug in Samba prevents SMB signing, even if explicitly set, which again, facilitates MitM attacks.

CVE-2016-2115 – SMB client connections for IPC traffic are not integrity protected: SMB signing was again not enforced, this time for IPC traffic, and once more facilitating MitM attacks.

CVE-2016-2118 – SAMR and LSA man-in-the-middle attacks possible: Typically available on all Windows systems, this vulnerability allows an attacker positioned as a MitM to impersonate any user against the Security Account Manager (SAM) database and Local Security Authority (LSA). As a result, the attacker is able to get read/write access to the Security Account Manager Database, which reveals all passwords and any other potential sensitive information.

Impact

The vulnerabilities disclosed under the Badlock name affect multiple versions of Samba and corresponding components found in the most recent versions of Windows and amount to either a MitM or DoS-style attacks.

Under the MitM scenario, a local attacker can intercept an authenticated session and perform Samba network calls under the current session context. Samba.org lists the following examples in their write-up:

  • Samba AD server – view or modify secrets within an AD database, including user password hashes, or shutdown critical services.
  • Standard Samba server – modify user permissions on files or directories.

It is important to note that the attacker would need to already have local access to the affected systems to properly execute this attack.

The DoS vulnerability is exploitable by a remote attacker and could bring down systems or services that rely on the Samba service.

No publicly available exploits have been identified for Badlock yet. SerNet has insinuated that they have proof-of-concepts, but no additional details have been released. Furthermore, while Microsoft has assigned Badlock an “Important” severity rating, they have assessed its exploitability at its lowest level: “3 – Exploitation Unlikely”.

Identification

The following versions of Samba are affected: 3.6.x, 4.0.x, 4.1.x, 4.2.0-4.2.9, 4.3.0-4.3.6, 4.4.0 (earlier versions have not been assessed).

Microsoft lists most of its latest Windows operating systems as being affected by Badlock, specifically: Windows Vista, Server 2008, Windows 7, Server 2008 R2, Windows 8.1, Server 2012, Server 2012 R2, Windows RT 8.1, and Windows 10. They have also specifically noted that this vulnerability does not affect SMB, only the SAM and LSAD remote protocols.

Remediation

The officially patched versions of Samba are: 4.2.10/4.2.11, 4.3.7/4.3.8 and 4.4.1/4.4.2. Versions earlier than 4.2.x have been discontinued and are no longer supported. It is recommended that organizations running older versions upgrade as soon as possible. Samba.org warns that due to the patch and related fixes, new options and defaults are present in the patched versions that might impact compatibility with older third-party software. Hints and workarounds for these scenarios are listed on the Samba.org site here.

Microsoft has released security bulletin MS16-047 to address this issue as part of April 12th’s regular “Patch Tuesday”.

Summary Opinion

While Badlock is certainly a concerning vulnerability that no doubt impacts an extremely large number of organizations and should be patched as soon as possible, the overblown hype and speculation it received leading up to its disclosure likely did more harm than good. For example, there were thirteen bulletins released on April 12th as part of Microsoft’s “Patch Tuesday.” Four of them had a “critical” severity, and one of those four (MS16-039) already has known remote command execution exploits in the wild. Despite this, discussions are focused on Badlock, a named vulnerability, where even according to SerNet, the name is arbitrary, as was the decision for it to be named in the first place.

Information security professionals need to tread carefully when it comes to creating awareness and not cross the line into generating unproductive fear, uncertainty, and doubt (FUD). As a penetration tester, I value the specific benefit that the branding gives to Heartbleed and Shellshock because it facilitates easier communication with our clients and brings awareness to truly critical issues. There will certainly be a future need for similar levels of awareness, and information security professionals should be much more calculated in these types of campaigns in order to retain our roles as trusted advisors.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Attackers DROWN TLS Security with SSLv2 Vulnerabilities

Decrypting RSA using Obsolete and Weakened eNcryption (DROWN) attacks allow attackers to decrypt intercepted Transport Layer Security (TLS) traffic by abusing vulnerabilities in the obsolete Secure Socket Layer Version 2 (SSLv2) protocol. A successful DROWN attack can provide the attacker with the encryption keys used to secure client-to-server communications. The attack works by making repeated requests to a server using the deprecated SSLv2 protocol instead of the recommended TLS protocol. Each SSLv2 connection request allows the attacker to decipher a few bits of the encryption key. With enough requests, attackers can piece together the entire encryption key, allowing interception and decryption of TLS-protected traffic encrypted with the same keys.

SSLv2 was deprecated in 1996 due to serious security flaws in its implementation. TLS is the current recommended protocol for protecting client-to-server communications; all versions of SSL have been rendered obsolete by significant security flaws in the protocols. Unfortunately, SSLv2 and SSLv3 are still prevalent due to the need to maintain backward compatibility with legacy systems, the lack of adequate vulnerability management and patching, and most significantly, the lack of proper configuration for public-facing server resources and applications that rely on encrypted client-to-server communications. The most recent estimates indicate that SSLv2 is directly supported by approximately:

  • 5.9 million Web servers (17% of all HTTPS-protected machines)
  • 81,000 of the top 1 million most popular web sites
  • 936,000 e-mail servers

Even though SSLv2 has been deprecated for more than 20 years, it is still available as an option for negotiating encryption during client-to-server communications in many applications and servers. Modern applications will attempt to use the more secure TLS protocol, but attackers can manually request to use SSLv2 on a vulnerable server to force the insecure protocol to be used, giving them the opportunity to conduct a DROWN attack. An attacker that successfully conducts a DROWN attack against a vulnerable server can use the deciphered encryption keys to intercept and decrypt TLS-encrypted network traffic if the same compromised key is used to encrypt the data. This also means that an attacker that successfully uses DROWN on one server could use the compromised keys to decrypt traffic from any other server that uses the same keys. For these reasons, these vulnerabilities should be addressed, or adequate workarounds implemented immediately, until vendor patching is made publically available.

Public-facing servers can be scanned using the free Qualys SSL Labs SSL Server Test to determine if the SSLv2 protocol is available to be used to encrypt communications. The scanner can be found at https://www.ssllabs.com/ssltest/.

Preventing the exploitation of these vulnerabilities and subsequent DROWN attacks can be achieved by removing SSLv2 support from your servers and then immediately updating any keys that could have been exposed by successful DROWN attacks to ensure that future TLS encrypted communications cannot be intercepted or decrypted by attackers.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, and with offices in Georgia, Massachusetts, Michigan, Minnesota, Missouri, Florida, Texas, and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Time Inc. Highlights GuidePoint Security in the WSJ CIO Journal

Time Inc. (Time) recently mentioned GuidePoint Security (GuidePoint) in an article in the Wall Street Journal CIO Journal. Time leverages GuidePoint’s Amazon Web Services (AWS) and Payment Card Industry (PCI) expertise to guide them through the migration of applications into AWS. Specifically, GuidePoint provides expertise in implementing architectures and control frameworks that not only provide security, but also PCI compliance.

“We appreciate GuidePoint Security’s advice through this process. Their specific working knowledge of security and PCI compliance in AWS has been a great asset to us,” said Keith O’Sullivan, VP – Global Information Security for Time Inc.

Organizations are rapidly increasing their cloud-adoption, however Information Security and compliance considerations present both a challenge and an opportunity while moving to the cloud. Organizations must include Information Security and compliance experts into their project team, or risk jeopardizing their cloud-application’s security and compliance.

GuidePoint provides this expertise through our Cloud Solutions and Compliance practices. We’ve worked with numerous clients developing secure architectures, control frameworks, policies and procedures, and implementing security technologies across IaaS, PaaS, and SaaS platforms enabling our clients to leverage the benefits of the cloud while maintaining or improving their Information Security and compliance posture.

Contact sales@guidepointsecurity.com or visit www.guidepointsecurity.com to learn more about our Cloud Solutions and Compliance practices.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Va., and with offices in Michigan, New Hampshire, Florida and North Carolina. GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM).

Another “Ghost” in the Machine

Introduction

A recent vulnerability disclosure from a group of Qualys researchers reaffirms that there is no rest for the weary and that the New Year will likely keep pace with the former as the first critical and highly publicized vulnerability of 2015 is unveiled. This vulnerability is being referred to as “Ghost” and technical news sources around the world are rushing to report on the impact. These reports have been consistently accompanied with ominous imagery of ghoulish figures and fear-inspiring phrases, but is this Ghost really as scary as the media has portrayed?

Overview – A “Ghost” of GNU Past

This vulnerability is a heap-based buffer overflow vulnerability that can be trigged when a malformed string is passed to the gethostbyname() or gethostbyname2() functions in the GNU C Library (glibc). These vulnerable functions have been present in the glibc library for nearly 15 years.

The origin of the vulnerability in each of these functions is a “hostname” variable. While the implicated code does perform some input validation on the string value stored in this variable, no bounds checking is performed. Due to this implementation flaw, an attacker can supply malformed input consisting of an excessive number of numerical digits and period characters to write to unintended portions of system memory. This type of memory access can potentially be leveraged to execute unauthenticated and unauthorized code on remote systems. The full technical details of this vulnerability can be found in the original disclosure thread from the OSS-Sec mailing list.

Impact – How Scary is Ghost?

The impact of this vulnerability, if exploited, is very high (as is always the case with remote code execution vulnerabilities). Additionally, many services on Linux systems leverage these vulnerable libraries, which would make them potential candidates for a variety of attack vectors.

However, the exploitability of this vulnerability requires highly specific circumstances that make actual exploitation in the wild extremely unlikely. This is due to multiple mitigating factors that were all addressed at length in the original disclosure. These mitigating factors were listed as follows:

  • A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013;
  • The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead;
  • Many programs, especially locally accessible SUID binaries, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the “inet-aton” requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe; and
  • Most of the other programs, especially remotely accessible servers, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe because the hostname passed to gethostbyname() has normally been pre-validated by DNS software:
    • “A string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets,” makes it impossible to satisfy the “1 KB” requirement; and
    • While glibc’s DNS resolver can produce hostnames of up to (almost) 1025 characters (in the case of bit-string labels and special or non-printable characters), this action introduces backslash characters (“\\”) and makes it impossible to satisfy the “digits-and-dots” requirement.

Despite the Qualys analysts’ disclosure of these highly restrictive conditions, the fear-mongering media has repeatedly omitted these details. Such periodicals consistently fixate upon the theoretical impact of this vulnerability but neglect to report on the real-world implications.

In the past year, the security industry has witnessed an emerging trend of vulnerability disclosures that come packaged with clever names and graphical imagery (Heartbleed, ShellShock, POODLE, etc.). This trend simply seems to be the result of an effort to drive media exposure. Although this practice does increase the public’s attention to information security concerns, it also increases the frequency of widespread reports that lack complete and/or accurate technical details from news sources that are solely concerned with exaggerating the facts for profit.

Consequently, there has also been a consistent increase in the spread of misinformation, flawed assumptions, technical inaccuracies, and unwarranted hysteria. Such trends have resulted in serious real-world issues, like ShellShock and Heartbleed, being lumped together with pedantic and highly theoretical proof-of-concepts, like POODLE and GHOST. Rather than getting caught up in the media frenzy, it is important that industry professionals stop to consider the actual technical details and corresponding real-world impact of a vulnerability to ensure that a measured and appropriate response is provided.

The Final Verdict

No matter how obscure the circumstances must be for exploitation to be possible, the underlying code associated with these functions is still vulnerable and should be updated as a matter of best practice. The vulnerability is the consequence of sustained support for functions that have already been deprecated for some time. As such, remediation will eliminate the risks associated with Ghost (however unlikely), with little-to-no impact on existing services or applications.

Identification

Under normal circumstances, the vulnerable library would only be found on Linux systems and not Windows workstations or servers. This is because GNU libraries are native to Linux, and the glibc library specifically is standard on Linux distributions. Therefore, all Linux systems are potentially vulnerable.

The easiest way to determine if a given Linux system is vulnerable is to identify the version of glibc in use on the system. Unpatched versions of glibc, prior to glibc-2.18, are vulnerable and should be updated. In most cases, a simple terminal command can be used to identify the version that’s in use. Note: in each example below, the command is in blue, and the identified version is in red.

  • Use the following command with Ubuntu and Debian:
# ldd --version
ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.20) 2.11.1
  • Use the following command with CentOS and RedHat:
# rpm -q glibc 
glibc-2.12-1.149.el6_6.5.i686 

Determining if the library contains the vulnerable functions requires consideration of both the running version and the patch / minor-version. This is due to the fact that numerous patched versions of the glibc library prior to glibc-2.18 are no longer vulnerable. If the returned version predates the versions listed below, then the system is vulnerable and should be patched:

  • Ubuntu 12.04 LTS: 2.15-0ubuntu10.10
  • Ubuntu 10.04 LTS: 2.11.1-0ubuntu7.20
  • Debian 7 LTS: 2.13-38+deb7u7
  • CentOS 6: glibc-2.12-1.149.el6_6.5
  • CentOS 7: glibc-2.17-55.el7_0.5
  • RHEL 5: glibc-2.5-123.el5_11.1
  • RHEL 6: glibc-2.12-1.149.el6_6.5
  • RHEL 7: glibc-2.17-55.el7_0.5

Unless unique circumstances dictate otherwise, GuidePoint recommends updating to the latest stable version, regardless of the current running version.

Remediation

To update to the latest version of glibc (whether for mitigation or general hardening), a single update command should be run from the terminal, and then the system will need to be rebooted for the change to take affect.

  • Use the following command with Ubuntu and Debian:
# sudo apt-get update && sudo apt-get dist-upgrade 
# sudo reboot

Warning: Upgrading the distribution can result in significant changes, so be sure to plan according. 

  • Use the following command with CentOS and RedHat:
# sudo yum update glibc 
# sudo reboot

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

POODLE May Still be off the Leash with Certain TLS Conditions

poodle 2The POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability was initially disclosed as a weakness in the Secure Sockets Layer (SSL) 3.0 protocol. This vulnerability permits data within “secure” communications between a user and an SSL-enabled website to be decrypted under certain conditions. Successful attacks could disclose sensitive information, such as the victim’s session cookies, which could in-turn be used to hijack the victim’s application session.

The Transport Layer Security (TLS) protocol supplants SSL and corrects the underlying flaw that’s present in the legacy protocol. However, several vendors’ TLS implementations do not properly implement the TLS specification and are consequently susceptible to the same attack.

Fortunately, such a scenario affects neither native Microsoft TLS implementations nor OpenSSL (which constitutes the majority of non-native Microsoft TLS implementations). Adam Langley identified and documented this issue on his ImperialViolet blog, and at this time, F5 Networks, A10 Networks, and IBM (IBM HTTP Server and other IBM servers) have issued security advisories and corresponding patches for remediation.

Other TLS implementations may also be vulnerable, but future disclosures will likely be increasingly obscure. Qualys’ SSL Server Test has been updated to test for the TLS variant of this vulnerability and can be used to perform an analysis of questionable TLS-enabled services.

The current SSL Pulse Report (December 6, 2014), which is also the first to include data pertaining to TLS POODLE checks, shows that just over 10% of the services analyzed are vulnerable. While that figure is significant, it is also unsurprising, when F5’s market share is taken into consideration. This figure will hopefully decrease quickly as awareness spreads and vendors’ patches are applied.

Qualys notes that, “A successful attack will use about 256 requests to uncover one cookie character, or only 4096 requests for a 16-character cookie. This makes the attack quite practical.” However, the referenced practicality is still dependent upon specific conditions being met in advance, namely the ability of an attacker to both inject JavaScript into the target web application and capture network communications between the victim and target application.

While that scenario isn’t unheard of, the overall exposure is significantly less than a remotely exploitable vulnerability such as Heartbleed. The greatest exposure for real-world attacks is over public, untrusted networks. Free public WiFi networks are obvious examples of locations where this attack could occur. Users can defend themselves by tunneling their traffic through a VPN in these cases.

But, attacks originating from facilities that manage Internet backbones and target communications that must traverse the Internet would be far more insidious. In these cases, users must ensure they’re using a recent browser that completely mitigates the SSLv3 attack vector and validate that the remote service is not vulnerable to the TLS-based variants of this vulnerability.

In conclusion, the state of SSL/TLS-based security remains in a precarious state as 2014 draws to a close. This year has been particularly brutal to these technologies, with critical flaws being discovered everywhere from specific vendor implementations, to common development libraries, and the protocols themselves.

The most recent SSL Pulse data was also the first to show TLS1.2 breaking the 50% adoption rate (50.1% to be exact — up from 48.1% in early November). This is an important milestone because TLS1.2 currently provides the only unbroken cryptographic configuration, as noted by Adam Langley, but it also demonstrates that there is still a very long road ahead.

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable Information Security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

 

Your Golden Ticket to Domain Admin – Microsoft’s Critical Kerberos Vulnerability – MS14-068

Overview

Microsoft issued a critical security bulletin on Tuesday November 18, 2014 (MS14-068) which stated there was a privately reported vulnerability found within the Kerberos Key Distribution Center (KDC) that could allow privilege escalation. The KDC authenticates clients and users, and issues session tickets and temporary session keys to users and computers within an Active Directory environment. The vulnerability exists in implementations of the KDC in Microsoft Windows and exists due to the KDC failing to properly validate signatures, which can result in forged parameters within a Kerberos ticket.

The KDC is a network service that runs on each Domain Controller as part of Active Directory Domain Services (AD DS) and by default listens on TCP and UDP port 88. Attackers that have access to a compromised domain user account as well as access to AD DS within an Active Directory environment could leverage the KDC vulnerability remotely. It would then be possible to elevate the privileges of the compromised user account to the role of Domain Administrator by sending the KDC a forged Kerberos ticket that identifies the user as a Domain Administrator. Once an attacker gains Domain Administrator privileges within an Active Directory environment they will be able to compromise any domain-managed system in the environment.

Impact

Unlike local privilege escalation vulnerabilities, an attacker that has a valid unprivileged user account within the domain can leverage this vulnerability remotely. Microsoft additionally stated within the security bulletin they are aware of limited targeted attacks that have attempted to exploit this vulnerability. Thus, it is reasonable to assume there is code in the wild that Microsoft has seen attempting to exploit this vulnerability. GuidePoint has not yet discovered enough information to exploit the vulnerability.

Affected Operating Systems

  • Windows Server 2003 and higher
  • Windows Server 2008 and higher
  • Windows Server 2012 and higher

For a complete list of affected hosts please refer to the MS14-068 Security Bulletin. In addition, Microsoft has released patches for Windows Vista, Windows 7, and Windows 8 and 8.1 as a defense-in-depth hardening of these operating systems. However, the Windows Vista, Windows 7, and Windows 8 and 8.1 operating systems are not directly vulnerable to this vulnerability.

Identification

Pre-Update Detection

To identify if an Active Directory environment has been targeted by any known exploits before updates have been applied to the affected systems, review Windows Security Event Log for Event ID 4624. This event is logged when successful logins occur within a domain. If the ‘Security ID’ and ‘Account Name’ fields of the log do not match, even though they should, it could indicate targeted attacks leveraging this vulnerability are underway.

Joe Bialek from the Microsoft Security Research and Defense blog illustrates pre-update detection very well within his detailed write-up of the MS14-068 vulnerability titled “Additional Information About CVE-2014-6324”. For additional information and illustration of pre-update detection it is highly recommended to read this blog post.

Post-Update Detection

To identify if an Active Directory environment is being actively targeted after applying the update to Windows Server 2008R2 and above, Event ID 4769 in the Kerberos Service Ticket Operation event log can be used for detection purposes.

Joe Bialek’s also illustrates post-update detection very well within his detailed write-up of the MS14-068 vulnerability titled “Additional Information About CVE-2014-6324”. Bialek explains event 4769 is a high volume event and it is advisable to only log failures of this event for detection purposes. For additional information and illustration of pre-update detection it is highly recommended to read this blog post.

Remediation

Microsoft has released an out-of-band patch to remediate the MS14-068 vulnerability. Users should test and deploy the patch to affected systems domain wide. Please refer to the MS14-068 Security Bulletin for more information.

References

A Shock 19 Years in the Making – Microsoft’s Critical WinShock Vulnerability – MS14-066

Overview

The vulnerability defined in MS14-066 (CVE-2014-6321), or “Winshock” as the media has dubbed it, has been categorized as a critical risk due to the potential impact that includes denial-of-service, information disclosure, and unauthenticated remote code execution. Microsoft describes Winshock in KB2992611 as the “improper processing of specially crafted packets by the Secure Channel (SChannel) security package.” This package is closely linked to critical system services, and this condition creates the possibility for a remote, unauthenticated attacker to obtain SYSTEM-level access. That is, undoubtedly, the worst-case scenario which could plausibly become the precursor to worms and other widespread damage.

 Impact

At its heart, the SChannel package is responsible for securing network communications with the SSL and TLS protocols. Numerous Microsoft service implementations including (but not limited to) IIS, Active Directory, Outlook Web Access, the Remote Desktop Protocol, and Internet Explorer utilize the SChannel package. However, due to the immediate lack of detailed technical information, it is currently unclear which of these services may genuinely be affected by this vulnerability.

For a detailed explanation on how to exploit the vulnerability, refer to the in-depth technical blog post by Beyond Trust that analyzes the patch and demonstrates how specially crafted SSL communications can be leveraged to target the vulnerable code and crash the operating system. The demonstration proves that not only is remote code execution theoretically possible, but that a simple denial of service condition is easily achieved by making a minor code change to the open source OpenSSL library.

It is important to note that the default IIS configuration does not accept client certificates. Additionally, other SSL/TLS-enabled services, such as Terminal Services, do not support client certificate configurations. However, new research demonstrates that (thanks to a second “bug” in Schannel) a malicious client certificate can still be utilized to trigger the vulnerability simply by configuring the attack technique to ignore the server configuration and submit the client certificate. While the service itself would ultimately ignore the client certificate in such a scenario, it will still be analyzed by the vulnerable SChannel code. In this case, any SSL/TLS service that utilizes the SChannel package, which includes all native Windows services, is conceivably vulnerable to exploitation.

At the moment, there are no publicly accessible exploits, nor have there been any reported cases of exploitation in the wild. However, Immunity Inc. has released a proof-of-concept exploit for subscribers that have access to their CANVAS Early Updates program. While the quality and reliability of this proof-of-concept are not disclosed, its existence confirms the feasibility of exploitation.

The technique demonstrated by Beyond Trust utilized client certificates to reach the vulnerable code. It is worth noting that Winshock appeared to address multiple code flaws, so client certificates should not be considered to be the only and definitive attack vector at this time. While a client certificate-based vulnerability would lack the prevalence of other recent SSL/TLS vulnerabilities, such as Heartbleed and POODLE, defending services affected by Winshock could arguably be a higher priority.

Identification

At this time there is no definitive way to determine if systems are vulnerable to Winshock. Anexia-it released a script that tests for the presence of four (4) ciphers that will exist on a system that has been patched against Winshock. This test, however, is not a guaranteed way to determine a system’s status in regards to Winshock. Microsoft includes a list of impacted Operating Systems (“OS”) in their MS14-066 advisory. If a system in your environment runs on an OS listed in the advisory, it would be safe to assume the system is vulnerable and proceed with mitigation steps to prevent system exploitation.

Remediation

Patching for Winshock is a largely straightforward task, and public-facing servers should obviously be prioritized due to their increased exposure. However, there are significant concerns that should be considered before applying the Microsoft supplied patch. The most common concern is the potential for negatively impacted performance.

Various well-known vendors, such as Amazon, Blackberry and IBM, have reported noticeable application performance degradation, TLS session disconnections, and SQL server performance issues. Reports of performance problems extending to client applications, such as web browsers, have surfaced as well.

Microsoft has been largely silent on these issues, and the lack of guidance makes remediation all the more problematic. On the one hand, this is a critical system vulnerability that should ideally be patched post haste, but on the other, the patch may immediately harm the organization in an alternate manner.

Before installing the patch from Microsoft, GuidePoint highly recommends carefully examining your environment to determine if installing the patch is worth the potential risk of performance degradation, and to prepare a rollback strategy should problems arise after installation.

Intermediary security controls and alternate SSL/TLS configurations may provide an ideal, short-term solution for some organizations. GuidePoint recommends contacting your inline network and host-based security control vendors to determine whether signatures have been developed to block attacks prior to reaching the vulnerable service.

Additionally, Non-Windows SSL/TLS proxy servers and offloading appliances may prevent attacks from succeeding against the underlying Windows service, but these configurations should be thoroughly tested to ensure that malicious requests are properly dropped or modified and cannot be used to successfully exploit the service.

 

POODLE: SSL 3.0 Fallback Vulnerability

Overview

The SSL version 3.0 POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability (CVE-2014-3566) was officially released on October 14, 2014 by OpenSSL. The flaw was disclosed by a team of Google researchers including Bodo Möller, Thai Duong, and Krzysztof Kotowicz. This vulnerability is a consequence of an implementation flaw associated with the use of block cipher encryption in SSLv3. Block ciphers encrypt data in fixed-length blocks. If the plain text value to be encrypted is not a multiple of the defined block size, the cipher will apply padding to the data to increase the size, so that it can be converted to cipher text. The concern is that the Message Authentication Code (MAC) does not cover the block cipher padding and when the message is decrypted, the integrity of the padding cannot be verified. This can allow an attacker to decrypt cipher text, one byte at a time.

This vulnerability only affects the SSLv3 protocol, which is rarely used by modern web browsers that prefer the usage of TLSv1 encryption. However, due to the widespread support for SSLv3 on both servers and web browsers, an attacker can still leverage this vulnerability by using it in conjunction with a downgrade attack. A downgrade attack could be accomplished by intercepting and manipulating traffic associated with the SSL/TLS cipher suite negotiation, conducted between the client and server.

In the original disclosure article, B.Möller, T. Duong, and K. Kotowicz succinctly illustrate the impact of this vulnerability, referencing a scenario in which it could be used to compromise secure session tokens within the context of a web application (p.2, https://www.openssl.org/~bodo/ssl-poodle.pdf).

“In the web setting, this SSL 3.0 weakness can be exploited by a man-in-the-middle attacker to decrypt “secure” HTTP cookies, using techniques from the BEAST attack [BEAST]. To launch the POODLE attack (Padding Oracle On Downgraded Legacy Encryption), run a JavaScript agent on evil.com (or on http://example.com) to get the victim’s browser to send cookie-bearing HTTPS requests to https://example.com, and intercept and modify the SSL records sent by the browser in such a way that there’s a non-negligible chance that example.com will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies.”

An attacker could inject the JavaScript agent in a persistent or even reflected Cross-Site-Scripting (XSS) attack, or inject this code within the context of an established Man-in-the-Middle attack. This could be used to cause the victim’s browser to send the attacker cookie bearing HTTPS requests; which, in turn, can be modified and, if accepted by the server, could allow the attacker to decrypt the cookie, one byte at a time.

Impact

Due to the fact that this vulnerability must be exploited within a chosen-plaintext context, the only probable exploitation scenario with any significant impact is within a web context. For an attacker to successfully exploit this vulnerability, multiple highly specific conditions must exist. These conditions include the following:

  • The attacker must be able to intercept and manipulate traffic between the client and server (as in a Man-in-the-Middle scenario)
  • The attacker must be able to execute custom JavaScript code to initiate multiple crafted requests within the context of the victim’s browser

Despite the special circumstances and high level of skill required to exploit this vulnerability, the impact of a successful attack would be significant. Successful exploitation could result in an attacker gaining access to small pieces of highly sensitive encrypted traffic such as session tokens. Acquisition of these session tokens could be used in session hijacking attacks to completely take over a victim’s session within the context of the web application.

Identification

Server Identification

Server Testing with OpenSSL Client:

To determine if a particular service is vulnerable, use the SSL client in SSLv3 mode and supply the server name or IP address in conjunction with the port number of the service in question. If the connection succeeds then SSLv3 is enabled:

Syntax:
openssl s_client -connect <server>:<port> -ssl3

Example:
openssl s_client -connect google.com:443 -ssl3

Server Testing with Nmap:

The SSL-enum Nmap Scripting Engine (NSE) script can also be used to determine if servers are vulnerable. Nmap should be executed with the syntax provided below:

Syntax:
nmap <server> –script ssl-enum-ciphers -p <port>

Example:
nmap google.com –script ssl-enum-ciphers -p 443

If the scan returns a list of support ciphers under the SSLv3 header, then SSLv3 is enabled.

SSLv3:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA – strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA – strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA – strong
|       TLS_RSA_WITH_AES_128_CBC_SHA – strong
|       TLS_RSA_WITH_AES_256_CBC_SHA – strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA – strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA – strong
|       TLS_RSA_WITH_RC4_128_MD5 – strong
|       TLS_RSA_WITH_RC4_128_SHA – strong
|     compressors:
|       NULL

Server Testing with SSLLabs:

Qualys has made a web-based testing utility available at the URL listed below. This can be used to test public facing servers.

https://www.ssllabs.com/ssltest

If the scan returns indication that there is still support for SSLv3, then the server is vulnerable.

poodle 1

Client Identification

Browser Client Testing with Poodle Test:

A web-based test has been constructed to test client browsers and determine if they are vulnerable to the POODLE attack.

https://www.poodletest.com/

If your browser is vulnerable, the site will display the following image:

poodle 2

Remediation

Unfortunately, there is no patch remediation for this vulnerability. However, SSLv3 is a depreciated protocol and should be disabled on both servers and clients (browsers). Further, both Mozilla and Google have posted that they will be updating both FireFox and Google Chrome, in the coming months, to disable SSLv3 support. However, it should be noted that disabling SSLv3 could potentially break some websites or legacy web applications that support SSLv3.

Browser Remediation

Remediation on Microsoft Internet Explorer:

Click the Settings button at the top-right corner of the browser, and then select ‘Internet Options’. Then browse to the ‘Advanced’ tab. In the Settings menu, scroll to the bottom and uncheck the box labeled ‘Use SSL 3.0’. Once completed, click ‘Apply’ then ‘OK’.
poodle 3

Remediation on Mozilla FireFox:

In the URL address bar, browse to ‘about:config’. You will then be given a warning, indicating that you should only modify these settings if you know what you are doing. We do, so click the button to disregard the warning and proceed. Then, in the Search bar, type ‘security.tls.version.min’. Double-click the setting with that Preference Name and then change the integer value from 0 to 1. Once this change has been made, click ‘OK’. This will disable SSLv2 and SSLv3, and only allow the browser to support TLSv1 and later.

poodle 4

Remediation on Google Chrome:

Ironically, despite the fact that it was a Google team that identified this vulnerability, Chrome’s GUI management interface offers no option to disable support for SSLv3. A common workaround is to start Chrome from a shortcut that leverages the command line argument to disable support for SSLv3.

To do this, right-click your Google Chrome shortcut and select ‘Properties’. Then, append the command line argument ‘ –ssl-version-min=tls1’ to the end of the value in the Target field (as seen in the provided image). Click ‘Apply’ and then ‘OK’. Once this modification has been made, support for any versions prior to TLSv1 is disabled anytime the browser is started from this Shortcut.

poodle 5

Server Remediation

Remediation on Apache Server:

Modify the SSLProtocol directive in the server’s ssl.conf file to disable support for versions earlier than TLSv1 on Apache. The location of this file may vary depending on the build of the server.

For Ubuntu, the file can be modified with:

sudo nano /etc/apache2/mods-available/ssl.conf

If mod-ssl is enabled, the location will be:

sudo nano /etc/apache2/mods-enabled/ssl.conf

For CentOS, the file can be modified with:

sudo nano /etc/httpd/conf.d/ssl.conf

In the configuration file, modify the SSLProtocol directive to include the following:

SSLProtocol All -SSLv2 -SSLv3

To verify the configuration change, use the following:

apachectl configtest

Once support for SSLv2 and SSLv3 has been disabled, the Apache service will need to be restarted. This can be done with the following command:

sudo service apache2 restart

Remediation on IIS:

To disable support for SSLv3 on Microsoft IIS, a registry tweak is required. Open the registry editor (with command ‘regedit’) and then browse to the following key:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\

Inside the Protocols key, there should be a key called ‘SSL 3.0’ and inside that key, there should be a key called ‘Server’. If these keys do not exist, create them. Then, inside the ‘Server’ key, create a DWORD value called ‘Enabled’ and then leave its value at 0 (default). Once completed, restart the server to implement the new changes.

poodle 6

Remediation on NGINX:

Modify the ssl_protocols directive in the nginx.conf file to disable support for versions earlier than TLSv1 on Nginx. This file is located at /etc/nginx/nginx.conf and can be modified with:

sudo nano /etc/nginx/nginx.conf

Modify the ssl_protocols directive in the file to include the following:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

To verify the configuration change, use the following:

sudo nginx -t

Once support for SSLv2 and SSLv3 has been disabled, the nginx service will need to be restarted. This can be done with the following command:

sudo service nginx restart

What is TLS_FALLBACK_SCSV?

In the event that you are not prepared to disable the use of SSLv3, downgrade attacks can be alternatively mitigated in some distinct scenarios by using a browser that supports a new cipher suite value called TLS_FALLBACK_SCSV. In the event that both the server and client browser support this option, a more secure negotiation process is used that prevents downgrading to a protocol or cipher that is less secure than the highest mutually supported option.

Unfortunately, at this time, limited support on the server-side and limited adoption by client browsers has made this an ineffective, comprehensive solution for this problem.

Presently, TLS_FALLBACK_SCSV is only supported by Google Chrome 33.0.1750 (February 2014 Build) and later. Other major web browsers will likely adopt support in the following months.

 References

About GuidePoint Security

GuidePoint Security, LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Reston, Virginia, and with offices in Michigan, New Hampshire, Florida and North Carolina, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Shellshock – Security Technology Vendor Information

Based on the requests of our clients, as discussed in our previous blog post “How shocking is “Shellshock?” below is a list of security technology vendors whose solutions are susceptible to the Shellshock vulnerability. This list will be regularly updated to provide you with timely information on the security technology vendors that you rely on to protect your organization.

Last Updated: Wednesday, October 1, 2014 13:47 EDT

Vendor