Squatting and software supply chain security

02/02/2023

In this lesson, Mortimer du Fence dives into typosquatting, an attack in which malicious actors will copy and slightly misspell the names of legitimate software packages. As a result of the speed of DevOps and human error, these typosquatted packages get downloaded, causing software supply chain attacks.

Keep learning• Related ReversingGlass: DNA of an app
• Special: The State of Supply Chain Security
• See the Forrester SCA Landscape Report

left;”>Lazarus also attempted to evade detection by changing file names before deleting them, as well as modifying timestamps using timestomping, an anti-forensic technique. This latest attack also allowed the hacking group to deliver multiple backdoor payloads designed to connect to a remote command-and-control (C2) server, allowing Lazarus to retrieve additional binaries and execute them in a fileless manner.  According to ASEC, Lazarus is a capable threat actor that continually researches software vulnerabilities and changes their TTPs (Techniques, Tactics and Procedures). They do this by “altering the way they disable security products and carry out anti-forensic techniques,” allowing the group to interfere with or delay any detection and analysis. Based on the hacking group’s willingness to exploit new vulnerabilities, it’s likely that they could carry out more attacks in South Korea and elsewhere. <h3 style=”text-align: left; font-weight: bold;”>News Roundup</h3> Here are the stories we’re paying attention to this week…  <h2 style=”text-align: left;”><a href=”https://www.csoonline.com/article/3689892/hard-coded-secrets-up-67-as-secrets-sprawl-threatens-software-supply-chain.html”>Hard-coded secrets are up 67% as secrets sprawl threatens software supply chain</a> (CSO)</h2> According to GitGuardian’s State of Secrets Sprawl 2023 report, the number of detected hard-coded secrets increased by 67% last year compared to 2021, with 10 million new secrets discovered in public GitHub commits in 2022.  <h2 style=”text-align: left; font-weight: bold;”><a href=”https://cyberscoop.com/israel-technion-hack-muddy-water-iran-mois/”>Israel blames prolific Iranian-linked hacking group for February university hack</a> (Cyberscoop)</h2> A prolific hacking group known as MuddyWater, which is affiliated with the Iranian government, is responsible for the Feb. 11 cyberattack on Technion University in Israel, the Israeli government said this past Tuesday. <h2 style=”text-align: left; font-weight: bold;”><a href=”https://www.bleepingcomputer.com/news/security/emotet-malware-attacks-return-after-three-month-break/”>Emotet malware attacks return after three-month hiatus</a> (BleepingComputer)</h2> Emotet is a notorious malware distributed through email containing malicious Microsoft Word and Excel document attachments. When users open these documents and macros are enabled, the Emotet DLL will be downloaded and loaded into memory. <h2 style=”text-align: left; font-weight: bold;”><a href=”https://www.theguardian.com/technology/2023/mar/08/darktrace-warns-of-rise-in-ai-enhanced-scams-since-chatgpt-release”>Darktrace warns of rise in AI-enhanced scams since ChatGPT release</a> (The Guardian)</h2> The cybersecurity firm Darktrace has warned that since the release of ChatGPT it has seen an increase in criminals using artificial intelligence to create more sophisticated scams to con employees and hack into businesses. <h2 style=”text-align: left; font-weight: bold;”><a href=”https://www.bleepingcomputer.com/news/security/new-tpm-20-flaws-could-let-hackers-steal-cryptographic-keys/”>New TPM 2.0 flaws could let hackers steal cryptographic keys</a> (BleepingComputer)</h2> The Trusted Platform Module (TPM) 2.0 specification is affected by two buffer overflow vulnerabilities that could allow attackers to access or overwrite sensitive data, such as cryptographic keys. <img src=”https://track.hubspot.com/__ptq.gif?a=3375217&k=14&r=https%3A%2F%2Fwww.reversinglabs.com%2Fblog%2Fthe-week-in-security-hackers-attacked-the-same-south-korean-entity-twice-hard-coded-secrets-are-up&bu=https%253A%252F%252Fwww.reversinglabs.com%252Fblog&bvt=rss” alt=”” width=”1″ height=”1″ style=”min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important; “></content:encoded>

<category>Security Operations</category>

<category>The Week in Security</category>

<author>carolynn.vanarsdale@reversinglabs.com (Carolynn van Arsdale)</author>

<guid>https://www.reversinglabs.com/blog/the-week-in-security-hackers-attacked-the-same-south-korean-entity-twice-hard-coded-secrets-are-up</guid>

<dc:date>2023-03-09T18:09:30Z</dc:date>

</item>

<item>

<title>PyPI repo poisoned with “Colour-Blind” RAT</title>

<description><div class=”hs-featured-image-wrapper”> <a href=”https://www.reversinglabs.com/blog/pypi-repo-poisoned-with-colour-blind-rat” title=”” class=”hs-featured-image-link”> <img src=”https://www.reversinglabs.com/hubfs/remote-access-trojan-rat-colour-blind.jpg” alt=”PyPI repository poisoned with "Colour-Blind" RAT” class=”hs-featured-image” style=”width:auto !important; max-width:50%; float:left; margin:0 15px 15px 0;”> </a> </div> Malicious actors are increasingly dropping malware packages into open-source software repositories in the hope that developers will spread that malicious code throughout their applications. The latest case in point: Kroll’s recent discovery of a full-featured information stealer and remote access trojan (RAT) into the Python Package Index (PyPI).</description>

<content:encoded><img src=”https://www.reversinglabs.com/hs-fs/hubfs/remote-access-trojan-rat-colour-blind.jpg?width=1400&height=732&name=remote-access-trojan-rat-colour-blind.jpg” alt=”remote-access-trojan-rat-colour-blind” width=”1400″ height=”732″ style=”height: auto; max-width: 100%; width: 1400px;”> Malicious actors are increasingly dropping malware packages into open-source software repositories in the hope that developers will spread that malicious code throughout their applications. The latest case in point: Kroll’s recent discovery of a full-featured information stealer and remote access trojan (RAT) into the Python Package Index (PyPI). Kroll, a risk and financial advisory company, unearthed the malware, which it dubbed Colour-Blind, through a tool it developed to gather more information about initial attack vectors. Colour-Blind shows how easily hackers can write the common functions of malware into a modern language, such as Python, <a href=”https://www.kroll.com/en/insights/publications/cyber/pypi-packages-deliver-python-remote-access-tools”>Kroll researchers Dave Truman and George Glass asserted in a company blog</a>. It is, they said, a harbinger of rising software supply chain risk.  <blockquote> ”This malware also provides insights into how the democratization of cybercrime could lead to an intensified threat landscape, as multiple variants can be spawned from code sourced from others.” —<a href=”https://www.kroll.com/en/insights/publications/cyber/pypi-packages-deliver-python-remote-access-tools”>Dave Truman and George Glass</a> </blockquote> Cybercriminals have been refining their business models for some time, simplifying what it takes to be a threat actor through crime-as-a-service offerings on the dark web, said Mike Parkin, a senior technical engineer at Vulcan Cyber. Brokers can mix and match attack components to meet a client’s specific needs, ”Only the clients here are cybercriminals who are looking to attack a specific sector, target, or region,” he said. Threat actors are always looking for new attack vectors, vulnerabilities, and techniques to reach their goals, Parkin added. Whether those actors are criminal gangs or state-sponsored threats, the attacks will be against whatever threat surface is weakest at the time, he said. <blockquote> ”Here, it’s code repositories. When those holes are closed, the attackers will find new ones.” —<a href=”https://www.linkedin.com/in/mike-parkin-5a7921/”>Mike Parkin</a> </blockquote> Here’s what you need to know about the Colour-Blind RAT, with insights and takeaways from supply chain security experts. <h2>Colour-Blind: Similar to W4SP stealer</h2> The functions and techniques deployed by the Colour-Blind RAT are similar to those found in a rash of malicious PyPI packages that <a href=”https://www.reversinglabs.com/blog/w4sp-continues-to-nest-in-pypi-same-supply-chain-attack-different-distribution-method”>Phylum, Checkmarx and ReversingLabs</a> <a href=”https://www.reversinglabs.com/blog/w4sp-continues-to-nest-in-pypi-same-supply-chain-attack-different-distribution-method”>discovered in November, 2022</a>. At the time, those infected packages were spreading the W4SP Stealer malware. Over the last few months, almost every piece of malware injected into the PyPI was attempting to steal cookies, passwords, tokens, and wallets, but a distinguishing feature of W4SP is its use of Flask, Cloudflare’s reverse tunnels and transfer.sh for data exfiltration by the threat actors linked to the malware. The similarities between Colour-Blind and W4SP seem too big to be a coincidence,  said ReversingLabs security researcher Karlo Zanki. <blockquote> ”Even the quite specific usage of Visual Basic script to acquire persistence, which is not commonly seen in Python malware, has been observed in both cases. The obfuscation strings containing 0-s and O-s, while not so uncommon, have also already been seen in the previous malware samples related to the W4SP group.” —<a href=”https://www.linkedin.com/in/karlo-zanki-b8a2341a5/”>Karlo Zanki</a> </blockquote> <h2>Frankenstein theory debunked</h2> The Colour-Blind malware was a kind of “Frankenstein” application cobbled together from a variety of other programs, Kroll researchers concluded. Some parts of the software were blatantly malicious, such as a function that attempted to avoid antivirus detection by adding the malware’s file location to the exclusion path for Microsoft Defender. Other parts of the code contained weak attempts at obfuscation. Zanki is skeptical of the Frankenstein theory, however. <blockquote> ”Even though the W4SP group usually open-sources their malware, they are also maintaining a private malware collection. The earliest malware package from our research was published by none other than billythegoat356 — a member of the W4SP group.” —Karlo Zanki </blockquote> Colour-Blind’s direct relation to the mentioned group doesn’t exist, Zanki said. While there remains a possibility that a new actor created this malware by gluing together various malware pieces, “I am more inclined to the theory that this is the work of the W4SP crew,” he said.   <h2>Mind your open source package use</h2> Organizations should be careful when using open-source software packages, Zanki said. He recommends security mechanisms for monitoring third-party dependencies, and security assessments for every software package in use or under development. The order of those is assessments is also key, and should be performed before a package is tested. “A lot of malicious packages execute their functionality upon installation,” he said. Application security teams should also be aware of the larger trend of supply chain attacks moving up the chain to development teams, as reported in <a href=”https://www.reversinglabs.com/the-state-of-software-supply-chain-security”>ReversingLabs’ State of Software Supply Chain Security</a>. <blockquote> ”Packages often target developers, not necessarily end-users of software. If you don’t possess adequate skills to perform such security assessments, use dedicated security tools.” —Karlo Zanki </blockquote> <h2 style=”font-weight: bold;”>Lessons from recent supply chain attacks</h2> Malicious actors are continuously improving their techniques and skills — and they won’t stop, Zanki said. Threat actors always like to achieve their goals with the least amount of work necessary, and that makes the supply chain an attractive target, Parkin added. <blockquote> ”If an attacker can get their malicious code into a well-known repository, and somehow get people to use it, they’re bypassing several steps in the attack chain by having the target do a large part of the work for them.” —Mike Parkin </blockquote> The increase in supply chain attacks, driven by the potentially high value data at stake, such as secrets in the recent <a href=”https://www.reversinglabs.com/blog/secrets-exposed-modern-development-open-source-repositories-expose-secrets-en-masse”>CircleCI hack</a>, is concerning. But the automation of attacks is even more worrying, Zanki said. <blockquote> ”The list of the sensitive data attackers aim to steal is continuously expanding. There aren’t too many security mechanisms preventing them from publishing to public software repositories, and the latest campaigns, which contain a large number of packages, suggest that the malware is getting published in an automated way.” —Karlo Zanki </blockquote> <img src=”https://track.hubspot.com/__ptq.gif?a=3375217&k=14&r=https%3A%2F%2Fwww.reversinglabs.com%2Fblog%2Fpypi-repo-poisoned-with-colour-blind-rat&bu=https%253A%252F%252Fwww.reversinglabs.com%252Fblog&bvt=rss” alt=”” width=”1″ height=”1″ style=”min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important; “></content:encoded>

<category>Threat Research</category>

<category>Software Supply Chain Security</category>

<author>jpmellojr@gmail.com (John P. Mello Jr.)</author>

<guid>https://www.reversinglabs.com/blog/pypi-repo-poisoned-with-colour-blind-rat</guid>

<dc:date>2023-03-09T16:31:13Z</dc:date>

</item>

<item>

<title>Why software transparency is critical: Understanding supply chain security in a software-driven society</title>

<description><div class=”hs-featured-image-wrapper”> <a href=”https://www.reversinglabs.com/blog/why-software-transparency-is-critical-understanding-supply-chain-security-in-a-software-driven-society” title=”” class=”hs-featured-image-link”> <img src=”https://www.reversinglabs.com/hubfs/software-trasnparency.jpg” alt=”Why software transparency is critical: Understanding supply chain security in a software-driven society” class=”hs-featured-image” style=”width:auto !important; max-width:50%; float:left; margin:0 15px 15px 0;”> </a> </div> By now the topic of software supply chain security is clearly among the most discussed topics in the IT/Cybersecurity industry. We know from reports from groups such as Sonatype that software supply chain attacks are up 742% over the last 3 years, and we have seen incidents hit everything <a href=”https://www.reversinglabs.com/the-state-of-software-supply-chain-security”>from proprietary software vendors to open-source software (OSS) projects and components</a>, impacting thousands of customers and millions of users around the world. </description>

<content:encoded><img src=”https://www.reversinglabs.com/hs-fs/hubfs/software-trasnparency.jpg?width=1400&height=732&name=software-trasnparency.jpg” alt=”software-trasnparency” width=”1400″ height=”732″ style=”height: auto; max-width: 100%; width: 1400px;”> By now the topic of software supply chain security is clearly among the most discussed topics in the IT/Cybersecurity industry. We know from reports from groups such as Sonatype that software supply chain attacks are up 742% over the last 3 years, and we have seen incidents hit everything <a href=”https://www.reversinglabs.com/the-state-of-software-supply-chain-security”>from proprietary software vendors to open-source software (OSS) projects and components</a>, impacting thousands of customers and millions of users around the world. This is why along with my co-author Tony Turner, we decided to write <a href=”https://www.amazon.com/dp/1394158483?ref_=cm_sw_r_cp_ud_dp_PHSFCKCRM7Q8KZ41RDXT”>“Software Transparency: Supply Chain Security in an Era of a Software-Driven Society”</a> with the publisher Wiley. Our technical editor is CycloneDX and Dependency Track founder/creator <a href=”https://www.linkedin.com/in/stevespringett/”>Steve Springett</a> from OWASP, and our Foreword is written by <a href=”https://www.linkedin.com/in/allanafriedman/”>Dr. Allan Friedman</a>, who has spearheaded Software Bill of Materials (SBOM efforts), first for the NTIA and now CISA. <a href=”https://www.amazon.com/dp/1394158483?ref_=cm_sw_r_cp_ud_dp_PHSFCKCRM7Q8KZ41RDXT”>The book (available now for pre-order)</a> is set to be published in June of 2023. Here’s an overview, with walk-throughs on each chapter, explaining what we cover and what readers will learn. <h2>Chapter 1: Background on software supply chain attacks</h2> In this initial chapter of the book we cover various topics such as the incentives for attackers, anatomy of hypothetical software supply chain attack as well as threat modeling to mitigate the risk of software supply chain attacks. We also cover various landmark cases that have impacted proprietary software vendors, open source software (OSS) components and managed service providers (MSP)’s. <h2>Chapter 2: Existing approaches to supply chain risk management </h2> Following the initial chapter of the book we take a look at the traditional approaches to vendor and supply chain risk management. This includes covering various application security maturity models, application security assurance testing methodologies and tooling as well as approaches to hashing and code signing. <h2>Chapter 3: Vulnerability databases and scoring methodologies</h2> This chapter provides a detailed and comprehensive overview of the vulnerability database ecosystem. We discuss some of the longstanding vulnerability databases and their origins, as well as emerging databases that address some of the existing gaps. We also take a deep dive into vulnerability scoring, metrics and exploit prediction.   <h2>Chapter 4: Rise of the Software Bill of Materials (SBOM) </h2> If you’ve been paying any attention to the software supply chain conversation, you’ve inevitably heard the term “SBOM”. This chapter is dedicated to providing an overview of the origin story of SBOM, from sources such as NTIA and CISA among others, as well as detailed breakdowns of the various SBOM formats. We also discuss the emergence of efforts such as Vulnerability Disclosure Programs and Reports, as well as Vulnerability Exploitability eXchange (VEX), which aims to provide context to SBOM’s to make them actionable for software consumers. <h2>Chapter 5: Challenges in software transparency </h2> One thing that is certain is that the path to software transparency is complex and challenging. In this chapter we discuss concepts such as firmware and embedded software as well as the OSS ecosystem. We also discuss user and legacy software and the challenges around secure transport of software, data and artifacts. <h2>Chapter 6: The cloud and containerization of software</h2> Software transparency on-premise and in the cloud look much different, each with their own unique considerations. In this chapter we cover cloud computing, different service models, complexity as well as the emergence and growth of Containers, Kubernetes and Serverless. We also discuss challenges associated with Software-as-a-Service (SaaS) and the continued adoption of DevSecOps.   <h2>Chapter 7: Existing and emerging supply chain guidance</h2> Software supply chain security is a complicated topic. Luckily we are seeing a tremendous amount of emerging guidance, resources and best practices. This chapter is focused on covering guidance from sources such as NIST, Google, CIS, Microsoft, OWASP and others, culminating in the most comprehensive coverage of existing guidance on the topic anywhere in the industry.   <h2>Chapter 8: Software transparency in operational technology </h2> Software transparency in IT is often the primary point of conversation around software supply chain security, that said Operational Technology (OT) doesn’t get sufficient attention. This chapter focuses on the potential kinetic effects of software, legacy software risks and also software transparency considerations and risks for industrial control systems (ICS). <h2>Chapter 9: Practical guidance for software suppliers</h2> Software supply chain risks most often originate through suppliers. Hence why this chapter is dedicated to providing practical guidance to software suppliers when it comes to transparency and supply chain security. Topics include vulnerability disclosure and response, product security teams, copyright concerns, the use of OSS and where and how to leverage automation. <h2>Chapter 10: Practical guidance for software consumers </h2> While suppliers are in the best position to address risks, it is often the consumers who bear the brunt of security incidents and data breaches. This chapter provides comprehensive guidance to software consumers on how to mitigate their risks of being impacted by software supply chain attacks. This includes guidance around the use of SBOM’s, VEX and vulnerability disclosures, understanding their software supply chain and suppliers, and the role that activities such as virtual patching play in some scenarios.  <h2>Chapter 11: Top software transparency predictions </h2> While attempting to predict the future is futile, we do our best to take a look at the direction the industry and society is headed and what we may be able to anticipate moving forward. This includes detailed coverage of emerging regulations and requirements, the power of Governments to affect markets, the acceleration of supply chain attacks and risks associated with our ever increasingly connected societies. Coverage includes efforts in the U.S. such as the Cyber Executive Order (EO) and National Cyber Strategy, as well as efforts from the EU, UK and others around the world. All of these efforts are aimed at addressing the systemic risk we now face as a society due to the pervasive nature of software in nearly every aspect of our lives. <h2 style=”font-weight: bold;”>Moving forward on supply chain security</h2> It is clear that <a href=”https://www.reversinglabs.com/blog/the-state-of-software-supply-chain-security”>the trend of software supply chain attacks is only accelerating</a> as malicious actors realize the value of compromising a single target, whether a proprietary software vendor, OSS component or service provider and have a massive cascading downstream impact. This reality requires <a href=”https://www.reversinglabs.com/blog/end-to-end-supply-chain-security-requires-dev-teams-and-the-soc-shift-left-together”>further collaboration between development, security and operations</a> — along with a whole industry effort to adopt modernized software supply chain practices and tooling, which we touch on throughout the book. Given the ubiquity of software in every area of society, coupled with the complex interdependencies of the modern software supply chain, it is what many refer to as a Gordian knot of a challenge that presents unprecedented levels of systemic risk. <img src=”https://track.hubspot.com/__ptq.gif?a=3375217&k=14&r=https%3A%2F%2Fwww.reversinglabs.com%2Fblog%2Fwhy-software-transparency-is-critical-understanding-supply-chain-security-in-a-software-driven-society&bu=https%253A%252F%252Fwww.reversinglabs.com%252Fblog&bvt=rss” alt=”” width=”1″ height=”1″ style=”min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important; “></content:encoded>

<category>Software Supply Chain Security</category>

<author>chris.hughes@aquia.us (Chris Hughes)</author>

<guid>https://www.reversinglabs.com/blog/why-software-transparency-is-critical-understanding-supply-chain-security-in-a-software-driven-society</guid>

<dc:date>2023-03-08T19:26:06Z</dc:date>

</item>

<item>

<title>App sec is addicted to vulnerability reporting: Why supply chain security requires evolution</title>

<description><div class=”hs-featured-image-wrapper”> <a href=”https://www.reversinglabs.com/blog/app-sec-is-addicted-to-vulnerabilities-why-software-supply-chain-attacks-demand-modernization” title=”” class=”hs-featured-image-link”> <img src=”https://www.reversinglabs.com/hubfs/evolution-app-sec.jpg” alt=”App sec is addicted to vulnerabilities: Why supply chain security requires evolution” class=”hs-featured-image” style=”width:auto !important; max-width:50%; float:left; margin:0 15px 15px 0;”> </a> </div> As application security professionals and developers seek ways to both prevent new flaws and manage existing vulnerabilities in software, the problems of scale and limited time inevitably rear their heads. Whether it is rooting out vulnerabilities before shipping code, or remediating flaws already in production, there’s rarely enough time to get to everything and meet top-line business objectives.</description>

<content:encoded><img src=”https://www.reversinglabs.com/hs-fs/hubfs/evolution-app-sec.jpg?width=1400&height=732&name=evolution-app-sec.jpg” alt=”evolution-app-sec” width=”1400″ height=”732″ style=”height: auto; max-width: 100%; width: 1400px;”> As application security professionals and developers seek ways to both prevent new flaws and manage existing vulnerabilities in software, the problems of scale and limited time inevitably rear their heads. Whether it is rooting out vulnerabilities before shipping code, or remediating flaws already in production, there’s rarely enough time to get to everything and meet top-line business objectives. This is why vulnerability prioritization is such a huge factor in securing software. Most security practitioners, developers, and DevOps teams understand this concept in principle. But when it comes to executing on it with effective prioritization, they consistently struggle. Even though the vulnerability management discipline has had decades to evolve, most organizations still struggle to effectively prioritize when and which flaws to fix or mitigate first in their software, their supply chain dependencies, and their application programming interfaces (APIs). There are a lot of factors that go into that struggle, but security experts increasingly believe that many of them come down to an unfortunate addiction to the holy trinity of vulnerability management. Vulnerability management programs and their tooling depend far too heavily on vulnerability information from the Common Vulnerability Enumeration (CVE), the National Vulnerability Database (NVD) which is fed by CVE data, and the simplistic severity rating of the Common Vulnerability Scoring System (CVSS). This over-reliance on CVEs, the NVD, and CVSS is leading to so many software security programs running to stand still. They struggle to appropriately gauge risk of any given vulnerability to their actually deployed software and their environments. They have a difficult time detecting errors in CVE information. And they can’t effectively use the NVD to manage software supply chain risks. Consequently, they’re working harder than ever but can’t keep up with the scope of vulnerabilities, which keep ballooning in the CVE/NVD. Here’s what you need to know about <a href=”https://www.reversinglabs.com/blog/6-reasons-software-security-teams-need-to-go-beyond-vulnerability-response”>app sec’s addiction to vulnerability reporting</a> — and why application security needs to evolve to take on supply chain security. [ See Special Reports: <a href=”https://www.reversinglabs.com/the-evolution-of-application-security”>The Evolution of Application Security</a> | <a href=”https://www.secure.software/reports/reversinglabs-nvd-analysis-2022-a-call-to-action-on-software-supply-chain-security”>NVD Analysis: A Call to Action on Software Supply Chain Security </a> ] <h2 style=”font-weight: bold;”>CVE/NVD portfolio: A signal to noise ratio-problem</h2> First instituted in 1999, the CVE system initially cut its grand-opening ribbon with a scant 321 published vulnerabilities through the work of MITRE. By 2004, about a year before the NVD was created through funding by the Department of Homeland Security, the database’s predecessor, the Internet Category of Attack (ICAT) had about 10,000 published CVEs. In 2022 alone, the number of CVEs published in a year exceeded 26,000. And at the end of 2022, the number of total published CVEs has snowballed to 190,971. Per a recent report by Cyentia Institute of the CVE landscape, by 2025 the median weekly rate of CVE publication will hover around 800 and could hit high points at around 1,200, <a href=”https://www.f5.com/labs/articles/threat-intelligence/the-evolving-cve-landscape”>the report highlighted</a>. <img src=”https://www.reversinglabs.com/hs-fs/hubfs/CVEs.png?width=2936&height=1741&name=CVEs.png” alt=”CVEs” width=”2936″ height=”1741″ style=”height: auto; max-width: 100%; width: 2936px;”> Source: Cyentia Institute/F5 <blockquote> ”Since each new vulnerability represents a theoretically new component in an attack vector, and since old vulnerabilities never really go away, defenders will face an escalating number of distinct attack vectors. The most urgent question facing CISOs today is not ‘will I be attacked?’ (yes) or ‘when will I be attacked?’ (today), but ‘how will I be attacked?’ This means that the task of triaging new CVEs and prioritizing patches will become an increasingly significant part of security operations.” —<a href=”https://www.f5.com/labs/articles/threat-intelligence/the-evolving-cve-landscape”>Cyentia Institute CVE landscape report</a> </blockquote> The whole point of CVE was a worthy goal at the time and still is even now for the task of standardizing the way developers and security pros identify and track flaws across different products and vendors, says Percy Grunwald, site reliability engineer (SRE) for Cisco Meraki and a full stack development veteran. <blockquote> ”This standardization is important because it enables organizations to efficiently manage their vulnerability management programs. Rather than having to manually track vulnerabilities for each product or vendor, organizations can rely on CVEs to keep them informed about newly discovered vulnerabilities and their associated patches.” —<a href=”https://www.linkedin.com/in/percygrunwald/”>Percy Grunwald</a> </blockquote> At the same time the CVE system has a number of limitations, he explains. In spite of the rapidly accumulating CVEs published in the NVD, <a href=”https://www.csoonline.com/article/3626478/why-code-reuse-is-still-a-security-nightmare.html”>the system has incomplete coverage that leads to “blind spots.”</a> Many of the most regrettable holes in the database are not just yet-unknown zero day vulnerabilities, but also those that are known by vendors and hidden by the ‘RESERVED’ marker in CVE/NVD that can obfuscate details about a flaw for extended periods of time, wrote longtime app sec pundit Mark Curphey in a recent two-part essay (See <a href=”https://blog.crashoverride.com/cve-nvd-doesnt-work-for-open-source-and-supply-chain-security”>Part 1</a> and <a href=”https://blog.crashoverride.com/cve-nvd-doesnt-work-for-open-source-and-supply-chain-security-part-two”>Part 2</a>) on the woes of CVE/NVD. <blockquote> ”The usual reason given is that they have long release cycles and need to coordinate disclosure to their customers. While true for some, it’s just bullshit for most. Of course when a vague reserved CVE is published, hackers do what we did at SourceClear. Unleash the bloodhounds, pour through the commits, find the vulnerability and build the exploit.” —Mark Curphey </blockquote> Additionally, CVEs lack valuable contextual information about the impact of a flaw on a specific environment, says Grunwald. “This means that organizations may not have a clear understanding of the risk that a vulnerability poses to their specific business operations,” he says. “For example, a vulnerability may be rated as high severity, but if it does not affect a critical asset or business operation, it may not pose a significant risk to the organization.” Now, because of the constant expansion of the scope of flaws within the NVD, most organizations are always on the hunt for tooling that “automagically” detects and prioritizes vulnerabilities for them, says <a href=”https://www.linkedin.com/in/walter-haydock/”>Walter Haydock</a>, founder and CEO of StackAware. Unfortunately, much of the automated tooling that organizations lean on today still relies solely on the scantily contextualized CVE information from the NVD, paired only with CVSS severity ratings (the limitations of which we’ll tackle in a second). Under the hood the outputs of many vulnerability management scanners and platforms are still mostly just a function of CVE and CVSS information. Overweighting is the issue facing the CVE system in a nutshell, explains Gary McGraw, the founder of Cigital and one of the grandfathers of modern app sec. <blockquote> ”The idea of having a common way of describing these things, it’s a great idea. Having that drive everybody’s product is silliness.” —<a href=”https://en.wikipedia.org/wiki/Gary_McGraw”>Gary McGraw</a> </blockquote> But that’s what happens so often in the average vulnerability management program. They’ll point their scanners at

SQUATTING: SQUIRTS SQUIRTING AROUND

Squatting and software supply chain security

Leave a Reply Cancel reply

Squatting and software supply chain security

Psst! Pass it on!!

Like this:

Related

Leave a Reply Cancel reply