Estimated Reading Time: 4 minutes
sayonara Flash, Its been real
November 1996. Clinton defeated Dole and Perot to win re-election, the Mars Global Surveyor was launched, and Macromedia Flash 1.0 was released. While technically, Flash traces its roots back a few more years to 1993, the tool that arguably changed the face of the web forever, made its debut 23 years ago, and the world hasn’t been the same.
Many of us have very mixed emotions about Adobe’s recent announcement about the soon-to-be demise of Flash, even though it has been in the works since 2017. One could argue that if it weren’t for Flash, the web wouldn’t be anywhere near as interactive as it is today. Hell, one could even argue that HTML5 wouldn’t even exist if it weren’t for Flash; or more precisely; the desire to not run Flash on mobile devices. Let’s face it, we would still be in a very bland, blinky, sprite-based world if it weren’t for Flash.
Yet, how many of my gray hairs are directly related to the decades of Flash vulnerabilities that have left my endpoints exposed to malicious actors? Even after 23 years, we are still, to this day, dealing with Flash vulnerabilities on our endpoints. Let’s not even get into the CPU and memory consumption issues that have plagued Flash for decades. At some point, we just need to say our goodbyes, push the uninstall button, and move on; which frankly, is exactly what Adobe is hoping we will do. Not too surprisingly, Apple just announced that the latest version of Safari will no longer support Flash, which should make the transition a bit easier.
However, being a pragmatist, I fully recognize that the official end of Flash is actually going to introduce more risk into our environments – not less. Since Adobe will no longer be supporting or patching Flash, we will all be left with a withering, vulnerable relic across our many of our endpoints until our IT teams can get it cleaned up – if they even can. Honestly, I am just waiting for the day to hear about that ‘major’ enterprise application that requires Flash to function. Some critical app that, for some lazy reason or another, the developers still haven’t fixed. Just like the never-ending need to run Java 1.x somewhere, don’t be surprised when we hear about enterprises being breached because they were still running Flash a year from now. It’s just the world we live in.
So Flash, just like that ’70 Chevelle that changed my life, it’s time to say goodbye. Thanks for the interaction, the entertainment, and for making the web what it is today. You weren’t perfect, but you were what we needed.
DDOS attacks and the takedown charade
Last week, both Akamai and Amazon announced that they experienced multi-terabit DDOS attacks earlier in the year. While we have been seeing terabit level attacks since 2018, the fact that, as in Amazon’s case, we are now getting over the 2-terabit level shows the level of growth of the botnets and in the reflective attack techniques that attackers are using.
Both of these reports seem to have overshadowed a Cornell study that shows that the law enforcement takedowns of large-scale ‘DDOS Booter’ services have had little to no impact on the overall capacity of the DDOS-for-hire underground market. In fact, the study argues that such takedowns are not only ineffective but also shortlived.
The full study, found here, does a month by month comparison of the major DDOS Booters, also known as booter services, are underground, malicious, service-based Distributed-Denial-of-Service networks that can be used to flood legitimate web sites and IP addresses with traffic. services and demonstrates how such services are readily back up and running within a few weeks with little impact on their overall functionality. Additionally, since so many of these services were using the same vulnerable reflector servers, there was actually an inherent rate-limiting feature since the reflectors could only handle so many requests at a time. One could argue that the takedown of one service may have actually increased the attack capabilities of another. Rather than taking down such services, the study argues that patching the vulnerable reflection servers would make a far bigger impact on the entire booting underground, then say, taking down a specific booter domain.
This brings up a very interesting debate; to what degree should companies be culpable in patching their environments to protect the rest of us? Much like the response to the recent COVID pandemic, can/should the government or law enforcement force businesses to address internet-based risks that put the larger community at risk? While there is a plethora of state/country-level legislation around protecting consumer privacy and mitigating the financial impact to businesses (i.e. SOX), there is not a single piece of legislation on the responsibility of a company to address the risks they are introducing to everyone else.
While I am generally not a proponent of vague/ineffective legislation, one has to wonder if something could be done to force companies to fix public-facing services and solutions and ensure that they are, at a minimum, not causing harm to others. Perhaps its time, as an industry, to start publicizing such companies that facilitate these global risks and ‘encourage’ them to fix their environments? Maybe the potential of bad press or refusing to do business with them would have a more immediate impact?
I’m sure there are many ramifications to such an approach, but history and experience say that embarrassment is a far bigger influencer than legislation. Maybe it’s time to start calling these companies out.
The Chronicles of a CISO Weekly Hotwash is a recap of critical stories and news that occurred over the past week. The goal is to hopefully share some insight and perspective on how these stories may impact our industry, our careers, or our companies.
Copyright © 2002-2020 John Masserini. All rights reserved.