Ils ne peuvent pas être sûrs. En fait, vous ne pouvez jamais être sûr de ne pas avoir été piraté. Mais un examen approfondi peut vous faire conclure que c'est plus ou moins probable.

Les déclarations 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, le libellé est un peu plus catégorique. Mais je pense que forcer une réinitialisation de mot de passe montre qu'ils comprennent les risques encourus.

Une autre chose à noter est que dans les deux cas, la fuite était dans un système de journalisation purement interne. Rien n'indique que des utilisateurs tiers aient déjà eu accès à ce système. Les systèmes de journalisation internes sont rarement exposés à l'extérieur 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: les 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 à moins qu'elles ne 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 le bogue que récemment, ce qui signifie qu'il est peu probable que des personnes extérieures à l'entreprise aient été au courant de ce bogue avant que Twitter ne soit, encore moins découvert et exécuté une attaque contre récupérez-les.

Il est difficile de prouver un négatif.

Alors, comment prouver un 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'intrusion, de SIEM et de divers systèmes de surveillance et de journalisation. Dans les réseaux actuels, chaque composant dispose d'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 elle-même - est sous une forme ou une autre surveillée. Ces journaux sont, en fonction du réseau et des 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 essaie de copier / accéder à un fichier journal interne, cela aurait probablement été consigné comme un comportement inattendu ou même interdit. Si un éventuel adversaire était capable de se faire passer pour quelqu'un avec les droits d'accès à ce fichier, il aurait également été enregistré, mais en tant que comportement attendu.

En théorie, il est possible qu'un attaquant soit capable de surmonter tous les contrôles de sécurité, exploiter les vulnérabilités 0day, ne laisser aucune trace dans chaque journal sur chaque composant, l'IDS, le SIEM et ainsi de suite, copier le fichier journal interne et le faire passer en contrebande à 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 eu une attaque de l'extérieur. Les analystes n'ont trouvé aucune donnée suspecte et ont donc conclu que avec une certitude quasi absolue il n'y avait 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. (Cela n'a pas vraiment fonctionné.;)

^{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, à quel moment, avec quel alias ils se sont connectés, leur adresse IP source, etc. S'ils peuvent le prouver eux-mêmes que tout accès était par des employés légitimes, ils peuvent affirmer en toute confiance qu'ils n'ont pas été piratés. Notez que cela ne garantit pas qu'ils ne seront pas piratés, mais que toutes les preuves pointent dans cette direction.

La réponse est très simple: nulle part ils ne déclarent être sûrs, en fait, ils vous disent implicitement qu'il pourrait y avoir eu une brèche de deux manières:

1. 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.
2. Ils vous implorent de changer votre mot de passe, juste par prudence. Cela implique qu'ils ne peuvent pas garantir qu'aucune violation ne s'est produite.

Mon interprétation de, en particulier de l'instruction GitHub plus audacieuse, est qu'ils veulent dire que le fait que les mots de passe aient é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 du code de débogage par accident en 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 contre les tentatives de piratage.

Les grandes entreprises comme celle-ci devraient avoir beaucoup de serveurs et donc tout accès extérieur est acheminé via un hôte bastion (à l'extérieur, ce qui signifie pas à partir de la cage / salle du serveur). Le bastion aurait peut-être mis en place la journalisation, car il relaie toutes les commandes du réseau extérieur vers les serveurs opérationnels. Les commandes si journalisé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é afin qu'une "bonne" adresse IP connue puisse être filtrée pour un utilisateur et toute entrée suspecte ou étrange 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 effectivement eu une faille de sécurité. Accidentellement. Probablement. Et par eux-mêmes. Le reste est brillant.

Ils peuvent voir l'individu différemment, en tant qu'employé, mais pas moi. Un bon hacker travaille de l'intérieur et gagne en 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 soit maintenant connu de tous.