Posté par Tangi Colin .
Évalué à 4.
Dernière modification le 30 août 2021 à 14:24.
Quelqu'un aurait plus d'info sur la faille ?
Du lien originel : https://www.wiz.io/blog/chaosdb-how-we-hacked-thousands-of-azure-customers-databases , on comprends qu'ils sont arrivés a passer d'un de leur notebook jupyter à celui d'une victime et donc a partir de la récupérer la clef primaire des db comos. Mais j'aimerai justement savoir comment ils sont passer d'un notebook à l'autre.
Posté par _kaos_ .
Évalué à 3.
Dernière modification le 01 septembre 2021 à 05:48.
J'aurais tendance à suspecter une fuite dans la tuyauterie (un défaut d'isolation des processus).
Si par un moyen ou un autre, on peut accéder à un bout de mémoire partagée, c'est gagné. La subtilité est peut-être là (ce n'est qu'une hypothèse).
Un notebook, de manière générale, ça utilise une REPL, c'est assez puissant à la base donc. Ça peut dépendre de la configuration, et je ne connais pas du tout le cas précis de jupyter, ni la manière dont il est déployé puis utilisé sur azure (instances docker partagées ou non par exemple…).
Dans le cadre d'un service commercial, la tentation est grande : pour qu'un notebook s'ouvre rapidement, il faut un système déjà lancé et prêt à répondre. La mutualisation permet de répondre de manière très rapide, dans une certaine limite, à des besoins ponctuels, d'où peut en découler un manque d'isolation ou un partage de ressources.
Exemple : Doc Azure SQL, on voit bien que le notebook a l'option "attacher à", et que ça tape sur une seule instance (ici, à priori, il faut probablement avoir les droits cependant)
Jadis les grandes compagnies informatiques pouvaient vendre la délocalisation de l'infrastructure avec l'argument suivant : « l'informatique se complexifie, les menaces se font plus sophistiquées, confiez vos données à de vrais experts, vous n'avez plus les moyens de les protéger en interne. »
Voici donc la nouvelle couche pour ces arguments massues : « Même les experts les plus avertis de compagnies spécialisées avec des moyens quasi illimités — les milliards de vos budgets — n'arrivent pas à garantir la sécurité ; alors imaginez ce qui se passerait si vous gériez vous même avec vos médiocres compétences… »
…alors imaginez ce qui se passerait si vous gériez vous même avec vos médiocres compétences… »
Certes je ne suis pas développeur, mais vu de loin, j'ai bien souvent pensé en informatique que c'était comme l'immobilier et qu'il est toujours préférable d'avoir un petit chez soi (quitte à payer un ingénieur sécurité) qu'un grand chez les autres.
Posté par BAud (site web personnel) .
Évalué à 1.
Dernière modification le 30 août 2021 à 22:27.
euh, mais, nous, en France, on a bien un cloud souverain ?!
ou pas :/
('fin si : mais il faudrait le mettre en valeur, réponse oui vu toutes les PME qui y travaillent et financées pour certaines par l'État d'ailleurs, la main gauche ne voit pas ce que fait la droite…)
# Details complet de l'attaque ?
Posté par Tangi Colin . Évalué à 4. Dernière modification le 30 août 2021 à 14:24.
Quelqu'un aurait plus d'info sur la faille ?
Du lien originel : https://www.wiz.io/blog/chaosdb-how-we-hacked-thousands-of-azure-customers-databases , on comprends qu'ils sont arrivés a passer d'un de leur notebook jupyter à celui d'une victime et donc a partir de la récupérer la clef primaire des db comos. Mais j'aimerai justement savoir comment ils sont passer d'un notebook à l'autre.
[^] # Re: Details complet de l'attaque ?
Posté par Flavien . Évalué à 1.
Ce n'est pas encore expliqué.
Au mieux une vidéo floutée de l'exploit
https://youtu.be/xaFs7y1jydc
[^] # Re: Details complet de l'attaque ?
Posté par _kaos_ . Évalué à 3. Dernière modification le 01 septembre 2021 à 05:48.
J'aurais tendance à suspecter une fuite dans la tuyauterie (un défaut d'isolation des processus).
Si par un moyen ou un autre, on peut accéder à un bout de mémoire partagée, c'est gagné. La subtilité est peut-être là (ce n'est qu'une hypothèse).
Un notebook, de manière générale, ça utilise une REPL, c'est assez puissant à la base donc. Ça peut dépendre de la configuration, et je ne connais pas du tout le cas précis de jupyter, ni la manière dont il est déployé puis utilisé sur azure (instances docker partagées ou non par exemple…).
Dans le cadre d'un service commercial, la tentation est grande : pour qu'un notebook s'ouvre rapidement, il faut un système déjà lancé et prêt à répondre. La mutualisation permet de répondre de manière très rapide, dans une certaine limite, à des besoins ponctuels, d'où peut en découler un manque d'isolation ou un partage de ressources.
Exemple : Doc Azure SQL, on voit bien que le notebook a l'option "attacher à", et que ça tape sur une seule instance (ici, à priori, il faut probablement avoir les droits cependant)
Matricule 23415
# Un argument de plus pour planer dans les nuages
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Jadis les grandes compagnies informatiques pouvaient vendre la délocalisation de l'infrastructure avec l'argument suivant : « l'informatique se complexifie, les menaces se font plus sophistiquées, confiez vos données à de vrais experts, vous n'avez plus les moyens de les protéger en interne. »
Voici donc la nouvelle couche pour ces arguments massues : « Même les experts les plus avertis de compagnies spécialisées avec des moyens quasi illimités — les milliards de vos budgets — n'arrivent pas à garantir la sécurité ; alors imaginez ce qui se passerait si vous gériez vous même avec vos médiocres compétences… »
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Un argument de plus pour planer dans les nuages
Posté par TuxMips . Évalué à 5.
Certes je ne suis pas développeur, mais vu de loin, j'ai bien souvent pensé en informatique que c'était comme l'immobilier et qu'il est toujours préférable d'avoir un petit chez soi (quitte à payer un ingénieur sécurité) qu'un grand chez les autres.
[^] # Re: Un argument de plus pour planer dans les nuages
Posté par cg . Évalué à 5.
J'avais lu ce mini bouquin gratuit de chez OReilly, ça date un peu (2016), mais de mémoire ça m'avait bien plu.
Cracking security misconceptions, en HTML sur une page, ou en PDF
Voir le "Misconception #6: Big Organizations Are the Most Secure" par exemple.
[^] # Re: Un argument de plus pour planer dans les nuages
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 30 août 2021 à 22:27.
euh, mais, nous, en France, on a bien un cloud souverain ?!
ou pas :/
('fin si : mais il faudrait le mettre en valeur, réponse oui vu toutes les PME qui y travaillent et financées pour certaines par l'État d'ailleurs, la main gauche ne voit pas ce que fait la droite…)
[^] # Re: Un argument de plus pour planer dans les nuages
Posté par cg . Évalué à 0.
Absolument, Français, ce nuage, mes chers compatriotes !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.