Sécurité : la « confusion des dépendances » a aussi touché Apple

Mickaël Bazoge |

Le chercheur en sécurité Alex Birsan est parvenu à pirater les systèmes informatiques internes de 35 entreprises, dont Apple, Netflix, Microsoft ou encore Tesla, avec une méthode toute bête (enfin, façon de parler). La trouvaille lui a permis de récupérer 130 000 $ de primes, dont 30 000 $ de la part d'Apple qui a sécurisé ses serveurs deux semaines après l'alerte donnée par le chercheur en août dernier.

Les logiciels des réseaux de ces entreprises exploitent des dépendances téléchargées depuis des dépôts open-source comme npm (Node), PyPI (Python) ou encore RubyGems (Ruby). Aucun de ces services ne peut garantir que le code contenu dans ces paquets ne contient aucun malware. Par ailleurs, les entreprises utilisent des dépendances publiques mais aussi privées, stockées en interne sur leurs serveurs et pas sur les dépôts publics.

C'est en observant la liste des dépendances dans le fichier package.json utilisé par PayPal qu'Alex Birsan s'est aperçu que le service utilisait des dépendances privées et publiques.

Après avoir téléversé sur les dépôts publics des paquets portant le même nom que ces dépendances privées, Alex Birsan s'est rendu compte que les applications utilisées par les réseaux de ces entreprises allaient télécharger non plus les paquets privés, mais les versions « piégées » et ce, de manière automatique. Dans le même genre, le chercheur a relevé que le paquet qui avait un numéro de version plus élevée avait la priorité, peu importe où il était stocké.

Cette attaque, baptisée « confusion des dépendances » par Birsan, est détaillée en long, en large et en travers par le chercheur dans ce billet Medium. C'est en s'attaquant à une dépendance privée de PayPal qu'il a eu l'idée de tester l'astuce avec des dizaines d'autres systèmes internes d'entreprises. À chaque fois, il a agi dans le respect des programmes de sécurité mis en place par ces sociétés.

Apple a confirmé que la faille pouvait permettre d'exécuter du code à distance sur ses serveurs, via le dépôt npm. En revanche, le constructeur a estimé que la vulnérabilité n'était pas de nature à créer des portes dérobées dans ses systèmes, en l'occurrence il était lié à l'authentification Apple ID.

Tags
avatar occam | 

Sticky d'Alex :
« If you want to know how you can get started in bug bounties, the first and most important step is learning how to use Google, because that'll be your main tool for your whole career. »
🤣

avatar Nesus | 

L’idée est excellente. Simple et terriblement efficace.

avatar r e m y | 

La simplicité de la méthode fait froid dans le dos... 🥶

avatar filaton | 

Je ne comprendrai jamais que d'aussi grosses boîtes n'utilisent pas des miroirs privés ("devpi" pour Python par exemple) et des dépendances strictes (avec "version==x.y.z" plutôt que "version^x.y.z"), surtout pour des produits publics.

avatar fred33 | 

@filaton +1, leurs admins systèmes ont de la chance sur ce coup.

avatar MarcMame | 

@filaton

"Je ne comprendrai jamais que d'aussi grosses boîtes n'utilisent pas des miroirs privés ("devpi" pour Python par exemple) et des dépendances strictes (avec "version==x.y.z" plutôt que "version^x.y.z"), surtout pour des produits publics."

Parce qu’il faudrait payer un mec pour le faire ?
Et même si on y remet de l’humain, qu’est-ce qui te dit que celui-ci ne fera pas la même chose, voir pire ?
L’humain fait souvent pire, surtout dans les choses répétitives.

avatar lmouillart | 

Les paquets devraient surtout être signés plutôt q'uniquement hashés.

avatar oomu | 

@filaton

ça a un coût en charge et maintenance.

les developpeurs vont aussi vous harceler pour avoir accès au projet public python/ruby/etc à la cool du moment, et donc naturellement vous serez poussé à certes avoir un devpi privé, mais aussi que ça soit super simple d'accès les miroirs publics.

on finit facilement par perdre de vue les conséquences de faciliter les outils de travail des devs.

Il faudrait aussi blinder le parefeu local pour empêcher des devs de récupérer d'eux même des projets sur des dépôts publiques.

idéalement restreindre qu'à des sources de confiance (qu'on arrive à gérer efficacement avec les nouvelles versions validées et mises à disposition sans 160 ans de retard...) et faire signer, et que cela entre dans les scripts de compilation et assurance qualité automatiques...

signer le tout, serait l'idéal et que les outils n'acceptent QUE ce qui est signé.. mais du coup faut une solide infra de certificats et bien maintenir

etc.

En général, un ingénieur va vous répondre : "pfiulalal, c'est de la perte de temps et je veux la version 2.172.1 qui est sortie hier !"

avatar Sometime | 

@oomu

Certes. Cela étant avoir un versionning strict permet d’éviter ce genre d’écueil - en grande partie en tout cas.
C’est peut-être le reflet d’une culture du développement un peu laxiste: on développe, c’est de l’interne, donc on versione peu, mal ou a la va-vite....

avatar oomu | 

on ne dit pas laxiste, on dit Agile !

avatar marc_os | 

@ oomu

> on ne dit pas laxiste, on dit Agile

Très bon.
Là où je travaille, la méthode Agile est un prétexte pour ne pas produire de spécifications écrites détaillées. Du coup c'est pendant l'implémentation que certains développeurs complètent ces spécifications, et eux seuls savent exactement ce qu'ils ont fait. Du coup les plans de test pour la QA sont hasardeux, et ces derniers temps on publie moult bogues au grand plaisir des clients. Mais écrire, oh écrire, que cela est difficile !

avatar tupui | 

@oomu

Sinon tu as des services qui font ça pour toi. Genre tidelift. Ils certifient les version, licences etc

avatar oomu | 

je note ce service tidelift, merci.

avatar Sébastien R. | 

En mettant le lien direct du dépôt en question meme privé impossible qu’il tape le registre global 🙃

avatar jackhal | 

Malheureusement très réaliste : https://xkcd.com/2347/
Dans l'article il s'agit de tromper le système de gestion des dépendances. Mais je pense que ce genre de petits projets cruciaux à plein d'autres et mis à jour automatiquement sont de bonnes cibles pour quelqu'un de malveillant.

avatar smog | 

"Après avoir téléversé sur les dépôts publics des paquets portant le même nom que ces dépendances privées"
C'est possible ça ? N'importe qui peut le faire ? Je ne comprends pas bien, dans ce cas c'est la porte ouverte à tous les empêcheurs de tourner en rond, non ? Et auquel cas ça doit être utilisé depuis belle lurette ?

avatar Sometime | 

@smog

A moins que qqn n’est « réservé » le nom il arrive souvent que le nom du paquet utilisé en interne soit « libre ». Il suffit donc d’en repérer un et de l’utiliser.

Certaines organisations réservent cependant sur les repos les noms utilisés en interne (pour un usage futur ou justement pour éviter ce genre de choses)

avatar smog | 

merci Sometime.
Mais comment rendre ce "paquet frelaté" disponible à tout le monde , C'est ça que je ne comprends pas... Il faut avoir accès à la source qu'utilise l'entreprise ? C'est possible de faire ça ?
Il faut bien "remplacer" le "bon" paquet...

avatar Sometime | 

@smog

Apparemment et entre autres choses si la version du paquet disponible sur le repo public est supérieure a la version disponible en interne, les outils type npm et consort semblent privilégier la source ou la version est la plus « récente ».

Donc en gros vous réservez smog-machin sur mettons npm, vous lui mettez une version suffisamment élevée, et vous attendez. Et la prochaine fois que certains outils/machines vont updater leur paquet, puisque la version frelatée du repo public semble plus récente, c’est celle-ci qui va être privilégiée à la version disponible quelque part en interne (encore une fois cela risque de dépendre de la configuration de la machine qui update ses paquets). En proposant publiquement une version plus récente, vous « surclassez » la source interne aux yeux de l’outil en quelque sorte, donc pas besoin d’accès a celle-ci.

avatar smog | 

@Sometime.
Oui, je comprends bien le truc alors, merci.
Mais pour réserver sur smog-machin ? Je ne dois pas montrer patte blanche ?

avatar Sometime | 

@smog

Je ne suis pas trop au fait du fonctionnement de toutes les plateformes, mais a priori non. Un email, un compte, et si le nom est libre c’est plus ou moins bon il me semble.

avatar smog | 

@sometime : l'informatique est parfois un domaine délirant... Je comprends le côté simplet de ces "attaques" alors. Merci !

avatar marc_os | 

@ Sometime

> A moins que qqn n’est « réservé » le nom...

Mieux serait : A moins que qqn n’ait « réservé » le nom...
(Je fais la remarque parce que j'ai dû m'y reprendre à deux fois pour vous comprendre.)

avatar Sometime | 

@marc_os

Tout a fait, je n’ai malheureusement pas pu éditer après coup a la relecture, l’option n’était plus disponible.

avatar marc_os | 

@ Sometime

Tiens ce n'était plus possible ?
Tant mieux en fait et ce serait une nouveauté ici :
AMHA on ne devrait plus pouvoir modifier un commentaire une fois que quelqu'un y a répondu.
Par contre, "on" pourrait autoriser des ajouts qui seraient marqués comme tels avec date d'ajout...

Pages

CONNEXION UTILISATEUR