Over 600 cloud providers not protecting users against Drown
Continuing use of SSLv2 is giving crooks a way into your cloud
Cloud providers have been slow to fix their infrastructure against the Drown vulnerability and this is putting users at risk of attacks. According to Sekhar Sarukkai, co-founder of Skyhigh Networks, a week after the critical flaw was disclosed, the firm found that 620 cloud services remained vulnerable to attack.
This is only slightly lower that the 653 services thought to be vulnerable last week. He said that cloud providers have been slower to respond to Drown compared with other SSL vulnerabilities of similar scope such as Heartbleed and Poodle.
“That's bad news for the 98.9 percent of enterprises who use at least one vulnerable service. As of today, the average organization uses 56 vulnerable services,” he said.
The slowness of response to Drown compares badly with the reaction to Heartbleed where in the space of a week, cloud services vulnerable to that flaw reduced by over 90 percent. Sarukkai said it was troubling that cloud providers had been slow to patch services against Drown – which they can do simply by disabling SSLv2 support.
“While more cloud services overall were vulnerable to Heartbleed compared with Drown, cloud providers quickly patched their systems to close their Heartbleed vulnerabilities,” he said. “A week after Heartbleed was disclosed, 92.7 percent of cloud providers initially vulnerable were no longer affected. A week after DROWN was disclosed, just 5.1 percent of cloud providers that were initially vulnerable have performed necessary remediation.”
The flaw enables hackers to compromise an encrypted session by exploiting a vulnerability in the outdated SSLv2 protocol, even if the session itself is encrypted with the newer and more secure TLS protocol.
According to Tod Beardsley, security research manager at Rapid7, the vulnerability needs an attacker to be in privileged position on the network in order to eavesdrop on a TLS session, and also needs to have already conducted some reconnaissance on the server-side infrastructure.
“But this is the nature of padding oracle attacks. While it's not Heartbleed, Drown techniques do demonstrate the weaknesses inherent in legacy cryptography standards,” he told SCMagazineUK.com.
Steve Ward, senior director at iSIGHT Partners, told SC that because of the need to be in a position to intercept traffic, “We anticipate limited actor interest and do not expect widespread exploitation."
Sarukkai recommended that all enterprises notify their end users about this vulnerability in the websites and cloud services they use. “Some enterprises may also configure their web proxy to redirect users to an educational page notifying them that their session may not be secure when they attempt to access a vulnerable site or cloud service,” he added.
James Maude, senior security engineer at Avecto, told SC that the vulnerability is reasonably straightforward to fix as most instances just require a configuration change to disable support for SSLv2.
“In the majority of cases, being vulnerable to the DROWN attack is symptomatic of a far worse problem – reliance on old versions of software,” he said.
“In IIS 7 or newer, SSLv2 is disabled by default, so either companies are running a lot of services on out-of-date platforms or configuring them badly by enabling SSLv2 – my money is on the former. Organisations who have not fixed this yet are effectively telling the attackers that they have no robust security in place and probably run a lot of other vulnerable systems.”
He added, “Many businesses won't have addressed this because they won't realise they are vulnerable. No matter how good the website and logo that accompanies the latest vulnerability, or how much press coverage it gets, it is still hard to reach those who haven't patched or updated their webserver in years.”
Giuliano Fasto, senior security consultant at Espion, told SC that some network devices embedding old versions of the OpenSSL software would need a vendor's update in order to address the problem, therefore companies need to wait for the updates to be released. “Workarounds could be possible in the meantime on specific environment and configurations, but it is safe to think that many companies would prefer to wait for a vendor update,” he said.