Related Articles
Users have been put at risk of attacks because Cloud providers have not been quick enough in fixing their infrastructure and resources after the Drown flaw.
Cofounder of Skyhigh Networks, Mr. Sekhar Sarukkai, claimed at least 620 cloud services companies were not prioritizing the fixing of infrastructure and therefore it left them still vulnerable to attack. The number has gone down from the 653 cloud services that were believed to have been at risk last week. The decrease in number is however still low and more had to be done to make more of the cloud services secure and immune to attacks.
Mr. Sarukkai said that the news meant that as of today, on average an organization was using 56 vulnerable services. The response to the Drown vulnerability was very slow when compared to the response that cloud services had to the Heartbleed vulnerability. When the Heartbleed vulnerability came in less than at least 90 percent of cloud services had already found a way to reduce the flaw. It now boggles the mind as to why there has a been a relatively slow response to the Drown flaw especially since to fix it they just had to disable SSLv2 support.
The other reason might be because more cloud services were affected by the Heartbleed flaw than the Drown therefore, cloud services felt the need to patch Heartbleed earlier than they feel threatened by Drown vulnerability. The numbers involved on both vulnerabilities are staggering. A week after Heartbleed 92.7 percent of cloud services had been fixed. This is in stark contrast to now where in a week only 5.71 percent have protected themselves from Drown.
The SSLv2 protocol is an outdated 90’s protocol thus the cloud services might be thinking it is not that important. Better safe than sorry, though. It however does. It matters if the system is using the more secure and new TLS protocol.
Mr. Sarukkai’s recommendation was that affected cloud services that were still vulnerable were supposed to notify all their customers about the risks that were involved in the websites and cloud services they were using. This seems to be a good idea to empower people so they can know which appropriate action to take. Some companies could also redirect their users to informative pages that educated them on the risks of accessing flawed sites and that their sessions were probably insecure.
Guillano Fasto, a senior security consultant at Espion, said that some network devices embedding old versions of the OpenSSL software would need a vendors update to address the problem. Therefore respective companies had to wait until there was a release of the updates and they could upgrade. He said, “Workarounds would be possible in the meantime on specific environment and configurations, but its safe to think that many companies would like to wait for a vendor update.”
Whether dangerous or not more has to be done to fix this Drown vulnerability.
