The Three CVEs that You’re Not Paying Attention to (But Probably Should)

Michael Roytman    June 17, 2015

The Risk I/O philosophy is all about fixing what matters – that is, using data to make decisions that make the most of the limited actions you can take in a day, a week, a month. It’s not about the sheer volume of vulnerabilities that your team closes — it’s closing the ones that reduce your overall risk the most.

Sometimes, the vulnerabilities that get the most attention aren’t the ones that represent the greatest threat. In my research, I’ve discovered a series of vulnerabilities that aren’t sexy, and don’t hog the spotlight–but in many environments actually represent major weaknesses. In fact, these three vulnerabilities have each been exploited over 100,000 times in 2014 alone!

The vulns I want to highlight are CVE-2010-3055, CVE-2002-0649, and CVE-2000-1209. They don’t have cutesy publicized names, so it might be a bit boring to talk about them. But you know what? If other people get to put ridiculous code names on their vulns, then I get to do the same thing. So let’s take a look.

Vulnerability CVE-2010-30551 Poster. CVE-2010-3055 has been exploited 121,000 times in 2014. Let’s call it the Poster vulnerability. It allows attackers to run arbitrary code in phpmyadmin via a POST request, and phpmyadmin runs millions of sites worldwide. It’s a CVSS 7.5, which means it’s bound to fly under the radar more often than not. But it shouldn’t. Security teams need to start worrying about Poster!

Vulnerability CVE-200-12092. Slammer. I’m calling CVE-2002-0649 the Slammer vulnerability. It’s an ancient worm that exploits SQL Server 2000 and Microsoft Desktop Engine 2000. Reading the wikipedia article on the worm ( makes it seem like it’s a long forgotten problem, but we’ve seen 156,000 successful exploitations in 2014. It’s not new, it’s not hip, it’s not current, so one talks about it–but it’s a significant threat.

Vulnerability CVE-2002-06493. Enterprise. Last up is Enterprise, which exploits (1) Microsoft SQL Server 2000, (2) SQL Server 7.0, and (3) Data Engine (MSDE) 1.0, including third party packages that use these products such as (4) Tumbleweed Secure Mail (MMS) (5) Compaq Insight Manager, and (6) Visio 2000, and are exploited by the Voyager Alpha worm. CVE-2000-1209 is also not to be forgotten, with 272,000 successful exploitations. Resistance is futile?

To name something is to have power over it – but it’s the quiet ones that you need to be worried about. Pay less attention to the flashy, glitzy vulnerabilities and pay more to the ones that are truly a lurking threat.

3 thoughts on “The Three CVEs that You’re Not Paying Attention to (But Probably Should)

  1. Rory McCune

    Interesting stuff. Is there anywhere on your blog or elsewhere, where “successful exploitation” is defined from your perspective?

    That last one you quoted (CVE-2000-1209) is ‘sa’ with a blank password, which is exploitable over the SQL server port (for those versions typically 1433/TCP) (more information )

    According to shodan, there are only 157 instances of that port open on the Internet for all versions of SQL server (report, so 272,000 “successful exploitations seems… a bit high!

  2. Michael RoytmanMichael Roytman Post author

    Hey Rory,

    A successful exploitation here is one where an exploit was fired off against a vulnerability that was open and unmitigated at the time of the exploit.

    First, That 157 is a bit misleading for a few reasons – the actual number of installations of SQL Server is the wild is in the millions, but most are likely not exposed to the internet. Additionally, searching for the port in Shodan is not always reliable. As the creator of Shodan tweeted, this is a much more reliable measure of the number of vulnerable installations, even if some of them are newer versions:

    Second, It’s very hard to upgrade a database for technical reasons and migrations, but it’s even harder when there’s licensing fees for a new version included.

    Third, even Shodan’s higher end estimates only show off sql server installations which are _exposed to the internet_. It’s entirely possible to get popped off a local network or via an opened email with this vulnerability.

    Lastly, our system calculates exploitations _with replacement_ meaning multiple machines could have been hit multiple times.

    Hope this helps clear up the issue. Keep in mind the point of this post is not to worry about SQL slammer, it’s instead to shift the discussion towards “what constitutes a vulnerability one should worry about” – it’s certainly not a logo!

  3. Rory McCune

    So next question, where do these stats come from, and how would you confirm that it was unmitigated at the time where the attack was fired? I’d be a little surprised if this was gathered from endpoints as usually people savvy enough to deploy endpoint security mechanisms don’t leave one of the easiest to find canonical security issues for SQL server (‘sa’/blank) lying around.

    The reason I raised CVE-2000-1209 in specific is that this is a vulnerability that hasn’t existed in shipping versions of SQL server for a long time (IIRC SQL server 2005 was the first not to ship with sa and a blank password).

    Now remember that every version of SQL server vulnerable to this issue is out of support with Microsoft and has been since 2013 (, so we’re talking 272k people with out of support SQL server in a default configuration that every vulnerability scanner and hacker has been testing for since 2000 or earlier.

    Johns query for SQL server that you mention covers *every* version of SQL server, including all the ones that are not vulnerable to this issue by default, and even then there are 110k systems, which is less than half the number you’ve got as “successfully exploited”…

    I’m a security tester and if I rarely see ‘sa’/blank on Internal tests these days, and I don’t think I’ve seen it on an external ever in the last 3 years…

    What I’m getting at here is like the numbers from the DBIR that we chatted about earlier in the year, these are just soo far away from chiming with what I’ve seen from 15 years in security that I think you might want to look more at how you’re drawing conclusions from your data.

    I’d agree though serious issues aren’t necessarily related to what gets a logo 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *