Security Trends in 2016: Known Vulnerabilities Are Still Dangerous

FINISH HIM! SSHowDowN Wins! The proxy attack Akamai published on last October of 2016 sound like a character from Mortal Kombat. That would be a fun MK character, a little digitized malware-bot killing Sub-Zero or Goro. In reality and actually a real world threat, SSHowDowN's a proxy exploit of OpenSSH daemons running on exposed devices (yes, the same devices that everyone's pwning these days). Where Mirai exploited user failure to change default username/password combos (and disable telnet), SSHowDowN exploited 12 year old vulnerability CVE-2004-1653 which allows OpenSSH to be used a a TCP tunnel for malicious traffic not originating on system. The issues are two-fold, A) we have devices shipping with SSH exposed and tunneling features enabled on public interfaces, and B) it's been out there for 12 years. We have to assume exploits exist we don't know about and enterprise-adopted source code is public; both good and bad users now have chances to pour over decades of material, looking for these hidden gems. 2016 gave us many more exploits of old known bugs so why are old bugs still causing us heartache?

What The Experts Say

HPE Security Research's 2016 Cyber Risk Report listed 7 major themes for the previous year; them three strike chords related to this article:

Theme #5: The industry didn't learn anything about patching in 2015
Theme #6: Attackers have shifted their efforts to directly attack applications
Theme #7: The monetization of malware

Additionally, patching vulnerabilities involves 4 generalized steps:

Researcher uncovers vulnerability; reports to vendor
Developers implement a fix
Vendor releases a patch
End user deploys a software update

The first step is usually made through a bug bounty program and here we run into a flaw: White versus Gray versus Black markets have made bugs a very lucrative mini-industry. Monetizing exploits is now big business and creates divergent paths for fixing known vulnerabilities for the various hat-colored people.

White Hats make money via bug bounties, Gray Hats make money by selling through private brokers who supposedly resell to ethical and approved sources. And then there's Black Hats and they do what they do best.

An Update Is Available... But You Can Keep Your Vulnerabilities

April of 2016 saw Oracle publish technical information to the public on the known vulnerabilities of older editions of Java and steps to reduce client risk. This alerted the general public that newer versions of Java installed along side previous versions instead of overwriting the previous install. Some developers do require multiple versions of Java and that's a handy feature. For most people installing Java (read consumers) this was an unknown. This allowed old public vulnerabilities to coexist with their patched counterparts, undermining patching efforts. Oracle did create uninstall procedure instructions and published alerts through various media outlets; because it was required to by the FTC. In this case because known vulnerabilities were listed as fixed in release notes, a malicious user could simply read Oracle's documentation on how to bypass older versions.

That Bug Is Old Enough To Drink

May of 2016 saw Slackware releasing a patch for a 21-year-old bug which allowed a malicious user to execute remote DoS attacks by exploiting CVE-2016-10087; a null-pointer-deference bug in png_set_text_2 (). The Libpng owners in their own documentation warned of the flaw since July of 2000. Now pause... the CVE is new, the library's been around for a long time, and the flaw was known and documented. This re-raises public discussion on ownership's responsibility of code made popular during the Shellshock and Heartbleed blame games. What CVE-2016-10087 does illustrate is a lot of open source is capable of being investigated and potentially exploited. Mind you this particular CVE is hard to trigger in the wild and would require interactive sessions with the system or through other methods requiring existing elevated privileges. Still... go buy this null-pointer-deference bug a beer.

Dirty Cows!!!

CVE-2016-5195 leverages an incorrect handling of copy-on-write (COW) feature to write to a read-only memory mapping, and was show to be exploited in wild by October of 2016. How does it relate? 9 years of Linux kernels (2.x through 4.x before 4.8.3) were affected and it was actively being exploited at time of discovery and patching. This was more critical due to it's ability to access sensitive memory, say becoming root in a short amount of time. There was quite a bit of media coverage on this due to the critical nature of the bug and it's reliability of exploitation under normal conditions. I don't need to cover more on this, just search for CVE-2016-5195 and sit down for some nice quiet time reading although most everyone covered the same content.

The Average Linux Security Flaw Is In Preschool

Keeping Dirty Cows in mind, last October of 2016 codeblog author and Google developer Kees Cook evaluated CVE's between 2011 through 2016 confirming Linux kernel bugs have an average life span of 5 years.

Numerical Summary By Severity:

Critical: 2 @ 3.3 years
High: 34 @ 6.4 years
Medium: 334 @ 5.2 years
Low: 186 @ 5.0 years

Additionally Kees noted for the Linux kernel work, fixing existing bugs tends to create additional bugs. We then have to wait on upstream providers to patch their affected systems. The total lifespan from discover to having your Home DVR fixed could well exceed that 5 year average. Kees also referred to Jon Corbet's analysis in 2010 which came to similar results when comparing Linux kernel 2.6.x open issues. Jon's research identified CVE-2010-1188 which was fixed in 2008 but only identified as a security issue in 2010. This type of delay in realizing kernel bugs would also delay a vendors need to update their distributed kernel. A nefarious user with code level knowledge of kernel development (it is open source after all) would have several years of malicious use to all exposed systems before vendors patched with fixed kernels.

Preventative Measures (Stop Airing Your Dirty Device Laundry)

Some of these vulnerabilities identified require existing access or require semi-compromised system states to fully realize the exploitive potential. Some are just easy and spooky (Dirty Cow) to exploit. But when we're speaking of nation states, nothing is ever off the table, nor with organized groups of malicious users. Protection comes from limiting exposure to key resources and due diligence for any system requiring internet access. Responsibility isn't just for end users to worry about though; vendors could've prevented SSHowDowN, and Oracle should've default to overwriting Java versions in the installer unless explicitly told not to. For enterprises, the naked exposure of linux-based devices is usually a non-issue but applications moved to the cloud and we have to worry again about what's exposed. Linux kernels may not be exposed but I bet some of you are managing your AWS instance via SSH. What else may be exposed? MongoDB? Apache? Oracle? We've shifted our vulnerabilities to a new world and we're still trying to catch up with the old ones. I don't expect anyone to memorize the current CVE database but admins do have the ability to reduce exposure to the internet. The next Heartbleed or SSHowDown is just around the corner and you may be inadvertently the next target.

Published Feb 08, 2017

Version 1.0