Software Vulnerability 101

January 31, 2019 Gabriel Avner

Software Vulnerability

Even as phishing and misconfigured cloud storage have yielded large troves of data for malicious actors, a good old fashioned software vulnerability is still the weapon of choice for hackers looking to make off with data that they can sell to the highest bidder on the darker corners of the internet.

These golden needles in a haystack have grown in importance as the role of software has taken center stage in everything from banking to dating to making your morning cup of joe. There is now more software being written than ever before by more developers, making for quite the soup of vulnerabilities to come along with them.

What’s more is that the needles are becoming more numerous. Reported software vulnerabilities have been on the rise in recent years, spiking drastically in 2017 to 14,714 from 6,447 the year before. Hardly a fluke, the CVE count increased steadily in 2018 and shows no sign of letting up.

However, before getting caught up in the numbers, we should be clear about what we are discussing here.

What Do We Mean By Software Vulnerability?

At its core, a software vulnerability is a mistake in a software component that leaves it open to exploitation by an adversary. In some cases, the coding error can be as basic as forgetting to close a parenthesis. Then there are those exploitations which can be found by an attacker who finds an alternative way to manipulate a given piece of code in ways that it was never intended.

These we can lovingly put into the “is it a bug or a feature” category.  

Since software is still primarily written by humans, we are faced with a mountain of software vulnerabilities that have have been written into our products, a situation that is unlikely to change in the years to come.

In thinking about software vulnerabilities, there are three primary factors that we need to consider our overall risk in our threat model.

Existence — Does a vulnerability exist in our software? As humans are still in the picture, we have to assume that there are.

Accessibility — Can a hacker reach this vulnerability in order to exploit said software vulnerability? If our application has been deployed, whether as a web app, mobile app, on a server or in some other available form, then the possibility needs to be accounted for.

Exploitability — What happens if the software vulnerability is exploited by the attacker? What happens right of boom? What are the repercussions and how bad will the damage be? Will our security precautions be enough to keep the ship from sinking?

Getting To Know Common Types Of Software Vulnerabilities

Thanks in part to lists like the OWASP Top 10, we are all familiar with SQL injection (SQLi) attacks that take advantage of poorly configured web forms, as well as buffer overflow and the like. While these can still be of concern, we are here to tell you that there are a whole lot of other kinds of vulnerabilities that can impact your products and data security.

The types of weaknesses in your software that can lead to an exploitation are wide and varied. We have compiled a quick breakdown of some of the most common software vulnerability types that your team should be keenly aware of and work to prevent.

1. CWE-119 —  Improper Restriction of Operations within the Bounds of a Memory Buffer

Description: The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.

2. CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Description: The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.

3. CWE-264 — Permissions, Privileges, and Access Controls

Description: Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.

4. CWE-20 Improper Input Validation

Description: The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.

5. CWE-200 — Information Exposure

Description: An information exposure is the intentional or unintentional disclosure of information to an actor that is not explicitly authorized to have access to that information.

These findings are based on WhiteSource’s data from tracking open source vulnerabilities. While every hacker — and more than a few government agencies — dream about finding that 0-day software vulnerability in Windows or iOS, we would argue that reported vulnerabilities, especially in the widely used open source basket of software, should be of far more concern.

Open source components comprise between 60-80% of the code base in modern applications. As reusable software components, a popular component can find itself in use by millions of developers in their products. Therefore when a critical vulnerability reported in a popular open source project, like say Apache Struts, it can be used to target a multitude of targets.

Your 5 Part Checklist for Handling Software Vulnerabilities

Software vulnerabilities are a fact of development life. However, there are a few steps that we can take to minimize the risk and potential damage that can be caused. Here are a few that you should consider.

1. Use application security testing tools for the code you write

Application Security Testing tools for proprietary code like Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Interactive Application Security Testing (IAST) can help your developers to catch potential mistakes in their coding before deployment.  

These technologies are still at the point where they are creating a fair amount of false positives, but they are a must for minimizing the risk to applications before they make it out the door.

2. Track Your Open Source Usage

When it comes to open source components, software vulnerabilities can often be hidden away in the dependencies that the component is built on. According to GitHub, over 75% of the projects on their platform have dependencies. Guarding against software vulnerabilities that can be stowed away in a dependency in one of these components can be difficult, especially if your team is working at scale.

Only Software Composition Analysis (SCA) tools can accurately identify which open source components are being used in your development, and alert to known vulnerabilities that are associated with them, including in the direct and transitive dependencies.

3. Segmentation

Dang, the attackers got past your defenses. Now is time for damage control. The first thing to think about is keeping them from getting to all of your data. Break up your data into various segments in a way that strikes a balance between usability and security. Sure it might be annoying to have to access different servers for parts of your organization, but it could pay off in the case that one of your servers is breached. Methodologies for micro-segmentation have gained ground in recent years for good reason.

4. Obfuscate, Obfuscate, Obfuscate!!!

If somehow a hacker was able to get past your defense and into your database, make sure that they are unable to make good use of their stolen booty. Nobody wants to have the proverbial egg on their face for having left user passwords in plaintext. We’ve seen those apologies and they are never pretty.

Encryption techniques have become standard for data security so that even if your customers’ data falls into the wrong hands, the thieves will have to work pretty hard to crack your safe. Avoid using outdated standards, meaning that MD5 is no longer up to the task and need to be updated.

5. Only Collect The Data You Need

This is a good rule for everyone. Holding on to large quantities of user data for possible marketing purposes or otherwise, can only serve to put your organization at increased risk, Regulation like GDPR are helping to lead the way toward better data management, but we should be getting smarter about this as an industry.

It is one thing if your server gets popped and basic necessary info like usernames and passwords are stolen. However, justifying why you were holding onto other bits of data like say social security numbers, addresses, etc that might not have been serving a purpose could put you in hot water.

Remember to minimize your risk with some well-deserved tidying up. Marie would be proud.

Previous Article
Top 5 New Open Source Vulnerabilities in January 2019
Top 5 New Open Source Vulnerabilities in January 2019

Next Article
Open Source Licenses Explained
Open Source Licenses Explained

Forrester Now Tech: Software Composition Analysis, Q1 2019

Download