Tuesday, October 4, 2022

Developer account body snatchers pose risks to the software supply chain

By Jaeson Schultz.
  • Over the past several years, high-profile software supply chain attacks have increased in frequency. These attacks can be difficult to detect and source code repositories became a key focus of this research.
  • Developer account takeovers present a substantial risk to the software supply chain because attackers who successfully compromise a developer account could conceal malicious code in software packages used by others.
  • Talos analyzed several of the major software repositories to assess the level of developer account security, focusing specifically on whether developer accounts could be recovered by re-registering expired domain names and triggering password resets.
  • Many software repositories have already begun taking steps to enhance the security of developer accounts. Talos has identified additional areas where the security of developer accounts could be improved. Talos worked with vulnerable repositories to resolve issues that we found.

Software supply chain attacks, once the exclusive province of sophisticated state-sponsored attackers, have been gaining popularity recently among a broader range of cyber criminals. Attackers everywhere have realized that software supply chain attacks can be very effective, and can result in a large number of compromised victims. Software supply chain attacks more than tripled in 2021 when compared with 2020.

Why are software supply chain attacks so effective? Organizations that possess solid cyber defenses may be difficult to attack directly. However, these same organizations are likely vulnerable to a software supply chain attack because they still regularly run/build software obtained from vendors who are trusted.

Rather than attacking an entire software repository itself, or identifying an unpatched vulnerability in a software package, compromising the software supply chain can be as simple as attacking the accounts of the package developers and maintainers. Most software repositories track the identities of their software developers using those developers' email addresses. If a cybercriminal somehow gains access to a developer's email account, the attacker can theoretically generate password reset emails at these software repositories and take over the account belonging to that developer. Once inside, an attacker could then publish malicious updates to the code maintained by that developer, affecting every other piece of software that uses that library from then on.

Cisco Talos examined several frequently used code repositories. We looked specifically at the security afforded to developer accounts, and how difficult it would be for an attacker to take over a developer account. While some repositories had stringent security in place, others did not. Fortunately, worked with the managers of these repositories to resolve the major issues we found.

Risks in the software supply chain

Re-inventing the wheel is typically not a good idea. This holds true for many things, including developing software. Much software written today depends on third-party packages and software libraries to facilitate necessary functionality contained in the program. Utilizing third-party libraries and packages, especially open source, also speeds up development and lowers costs.

Popular software packages have also become attractive targets for attackers. The more popular a software library is, the more external software will be using that library, and thus, the larger the potential attack surface. Compromising a software library can potentially compromise every other piece of software that relies on that software library for its functionality. This is the risk inherent in the software supply chain.

With the exception of language-agnostic repositories like GitHub, most software repositories tend to be language specific. For example, JavaScript authors rely mostly on NPM, Python developers have PyPI, Perl programmers can often be found using packages obtained via CPAN, and so on. Each software repository sets its own rules when it comes to developers' accounts.

Additionally, as many programmers are aware, some programming languages make a better choice for solving certain types of problems. For example, embedded systems drivers are more commonly written in C instead of Perl, while parsing text is more commonly done in Perl or Python, rather than C. This means that the process of writing programs that integrate third-party libraries into the code will also be different for each language. It is difficult to imagine a developer integrating a third-party library into a system-level driver written in C without carefully reviewing the related code and testing it for speed and functionality. However, when developing a feature-rich Perl proof-of-concept application or a web-based JavaScript application, this might not always be the case. A programmer in those instances might conceivably import a package first and ask questions later. This means some software repositories will carry more risk than others when it comes to malware hiding in the source code.


Node Package Manager is a JavaScript software repository and has been the subject of some "independent" security audits recently. There has been a lot of discussion online, especially concerning the security of the developer accounts there, and how easy it is to take over these accounts by re-registering expired email domains.

There are more than 2 million packages in the NPM repository. Conveniently, an NPM package called "all-the-package-names" contains a list of all packages in the NPM repository. Each individual package at NPM has associated metadata, such as a text description of the package, a link to the package tarball, and a list of the package maintainers. Most importantly, the list of package maintainers has the developer's username and email address.

Iterating through all the package names, and extracting the email addresses, then further extracting the domain names from those email addresses, provides the raw data necessary to find developer accounts associated with expired domains. Once an expired domain is found, it can be re-registered and theoretically used to take over the NPM developer account. But does it work this way in practice?

Although we found a couple thousand expired developer account domain names, we could not recover the associated developer accounts. It appears the "couple things in place to protect against [account takeover]" that NPM administrator @MylesBorins mentioned in his tweet above are working as planned.

Stale metadata helps foil attackers

NPM provides developers with the ability to update the email address associated with their accounts. When a developer decides to switch email addresses, only the future package/version's metadata will contain the new email address. NPM does not retroactively update old metadata associated with a package that was previously published. This means that, even though someone looking to take over an NPM developer account might find package metadata indicating a developer with an expired email domain, it could simply be that the developer has updated their NPM account to a new email address.

This was the case in May 2022, when a security researcher claimed to have taken over the NPM package "foreach" by re-registering the email domain belonging to the NPM developer. Unbeknownst to the security researcher, the developer in question had actually updated their NPM account to use their Gmail address instead. So if any password recovery attempts were made, they would have failed — NPM would have generated and sent the password reset emails to the new Gmail account on file, which is still under the original developer's control.


PyPI is the Python Package Index and currently contains almost 400,000 projects. Developers at PyPI have email addresses associated with their accounts, however, PyPI does not display the email address publicly by default. This is an option that the developer must explicitly choose to enable. Many developers are, of course, eager to interact with others who are running their code, so it is no surprise that large numbers of developers enable this feature.

PyPI accounts do not come with MFA enabled by default, so this is something else a developer would have to choose to enable. However, in July 2020 PyPi announced that it was rolling out mandatory MFA to "critical projects," a.k.a. the top 1% of the projects at PyPi (based on the number of downloads).

A list of all PyPI packages is available online. Many of these packages contain a mailto: link containing an email address. There is also a list of maintainers of the package. For developers that expose their email addresses publicly, it's found on the user's public profile page. It is a relatively simple process to scrape the email addresses associated with PyPI projects. PyPI reveals whether an email address is associated with an account (but it probably should not).

Account takeovers have been a problem at PyPI in the past. As recently as May 14, 2022, an attacker managed to take over a developer account and replaced the "ctx" package, adding malicious code that stole the user's environment variables, base64-encoded them and transmitted the data back to the attacker's C2 server. Fortunately, the changes made by the admins over at PyPI seem to be moving account security in the right direction.


The Comprehensive Perl Archive Network (CPAN) contains more than 200,000 Perl modules. CPAN also provides an index of all the module authors.

The individual module authors each have their own "homepage" that lists their contributed modules. For anyone who wants to reach out to the dev, CPAN includes the author's email address.

A motivated attacker can easily scrape the CPAN website for a list of all author IDs and use those to scrape the email address belonging to the developers. A whois search on the email domain of the developer email addresses provides us with a list of developer accounts that are vulnerable to account takeover. From there, all that is required is standing the domain up somewhere and running a mail server. Triggering a password reset provides us with the magic link to get into the developer's account.

Talos has reached out to the admins at CPAN and provided them with a list of the vulnerable developer accounts we found. CPAN has disabled these accounts.


NuGet is a software repository for .NET developers. The NuGet "gallery" contains more than 317,000 packages. Fortunately, registered developers at NuGet have their email addresses hidden by default. There is an option to allow users to contact you, using a form on the NuGet website that does not disclose the email address of the developer. Developers have the option of adding their Twitter handle, and many developers do. If an attacker wishes to attack NuGet developers en masse, they would have a very difficult time assembling a list of developer email addresses.


RubyGems is a software repository for Ruby developers. There are currently approximately 172,000 gems (packages) in the repository. Developer email addresses are hidden from the public by default. Even unchecking the "Hide email in public profile" check box has no discernable effect, and the email address remains hidden.

Some gems have "maintainers" files to indicate the contact email addresses of the developers, but this is not consistent across gems. Recently, the RubyGems team announced that they are enforcing MFA for top developer accounts.


The software supply chain attack problem is not likely to go away anytime soon. It is unreasonable to ask organizations to vet every piece of software that runs in their environment. Some amount of trust in software vendors and suppliers will always be necessary. However, that doesn't mean that defenders are helpless against these types of attacks.

Organizations should analyze what software is required on various internal systems. Many times, there may be opportunities to segment a group of systems running a particular piece of software from the rest of the internal network. This way, any compromise that occurs as a result of a software supply chain attack will be limited in scope. Obviously, there are limitations to this approach.

All parties in the software supply chain need to take more responsibility for security. For example, it would be far safer for software repositories to stop publishing or releasing any information related to a developer's email address. Yes, this is arguably a bit of security-by-obscurity, but it forces attackers to go elsewhere to correlate the email account of a developer with the particular software package in question, and greatly enhances the security of the repository. If a repository wishes to publish a developer's email address, it could instead give each developer an email address at the domain of the repository itself (ex., @npmjs.com, @cpan.org, etc.).

Forcing MFA on the most popular package maintainers also seems to be a sensible remedy that is currently being pursued by several repositories. However, security is always a delicate balance. If you sacrifice too much usability in the pursuit of security, developers may rebel, as was the case with PyPI developer "untitaker."

One sure-fire countermeasure against developer account takeover via expired domain registration is code signing. This is really the best way to be sure that the code you use has not been tampered with since it was last signed, and is indeed from a developer you trust. An attacker who gets control of a developer's expired domain name would have no way to recover the code signing keys belonging to that developer and no way to impersonate that developer.

Monday, October 3, 2022

Researcher Spotlight: Globetrotting with Yuri Kramarz

From the World Cup in Qatar to robotics manufacturing in east Asia, this incident responder combines experience from multiple arenas 

By Jon Munshaw. 

Yuri “Jerzy” Kramarz helped secure everything from the businesses supporting the upcoming World Cup in Qatar to the Black Hat security conference and critical national infrastructure. 

He’s no stranger to cybersecurity on the big stage, but he still enjoys working with companies and organizations of all sizes in all parts of the world. 

“What really excites me is making companies more secure,” he said in a recent interview. “That comes down to a couple things, but it’s really about putting a few solutions together at first and then hearing the customer’s feedback and building from there.” 

Yuri is a senior incident response consultant with Cisco Talos Incident Response (CTIR) currently based in Qatar. He walks customers through various exercises, incident response plan creation, recovery in the event of a cyber attack and much more under the suite of offerings CTIR has. Since moving from the UK to Qatar, he is mainly focused on preparing various local entities in Qatar for the World Cup slated to begin in November. Qatar estimates more than 1.7 million people will visit the country for the international soccer tournament, averaging 500,000 per day at various stadiums and event venues. For reference, the World Bank estimates that 2.9 million people currently live in Qatar.

Friday, September 30, 2022

Threat Advisory: Microsoft warns of actively exploited vulnerabilities in Exchange Server

Cisco Talos has released new coverage to detect and prevent the exploitation of two recently disclosed vulnerabilities collectively referred to as "ProxyNotShell," affecting Microsoft Exchange Servers 2013, 2016 and 2019. One of these vulnerabilities could allow an attacker to execute remote code on the targeted server. Limited exploitation of these vulnerabilities in the wild has been reported. CVE-2022-41040 is a Server Side Request Forgery (SSRF) vulnerability, while CVE-2022-41082 enables Remote Code Execution (RCE) when PowerShell is accessible to the attackers.

While no fixes or patches are available yet, Microsoft has provided mitigations for on-premises Microsoft Exchange users on Sept. 29, 2022. Even organizations that use Exchange Online may still be affected if they run a hybrid server. Cisco Talos is closely monitoring the recent reports of exploitation attempts against these vulnerabilities and strongly recommends users implement mitigation steps while waiting for security patches for these vulnerabilities. Exchange vulnerabilities have become increasingly popular with threat actors, as they can provide initial access to network environments and are often used to facilitate more effective phishing and malspam campaigns. The Hafnium threat actor exploited several zero-day vulnerabilities in Exchange Server in 2021 to deliver ransomware, and Cisco Talos Incident Response reported that the exploitation of Exchange Server issues was one of the four attacks they saw most often last year.

Threat Roundup for September 23 to September 30

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Sept. 23 and Sept. 30. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, or ClamAV.net.

Thursday, September 29, 2022

Threat Source newsletter (Sept. 29, 2022) — Personal health apps are currently under a spotlight, but their warning signs have always been there

By Jon Munshaw. 

Welcome to this week’s edition of the Threat Source newsletter. 

I’ve spent the past few months with my colleague Ashlee Benge looking at personal health apps’ privacy policies. We found several instances of apps that carry sensitive information stating they would share certain information with third-party advertisers and even law enforcement agencies, if necessary. 

One of the most popular period-tracking apps on the Google Play store, Period Calendar Period Tracker, has a privacy policy that states it will "share information with law enforcement agencies, public authorities, or other organizations if We’re [sic] required by law to do so or if such use is reasonably necessary. We will carefully review all such requests to ensure that they have a legitimate basis and are limited to data that law enforcement is authorized to access for specific investigative purposes only." 

A report from the Washington Post also released last week found that this app, as well as popular health sites like WebMD, “gave advertisers the information they’d need to market to people, or groups of consumers based on their health concerns.” 

To me — these were all things I had never considered before. I’m sure I’m not alone in just going to Google to type in “pain in left flank” or something along those lines to see if I’m dying or not. The research Ashlee and I did really make me rethink the type of information I’m inputting into apps on my phone, especially around my health.

Wednesday, September 28, 2022

New campaign uses government, union-themed lures to deliver Cobalt Strike beacons

By Chetan Raghuprasad and Vanja Svajcer.
  • Cisco Talos discovered a malicious campaign in August 2022 delivering Cobalt Strike beacons that could be used in later, follow-on attacks.
  • Lure themes in the phishing documents in this campaign are related to the job details of a government organization in the United States and a trade union in New Zealand.
  • The attack involves a multistage and modular infection chain with fileless, malicious scripts.

Cisco Talos recently discovered a malicious campaign with a modularised attack technique to deliver Cobalt Strike beacons on infected endpoints.

The initial vector of this attack is a phishing email with a malicious Microsoft Word document attachment containing an exploit that attempts to exploit the vulnerability CVE-2017-0199, a remote code execution issue in Microsoft Office. If a victim opens the maldoc, it downloads a malicious Word document template hosted on an attacker-controlled Bitbucket repository.

Talos discovered two attack methodologies employed by the attacker in this campaign: One in which the downloaded DOTM template executes an embedded malicious Visual Basic script, which leads to the generation and execution of other obfuscated VB and PowerShell scripts and another that involves the malicious VB downloading and running a Windows executable that executes malicious PowerShell commands to download and implant the payload.

The payload discovered is a leaked version of a Cobalt Strike beacon. The beacon configuration contains commands to perform targeted process injection of arbitrary binaries and has a high reputation domain configured, exhibiting the redirection technique to masquerade the beacon's traffic.

Although the payload discovered in this campaign is a Cobalt Strike beacon, Talos also observed usage of the Redline information-stealer and Amadey botnet executables as payloads.

This campaign is a typical example of a threat actor using the technique of generating and executing malicious scripts in the victim's system memory. Defenders should implement behavioral protection capabilities in the organization's defense to effectively protect them against fileless threats.

Organizations should be constantly vigilant on the Cobalt Strike beacons and implement layered defense capabilities to thwart the attacker's attempts in the earlier stage of the attack's infection chain.

Friday, September 23, 2022

Threat Roundup for September 16 to September 23

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Sept. 16 and Sept. 23. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, orokibot ClamAV.net.

Thursday, September 22, 2022

Threat Source newsletter (Sept. 22, 2022) — Attackers are already using student loan relief for scams

By Jon Munshaw. 

Welcome to this week’s edition of the Threat Source newsletter. 

We’ve seen attackers capitalize on the news time and again, from COVID-19 to U.S.-North Korea relationships and, of course, holiday shopping sales every November. 

So, I was far from surprised to see that attackers are already using U.S. President Joe Biden’s student loan forgiveness plan as a basis for scams and phishing emails.  

The Better Business Bureau and the U.S. Federal Trade Commission both released warnings over the past few weeks around fake offers, scams and website links related to the debt forgiveness plan, with which some borrowers will have up to $20,000 worth of loans forgiven. 

Many of these scams, coming via phone calls, text messages and emails, are promising to provide guaranteed access to the forgiveness program or early applications for a fee. (Hint: This will not work.)

Insider Threats: Your employees are being used against you

By Nick Biasini.
  • Insider threats are becoming an increasingly common part of the attack chain, with malicious insiders and unwitting assets playing key roles in incidents over the past year.
  • Social engineering should be part of any organization’s policies and procedures and a key area for user education in 2023 and beyond.
  • Mitigating these types of risks include education, user/access control, and ensuring proper processes and procedures are in place when and if employees leave the organization.

Traditionally, attackers try to leverage vulnerabilities to deliver malicious payloads via exploitation. But more recently, that activity has shifted away from exploitation and consistently moved closer and closer to the user. Initially, threat actors loved to trick users into enabling malicious macros in Microsoft Office documents, but as Microsoft moves to blunt the effectiveness of macros, adversaries are always going to move to the next avenue to generate malicious revenue. This is where insider threats come into play. There are two broad categories of insider threats: the malicious insider and the unwitting asset. Both present unique challenges in detection and prevention for defenders and organizations’ IT admins. 

Malicious Insiders

There are a variety of reasons a user may choose to become a malicious insider, and unfortunately, many of them are occurring today. Let’s start with the most obvious: financial distress. When a user has a lot of debt, selling the ability to infect their employer can be a tempting avenue. We’ve seen examples of users trying to sell access into their employers’ networks for more than a decade, having spotted them on dark web forums. The current climate is, unfortunately, ripe for this type of abuse. The economy is on the brink of a recession, inflation continues to spike, and the cryptocurrency markets have lost as much as 70% of their peak value from late 2021. Combined, these factors can create an environment where employees are susceptible to coercion, putting the enterprise at risk.

Vulnerability Spotlight: Vulnerabilities in popular library affect Unix-based devices

Lilith >_> of Cisco Talos discovered these vulnerabilities. 

Cisco Talos recently discovered a memory corruption vulnerability in the uClibC library that could affect any Unix-based devices that use this library. uClibC and uClibC-ng are lightweight replacements for the popular gLibc library, which is the GNU Project's implementation of the C standard library. 

TALOS-2022-1517 (CVE-2022-29503 - CVE-2022-29504) is a memory corruption vulnerability in uClibC and uClibc-ng that can occur if a malicious user repeatedly creates threads. 

Many embedded devices utilize this library, but Talos specifically confirmed that the Anker Eufy Homebase 2, version, is affected by this vulnerability. Anker confirmed that they’ve patched for this issue. However, uClibC has not issued an official fix, though we are disclosing this vulnerability in accordance with Cisco’s 90-day vulnerability disclosure policy. Talos tested and confirmed the following software is affected by these vulnerabilities: uClibC, version and uClibC-ng, version 1.0.40.