This web site uses cookies to improve your experience. By viewing our content, you are accepting the use of cookies. To find out more and change your cookie settings, please view our cookie policy.

Search
  • Videos
  • Smart Cities
  • Windows 10
  • Cloud
  • Innovation
  • Security
  • Tech Pro
  • more
    • ZDNet Academy
    • Microsoft
    • Mobility
    • IoT
    • Hardware
    • Executive Guides
    • Best VPN Services
    • See All Topics
    • White Papers
    • Downloads
    • Reviews
    • Galleries
    • Videos
  • Newsletters
  • All Writers
    • Log In to ZDNET
    • Join ZDNet
    • About ZDNet
    • Preferences
    • Community
    • Newsletters
    • Log Out
  • Menu
    • Videos
    • Smart Cities
    • Windows 10
    • Cloud
    • Innovation
    • Security
    • Tech Pro
    • ZDNet Academy
    • Microsoft
    • Mobility
    • IoT
    • Hardware
    • Executive Guides
    • Best VPN Services
    • See All Topics
    • White Papers
    • Downloads
    • Reviews
    • Galleries
    • Videos
      • Log In to ZDNET
      • Join ZDNet
      • About ZDNet
      • Preferences
      • Community
      • Newsletters
      • Log Out
  • us
    • Asia
    • Australia
    • Europe
    • India
    • United Kingdom
    • United States
    • ZDNet around the globe:
    • ZDNet China
    • ZDNet France
    • ZDNet Germany
    • ZDNet Korea
    • ZDNet Japan

Before Heartbleed: Worst vulnerabilities ever?

14 of 15 NEXT PREV
  • Heartbleed: Living the nightmare

    Heartbleed: Living the nightmare

    More Heartbleed

    • How to protect yourself
    • Lesson: Passwords must die
    • Before Heartbleed: Worst vulnerabilities ever?
    • LastPass' Security Check has you covered
    • OpenSSL needs corporate funding to avoid Heartbleed repeat
    • CloudFlare keys snatched
    • Heartbleed's engineer: It was an 'accident'
    • Did open source matter for Heartbleed?

    With the mainstream media and general public now used to big tech stories, Heartbleed may be the most famous software vulnerability in history. Is it the worst ever?

    It's up there. The pervasiveness of technology and our reliance on encryption, and SSL/TLS in particular, makes us sitting ducks for Heartbleed attackers, if there are any out there. On top of that, Heartbleed is a partly zero-day vulnerability; when the news broke, the fixes were in process, but far from complete.

    And the consequences of Heartbleed are widespread. It may be that every SSL digital certificate needs to be reissued. You may need to change most, maybe all of your passwords. These things take time, and while they're taking their time we're open to attack.

    In this gallery we have collected 15 of the most severe vulnerabilities in tech history. All the vulnerabilities are in software. One purely hardware vulnerability suggested to us — the thermal exhaust port on the Death Star — was deemed out of scope, even though it was a relatively critical bug.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Caption by: Larry Seltzer

  • SQL Slammer

    SQL Slammer

    SQL Slammer is the undisputed speed champion for vulnerabilities. With a tiny payload and through the magic of UDP, it spread across the world in a matter of minutes on January 25, 2003. (How tiny? The picture above is a complete disassembly of the worm, with comments added!)

    The actual vulnerabilities exploited, multiple buffer overflows in the Resolution Service for Microsoft SQL Server 2000 and Microsoft Desktop Engine 2000 (MSDE), had been patched months before by Microsoft, but there wasn't quite the sense of urgency back then that there is now about applying updates.

    The breathtaking speed with which Slammer hit created fear of similar future attacks, but fortunately it was not to be. Slammer isn't the only worm we've had, but it's the only one that crossed the globe before anyone knew what was going on.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: Disassembly of Slammer worm, courtesy Immunity, Inc.

    Caption by: Larry Seltzer

  • The Morris Worm

    The Morris Worm

    what's hot on zdnet

    • Why Amazon's home robots aren't a stretch: All the infrastructure, ecosystem via AWS is in place
    • Global automation readiness. Who's prepared, who's in trouble?
    • Why the next iPhone doesn't need to be faster or thinner
    • A regulation straitjacket is no less than Facebook and everyone else deserves

    Just six months ago  we celebrated the 25th anniversary of the Morris Worm . By today's standards the raw number of systems affected — 6,000 — is not impressive. It looks different when you see that there were only 60,000 systems on the entire Internet on November 2, 1988.

    Yes, Robert Morris, then a student at Cornell, brought down 10 percent of the entire Internet, and he did it by accident. Morris wrote a worm program as a selfish intellectual experiment. Exploiting known vulnerabilities in Unix sendmail, finger, and rsh/rexec, as using a list of weak passwords with which to access accounts, it attempted to span the entire Internet. But a bug in the worm turned it instead into a massive distributed denial of service attack against the entire Internet.

    Computer security was an academic issue before the Morris worm. After November 2, 1988 it became very real.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: Wikipedia

    Caption by: Larry Seltzer

  • Conficker: Still botting after all these years

    Conficker: Still botting after all these years

    On Thursday, October 23, 2008 (yes, it was "out of band"), Microsoft published MS08-067: Vulnerability in Server Service Could Allow Remote Code Execution. This was one of the really bad ones in that a remote user could gain administrator control of a PC and turn it into a bot. The word went out that it was important to apply the update, but you know how people are; security firm Qualys estimated that in January 30% of vulnerable PCs were still unpatched.

    It was almost a month later that the first variant of Conficker, also known as Downadup and which spawned the great Waledac spam botnet, was detected. Conficker was — make that "is" because it's still alive — pretty sophisticated malware. It was capable of updating itself and was one of the principal bots to spread via file shares and USB drives.

    In Europe the spread was particularly severe, affecting the military networks in France, the UK and Germany. It spread to over 200 countries and became one of the largest botnets ever.

    In fact, Conficker would be blocked by decent firewall rules as well as the update. The fact that it spread so far and still lives shows just how widespread bad configurations are.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: The Conficker Working Group

    Caption by: Larry Seltzer

  • Adobe Flash: Quick! Everyone update again!

    Adobe Flash: Quick! Everyone update again!

    The Adobe Flash Player Security Bulletins page shows 101 security updates, fixing some much larger number of vulnerabilities in the product since the release of version 9 a little over five years ago. None of these vulnerabilities was all that more egregious than the others, but the sheer number of them and Flash's weak updating process have meant that there are always large numbers of users who are vulnerable to known Flash vulnerabilities.

    One of the most famous and consequential Flash vulnerabilities  was used to penetrate RSA (the company) in order to compromise their SecureID two factor authentication tokens . Remediating this problem was expensive and, in the interim, large numbers of high-value customers were exposed.

    Adobe has improved the update process, and both Google and Microsoft have (ironically) built Flash directly into their web browsers in order to use their stronger update processes to force Flash updates.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Caption by: Larry Seltzer

  • IIS is a sitting duck

    IIS is a sitting duck

    Before Microsoft got its security act together, one of their most vulnerable products was one of the most exposed: IIS (Internet Information Server), the web server that comes with Windows. Both the Code Red and Nimda botnets were highly successful in exploiting vulnerabilities simply by sending HTTP requests to IIS servers.

    eEye Digital Security employees Marc Maiffret and Ryan Permeh. They named it "Code Red" because Code Red Mountain Dew was what they were drinking at the time.

    Code Red was the first widespread use of IIS vulnerabilities and must have been one of the major motivations behind Bill Gates's decision to make security a major priority at Microsoft. Within a few years IIS did a Charles Atlas, going from 90 pound security weakling to the most secure web server available. But at the time, IIS's reputation was deservedly in the gutter.

    Nimda was also a pioneer in the use of multiple infection vectors: it could also spread via email, network shares, by surfing compromised web sites, and through back doors left by other bots.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: Wikipedia

    Caption by: Larry Seltzer

  • iPwn! Hack an iPhone with an SMS message

    iPwn! Hack an iPhone with an SMS message

    Charlie Miller, now an engineer at Twitter, has long been known as one of the top researchers of Apple products. In August 2009 at the Black Hat security conference, Miller outdid himself with an iPhone hack that must have rattled some chains at Apple.

    Miller, along with Collin Mulliner, demonstrated how they could send an SMS text message to an iPhone and compromise the phone automatically when the message was received.

    The vulnerability led to no real-world attacks because Miller reported it responsibly to Apple, who had an update out in time for Black Hat. Had the wrong people discovered it earlier the consequences would have been severe.

    To this day, the iPhone SMS hole remains one of the most eye-opening security vulnerabilities ever.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: Charlie Miller

    Caption by: Larry Seltzer

  • Adobe Acrobat & Reader. Now we fear PDFs.

    Adobe Acrobat & Reader. Now we fear PDFs.

    Adobe's PDF document format, long ago released as an open standard, has become one of those formats that you can assume everyone can read. Lots of software reads PDF files, but most people still use the Adobe Reader program to do it. In the mid-to late 00's, numerous vulnerabilities led to numerous exploits using numerous malicious PDFs to turn numerous Windows users into bots.

    There were two types of problems. First, PDF is a sufficiently complex format that it's hard to write a program that can process them without exploitable bugs. Second, over the years Adobe added many features to PDF, including JavaScript and embedded Flash objects, creating new "attack surface" in it.

    As with the Flash vulnerabilities of years gone by, none of the Acrobat/Reader vulnerabilities really stood out over the others. It was the steady parade of them and the consequent need for frequent updates that stands out.

    As with Flash vulnerabilities, Adobe has steadily hardened Reader and Acrobat so that vulnerabilities are fewer and less-severe.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: Security @ Adobe blog

    Caption by: Larry Seltzer

  • The other OpenSSL problem

    The other OpenSSL problem

    Ten to fifteen years ago, before there was awareness enough to create Heartbleed-level hysteria, some really horrible vulnerabilities in really important software would go relatively unnoticed.

    CVE-2002-0656 is one of a few remote code execution vulnerabilities from that era in Apache web servers and OpenSSL — yes, the same OpenSSL implicated in Heartbleed. It was found by well-known researcher Alexander Sotirov who demonstrated how to use it to gain a shell, meaning code execution capability, on Apache/OpenSSL web servers and a root shell on some servers.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Caption by: Larry Seltzer

  • billy gates why do you make this possible ?

    billy gates why do you make this possible ?

    Blaster, also known as MSblast, LovSAN and a few other names, was the first of a series of persistent worms using remotely-exploitable Windows vulnerabilities to spread. Microsoft first released the update for the vulnerability used by it in July of 2003 and everyone knew the race was on to create a worm with the flaw, a buffer overflow in the DCOM RPC procedures, a protocol for remote program calls over the network.

    Blaster appeared first in August. The Chinese authors of the A variant built it by reverse-engineering the Windows patch. The executable contained many inexplicable and taunting statements, such as the one pictured here. Blaster was buggy and frequently caused system shutdowns.

    Unusually for these things, the author of the B variant was caught. He was an 18 year old from Minnesota and he received an 18 month prison sentence.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: Wikipedia

    Caption by: Larry Seltzer

  • Sasser, the buggy botnet

    Sasser, the buggy botnet

    MS04-011 was one of those "uh-oh" Patch Tuesday releases. Experts looked at CAN-2003-0533 ("a Stack-based buffer overflow in certain Active Directory service functions in LSASRV.DLL of the Local Security Authority Subsystem Service (LSASS) in Microsoft Windows NT 4.0 SP6a, 2000 SP2 through SP4, XP SP1, Server 2003, NetMeeting, Windows 98, and Windows ME") and immediately knew a worm was on its way.

    Blaster had paved this trail months before and Sasser followed the script. By the end of the month that worm, Sasser, appeared on the scene. Sasser was also distinguished by its bugginess. It caused system shutdowns of the sort pictured here.

    Just as with Blaster, the author of Sasser, an 18 year-old German, was caught. Because he was a minor when he wrote it he was treated as one and received a suspended sentence.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Caption by: Larry Seltzer

  • Java applets, a rough grind

    Java applets, a rough grind

    Believe it or not, when Java first appeared almost 20 years ago, security was one of the main points of it. How far it has fallen!

    Java the language contains many features to make programming safer, but Java the environment for running those programs has proved buggy, leading to a large number of vulnerabilities and exploits, such as this one . After Adobe improved their security in Flash and Acrobat, Java became the leading target for malware writers seeking to exploit Windows and, on occasion, non-Windows users.

    As with Flash and Acrobat, no one Java vulnerability stands out, but there have been so many that Java itself is considered a problem on Windows PCs, and  many recommend that it be removed .

    In fairness to Java, it is basically the use of Java applets in browsers which have proven impossible to secure. Server-side Java is much more secure and successful.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Caption by: Larry Seltzer

  • Welchia: Just trying to help

    Welchia: Just trying to help

    Welchia is what they call a "helpful" worm. Instead of attacking, it attempts to download and install missing Windows security patches. What a great idea! What could possibly go wrong? go wrong? go wrong?

    Because of the way the worm spread and the way it did its updates, it caused traffic storms on company networks as systems all pulled updates and communicated at the same time. Removal was a manual business, costing IT departments lots of time.

    Welchia contains and displays many messages, including the ones displayed here, alluding to Japanese involvement in World War II.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Caption by: Larry Seltzer

  • Apache blows chunks

    Apache blows chunks

    Apache Chunked-Encoding Memory Corruption Vulnerability is another in a group of remote code execution vulnerabilities in the Apache server in the early part of the last decade. This one could be exploited merely by sending a carefully crafted invalid request, and the vulnerable code was turned on by default.

    This one was exploited in the wild leading to a particularly messy cleanup.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Caption by: Larry Seltzer

  • Shell game

    Shell game

    SSH is the UNIX Secure Shell, so you don't expect it to be a problem. Way back in early 2001 researcher Michal Zalewsky found a remote integer overflow in SSH and OpenSSH. The vulnerability allowed a remote attacker to take complete control of the shell.

    Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

    Photo by: Wikipedia

    Caption by: Larry Seltzer

14 of 15 NEXT PREV
  • 0
  • Heartbleed: Living the nightmare
  • SQL Slammer
  • The Morris Worm
  • Conficker: Still botting after all these years
  • Adobe Flash: Quick! Everyone update again!
  • IIS is a sitting duck
  • iPwn! Hack an iPhone with an SMS message
  • Adobe Acrobat & Reader. Now we fear PDFs.
  • The other OpenSSL problem
  • billy gates why do you make this possible ?
  • Sasser, the buggy botnet
  • Java applets, a rough grind
  • Welchia: Just trying to help
  • Apache blows chunks
  • Shell game

There have been some pretty bad vulnerabilities before Heartbleed. Is it really any more severe than CodeRed or Blaster?

Read More Read Less

Apache blows chunks

Apache Chunked-Encoding Memory Corruption Vulnerability is another in a group of remote code execution vulnerabilities in the Apache server in the early part of the last decade. This one could be exploited merely by sending a carefully crafted invalid request, and the vulnerable code was turned on by default.

This one was exploited in the wild leading to a particularly messy cleanup.

Published: April 11, 2014 -- 15:44 GMT (08:44 PDT)

Caption by: Larry Seltzer

Related Topics:

Security TV Data Management CXO Data Centers
  • 0
LOG IN TO COMMENT
  • My Profile
  • Log Out
| Community Guidelines

Join Discussion

Add Your Comment
Add Your Comment

Related Galleries

  • 17 internet-connected things that really shouldn't be online

    Security

    17 internet-connected things that really shouldn't be online

  • Smart home suites match up devices for security and convenience

    Security

    Smart home suites match up devices for security and convenience

  • Adjust these Facebook privacy settings to protect your personal data

    Social Enterprise

    Adjust these Facebook privacy settings to protect your personal data

  • Social media cannot be trusted without these features

    Social Enterprise

    Social media cannot be trusted without these features

ZDNet
Connect with us

© 2018 CBS Interactive. All rights reserved. Privacy Policy | Cookies | Ad Choice | Advertise | Terms of Use | Mobile User Agreement

  • Topics
  • All Authors
  • Galleries
  • Videos
  • Sponsored Narratives
  • About ZDNet
  • Meet The Team
  • Site Map
  • RSS Feeds
  • Reprint Policy
  • Manage | Log Out
  • Log In to ZDNET | Join ZDNet
  • Membership
  • Newsletters
  • Site Assistance
  • ZDNet Academy