Chances are good that most security professionals recall the DROWN vulnerability from earlier this year; for organizations...
that have an external-facing web presence, that recollection probably extends to evaluating their own web services and applications to make sure they aren't vulnerable.
While it's been a few months since the original DROWN vulnerability research was published and many shops have already taken action, it's worth revisiting now for a few reasons. First, the serious nature of the issue and the widespread impact that it had make it important to keep abreast of -- at the time the research was published, it impacted about 33% of HTTPS servers. Second, organizations that rely heavily on SaaS -- i.e., that are using web services that they may not explicitly control themselves -- need to pay particular, and ongoing, attention to the problem to ensure that the services they use continue to remain DROWN-free.
What is the DROWN vulnerability and why does it matter?
DROWN (Decrypting RSA using Obsolete and Weakened eNcryption) codified under CVE-2016-0800, specifically, the research describes an issue whereby SSLv2 is used as an oracle to decrypt TLS connections. Meaning, leaving SSLv2 support turned on allows an attacker to potentially leverage that functionality to attack TLS support that shares the same key.
Most practitioners already know about the security issues with SSLv2 -- and, in fact, modern browsers won't actually negotiate it. Nevertheless, circumstances could arise where support for it on the server side is enabled. For example, an organization might have consciously elected to leave v2 support on to support legacy browser versions or they may have used default settings with support enabled. Unless there is a compelling reason to actually identify that SSLv2 support is enabled -- for example, if an organization is required to go through the PCI external scanning process where support for SSLv2 is a mandatory failing scenario -- support for this legacy version may be turned on without anybody being the wiser. This was true before the vulnerability was disclosed and can conceivably be the case now.
At the time when the research was published, a number of cloud service providers were impacted by this issue. Netskope published an analysis of this where it tracked the number of SaaS applications that are vulnerable. The last update from March 2016 still showed over 500 vulnerable SaaS applications, of the original 676 that they initially identified.
It's important that cloud customers take note of this and that they continue to have the DROWN vulnerability on their radar. Whenever industry buzz about an issue declines, the temptation is for it to fall off the already-full radar of security practitioners. However, it is not outside the realm of possibility that a cloud provider might still be impacted.
Specifically, enterprise cloud usage is not static: new providers are continuously added to the mix and new usage of SaaS develops as business needs change. Moreover, shadow IT adoption means new usage is continuously discovered by practitioners as they go about their daily jobs. What this means from a practical point of view is that security teams need to remain vigilant for this issue as new cloud usage is discovered, as they vet new SaaS providers, and as they continue to expand their knowledge of their own organization's use of cloud services.
In light of the DROWN vulnerability, it's important to evaluate what measures the cloud customer can employ to ensure that this bug stays quashed and that issues don't resurface. First and foremost, it's important that organizations continue to monitor their use of SaaS applications. Meaning, there should be ongoing discovery of SaaS usage. Finding and cataloging cloud usage is an ongoing challenge, but DROWN and vulnerabilities like it up the ante. A useful first step for those that haven't tackled this problem already is usage discovery. There are commercial discovery tools -- most of the CASB tools can help in this regard -- which can be bolstered by manual approaches such as actively canvassing business teams relative to SaaS usage -- or even partnering with other organizations like Internal Audit or BCP/DR teams to gather data.
During SaaS usage discovery, the next step is to ensure that there is an active mechanism to identify areas of weakness. This is a good step anyway, but is particularly beneficial for known-vulnerable situations like SSLv2. The DROWN vulnerability page has a tool to test a domain or IP for SSLv2 support; this is a useful first step, but it means thinking about how to address the issue more comprehensively. For example, if the provider allows it and will work with the organization on it, the organization may wish to consider leveraging scanning tools to help locate this and other issues. Most scanning tools -- both application and OS tools -- will flag SSLv2 as a problem. This is a useful step in situations where it is permissible; it's worth noting that this should be actively discussed with the services provider ahead of time to ensure they give their written permission before undertaking the test.
Alternatively, the PCI compliance status of the provider can be used as a barometer for the DROWN vulnerability status. Since the PCI quarterly scanning methodology specifically requires approved scanning vendors to fail an environment on the basis of SSLv2 support alone, asking for a complaint RoC, attestation of compliance, or other supporting artifact that establishes conformance with that standard can be a useful surrogate.
In a situation where a site has SSLv2 support enabled at a cloud provider, the question then becomes what can be done about it. Unfortunately, there isn't much technically that can be done on the client side to mitigate the issue; informing the CSP and pointing them to resources about how to remediate is probably the best option. That said, determining that a CSP still has SSLv2 turned on at this late point in the vulnerability lifecycle should probably indicate something important about that provider's security acumen -- this might mean scrutinizing that vendor in particular from a security perspective.
The point is, while trade media coverage of the DROWN vulnerability may have waned, it's every bit as important from a cloud customer point of view as it was in March 2016 when it was first published. It is imperative that cloud customer organizations remain alert for this issue and take action when it rears its head.
Find out why the security industry needs to standardize CASBs
Learn more about cloud-based security vulnerabilities
Discover how to buy the best SSL for your enterprise