Security operations · 5 MIN READ · AARON WALTON · OCT 28, 2024 · TAGS: MDR
TL;DR
This is a summary of what you’ll find in each blog in this series:
- Volume I: Q3 by the numbers
- Volume II: CAPTCHA trick or treat. We look at the rising fad of using CAPTCHAs and fake error messages to trick users into executing malicious code on their own devices.
- Volume III: Malware trends. Infostealer malware—specifically Lumma—is trending, so we discuss recommendations.
- Volume IV: Identity trends. Phishing-as-a-service (PhaaS) continues to rise in popularity; we offer recommendations to detect their use.
- Volume V: Spotlight—preparing for software supply chain risks. We look at risks that exist now (and into the future) that need addressed to ensure a secure software supply chain.
Last (but certainly not least) in our Q3 Quarterly Threat Report (QTR) blog series, we dig into potential supply chain risks.
Many of our customers are responsible for the software and infrastructure they use to run their business. In our review of cloud infrastructure incidents, we found that most incidents we see today are due to a misconfiguration or exposed API key or secret. While there are some attackers targeting cloud infrastructure specifically, we don’t see it as a trend yet. However, there are big risks we see looming on the horizon for software and cloud infrastructure in the supply chain we think are important to prepare for.
In this post, we’ll discuss some major risks that were identified by JFrog and Orca Security. Mitigating and monitoring the following risks is important to ensure the future security of our organizations, especially regarding supply chains.
Malicious packages
To reduce the work required to write programs, developers rely on libraries, packages, workflows, and containers that they didn’t write or build. However, this practice commits developers to validate and/or trust that those repositories are safe—and stay safe. Of course, there are multiple ways that threat actors can abuse this trust.
Revival hijacking
One way attackers can abuse this trust in packages is revival hijacking, discussed here by JFrog. Revival hijacking is when an attacker creates a repository with the same name as one that had been previously deleted by its developer. This is possible since some systems, like PyPI, the Python Package Index, don’t have controls to prevent the replacement of deleted repositories. This deletion and replacement becomes a risk when code bases depending on the original repository start to load the newly created repository without knowing.
This type of attack sounds hypothetical, but it isn’t. According to StableBuild, there are about 15,000 deleted PyPI repositories. While not all of these repositories are in high demand, JFrog proved in their own testing that some are, and many codebases still attempt to rely on these repositories. For example, JFrog created a new package in place of the previously deleted jaydebeapi3 repository, and observed 178,000 attempted downloads of the repository after their takeover.
What can we do?
First, we recommend maintaining a software bill of materials (SBOM) at a minimum. These can be created through manual or automated processes. Having a SBOM can help document and assess what software your organization relies on. That way, when supply chain incidents occur (such as the purchase of the PolyFill javascript Library or the XZ backdoor), your organization can readily understand whether your software is impacted. The USA’s National Telecommunications and Information Administration’s guidelines, The Minimum Elements for a Software Bill of Materials, can provide a lot more guidance on the how and why of maintaining SBOM.
Second, we recommend using tools that can assess the health of your software dependencies. Tools from companies like JFrog, Snyk, and others determine the level of risk associated with the dependencies used by your software, and identify malicious repositories that may have been included due to typosquatting, package revival, or AI package hallucination.
Finally, organizations and individuals should consider additional ways to contribute to the health of package managers that they rely on. PyPI, for example, has outstanding feature requests that could protect users from weaknesses like the revival hijacking attack, but the normal contributors lack the capacity to add some of these suggested features.
Wrong workflows
We mentioned that repositories are vulnerable to typosquatting, but there are other places typosquatting can occur, too. Typosquatting is when an attacker intentionally creates something with a misspelled name with the expectation that what they create will be mistaken for the real thing. We most often see typosquatting associated with websites, however, it happens frequently with software packages. Orca Security called attention to the fact that GitHub actions are vulnerable to typosquatting, too.
GitHub Actions are automation workflows that can be built into a GitHub repository. These actions are frequently used to help build, test, and deploy software all within GitHub. In Orca Security’s research, they observed multiple public repositories using misspelled GitHub Actions and created their own as proof of frequent typosquatting.
After creating some example workflows, they found that over time, organizations would accidentally use the typosquatting GitHub Actions. Without the typosquatting action, the mistyped workflow would have failed. But with it in place, the workflow completes successfully, and an organization may not notice anything is amiss. The attacker can then add malicious code to compromise victims using the wrong workflow.
Protecting workflows with commit hashes
We recommend using commit hashes to ensure that you’re using the right workflow. The commit hash can be copied from the workflow’s repository, and helps ensure that the intended workflow is run—whether you make a typo or not.
In our search, we found there wasn’t a clear guide on how to use commit hashes, so we’re going to cover it here.
GitHub Actions all have their own repositories under an organization, which is where you can find the commit hash. So for example, our workflow here uses the Github Action called actions/checkout. The image below shows the actions organization and checkout repository.
The commit hash can be found by clicking on commits at the top of the repository.
This takes you to a list of all of the commits. On the right side of the Commit details, it shows a part of the commit hash. The whole hash can be copied by clicking the button that looks like overlapping squares.
You can then paste the hash into your GitHub workflow’s yml file. Your yml file may have an instruction similar to this:
steps:
– uses: actions/checkout@v4
You’ll want to replace the version number “v4” with the commit hash, like this:
steps:
– uses: actions/checkout@6b42224f41ee5dfe5395e27c8b2746f1f9955030
This ensures that your workflow is running the specific version of the workflow that you’ve specified, not just based on spelling.
That’s a wrap on Q3!
As we continue through the last quarter of 2024, we’ll continue to share what we’re learning from trending issues in our SOC. October also marks the end of Cybersecurity Awareness Month, but that doesn’t mean the awareness and education have to stop.
It’s always a safe bet to continue improving your defensive strategies, maintain security best practices as a status quo, and to practice incident responses before they’re happening in real time. And bonus points if you use our learnings—shared quarterly in these reports, and across the blog—to help guide resilience strategies against the latest trending attacks.
And next up, our data from Q4 will be wrapped up in our Annual Threat Report for 2024, which will recap the entire year, and explore trends we’re expecting to see in 2025. Stay tuned for that, and we’ll continue to track data, identify patterns, and share insights as they emerge to keep you and your org protected.
Questions about this series or just want to chat? Give us a shout.
About these reports
The trends described in our QTRs are based on incidents our security operations center (SOC) identified through investigations, alerts, email submissions, or threat hunting leads in the third quarter (Q3) of 2024. We analyzed incidents across our customer base, which includes organizations of all sizes, in many industries, and with differing security maturity levels. In the process, we sought patterns and attacker tendencies to help guide strategic decision-making and operational processes for your team.
