Comment Twitter et GitHub peuvent-ils être sûrs qu'ils n'ont pas été piratés?
Hier, Twitter annoncé qu'ils ont récemment identifié un bogue qui stockait des mots de passe démasqués dans un journal interne. Récemment, Github avait également un bug similaire . Dans les deux cas, ils affirment que personne n'avait accès à ces fichiers.
Twitter:
Nous avons corrigé le bogue, et notre enquête ne montre aucune indication de violation ou d'utilisation abusive par quiconque.
Encore une fois, bien que nous n'ayons aucune raison de croire que les informations sur les mots de passe ont déjà quitté les systèmes de Twitter ou ont été utilisées à mauvais escient par quiconque, vous pouvez prendre quelques mesures pour nous aider à protéger votre compte:
GitHub:
La société affirme que les mots de passe en texte brut n'ont été exposés qu'à un petit nombre d'employés de GitHub ayant accès à ces journaux. Aucun autre utilisateur de GitHub n'a vu les mots de passe en clair des utilisateurs, a déclaré la société.
GitHub a déclaré avoir découvert son erreur lors d'un audit de routine et précisé que ses serveurs n'avaient pas été piratés.
À noter, GitHub n'a été piraté ou compromis d'aucune façon.
Comment Twitter et GitHub peuvent-ils être sûrs qu'ils n'ont pas été piratés ou compromis de quelque manière que ce soit? Est-ce que quelqu'un qui compromet un serveur et qui lit/copie un fichier laisse toujours des traces?
Ils ne peuvent pas en être sûrs. En fait, vous ne pouvez jamais être sûr que vous n'avez pas été piraté. Mais un examen approfondi peut vous faire conclure que c'est plus ou moins probable.
Les déclarations de Twitter indiquent seulement qu'il n'y a aucune indication de piratage. Cela n'exclut pas la possibilité qu'ils aient été piratés, et en exhortant leurs utilisateurs à changer leurs mots de passe, ils l'admettent implicitement.
Quant à GitHub, la formulation est un peu plus catégorique. Mais je pense que forcer une réinitialisation du mot de passe montre qu'ils comprennent les risques impliqués.
Une autre chose à noter est que dans les deux cas, la fuite s'est produite dans un système d'enregistrement purement interne. Rien n'indique que des utilisateurs tiers aient jamais eu accès à ce système. Les systèmes de journalisation internes sont rarement exposés en externe et ne sont consultés en interne que lorsqu'un système nécessite un dépannage. C'est aussi probablement la raison pour laquelle ce bogue est passé inaperçu pendant des mois: des entrées de journal singulières quelque part dans ce qui est probablement une quantité gigantesque d'autres instructions ne sont généralement pas remarquées, sauf si elles se trouvent juste à côté ou au milieu des instructions nécessaires pour déboguer d'autres entrées.
Twitter n'a également découvert que récemment le bogue lui-même, ce qui signifie qu'il est peu probable que des personnes extérieures à l'entreprise soient au courant de ce bogue avant que Twitter ne le sache, et encore moins ait compris et exécuté une attaque pour les récupérer.
Il est difficile de prouver un résultat négatif.
Alors, comment prouver un résultat positif? Dans ce cas: comment prouver une attaque de l'extérieur? En règle générale, plusieurs systèmes sont en place pour surveiller différentes formes d'attaques, de violations ou d'accès. Il peut s'agir de pare-feu, de systèmes de détection d'intrusions, SIEM et d'une variété de systèmes de surveillance et de journalisation. Dans les réseaux actuels, chaque composant a une forme de surveillance ou permet une surveillance via des outils tiers tels que Check_MK.
Ainsi, chaque étape du processus - de la frontière du réseau d'entreprise à la machine qui contenait les informations précieuses elles-mêmes - est sous une forme ou une autre contrôlée. Ces journaux sont, selon le réseau et les politiques de l'entreprise, régulièrement analysés. Les systèmes d'analyse peuvent faire la distinction entre le trafic ou le comportement attendu et inattendu. Le comportement non/attendu est par exemple l'accès aux fichiers.
Les fichiers journaux internes sont généralement considérés comme des données confidentielles, donc l'accès aux fichiers est probablement également surveillé. Si quelqu'un qui ne fait pas partie d'un certain groupe d'utilisateurs tente de copier/accéder à un fichier journal interne, cela aurait probablement été enregistré comme un comportement inattendu ou même interdit. Si un adversaire potentiel avait pu usurper l'identité d'une personne ayant les droits d'accès à ce fichier, il aurait également été enregistré, mais comme prévu.
En théorie, il est possible qu'un attaquant soit en mesure de surmonter tous les contrôles de sécurité, d'exploiter les vulnérabilités 0day, de ne laisser aucune trace dans chaque journal de chaque composant, l'IDS, le SIEM, etc., de copier le fichier journal interne et de le faire passer à l'extérieur, mais c'est très peu probable.
Je suppose qu'après la découverte du fichier journal, tous ces journaux ont été soigneusement analysés pour essayer de prouver s'il y avait une attaque de l'extérieur. Les analystes n'ont trouvé aucune donnée suspecte et ont donc conclu que avec une certitude presque absolue il n'y a pas eu d'attaque de l'extérieur. Et c'est en fait ce que vous voyez dans le communiqué de presse de Twitter (voir le commentaire de Florin Coada). Encore une fois, je suppose: le communiqué de presse de GitHub avait un langage plus strict pour arrêter les spéculations si il y avait un hack. (Ça n'a pas vraiment marché.;)
Bien sûr, il est également possible que Twitter et GitHub n'aient pas de tels contrôles de sécurité en place, mais j'espère vraiment que non.
Je suppose qu'ils ont des journaux d'accès pour à peu près tout ce qui se passe sur leurs serveurs, ils peuvent vérifier si quelqu'un a accédé au fichier, quand cela s'est produit, avec quel alias ils se sont connectés, leur adresse IP source, etc. S'ils peuvent se prouver que tous l'accès était par des employés légitimes, ils peuvent dire en toute confiance qu'ils n'ont pas été piratés. Notez que cela ne garantit pas qu'ils ne soient pas piratés, mais que toutes les preuves vont dans ce sens.
La réponse est très simple. Nulle part ils n'affirment qu'ils sont sûrs. En fait, ils vous impliquent implicitement qu'il pourrait y avoir eu une violation de deux manières:
- Ils affirment qu'il n'y a "aucune raison de croire qu'il y avait" ou "aucune preuve" d'une violation. Le manque de preuves pourrait simplement signifier que le ou les intrus ont couvert leurs traces.
- Ils vous implorent de changer votre mot de passe, juste pour être du bon côté. Cela implique qu'ils ne peuvent garantir qu'aucune violation ne s'est produite.
Mon interprétation de, en particulier de la déclaration GitHub plus audacieuse, est qu'ils veulent dire que le fait que les mots de passe ont été placés dans le fichier journal n'est pas le résultat d'une attaque de piratage, mais le résultat d'un développeur introduisant accidentellement du code de débogage dans production. Ceci est pertinent car un attaquant pourrait avoir introduit cette fonctionnalité afin de collecter des mots de passe pour les récupérer plus tard.
Il n'y a aucune garantie qu'ils n'ont jamais été piratés et ne le seront jamais, mais cet incident est indépendant des tentatives de piratage.
Les grandes entreprises comme celle-ci devraient avoir beaucoup de serveurs et, par conséquent, tout accès extérieur est acheminé via un hôte bastion (ce qui signifie en dehors de l'intérieur de la cage/salle du serveur). Le bastion pourrait dire que la journalisation est configurée d'une certaine manière car elle relaie toutes les commandes du réseau extérieur vers les serveurs opérationnels. Les commandes, si elles sont enregistrées, pourraient facilement être utilisées pour dire si quelqu'un a ouvert un fichier avec vim par exemple et cela résoudrait la question de savoir si un utilisateur avait été piraté. L'accès SSH est également consigné, de sorte qu'une "bonne" IP/s connue peut être filtrée pour un utilisateur et toute entrée suspecte ou impaire pourrait être examinée par le service informatique et si une entrée n'a pas pu être expliquée, cela constituerait une violation. Sinon, le serveur serait "sûr" et il n'y aurait pas autant besoin de s'inquiéter à ce sujet.
Ce qu'ils disent en fait, c'est qu'ils sont sûrs à 100% qu'il y a bien eu une violation de la sécurité. Accidentellement. Probablement. Et par eux-mêmes. Le reste est brillant.
Ils peuvent voir l'individu différemment, comme un employé, mais je ne le pense pas. Un bon hacker travaille de l'intérieur et gagne la confiance. NSA? FSB?
Ils ne devraient jamais avoir accès en texte brut à nos mots de passe. Ce n'est pas ainsi que fonctionne l'accès par mot de passe. Les implications sont que c'est maintenant à vous de changer ce mot de passe partout où vous l'utilisez. Supposons que le mot de passe est désormais connu de tous.