Sie können nicht sicher sein. In der Tat können Sie nie sicher sein, dass Sie nicht gehackt wurden. Eine gründliche Untersuchung kann jedoch zu dem Schluss führen, dass dies mehr oder weniger wahrscheinlich ist.

Die Twitter-Aussagen besagen nur, dass es keinen Hinweis auf einen Hack gibt. Das schließt die Möglichkeit nicht aus, dass sie gehackt wurden, und indem sie ihre Benutzer auffordern, ihre Passwörter zu ändern, geben sie dies implizit zu.

Bei GitHub ist der Wortlaut etwas kategorischer. Ich denke jedoch, dass das Erzwingen eines Zurücksetzens des Passworts zeigt, dass sie die damit verbundenen Risiken verstehen.

Eine weitere Anmerkung ist, dass sich das Leck in beiden Fällen in einem rein internen Protokollierungssystem befand. Es gibt keinen Hinweis darauf, dass Benutzer von Drittanbietern jemals Zugriff auf dieses System hatten. Interne Protokollierungssysteme werden selten extern verfügbar gemacht und nur dann intern konsultiert, wenn ein System eine Fehlerbehebung benötigt. Dies ist wahrscheinlich auch der Grund, warum dieser Fehler monatelang unbemerkt blieb: Einzelne Protokolleinträge irgendwo in einer wahrscheinlich riesigen Menge anderer Anweisungen werden normalerweise nicht bemerkt, es sei denn, sie befinden sich direkt neben oder mitten in den erforderlichen Anweisungen Debuggen Sie andere Einträge.

Twitter hat auch erst kürzlich selbst von dem Fehler erfahren, was bedeutet, dass es unwahrscheinlich ist, dass Personen außerhalb des Unternehmens diesen Fehler vor Twitter kannten, geschweige denn herausgefunden und einen Angriff ausgeführt haben Rufen Sie sie ab.

Es ist schwer, ein Negativ zu beweisen.

Wie beweisen Sie also ein Positiv? In diesem Fall: Wie beweisen Sie einen Angriff von außen? In der Regel sind mehrere Systeme vorhanden, um verschiedene Formen von Angriffen, Sicherheitsverletzungen oder Zugriff zu überwachen. Dies können Firewalls, Intrusion Detection-Systeme, SIEMs und eine Vielzahl von Überwachungs- und Protokollierungssystemen sein. In heutigen Netzwerken verfügt jede Komponente entweder über eine Überwachung oder ermöglicht die Überwachung über Tools von Drittanbietern wie Check_MK.

Jeder Schritt auf dem Weg - von der Grenze des Unternehmensnetzwerks bis zur Maschine, auf der die wertvollen Informationen selbst gespeichert sind - wird in irgendeiner Form überwacht. Diese Protokolle werden abhängig von den Netzwerk- und Unternehmensrichtlinien regelmäßig analysiert. Die Analysesysteme können zwischen erwartetem und unerwartetem Verkehr oder Verhalten unterscheiden. Unerwartetes Verhalten ist beispielsweise der Dateizugriff.

Interne Protokolldateien werden normalerweise als vertrauliche Daten betrachtet, sodass der Dateizugriff wahrscheinlich auch überwacht wird. Wenn jemand, der nicht Teil einer bestimmten Benutzergruppe ist, versucht, eine interne Protokolldatei zu kopieren / darauf zuzugreifen, wurde dies wahrscheinlich als unerwartetes oder sogar verbotenes Verhalten protokolliert. Wenn ein möglicher Gegner sich als jemand mit den Rechten zum Zugriff auf diese Datei ausgeben könnte, wäre diese ebenfalls protokolliert worden, jedoch wie erwartet.

Theoretisch ist es möglich, dass ein Angreifer sie überwinden kann Alle Sicherheitskontrollen nutzen 0-Tage-Schwachstellen aus, hinterlassen keine Spuren in jedem Protokoll jeder Komponente, des IDS, des SIEM usw., kopieren die interne Protokolldatei und schmuggeln sie nach draußen, dies ist jedoch sehr unwahrscheinlich.

Ich vermute , dass nach dem Erkennen der Protokolldatei alle diese Protokolle gründlich analysiert wurden, um zu beweisen, ob ein Angriff von außen stattgefunden hat. Die Analysten fanden keine verdächtigen Daten und kamen daher zu dem Schluss, dass mit nahezu absoluter Sicherheit kein Angriff von außen erfolgte. Und genau das sehen Sie in der Pressemitteilung von Twitter (siehe Florin Coadas Kommentar). Nochmals meine Vermutung: GitHubs Pressemitteilung hatte eine strengere Sprache, um Spekulationen zu stoppen, wenn es einen Hack gab. (Hat nicht wirklich geklappt .;)

^{Natürlich ist es auch möglich, dass Twitter und GitHub keine solchen Sicherheitskontrollen eingerichtet haben, aber ich hoffe wirklich nicht. Sup>}

Ich gehe davon aus, dass sie Zugriffsprotokolle für fast alles haben, was auf ihren Servern passiert. Sie können überprüfen, ob jemand auf die Datei zugegriffen hat, wann dies war, mit welchem ​​Alias ​​sie sich angemeldet haben, mit welcher Quell-IP-Adresse usw. Wenn sie dies nachweisen können selbst, dass der gesamte Zugriff von legitimen Mitarbeitern erfolgte, können sie zuversichtlich sagen, dass sie nicht gehackt wurden. Beachten Sie, dass dies nicht garantiert, dass sie nicht gehackt werden, sondern dass alle Beweise in diese Richtung weisen.

Die Antwort ist sehr einfach. Nirgendwo geben sie an, dass sie sicher sind. Tatsächlich sagen sie Ihnen implizit, dass es tatsächlich auf zwei Arten einen Verstoß gegeben haben könnte:

1. Das sagen sie dort ist "kein Grund zu der Annahme, dass es einen Verstoß gab" oder "keine Beweise dafür". Mangelnde Beweise könnten einfach bedeuten, dass die Eindringlinge ihre Spuren verwischt haben.
2. Sie bitten Sie, Ihr Passwort zu ändern, um auf der sicheren Seite zu sein. Dies bedeutet, dass sie nicht garantieren können, dass kein Verstoß aufgetreten ist.
ol>

Meine Interpretation, insbesondere der kühneren GitHub-Anweisung, lautet, dass sie sagen möchten, dass die Tatsache, dass die Passwörter in die Protokolldatei eingegeben wurden, nicht das Ergebnis eines Hacking-Angriffs ist, sondern das Ergebnis eines Entwicklers, der Debugging-Code einführt durch Zufall in die Produktion. Dies ist relevant, da ein Angreifer diese Funktion möglicherweise eingeführt hat, um Kennwörter zu sammeln, um sie später abzurufen.

Es gibt keine Garantie dafür, dass sie nie gehackt wurden und niemals gehackt werden, aber dieser Vorfall ist unabhängig von Hacking-Versuchen.

Große Unternehmen wie dieses sollten viele Server haben, und daher wird der gesamte externe Zugriff über einen Bastion-Host geleitet (außerhalb bedeutet, dass er nicht aus dem tatsächlichen Serverkäfig / -raum stammt). Die Bastion hat möglicherweise die Protokollierung so eingerichtet, dass sie alle Befehle vom externen Netzwerk an die Betriebsserver weiterleitet. Die protokollierten Befehle können leicht verwendet werden, um festzustellen, ob jemand beispielsweise eine Datei mit vim geöffnet hat, und dies würde die Frage lösen, ob ein Benutzer gehackt wurde. Der SSH-Zugriff wird ebenfalls protokolliert, sodass eine bekannte "gute" IP / s für einen Benutzer herausgefiltert werden kann und verdächtige oder ungerade Einträge von der IT geprüft werden können. Wenn ein Eintrag nicht erklärt werden konnte, würde dies einen Verstoß darstellen. Andernfalls wäre der Server "sicher" und es wäre nicht so wichtig, sich in dieser Angelegenheit Sorgen zu machen.

Was sie tatsächlich sagen, ist, dass sie zu 100% sicher sind, dass tatsächlich eine Sicherheitsverletzung vorliegt. Versehentlich. Wahrscheinlich. Und für sich. Der Rest ist Glanz.

Sie sehen die Person als Angestellter möglicherweise anders, aber ich nicht. Ein guter Hacker arbeitet von innen und gewinnt Vertrauen. NSA? FSB?

Sie sollten niemals Klartextzugriff auf unsere Passwörter haben. So funktioniert der Passwortzugriff nicht. Die Auswirkungen sind, dass es nun an Ihnen liegt, dieses Passwort überall dort zu ändern, wo Sie es jemals verwenden. Angenommen, das Passwort ist jetzt allen bekannt.