Why DoS isn’t compromise – 5 Years of Real Penetration Test Data to Stand Behind

Verizon recently released their annual Data Breach Investigations Report (DBIR) which contains a list of “the top 10 vulnerabilities accounting for 85% of successful exploit
traffic”. As someone who makes their living actually breaking into organizations, I was interested in checking out the top 10 list. Such information, if it were accurate, could be a goldmine of useful information. After reviewing the list however, it instantly becomes clear that whoever put the list together did not run it by folks who actually break into systems and networks. With that being said, the purpose of this write-up is not to dig deeper into how grossly inaccurate and ridiculous the data behind the top 10 vulnerabilities is, as a number of smart folks have already done a good job of that, but rather to provide actual data (that I personally can stand behind and answer questions about) from real life penetration tests that I have at my disposal from years as an Offensive Security consultant.

So let’s get into it.

Let me first start out by stating that I am not a data scientist or a mathematician, nor do I claim to be. You won’t find any hardcore statistics here, no calculations, etc… If you are able to take this data, analyze it, and figure out how to solve security by using it, then by all means go forth (if you have any questions about specific pieces of data feel free to reach out). I am simply presenting this data as it makes sense to me as an attacker.

Drawing the line on Vulnerability Criteria

The data was taken from approximately 200 deliverables between 2011 to present day from my team’s engagements with clients in all verticals. Vulnerabilities selected to be presented here were done so using the following criteria:

• The vulnerability must have been a true positive (manual verification required)
• The vulnerability must have had significant impact (more about this shortly)
• The vulnerability must be from an external penetration test (no internal penetration test data is included here)

I should note that on the penetration tests we pulled this data from, we focus on depth rather than breadth (you’re probably better off performing less expensive vulnerability scans if you’re looking for breadth, though that’s a conversation for a different day).

How we defined Impact

When an organization decides whether or not to fix a vulnerability it usually comes down to the impact of the vulnerability to that organization; vulnerabilities we’re presenting here fell into the following impact categories:

• Authentication Bypass
• Internal Network Access
• Privilege Escalation
• Remote Command Execution
• Unauthorized Access to Data

A note about Unauthorized Access to Data: the data we’re referring to here is mission critical data. This generally falls into Electronic protected health information (ePHI), Personally Identifiable Information (PII), Credit Card data, Passwords, or Intellectual Property (IP) that an organization relies on such as trade secrets, source code, drilling locations, etc…

Some of these categories could be presented differently; however, this is what made the most sense to us. I could absolutely see the argument that many of these categories could ultimately lead to Unauthorized Access to Data (which most of the time is likely the end goal of an attacker),but we wanted to look at the impact directly resulting from exploitation of that specific instance of the vulnerability, or the impact of that vulnerability when it was part of a larger exploit chain (yes, we accounted for chained vulnerabilities where applicable! Let’s actually chat about those now).

C-C-C-C-Combo

What do we mean by chained vulnerabilities?  Exploiting a combination of two or more vulnerabilities in order to achieve higher impact. This can be the difference between getting Unauthorized Access to Data or getting full blown Remote Command Execution. A couple examples:

1. Default Credentials to MobileIron’s (MDM) admin interface (admin/mobileiron123) may lead to Unauthorized Access to Data, but combining it with a Command Injection vulnerability I found in the spanMonitor function’s snaplen parameter led to Remote Command Execution.
2. SQL Injection in an application may lead to Unauthorized Access to Data, but combining it with an application running with higher privileges (SQL User is SA) leads to Remote Command Execution through the ability to run xp_cmdshell.

These types of chaining are pretty much exactly how most attacking works. It’s just a series of steps (exploiting vulns) until you complete your objective.

Show me the money!

For those of you who might have trouble for one reason or another viewing this embedded Google Sheet on WordPress, here is a link directly to the sheet itself: Sanitized Real Vulnerability Data. I also plan on uploading the data to our Github for anyone who wants to grab it there.

So as you can see the data is fairly standardized when it comes to the Vulnerability Name and Vulnerability Impact. The reason we did that was so that analysis of the data would be a bit easier (as you can see from my fancy pivot tables).

The idea behind the authenticated column was essentially – did the attacker need initial credentials to perform the attack? This column was also affected by chaining vulnerabilities. Revisiting the first example of chained vulnerabilities above, the Command Injection in MobileIron would have required authentication; however, as default credentials were in use we considered the attack unauthenticated (hopefully the reason we did it this way makes sense).

With some of these vulnerabilities we thought it would be important to add a note with either a little more clarification around the vulnerability or how exactly the vulnerability made the cut. These reasons can be seen on row 12 (668f39e3-7c26-48f6-8d5e-45a7e4b67550) and row 53 (701bd22c-e252-4cbd-b7ac-c4fa2c9d8eab); these UUIDs in parenthesis will be talked about in the next paragraph. If anyone has any questions regarding any of the vulnerabilities here, feel free to reach out and I’ll update the notes accordingly.

Lastly, adding UUIDs to each of the vulnerability instances came to me while writing this post. I figured it would probably be good to have an identifier for each vulnerability instance in case the data ends up getting sorted differently so that I can map the vulnerability instance back to the actual report it was pulled from.

Interesting points of note

Now that we’ve seen the data, let’s take a look at our top 10 vulnerabilities that led to confirmed breaches:

1. SQL Injection – 38 Instances
2. Insecure Authorization – 23 Instances
3. Insecure Direct Object Reference – 15 Instances
4. Stored Cross-site Scripting – 13 Instances
5. Insecure Authentication – 9 Instances
6. Insecure Password Reset – 9 Instances
7. Guessed Password – 9 Instances
8. Default Credentials – 8 Instances
9. Single Factor Authentication – 8 Instances
10. Insecurely Configured Application Server – 6 Instances

This is exactly the type of data I figured I would see (as an attacker) when looking at the Verizon DBIR. But instead I learned two things:

• Verizon doesn’t care enough about the quality of their reports that they verify the data they put in them with people who actually exploit vulnerabilities to compromise systems and networks
• Whatever world Verizon is living in, DoS leads to compromise… somehow.

Anyway, back to the data. We can also take a look at the impact of these vulnerabilities (I won’t show all of them here, you have access to the pivot tables):

• SQL Injection – 38 Instances
  • Unauthorized Access to Data – 26 Instances
  • Remote Command Execution – 12 Instances

So we can see that SQL Injection leads to Unauthorized Access of Data (which isn’t too surprising), but more importantly that almost half of the time SQL Injection leads to Remote Command Execution because the database user is running with higher privileges than necessary.

Let’s switch over to the pivot table for Impact and look at what vulnerabilities directly lead to things like Remote Command Execution and Internal Network Access:

• Remote Command Execution – 51 Instances
  • SQL Injection – 12 Instances
  • Default Credentials – 6 Instances
  • Insecurely Configured Application Server – 6 Instances
  • Guessed Password – 5 Instances
  • Outdated Software – 5 Instances
  • SQL User is SA – 5 Instances
  • Single Factor Authentication – 3 Instances
  • Command Injection – 2 Instances
  • Insecure File Upload – 2 Instances
  • Public Credential Leakage – 2 Instances
  • Unsafe Deserialization – 2 Instances
  • Reflected Cross-site Scripting – 1 Instance

We’ll ignore SQL Injection as we spoke about that a couple minutes ago, but talk about a subset of other vulnerabilities that can lead to Remote Command Execution. Looking at the notes for the Insecure Configured Application Servers we see JBOSS and Axis2. Both of these Application Servers have a long history of being exploited by attackers, even in the wild.

Reflected Cross-site Scripting leading to Remote Command Execution? Without context you may be thinking this data may be inaccurate; however, looking at the notes section we see “Kiosk escape”. Thinking about it, it does actually make sense with that additional information. In this test we were in a scenario where we had access to a client’s kiosk in a public location. By finding a Reflected Cross-site Scripting vulnerability in the kiosk application itself we were able to open up an explorer Window and gain command execution on the host. Context is key.

• Internal Network Access – 11 Instances
  • Single Factor Authentication – 5 Instances
  • Guessed Password – 4 Instances
  • Default Credentials – 1 Instance
  • Public Credential Leakage – 1 Instance

You can probably already guess where I’m going with this, but I’m going to walk down this path anyway, talking about a subset of the vulnerabilities that can lead to Internal Network Access.

One of the most common recommendations we make to our clients is that multi-factor authentication should be used on external endpoints. This includes things like Outlook Web Access, Citrix, and VPN. Why do we recommend this? Because no matter how much security awareness training you provide, someone in your organization is going to choose a weak password.

But your password policy requires complexity (technical policy, not paper)? Do any of the following meet your  Spring2016, Spring2016!, or Password1! complexity requirements? The answer is most likely yes, and that’s what attackers are banking on. The sophistication level of an attacker does not have to be very high to guess these passwords. And if you only require multi-factor authentication on 4/5 Citrix portals on the Internet, guess which one that attacker is going to login to?

When I came up with the idea to put this data together I was pretty excited because it’s real data. I think our industry needs more real data that the folks who make it public will stand behind and answer to, not evade questions about. If they feel their data is important enough to put out there, shouldn’t they be comfortable standing behind it? If not, then they’re probably selling Snake Oil.

Moving forward

For the readers out there who do this work every day, I’m guessing you’re not surprised by this data, nor should you be (we certainly weren’t). But what (most of) you likely haven’t done is manually gone through years and years of reports, looked at each and every vulnerability for what it was and what the direct impact of it was, and put that data together. What I’m hoping for is that after reading through this write-up, I’ve piqued your interest; that while you were reading this write-up you said to yourself “Hmm… I wonder if our data lines up with this data”. It may or it may not, but I would certainly be interested in finding out. So I’m putting this out there to all of you that may be in a similar position as myself:

If you have access to exploited vulnerability data that shows direct breach impact and has gone through manual verification, sanitize it and make it available.

I’m not talking about 14,000 pages of internal vulnerability scan data; I’m not talking about gigabytes of IDS/IPS/Firewall logs; I’m talking about exploited vulnerability data that shows direct breach impact that you can stand behind and answer questions about.

If we can get a substantial amount of this data out in the public, I can only imagine that it’s going to benefit our industry. Perhaps then, people who are much smarter than myself at data analysis, can work with real and trusted data to come up interesting and meaningful solutions and statistics.

Lastly, I do plan on keeping this data updated as my team continues to perform these assessments. Most of the work was up front, going through the previous 200 or so reports, so it should only be easier moving forward and adding to the data set as we go.

Questions / Thoughts / Etc…

As I mentioned throughout the post, if you have any questions or comments about the data, perhaps you want to know more about a specific vulnerability based on it’s note, or if you think there is a better way of structuring the data, please do reach out! I’m available via most mediums:

• Twitter – @jstnkndy
• E-mail – justin.kennedy[at]nttcomsecurity.com
• E-mail – jstnkndy[at]gmail.com

Even if you just want to share war stories over a beer or coffee at the next conference, I could talk about this stuff all day 🙂

Comments are closed.