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.

Does RASP Spell the Death of WAF?

RASP, or Runtime Application Self Protection, has been around since at least 2012 as coined by Gartner in this article. The technology essentially seeks to move traditional inline protections such as those provided by a web application firewall (WAF) closer to the application. In addition, RASP provides additional context to make more intelligent decisions about application attacks. This is not unique to web application attacks, as RASP can function for any instrumented application. Depending on who one talks to, RASP is either complementary to or a direct replacement for WAF.

As the marketing around these technologies tends to be a bit confusing, it is important to clarify a few things before we get started with a comparison of the two. There are many ways that WAF can be deployed: either traditionally inline in reverse proxy or transparent bridge mode, passively decrypting out of band, as an embedded on-host solution, and even via hybrid architectures such as cloud-based CDN WAF. Other techniques include a distributed WAF or virtual WAF hosted in a cloud environment. Comparably, RASP products are not all architected in the same manner either. The primary difference between RASP and a traditional WAF is the added context, as the analysis engine is driven by instrumentation, not observed traffic. As a technology, RASP has not matured to the point where WAF is today. Nor is RASP supported by such standards as WAFEC. So much of this is very opaque to potential RASP consumers.

The Argument for WAF

When comparing RASP to WAF, be sure to include all WAF or RASP deployment scenarios in the assessment. In some cases RASP is installed as an agent, or possibly exposed as a SDK that developers must make use of when coding their projects. In some instances, mitigation occurs by throwing exceptions and allowing the application’s exception-handling mechanisms to manage the issue. In other cases, inputs and outputs are scrubbed before they can do too much damage. In early versions, RASP was only protecting against legacy attacks such as XSS and SQLi, much the same as a WAF would. In fact, some of these products still function the same way today. When looking at RASP vendors, make sure they are not simply moving WAF logic inwards inside the runtime environment. Compliance frameworks such as PCI DSS do not recognize RASP as an acceptable application security control and attempts to replace WAF with RASP in 2016 may result in backwards momentum for compliance objectives, regardless of actual security impacts.

RASP brings to the table a very compelling argument; that the protection layer occurs as close to execution of code as possible, inside runtime environments such as .NET or Java JVM, and that it is required to install an agent on the server. RASP proponents stipulate that this makes them better suited to stop attacks that are occurring. But that also means these agent-based protections are not useful for applications based on PHP, Ruby, Python, or other languages that do not utilize a runtime environment. Many RASP technologies require that all or at least some of the functionality requires custom development work if you want to utilize the full benefits of their technology. This means custom development is usually required for all the capabilities that the agent alone will not provide.

However, RASP or WAF are, at best, compensating controls. I’m not comfortable with excessive development time spent on compensating controls when that time could be better utilized simply fixing the application vulnerabilities. This is especially important, considering that you may be locked into a code version that brings with it additional RASP licensing costs. This also increases the attack surface, added application complexity and increases overhead on the application server. By focusing on an external component such as a WAF, this creates a philosophical separation of control that allows for a more layered, yet centrally managed control, as opposed to an integrated approach that has multiple management points, scalability concerns, and a potential for human error to impact the consistency of controls. Additionally, WAF products are generally more configurable, but this also speaks to the maturity of the product space as these capabilities have evolved over time due to customer feature enhancements.

RASP also does not provide the same benefits a WAF brings for virtually patching application architectures. When the next TLS bug gets announced with a trendy new name, you will want the protection of a robust reverse proxy that can mitigate that issue in one place until the backend servers can be patched – RASP will not help there. It is also a very dangerous precedent to set that developers no longer need to write secure code, as you will be virtually patching all of their code with an agent inside the runtime environment or by utilizing this new set of SDKs required by the RASP vendor.

The Argument for RASP

On the other hand, RASP is very good at providing visibility into what a request or database response looks like to the application. WAF is usually several layers removed from the application where the request is destined, and after normalization the application may see a very different version of that same request. The WAF will never see the database response coming back to the application, only the http response that is being delivered to the end user. The WAF will never be able to understand data flows inside the application, unless that application is making additional web requests through the WAF to another application. The WAF has no understanding of how the application actually works. Finally, the WAF has no visibility into unhandled exceptions. This is where RASP starts making a lot more sense.

RASP technologies do not suffer from the same issues with false positives or tuning as they typically identify malicious activities that are occurring in real time. The WAF will see a user input the name “O’Malley” in a contact form and flag the blacklisted ‘ character, while RASP never needs to be tuned to ignore that in the last name variable because it did not result in an actual attack. There was no SQL injection attack, and the RASP will not flood the analyst with false positives that must be reduced. WAF typically has very little context other than what is observed from the actual requests passing through it. WAF has to be heavily tuned to understand what is and what is not acceptable. RASP on the other hand, has full visibility and context for what the application is processing, and can simply focus on what is actually impactful.

RASP is also largely protocol agnostic, as it does not rely on network traffic. It is purely driven by instrumentation and a set of rules that governs what an attack looks like from the standpoint of abuse of library calls, or queries and responses with the database. Inside an application, data flows and functions work largely the same regardless of what network protocols data is sent over. That means, in many instances, RASP technology can be extended outside the traditional web application stack that WAF protects to include AJAX, SQL, SOAP and more.

The other area that makes RASP very interesting is that WAF innovation has largely stalled. WAF vendors are not creating many new detection techniques or mitigation mechanisms, but are instead focused on keeping pace with changing architectures and cloud deployments. This is due to the fact that the WAF product space is relatively mature, but is very dependent on the application deployment architecture to function properly. In contrast, RASP is newer and more focused on integrating with server operating systems and application frameworks and languages. Many of the RASP vendors vying for market dominance are being much more forward thinking in their approach as they seek to differentiate themselves as the market leader.

Conclusions

My contention is that the marketing around RASP is very short-sighted as the vendors know most organizations have a limited security budget and they’d rather you buy their RASP product then continue renewing your WAF maintenance. My personal opinion is that RASP offers a very complementary feature set for traditional WAF deployments. The best of both worlds is to deploy both. But, if you can only afford one, utilize the points made above and decide what makes the most sense for your organization.

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.