Engineering Nightmare: Dependency Security Exploits! Moq???

Everyone hates talking about security. SOC2 is a 4 letter word around most companies. As startups and engineering teams, there is a newer kind of security exploit that everyone needs to be aware of: dependency and supply chain vulnerabilities.

Modern apps use dozens and potentially hundreds of dependencies, SDK, packages, or whatever you want to call them. Every programming language relies on packages for things like JSON parsing, unit testing, web servers, connecting to databases, and even ridiculous things like checking if numbers are odd.

Every one of those packages is an attack vector from a future would-be hacker.

In this article, I will cover a few instances that caused significant security concerns or exploits, including one from this week!

Moq Maintainer Goes Sponsored???

Just this week, a popular .NET mocking framework for unit testing, Moq, was updated with code that potentially tries to collect the email addresses of the developers. The lead developer also has a project called SponsorLink that I guess is supposed to help with support around sponsored projects on GitHub.

This is a big deal because Moq has been downloaded 476 million times. It gets downloaded 100,000 times a day. If someone slipped in some malicious code, just like SponsorLink, it could be a major security hole.

The uproar started over Moq due to this new dependency that was added that might try to college email addresses. SMH.

Strutting Your Java Stuff

Apache Struts is a popular Java EE web application framework. In 2017, a severe vulnerability was found in its file upload parser. This allowed attackers to execute arbitrary OGNL expressions, enabling remote code execution. The flaw stemmed from poor Content-Type header validation during file uploads.

Despite a quick patch release, many, including Equifax, delayed updating. This delay resulted in the Equifax breach, affecting 147 million individuals.

Logging Not 4 J

Log4j, a widely-used Java logging library, had a critical vulnerability named Log4Shell discovered in December 2021. This flaw related to JNDI references allowed remote code execution by attackers. Malicious actors could send strings making the library run external code, risking system compromise.

Due to Log4j's global use, the exploit's potential impact was massive. Organizations urgently acted to address the threat, with some likening its severity to Heartbleed. This highlighted the need for secure coding and regular software upkeep in tech.

The Bleeding SSL Heart

Heartbleed, discovered in April 2014, was a critical vulnerability in the OpenSSL cryptographic library used for SSL/TLS encryption. It resulted from a faulty "heartbeat" feature, causing memory leaks. Attackers could exploit this to access sensitive data like private keys and user credentials.

The revelation alarmed the online community as many servers were at risk. Organizations quickly worked to secure their systems. The incident highlighted the importance of rigorous open-source software security and remains a cautionary tale.

Burning in the Solar Winds

The SolarWinds attack in December 2020 was a major cyberespionage event where malicious actors compromised the Orion software, distributing a backdoor to thousands. This "SUNBURST" update let attackers access networks of U.S. agencies and major corporations.

Many believed a Russian intelligence agency was behind the precision attack. The breach exploited trust between software vendors and clients, prompting global security reevaluations. This incident highlighted supply chain vulnerabilities, stressing the need for enhanced security in software. Its impact still shapes cybersecurity discussions and strategies.

How do we Improve our Security Posture?

As startups and engineering leaders, what do we do about these potential types of exploits?

Update Dependencies Regularly

First off, it’s important to keep up with dependency updates. Over time a lot of security issues get identified and patched. If you don’t keep up with these updates, you leave yourself exposed.

Scan Your Code

You can use tools like Veracode that can scan your projects looking for packages that have known security flaws. These kinds of tools also do static code analysis looking for common bad practices in your code. Some can even be built into your CI/CD pipelines to really force these security checks.

Even docker container images can have security exploits baked into them!

Reduce Dependencies

One of the best things you can do to reduce your attack surface is to use fewer external packages. Granted, this can be hard to do. We don’t want to write our own versions of packages. Instead, we want to build on top of common open-source packages. For example, inventing your own JSON parser or web server would be silly.

It starts by periodically cleaning out the packages we have references to that we don’t really need. Or identifying where we have multiple packages to do the same task and we need to standardize. Most importantly, don’t use stupid packages like “is-odd” or “upper-case”. Amazingly, there are a lot of ridiculous packages out here.

Trusted Sources

When you add a new package to your project, how often do you think about who the author is? It is one thing to be using standard .NET packages from Microsoft, database drivers from Oracle or common packages for React or Angular. It is another to find arbitrary packages on GitHub and add them without any thought.

I would suggest always considering who the authors are of the packages and if you can trust them.

This also applies to 3rd party vendor software you install on your servers. Solar Winds was a very reputable and trustworthy company before its exploit happened. You can never predict what may occur, but you can reduce your exposure by being picky about what you allow on your servers.

Lock Versions & Review Changelogs

As much as we want to always update the package so we don’t get behind and we always get the latest security update, auto-updating packages are its own danger. The previous example of the .NET Moq package is an excellent example of this. If you didn’t do auto-updates, you wouldn’t have got the changed version. They have since reverted the controversial change. You would have missed the whole controversy.

Updating packages is time-consuming and a pain in the neck. However, if you want to maximize security and do a deep dive into what has changed in the packages, you should consider reviewing the detailed changelogs. Most projects keep good release notes about the changes they have made. This can also be important to understand if the behavior or compatibility of the package has changed.

Final Thoughts

Security is not something most engineering teams put a lot of focus on. However, it can also put a company out of business. It is always good to allocate some time for ongoing training of your team around various security best practices and simple things like the OWASP top ten.

In today's software environment, security is an ongoing challenge, particularly with the prevalent use of third-party tools and systems. Episodes like Heartbleed and the SolarWinds attack underline the repercussions of security oversights. While third-party packages speed up development, a proactive stance is essential. This includes regular updates, minimizing package use, and thorough code analysis.

Security is everyone's responsibility, from developers to IT teams. 

By fostering a culture of security and consistent learning, we can aim for efficient and secure software. In cybersecurity, being safe is as crucial as being fast.