Sécurité : la « confusion des dépendances » a aussi touché Apple
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.
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.
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. »
🤣
L’idée est excellente. Simple et terriblement efficace.
La simplicité de la méthode fait froid dans le dos... 🥶
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.
@filaton +1, leurs admins systèmes ont de la chance sur ce coup.
@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.
Les paquets devraient surtout être signés plutôt q'uniquement hashés.
@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 !"
@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....
on ne dit pas laxiste, on dit Agile !
@ 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 !
@oomu
Sinon tu as des services qui font ça pour toi. Genre tidelift. Ils certifient les version, licences etc
je note ce service tidelift, merci.
En mettant le lien direct du dépôt en question meme privé impossible qu’il tape le registre global 🙃
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.
"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 ?
@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)
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...
@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.
@Sometime.
Oui, je comprends bien le truc alors, merci.
Mais pour réserver sur smog-machin ? Je ne dois pas montrer patte blanche ?
@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.
@sometime : l'informatique est parfois un domaine délirant... Je comprends le côté simplet de ces "attaques" alors. Merci !
@ 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.)
@marc_os
Tout a fait, je n’ai malheureusement pas pu éditer après coup a la relecture, l’option n’était plus disponible.
@ 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...
@marc_os
Depuis l’application en tout cas il y a une durée après laquelle l’edit n’apparaît plus possible. Après je n’ai pas vu ça immédiatement non plus, donc le délai est peut-être tout a fait raisonnable.
@ Sometime
Ah... L'application et le (ou plutôt les) site(s) web de macg n'ont donc pas le même comportement.
De mon côté j'ai abandonné l'app de macg il y a un bon moment car elle faisait trop chauffer mon iPhone à mon goût. Et depuis je ne passe plus que par le site web et sur ordi uniquement. Du coup, en effet kiss cool, ça limite le temps que je passe ici et donc le nombre de mes interventions, et c'est bien comme ça. ;-) Je viens donc trainer ici quand j'ai des petites pauses forcées, comme là présentement où j'attends que la "notarisation" du machin sur lequel je travaille veuille bien se terminer, ce qui prends 4 à 6 minutes en moyenne...
Plutôt aujourd'hui je me plaignais du fait qu'on puisse modifier (sur le site web) des commentaires après que quelqu'un ait répondu, et qu'il soit possible d'enregistrer une réponse alors qu'entre deux le commentaire avait été modifié....
Sans surprise encore NPM. La qualité JavaScript ça se paie à un moment ou un autre.
Solution radicale mais la seule fiable à mon avis :
Copier sur un serveur local toute resource externe et n'utiliser que ces copies - qu'on aura pris le temps au préalable de valider (QA), surtout s'il y a eu une mise à jour sur le serveur publique.
Et régler son pare-feu ou ses paramètres réseau pour empêcher toute récupération "automatique" de projets open source sur Internet.