4 Dangers of Using Components with Known Vulnerabilities

Do you know what’s in your software soup? It could be a bunch of open-source software, some unknown number of third-party libraries, and maybe one or more vulnerable components. Discover the risks and threats organizations may face relying on software with known vulnerabilities in a world where 81% of codebase contains at least one flaw

20,175. Do you know what it is? Nope, it isn’t a lucky lottery number or the price of a new car (those are often much higher now). As shown on the latest Skybox Research Lab report, it’s the total number of new vulnerabilities published in 2021. And if you have a look at the total number of vulnerabilities published annually in the last decade, you’ll notice that number has more than tripled, reaching a whopping 166,938 vulnerabilities published in 2021 alone.

Thanks to open-source software and third-party components, organizations are now able to develop complex and sophisticated applications at a fraction of historical costs — but there is a catch. With so many vulnerabilities piling up, and with applications becoming more and more like patchwork quilts of libraries and modules, the risk of inadvertently using vulnerable or outdated components is very real (and growing).

In this article, we’re going to explore why every organization must understand the dangers of using components with known vulnerabilities. We’ll also discover the four most common risks organizations could face using such software and have a look at the magnitude of damage that some related real-life cyber attacks have had on organizations.

The Consequences of Using Components With Known Vulnerabilities

What if I told you that a 15-year-old zero-day vulnerability, the CVE-2007-4559, has been found in 61% of 300,000+ unique files available on GitHub? Yup. Identified in 2007, based on a Trellix analysis, this Python tarfile module has been unintentionally included in hundreds of thousands of codes. Isn’t that a wonderful software supply chain playground for attackers?

Is this an example of a vulnerable component? Yes, it is. In fact, vulnerable components are all third-party software, libraries, and frameworks included in an application that are outdated, unpatched, or contain flaws already identified and published. You can find a whole list on trusted websites like:

• The National Institute of Standards and Technology (NIST)’s National Vulnerabilities Database.
• MITRE’s CVE list.

Now, it’s time to ask yourself whether your organization uses one or more vulnerable components. If it is, it may be at risk of cyberattacks. And the consequences of a successful attack can range from relatively minor to major disasters. Let’s have a look at some key examples:

• Data breaches. 83% of organizations suffered more than one data breach in 2021. Can you guess how much IBM said was the average cost of a breach? A cold $4.35 million. OK, maybe your small business won’t face such a huge bill, but as Eataly’s data breach showed, losses can still be significant even for small businesses.
• Lost sales and revenue. What if you have an online store and your website goes offline for a few hours? (I’m being optimistic here). Your customers won’t be able to place orders and make payments. No orders, no money — it’s as simple as that. Now, imagine that the breach lasts days or even a week. Do you think that owning a physical store will keep you safe? Wrong. In April 2022, The Works (a U.K. retail chain) had to close down stores as a cyber attack interrupted good deliveries, slowed down online order fulfillment, and compromised payments online and at its physical store locations. Thankfully, they were able to fix the issue relatively quickly, but lost time is still lost money and can result in reputational harm.
• Damaged reputation. Let’s say you’re looking to buy a new smartphone. You always stick with the same brand however this time you decided to be adventurous and check out different ones. Would you consider buying a model from a brand that has been a victim of a cyber attack? I guess the majority of you would say no. And when the organization’s reputation is tarnished, customers aren’t the only ones to be unimpressed. An affected business’s market value could drop by 25% even one year after an attack.
• Lost customer trust. On average, data from Okta shows that 75% of Americans wouldn’t purchase from a digital brand they don’t trust. In the digital era, where buying products from online stores has become an everyday activity, trust is crucial to every business’s success. Lose it once and it’ll take you ages (and a ton of money) to rebuild it.  
• GDPR and other privacy and security regulations liabilities. Do you know how much a fine for a single E.U. General Data Protection Regulation (GDPR) violation costs? Potentially €20 million or 4% of an organization’s annual revenue, whichever is greater. Google had a taste of it when it was fined €50 million by the French data protection authority. 

I guess this is enough to make any organization or business owner shiver, right? OK. Now that you know the consequences, it’s time to grab a drink, get cozy, and find out how deep this rabbit hole goes.

4 Dangers of Using Components With Known Vulnerabilities

As we’ve just seen, going into denial and completely ignoring the risks and threats of flawed components isn’t a good option. Want to minimize the risk of attacks? Awareness is your best defense. Let’s start with getting to know the four most common attacks. Ready? Let’s go!

1. Code Injection

Code injection is a category of cyber attack wherein cybercriminals inject malicious code into a vulnerable application or script. Once run, the code will compromise the security, functionality, and/or integrity of the application itself or of its database. How dangerous can a code injection attack be? Judge it by yourself:

• It’s the third most dangerous web application security vulnerability listed on the 2021 OWASP Top 10,
• One single type of code injection in particular, SQL (more on that in a minute), shows 10,571 identified vulnerabilities on MITRE’s CVE database.

Code Injection: A Real-Life Example

Do you remember the Panama Papers hack? In 2016, the Mossack Fonseca law firm, an offshore legal services provider, fell victim to a massive hacker attack. The attackers exploited several vulnerabilities, including outdated versions of WordPress, Drupal, PHP, and an obsolete secure socket layer (SSL) protocol and certificate. The attackers managed to expose 2.6 terabytes of data, including 11.6 million files from more than 214,000 offshore companies. In the end, the scale of the breach was so huge that in 2018 the law firm closed down for good.

How Did They Do It?

The cybercriminals used an SQL injection. This type of attack enables a cybercriminal to interfere with the database queries made by an application. Once the attacker finds a vulnerable component, they inject malicious code into an SQL query to return the information they want to access.

2. Code Execution

When an attacker finds a vulnerable component, they can exploit it to execute a series of commands on the targeted device. These arbitrary code execution (ACE) attacks enable cybercriminals to modify programs, open backdoors, or even use the affected device as a “zombie” computer (i.e., botnet drone) to attack other devices.

Code Execution: A Real-Life Example

In September 2017, Equifax, a well-known credit reporting agency announced it suffered a data breach of humongous proportions. The cybercriminals managed to access and steal the personal information of more than 140 million customers. CVE-2017-5638 was the entry point. This is an Apache Struts vulnerability that was discovered in March of the same year that Equifax’s IT department forgot to patch. Yup. Missing an important patch happens to big corporations, too, not only to John Doe’s small business. And as you can see, the consequences of something as simple as forgetting to apply an update can be devastating.

How Did They Do It?

This time they used a remote code execution (RCE), one of the most dangerous types of ACE attacks. The bad guy exploits a vulnerability (e.g., improper input validation) to run remotely executed commands on a device. To give you an example, after an attacker succeeds to modify a vulnerable application’s command, the attacker can execute it undisturbed. As a result, they’ll take control over the compromised device without having physical access.

How dangerous is it? Well, I guess you already got the picture. If that wasn’t enough, though, just remember that remote code executions have been used in other famous exploits like the WannaCry ransomware attack and Log4J-based attacks.

3. Buffer Overflow

Buffer overflow is one of the oldest vulnerabilities and it’s listed in SAN’s top 25 most dangerous software errors. It happens when a program writing data overruns its buffer capacity. Thus, the original data gets overwritten or corrupted.

It’s a bit like when you pour two liters of your favorite beer into a one-liter jug. What happens? As there isn’t enough space, the beer will end up on the table (and maybe even the floor). What a waste! Don’t worry, though, as you’ll discover in the example below, attackers don’t let anything go to waste.

Buffer Overflow: A Real-Life Example

In January 2021, Apple released a new iOS version including patches for not one, but three newly identified vulnerabilities: two in Safari’s browser engine and one in the kernel, the core of iPads and iPhones operating system. All of them were being actively exploited by cybercriminals giving them full access to data and devices. Apple has never revealed how many customers have been effectively hacked, but this just shows once again that it doesn’t matter how big or small your organization is… everyone can fall to the dangers of an attack when using components with known vulnerabilities.

How Did They Do It?

How did attackers manage to breach into Apple devices when 49% of interviewed Android users consider switching to Apple because the brand’s devices are perceived as being more secure? They used a buffer overflow attack. Let me give you an example. Say, your organization’s website uses OpenSSL, an open-source library to implement the SSL and transport layer security (TLS) protocols. Unfortunately, you’re leaving the door open to hackers if you forget to patch OpenSSL against the Heartbleed bug (CVE-2014-0160).

During a TLS-encrypted handshake, the attacker sends a heartbeat request with a length field value higher than the payload (i.e., the information sent to or received by a server). However, the unpatched OpenSSL doesn’t verify if the payload exceeds the allocated buffer size. Then the server automatically copies extra data from the memory to reply with exactly the same length field value of the request. What’s included in that extra data, though? It depends on how unlucky you are. It could be anything that was stored in the memory: session tokens, usernames, passwords — you name it. It could even include the website security certificates’ secret keys that are used to decrypt the server’s secure communication. This is a significant disaster that affected — and still affects — hundreds of thousands (if not more) of servers and systems.

Still confused about buffer overflow attacks? Let’s have a look at the example illustration below:

4. Cross-Site Scripting (XSS)

Cross-site scripting attacks are another form of code injection. The attacker injects malicious scripts into a vulnerable code of a legitimate website. Once the users access the website and the script is executed, the cybercriminal can:

• Redirect the users to a phony website,
• Record the users’ keystrokes and send them to the attacker, or
• Get the logged-in users’ cookies information.

All this with just a small change to a vulnerable code. Isn’t that amazing?

Cross-Site Scripting: A Real-Life Example

In 2018, British Airways was the victim of a data breach that impacted roughly 500,000 customers. The attackers managed to get hold of customers’ names, email addresses, and card details due to an XSS vulnerability in Feedify, a JavaScript library used by the company’s website. How did it all end? RISKIQ researchers found the bug and British Airways fixed it, but the airline was fined a record $25 million. What made it even worse for the air carrier? The organization also had to pay compensation to the customers affected by the breach.

How Did They Do It?

The attackers used a simple XSS attack by exploiting a vulnerable component on British Airways’ website. How? By modifying a script in a way that when the customers clicked on a submission button, they were redirected to a phony domain controlled by the hackers. The bad guys managed to do everything by injecting a mere 22 lines of code. They even bought an SSL certificate to make the page look as if it was safe.

How Can You Address the Dangers of Using Components with Known Vulnerabilities?

In an ideal world, the best answer would be “don’t use them.” But we all know that in today’s digital world, it’s virtually impossible. Even if 47% of security leaders interviewed by Ponemon reported having a backlog of vulnerable applications? Yes. And even 66% of them confirmed that their backlog amounted to 100,000 vulnerabilities. What are the alternatives then?

• Prioritize and automate. How? Implementing a secure software development lifecycle (SDLC) process. Security is integrated into all steps of the development process right from the beginning, thanks to automation.
• Use software composition analysis (SCA). A collection of automated tools that’ll enable you to identify and track third-party software and vulnerabilities by also compiling a software bill of materials (SBOM). Do you want to know more? Check OWASP’s component analysis page.
• Set out a patch management process. How will you keep your components up to date? How will you address a vulnerability once detected? These are a few examples of questions that your patch management procedures and policy should answer.
• Monitor your applications. Continually test and monitor applications and vulnerability lists. How? For example, a web application firewall (WAF) can help you identify and filter suspicious traffic. Subscribing to trusted vulnerability database bulletins — such as the ones offered by the Cybersecurity and Infrastructure Security Agency (CISA) or MITRE — will ensure you won’t miss any newly published vulnerabilities.  
• Streamline your applications. Sometimes, less is more, and that’s true of application usage, too. Are you sure your applications are only using the components you really need? It’ll help you limit the number of potential vulnerabilities and reduce the number of dangerous dependencies.

Final Thoughts on Four Dangers of Using Components with Known Vulnerabilities

There you have it. We hope you’ve learned something new and realized that staying on top of components vulnerabilities isn’t easy, even for big and well-known corporations. Incidents happen, but they can be avoided or their impact can be minimized if you’re prepared and know what you’re up against.

What about you? Is your organization using components with known vulnerabilities? As you have learned, one vulnerable component is enough to put your whole organization in danger of data breaches and attacks. And when the worst happens, it can cost you dearly both financially and reputationally.

Code injection, buffer overflows — you name it. Once a vulnerability is discovered and published, the bad guys will be actively working to exploit it before everyone applies patches. That’s why it’s paramount for organizations to fully understand the risks of using components with known vulnerabilities.

The solution?

• Use only the strictly necessary components.
• Make sure that they’re coming from trusted sources.
• Keep them up to date and patched at all times by following CISA’s guidance (e.g., prioritizing patching known exploited vulnerabilities and replacing end-of-life software).

The digital world is a dangerous one. Don’t make it worst by using vulnerable components.