it-swarm.com.de

Wie können Twitter und GitHub sicher sein, dass sie nicht gehackt wurden?

Gestern hat Twitter angekündigt angegeben, dass kürzlich ein Fehler festgestellt wurde, bei dem Kennwörter entlarvt in einem internen Protokoll gespeichert wurden. Vor kurzem hatte Github auch einen ähnlicher Fehler . In beiden Fällen behaupten sie, dass niemand Zugriff auf diese Dateien hatte.

Twitter:

Wir haben den Fehler behoben und unsere Untersuchung zeigt keinen Hinweis auf einen Verstoß oder Missbrauch durch irgendjemanden.

Auch wenn wir keinen Grund zu der Annahme haben, dass Passwortinformationen jemals die Systeme von Twitter verlassen haben oder von irgendjemandem missbraucht wurden, können Sie einige Schritte unternehmen, um die Sicherheit Ihres Kontos zu gewährleisten:

GitHub:

Das Unternehmen gibt an, dass die Klartext-Passwörter nur einer kleinen Anzahl von GitHub-Mitarbeitern mit Zugriff auf diese Protokolle zugänglich gemacht wurden. Laut Angaben des Unternehmens haben keine anderen GitHub-Benutzer die Klartext-Passwörter der Benutzer gesehen.

GitHub sagte, es habe seinen Fehler während eines Routine-Audits entdeckt und klargestellt, dass seine Server nicht gehackt wurden.

Zu beachten ist, dass GitHub in keiner Weise gehackt oder kompromittiert wurde.

Wie können Twitter und GitHub sicher sein , dass sie in keiner Weise gehackt oder kompromittiert wurden? Würde jemand, der einen Server kompromittiert und eine Datei liest/kopiert, immer Spuren hinterlassen?

73
Kepotx

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 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.

118
Anders

Zu beachten ist außerdem, 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 von dem Fehler selbst erfahren, was bedeutet, dass es unwahrscheinlich ist, dass Personen außerhalb des Unternehmens von diesem Fehler Kenntnis hatten, bevor Twitter es war, geschweige denn herausgefunden und einen Angriff ausgeführt hat, um sie abzurufen.

20
Nzall

Es ist schwer, ein Negativ zu beweisen.

Wie beweisen Sie ein positives Ergebnis? 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 zu einer bestimmten Benutzergruppe gehört, 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 sie ebenfalls protokolliert worden, jedoch wie erwartet.

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

Ich vermute , dass nach dem Erkennen der Protokolldatei alle diese Protokolle gründlich analysiert wurden, um zu beweisen, ob es einen Angriff von außen gab. Die Analysten fanden keine verdächtigen Daten und kamen daher zu dem Schluss, dass mit fast 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 if Es gab einen Hack. (Hat nicht wirklich geklappt .;)

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

10
Tom K.

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 sich das alles beweisen können Der Zugang erfolgte durch legitime Mitarbeiter, von denen sie sicher sagen können, dass sie nicht gehackt wurden. Beachten Sie, dass dies nicht garantiert, dass sie nicht gehackt werden, sondern dass alle Beweise in diese Richtung weisen.

5
kevin

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. Sie sagen, dass es "keinen Grund zu der Annahme gibt, 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ß vorliegt.
1
MahNas92

Meine Interpretation, insbesondere der kühneren GitHub-Anweisung, ist, dass sie sagen wollen, 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 versehentlich Debugging-Code einführt Produktion. Dies ist relevant, da ein Angreifer diese Funktionalität 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.

0
johannes

Große Unternehmen wie dieses sollten viele Server haben und daher wird der gesamte Zugriff von außen über einen Bastion Host geleitet (außerhalb bedeutet nicht innerhalb des tatsächlichen Serverkäfigs/-raums). 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.

0
user177420

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 mögen die Person als Angestellter anders sehen, 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.

0
Sentinel