GitGuardian researchers published the results of an analysis of sensitive data forgotten by developers in code hosted on the Python Package Index (PyPI). After reviewing over 9.5 million files and 5 million package releases related to 450 thousand projects, 56,866 instances of sensitive data leakage were identified. Considering only unique data, without duplication across different releases, the number of identified leaks amounted to 3,938, with 2,922 projects having at least one leak.
A total of more than 150 types of sensitive information leaks have been identified, including common passwords, cryptographic keys, access tokens to cloud services, continuous integration systems, and APIs. At least 768 credentials were still active at the time of the study. Examples of popular leaks that remain relevant include access keys to Azure Active Directory, SSH credentials, MongoDB, MySQL, and PostgreSQL credentials, keys to GitHub OAuth Apps, Dropbox, and Auth0, as well as login parameters for Coinbase and Twilio.
Among the increasingly popular types of leaks are tokens for accessing bots on Telegram, which doubled in number at the beginning of 2021 and then doubled again in spring 2023. A steady increase in leaks has also been recorded since 2020 for access keys to Google APIs, and since 2022 for database credentials. Notable packages leading in the number of leaks include chatllm and safire, which contained 209 keys to OpenAI and 320 keys to Google Cloud.
Among the file types with the highest number of leaks, in addition to files with the '.py' extension, are files with the .json extension (610 leaks), .md (270), PKG-INFO (240), METADATA (210), .txt (170), as well as README files (209) and files from directories named test (675). Many leaks are also associated with oversights and errors in excluding files during package builds. For example, files with local configuration files (.cookiecutterrc, .env, .pypirc, etc.) can be excluded from Git repositories through a '.gitignore' file, which is not considered when creating a package. Specifically, the repository contained 43 .pypirc files with credentials for accessing PyPI. In 15 instances of leaks, developers did not plan to publicly publish packages originally created for internal use but mistakenly published them on PyPI.
Additionally, two more events related to PyPI can be mentioned:
- The PyPI repository has identified 8 malicious packages presented as utilities for obfuscation, i.e., making code unreadable, complicating the process of recovering the algorithm. The identified packages contained the string "pyobf" in their names (Pyobftoexe, Pyobfusfile, Pyobfexecute, Pyobfpremium, Pyobflight, Pyobfadvance, Pyobfuse, and pyobfgood) and were downloaded over 2000 times.
The integrated malicious code was specific to the Windows platform and allowed connections to an external controller server, executing arbitrary commands on the developer's computer, finding and sending confidential information, such as access keys, to an external server, as well as transferring arbitrary files from the system. Additionally, the malicious code could function as a keylogger, intercepting passwords typed into Chrome, taking screenshots, recording audio, and even controlling the webcam.
- The results of an independent audit of the codebase of the tools used to manage the operation of the repository pypi.org, and the "cabotage" framework involved in the orchestration of containers, have been published. The audit was conducted with the support of the non-profit organization OTF (Open Technology Fund). The audit found no high-level security issues, and the source code was deemed to meet the basic requirements for secure coding. However, it noted insufficient test coverage of the cabotage codebase and identified 29 issues, 8 of which were assigned a moderate danger level, 6 were low, and 14 were marked as informative remarks.
The most notable issues were:
- Insufficient verification of digital signatures used for PyPI integration with AWS SNS allowed notifications to be sent to the email of individual users.
- Information leakage in the upload handler that allowed the existence of an account to be determined without generating login attempt events.
- Use of unreliable cryptographic hashes that do not prevent cache poisoning attacks.
- With build process execution rights through cabotage, an attacker could potentially substitute their own commands.
- With deployment rights in cabotage, an attacker could potentially deploy a legitimately looking image.
Source: opennet.ru
