Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Fake SDKs Supply-Chain Security. Show all posts

Apps Targeting U.S. Military Personnel Found to Contain Chinese and Russian Software Components, Study Finds

 


A study led by researchers from Purdue University has found that a notable number of Android applications marketed toward U.S. military personnel include software components developed by companies based in China, Russia, and other countries identified by the U.S. Department of Defense as adversarial nations.

The research, conducted in collaboration with the U.S. Military Academy at West Point and Florida International University, examined more than 220 Android applications obtained from Google Play and online military communities. According to the researchers, over one in every eight apps analyzed contained code associated with organizations headquartered in countries regarded as strategic competitors of the United States. The Pentagon declined to comment on the study's findings.

Rather than identifying malicious applications outright, the study highlights a growing software supply chain challenge created by third-party Software Development Kits (SDKs), which developers routinely integrate into applications to support features such as advertising, analytics, authentication, and push notifications. While these components simplify development, they can also introduce external code that developers may not fully inspect or even realize has been included.

Researchers found SDKs in approximately 64% of the analyzed applications. Among them, twelve apps contained Huawei's HMS Core framework, including applications developed for state National Guard organizations. In one instance, Huawei's software was not intentionally added by the application's developer. Instead, it was introduced indirectly through a commercial notification service that bundled Huawei's SDK as a dependency.

The researchers noted that this type of indirect integration presents an important security concern because SDKs can receive remote updates over time. Even if no sensitive information is transmitted today, future updates could potentially alter an application's behavior without users being aware. Although the study did not observe any data being sent to Huawei-controlled servers during testing, the researchers cautioned that the presence of such software should not automatically be considered harmless.

Beyond Huawei, the analysis also identified software associated with Russian technology companies. SDKs linked to Yandex advertising services were found in applications used by military-affiliated users. The study also referenced Pushwoosh, a Russian software company that previously presented itself as a U.S.-based business. Reuters reported in 2022 that Pushwoosh code had been embedded in official mobile applications operated by the U.S. Army and the U.S. Centers for Disease Control and Prevention (CDC). Both organizations subsequently removed the software following public disclosure.

The researchers also discovered discrepancies between application behavior and the privacy information disclosed through Google Play. Approximately 40% of the applications examined either collected or shared more user data than indicated by their app store privacy labels. Overall, around 7% of the analyzed applications contained software linked to companies headquartered in countries designated by the Pentagon as adversarial nations.

Lead author Joshua Shinkle of Purdue University said the team hopes the findings encourage stronger awareness among military personnel, application developers, platform providers, and policymakers. According to Shinkle, the research is intended to support more informed privacy decisions while encouraging discussions about improving transparency and addressing existing security gaps.

The study argues that the implications extend beyond software development practices. Researchers pointed to the commercial mobile advertising ecosystem, where applications routinely collect location and device information that can later be shared through data brokers. Such information has the potential to expose sensitive operational patterns, including troop movements, deployment routines, and activity around military installations.

The report references an April letter in which U.S. Central Command (CENTCOM) informed Senator Ron Wyden that it had received multiple threat reports indicating that adversaries were exploiting commercially available location data to monitor U.S. military personnel operating near Iran and the Strait of Hormuz. Lawmakers described the disclosure as the first official acknowledgement that commercially traded mobile data had been used to track troops deployed in an active conflict zone.

Researchers also surveyed 103 military-affiliated Americans to better understand attitudes toward mobile application privacy. More than 83% of respondents reported using at least one application whose data collection practices made them uncomfortable. Between 76% and 83% indicated they would be extremely uncomfortable using applications containing software developed by companies from adversarial nations.

Despite these concerns, participants expressed greater trust in applications carrying military branding, suggesting that official appearance can influence perceptions of security even when underlying software components remain largely invisible to users. Nearly two-thirds of respondents also reported receiving little or no institutional guidance regarding the security risks associated with personal mobile applications.

When asked about potential solutions, respondents strongly supported greater transparency regarding third-party software embedded within applications. The most widely supported recommendation involved providing users with in-device notifications identifying foreign-developed SDKs before installation or use.

Participants also backed stronger federal restrictions on the commercial trading of military-affiliated location data, independent security audits of applications, and tighter controls on the inclusion of foreign-developed SDKs in apps marketed toward service members.

While the U.S. Marine Corps already prohibits several categories of applications, including gambling, dating, and cryptocurrency apps, from government-issued devices and has warned personnel against using platforms such as TikTok and WeChat, the researchers argue that personal smartphones remain a largely unaddressed area of risk because they frequently fall outside existing policy controls.

According to the researchers, improving software transparency will require greater visibility into third-party components that operate behind the scenes. They recommend clearer country-of-origin labeling for embedded SDKs within application marketplaces and encourage developers to regularly audit their software dependency chains to better understand which external components are included in their applications.

The study concludes that branding alone should not be viewed as an indicator of application security. As modern mobile apps increasingly rely on extensive networks of third-party software, researchers argue that stronger transparency, routine dependency auditing, and more robust privacy safeguards will be necessary to reduce hidden supply chain risks facing military personnel and other users handling sensitive information.

Fake Paysafe and Skrill SDKs on npm and PyPI Steal Developer Credentials

 

A coordinated supply-chain attack has compromised developers by distributing 17 malicious packages on npm and PyPI that impersonate legitimate SDKs for Paysafe, Skrill, and Neteller payment services. These packages were designed to silently exfiltrate sensitive credentials, including API keys, AWS tokens, GitHub secrets, and npm tokens, to a command-and-control server hosted on Amazon Web Services. 

The threat actor published these fake SDKs with names closely resembling official payment integration libraries, such as paysafe-checkout, skrill-payments, and paysafe-api. While the packages expose expected APIs and return fake success responses to avoid detection, their real purpose is credential theft. The embedded malware scans the compromised environment for secrets and exfiltrates them to the attacker's server. 

Security researchers at Socket identified 13 malicious npm packages and four PyPI packages in this campaign. The npm packages were released in four versions (1.0.0 to 1.0.3), while the PyPI packages had only one malicious version (1.0.0). The full list includes well-known names like paysafe-js, paysafe-fraud, skrill-sdk, neteller, and paysafe-kyc. Developers who installed any of these packages risked having their secrets stolen, especially if they were working on payment integration projects for these services. The data theft module in the npm packages attempts exfiltration only if a Paysafe API key is present and activates when the fake SDK is called. The PyPI packages automatically activate the data theft routine upon initialization and do not require a Paysafe API key to be present at all. 

The malware incorporates basic anti-analysis features to avoid detection in sandboxed or virtualized environments. For instance, it halts execution if it detects fewer than two CPU cores or if the hostname or username suggests a virtual machine. To detect potential compromise, organizations should search their dependency trees for the listed package names and scan CI/CD logs for PAYSAFE_API_KEY in combination with these packages. Denying requests for these packages at the registry proxy level is also recommended to prevent accidental installation. If any of the listed packages were installed, developers are recommended to immediately rotate all secrets on any machine that imported or executed this package. 

The researchers also advise searching dependency trees for the package names used in the campaign and deny any requests for them at the registry proxy level. It is also recommended to look in the logs of Continuous Integration (CI) systems for PAYSAFE_API_KEY in combination with any of the listed package names. Additionally, teams should audit their project dependencies and CI/CD pipelines to ensure no traces of these malicious packages remain. Staying vigilant and verifying package sources before installation remains crucial to avoiding similar supply-chain attacks in the future. This incident highlights the growing sophistication of attackers targeting open-source repositories and the critical need for robust software supply-chain security practices. 

Developers must remain cautious when integrating third-party libraries into their projects, especially those related to financial services and payment processing. The use of automated dependency scanning tools and regular security audits can help identify and mitigate risks associated with malicious packages. Furthermore, organizations should implement strict access controls and monitoring for their CI/CD environments to detect and respond to potential credential theft attempts quickly. By adopting a proactive security posture and staying informed about emerging threats, the developer community can better protect itself against evolving supply-chain attacks.