Un groupe de chercheurs de l'Université de Turku (Finlande) a publié les résultats d'une analyse des packages du référentiel PyPI pour l'utilisation de constructions potentiellement dangereuses pouvant conduire à des vulnérabilités. Lors de l'analyse de 197 749 colis, 46 XNUMX problèmes de sécurité potentiels ont été identifiés. XNUMX % des colis présentent au moins un de ces problèmes. Parmi les problèmes les plus courants figurent les lacunes liées à la gestion des exceptions et à l’utilisation de fonctionnalités permettant la substitution de code.
Sur les 749 442 problèmes identifiés, 41 227 (30 %) ont été qualifiés de mineurs, 80 11 (2589 %) de problèmes modérés et 2356 XNUMX (XNUMX %) de dangereux. Certains packages sortent du lot et contiennent des milliers de problèmes : par exemple, le package PyGGI a identifié XNUMX XNUMX problèmes, principalement liés à l'utilisation de la construction « try-sauf-pass », et le package appengine-sdk a trouvé XNUMX XNUMX problèmes. Un grand nombre de problèmes sont également présents dans les packages genie.libs.ops, pbcore et genie.libs.parser.
Il est à noter que les résultats ont été obtenus sur la base d'une analyse statique automatisée, qui ne prend pas en compte le contexte d'application de certaines structures. Le développeur de la boîte à outils Bandit, utilisée pour analyser le code, a exprimé l'opinion qu'en raison du nombre assez élevé de faux positifs, les résultats de l'analyse ne peuvent pas être directement considérés comme des vulnérabilités sans un examen manuel supplémentaire de chaque problème.
Par exemple, l'analyseur considère l'utilisation de générateurs de nombres aléatoires et d'algorithmes de hachage peu fiables, tels que MD5, comme un problème de sécurité, alors que dans le code, de tels algorithmes peuvent être utilisés à des fins qui n'affectent pas la sécurité. L'analyseur considère également tout traitement de données externes dans des fonctions non sécurisées telles que pickle, yaml.load, subprocess et eval comme un problème, mais cette utilisation n'implique pas nécessairement une vulnérabilité et en fait l'utilisation de ces fonctions peut être implémentée sans menace de sécurité. .
Parmi les tests utilisés dans l’étude :
- Utilisation de fonctions potentiellement dangereuses exec, mktemp, eval, mark_safe, etc.
- Paramétrage non sécurisé des droits d'accès aux fichiers.
- Connexion d'une prise réseau à toutes les interfaces réseau.
- Utilisation de mots de passe et de clés strictement spécifiés dans le code.
- Utilisation d'un répertoire temporaire prédéfini.
- Utilisation de pass et continue dans les gestionnaires d'exceptions de style fourre-tout ;
- Lancement d'applications Web basées sur le framework Web Flask avec le mode débogage activé.
- Utilisation de méthodes de désérialisation de données dangereuses.
- Utilise les fonctions de hachage MD2, MD4, MD5 et SHA1.
- Utilisation de chiffrements DES et de modes de cryptage non sécurisés.
- Utilisation d'une implémentation HTTPSConnection non sécurisée dans certaines versions de Python.
- Spécification du schéma file:// dans urlopen.
- Utilisation de générateurs de nombres pseudo-aléatoires lors de l'exécution de tâches cryptographiques.
- Utilisation du protocole Telnet.
- Utilisation d'analyseurs XML non sécurisés.
De plus, on peut noter que 8 packages malveillants ont été détectés dans le répertoire PyPI. Avant leur suppression, les packages problématiques étaient téléchargés plus de 30 64 fois. Pour masquer les activités malveillantes et contourner les avertissements des simples analyseurs statiques dans les packages, les blocs de code ont été codés en BaseXNUMX et exécutés après décodage à l'aide d'un appel eval.
Les packages noblesse, genesisbot, are, souffrance, noblesse2 et noblessev2 contiennent du code pour intercepter les numéros de carte de crédit et les mots de passe stockés dans les navigateurs Chrome et Edge, ainsi que pour transférer les jetons de compte depuis l'application Discord et envoyer des données système, y compris des captures d'écran du contenu de l'écran. Les packages pytagora et pytagora2 incluaient la possibilité de charger et d'exécuter du code exécutable tiers.
Source: opennet.ru