Ein tieferer Einblick in den Sicherheitsvorfall vom Mai 2019: Feedback zu Blog-Posts
Wir haben gerade ein Update zu dem Sicherheitsvorfall veröffentlicht , der im Mai 2019 passiert ist, mit technischen Details darüber, was passiert ist, wie es passiert ist und welche Abhilfemaßnahmen wir angewendet haben, um zu verhindern, dass ein solcher Vorfall erneut auftritt. Hier ein paar Auszüge aus dem Beitrag - zuerst aus der Einleitung:
Am 12. Mai 2019, gegen 00:00 UTC, wurden wir von mehreren Mitgliedern der Community auf eine unerwartete Eskalation von Berechtigungen für ein neues Benutzerkonto aufmerksam gemacht. Ein Benutzer, den niemand erkannte, hatte Zugriff auf Moderator- und Entwicklerebene auf allen Websites im Stack Exchange-Netzwerk erhalten. Unsere sofortige Reaktion bestand darin, Berechtigungen zu widerrufen und dieses Konto zu sperren und dann einen Prozess in Gang zu setzen, um die Aktionen zu identifizieren und zu prüfen, die zu dem Ereignis geführt haben.
Nach der ersten Entdeckung stellten wir fest, dass die Eskalation der Privilegien nur die Spitze des Eisbergs war und der Angriff tatsächlich zur Exfiltration unseres Quellcodes und zur unbeabsichtigten Offenlegung der PII (E-Mail, richtiger Name, IP-Adressen) von 184 Benutzern geführt hatte des Stack Exchange Network (alle wurden benachrichtigt). Zum Glück wurde keine der Datenbanken - weder öffentlich (gelesen: Stack Exchange-Inhalt) noch privat (Teams, Talente oder Unternehmen) - exfiltriert. Darüber hinaus gab es keine Hinweise auf einen direkten Zugriff auf unsere interne Netzwerkinfrastruktur, und der Angreifer hatte zu keinem Zeitpunkt Zugriff auf Daten in Teams, Talenten oder Enterprise-Produkten.
Und aus dem letzten Absatz:
Dieser Vorfall erinnerte uns an einige grundlegende Sicherheitspraktiken, die jeder befolgen sollte:
- Protokollieren Sie Ihren gesamten eingehenden Datenverkehr. Wir führen Protokolle über alle eingehenden Verbindungen. Dies ermöglichte alle unsere Untersuchungen. Sie können nicht untersuchen, was Sie nicht protokollieren.
- Verwenden Sie 2FA. Das verbleibende System, das noch die Legacy-Authentifizierung verwendet, kann Ihre größte Sicherheitsanfälligkeit sein.
- Wachgeheimnisse besser. TeamCity hat eine Möglichkeit, Geheimnisse zu schützen, aber wir haben festgestellt, dass wir es nicht konsequent verwenden. Informieren Sie die Ingenieure darüber, dass "Geheimnisse nicht nur Passwörter sind". Schützen Sie auch SSH-Schlüssel und Datenbankverbindungszeichenfolgen. Wenn Sie Zweifel haben, schützen Sie sie. Wenn Sie Geheimnisse in einem Git-Repo speichern müssen, schützen Sie sie mit Git-Crypt oder Blackbox .
- Kundenanfragen validieren. Je ungewöhnlicher eine Anfrage eines Kunden ist, desto wichtiger ist es zu überprüfen, ob die Anfrage legitim ist oder nicht.
- Nehmen Sie Sicherheitsberichte ernst. Wir sind dankbar, dass unsere Community verdächtige Aktivitäten so schnell gemeldet hat. Vielen Dank!
Der Blog-Beitrag enthält noch viel mehr. Sie können gerne Fragen oder Kommentare zu dem folgenden Beitrag stellen, und wir werden unser Bestes tun, um diese zu beantworten. Aufgrund laufender Untersuchungen können wir keine weiteren Details im Zusammenhang mit dem Angriff kommentieren, die über die Angaben im Blog-Beitrag hinausgehen.
Antworten
Können Sie einen Kommentar zu den Absichten des Angreifers abgeben?
Scheint es, dass sie nach einem bestimmten Ziel / bestimmten (Benutzer-) Daten waren?
Oder war es vielleicht eher ein "neugieriger Teenager", der mit Stöcken stocherte, um zu sehen, wie weit sie kommen konnten?
PS danke für die Offenheit in dieser Angelegenheit, es wird wirklich geschätzt!
Diese Linie:
Dieses Nachschlagen (Besuchen von Fragen) im Stack Exchange-Netzwerk kommt häufig vor und ermöglicht es uns, die Methodik des Angreifers in den kommenden Tagen zu antizipieren und zu verstehen. (Hervorhebung von mir)
Es klingt so , als ob Sie in Echtzeit während des Angriffs genau bestimmen könnten, was der Angreifer tun würde, basierend auf dem, was er bei Stack Overflow besucht hat, anstatt das, was er getan hat, indem er forensisch betrachtet, was er (nach dem Angriff) angesehen hat. Welches hast du gemeint?
Einige Fragen betrafen hauptsächlich den Angreifer:
- Was ist mit dem Angreifer passiert?
- Haben Sie ihr Konto gesperrt?
- Hat SE den Angreifer zu irgendeinem Zeitpunkt kontaktiert?
- Warum enthüllen Sie nicht die Identität des Angreifers?
- Hat jemand später versucht, dieselbe Angriffsmethode zu verwenden?
Gab es am anderen Ende der Ereignisse einen erkennbaren Schlafzyklus?
Bearbeiten, um zu verdeutlichen:
Nachdem Sie auf den Angreifer aufmerksam geworden sind und einige ihrer Aktionen im Verlauf verfolgt haben, haben Sie etwas bemerkt, das sowohl täglich als auch nachträglich einem biologischen Zyklus ähnelt? ZB: Essen (1-2 Stunden Pausen), Schlafen (8 Stunden Inaktivitätsmuster), "Power Naps" (90 Minuten) usw.?
Dies ist nicht wirklich Teil des Vorfalls, sondern eine allgemeinere Sorge um Sicherheitsmaßnahmen in Bezug auf Mitarbeiterkonten. Es gab viele Schritte in diesem Vorfall, aber der letzte war die Eskalation der Berechtigungen eines SE-Kontos. Ich kann mir viel einfachere Möglichkeiten vorstellen, dies zu versuchen, als über die Dev-Instanz Administratorzugriff auf den CI-Server zu erhalten, um SQL in der Produktion auszuführen, und ich bin daran interessiert, welche Abhilfemaßnahmen und Sicherheitspraktiken SE implementiert hat, um sich gegen einfachere Versuche zu verteidigen Zugriff auf ein Mitarbeiterkonto.
Sie können die wichtigsten SE-Sites nicht offensichtlich hinter der Firewall platzieren, sodass sie immer verfügbar sind. Und die interne SE-Anmeldemethode bietet keine 2FA-Methoden, die ich etwas besorgniserregend finde.
- Sind Mitarbeiterkonten 2FA durch andere Mittel (oder andere Login-Anbieter) geschützt?
- Gibt es Maßnahmen, um sicherzustellen, dass keine privaten E-Mail-Adressen oder Anmeldeanbieter an Mitarbeiterkonten angehängt werden, die möglicherweise weniger sicher sind und dennoch zum Empfangen von Wiederherstellungs-E-Mails verwendet werden, um Zugriff auf das Konto zu erhalten?
- Gibt es eine Überwachung von Anmeldeversuchen aus neuen Quellen für Mitarbeiterkonten?
- Gibt es zusätzlichen Schutz für gefährliche Mitarbeiter-Tools, falls jemand Zugriff auf eine laufende Sitzung eines Mitarbeiterkontos erhält (z. B. beim Zugriff auf sicherheitskritische Tools erneut Kennwort und / oder 2FA-Token erforderlich)?
So etwas wie Spear Phishing ist wahrscheinlich immer noch eine der wahrscheinlichsten Möglichkeiten, wie jemand versuchen könnte, Zugriff auf ein Mitarbeiterkonto zu erhalten.
Etwa zur gleichen Zeit, als dieser Sicherheitsvorfall eintrat, bemerkten einige Benutzer einige Tage später, dass Twitter Oneboxing im Chat nicht mehr funktionierte . Ein Mitarbeiter bestätigte daraufhin im Februar nächsten Jahres, dass er tatsächlich absichtlich deaktiviert worden war, weil er aufgrund dieses Sicherheitsvorfalls "einige Lücken schließen" musste.
Können wir eine vollständige Erklärung erhalten, warum Twitter Oneboxing im Chat aufgrund dieses Sicherheitsvorfalls deaktiviert werden musste? In dem zu diesem Zeitpunkt veröffentlichten Blog-Beitrag wurde angegeben, dass "andere potenzielle Vektoren" zu diesem Zeitpunkt geschlossen wurden, und in der oben verlinkten Mitarbeiterbotschaft vom Februar 2020 wurde angegeben, dass die Twitter-Oneboxing-Funktion "eine der von uns geschlossenen Lücken ausgenutzt hat". Was war das für ein Ding und welches Sicherheitsrisiko hat es geschaffen?
Gibt es eine Möglichkeit, diese Funktionalität auf sichere Weise wieder zu implementieren? Im August 2020, wenige Monate nach der obigen Mitarbeitermeldung, wurde der zu diesem Zeitpunkt eingereichte Fehlerbericht von einem anderen Mitarbeiter als status-by-design markiert . Würde eine Feature-Anfrage zur Änderung des Designs (auf sichere Weise) in Betracht gezogen, oder ist dies nicht möglich, ohne einen Angriffsvektor zu öffnen?
Ich würde darauf hinweisen, dass "Passwort" -Parametertypen in TeamCity nicht als so sicher angesehen werden:
Der Kennwortwert wird in den Konfigurationsdateien unter TeamCity Data Directory gespeichert. Abhängig von den Serververschlüsselungseinstellungen wird der Wert entweder verschlüsselt oder mit einem benutzerdefinierten Schlüssel verschlüsselt.
Der Wert des Erstellungsprotokolls wird mit einem einfachen Such- und Ersetzungsalgorithmus ausgeblendet. Wenn Sie also ein triviales Kennwort von "123" haben, werden alle Vorkommen von "123" ersetzt, wodurch möglicherweise das Kennwort angezeigt wird. Das Setzen des Parameters auf den Kennworttyp garantiert nicht, dass der Rohwert nicht abgerufen werden kann. Jeder Projektadministrator kann es abrufen, und jeder Entwickler, der das Build-Skript ändern kann, kann möglicherweise schädlichen Code schreiben, um das Kennwort zu erhalten.
Warum war die magische Verbindung in dev für CMs sichtbar (vermutlich nur in dev) eine echte magische Verbindung?
Dies ist wirklich ein großartiger Vorfallbericht! Eine der besten, die ich gelesen habe.
Vielen Dank an Stack für die Veröffentlichung und an Dean für das großartige Schreiben!
Ich bin nur neugierig, ein paar Dinge zu wissen:
- Wie groß ist das Incident-Response-Team?
- Gab es während der Untersuchung spezielle Protokolle?
- Welcher Schlüsselfaktor war beteiligt, um einen externen Sicherheitsanbieter zu engagieren? Welche Punkte wurden bei der Auswahl dieses bestimmten Anbieters berücksichtigt?
- Welche Lehren wurden aus dem externen Sicherheitsanbieter gezogen? War ihr Prüfungsprozess anders (effektiv / ineffektiv) als der, den das Team bereits verwendet hat?
Der Artikel gibt einen guten Einblick in die gesamte Architektur von Stack und die Entwicklungsprozesse. Eine detailliertere Lektüre oder ein Link, wenn es bereits einen Artikel darüber gibt, wäre großartig.
Unter "Ratschläge für andere":
Protokollieren Sie Ihren gesamten eingehenden Datenverkehr. Wir führen Protokolle über alle eingehenden Verbindungen. Dies ermöglichte alle unsere Untersuchungen. Sie können nicht untersuchen, was Sie nicht protokollieren.
Wie kann ein Netzwerk, das so ausgelastet ist wie Stack Exchange, den gesamten eingehenden Datenverkehr protokollieren? Handelt es sich bei diesen Protokollen um Webservereinträge, IP-Flows oder vollständige TCP-Sitzungen?
Ich konnte die meisten Einträge und Verbindungsversuche in meinem winzigen Netzwerk aufzeichnen, habe aber keine Ahnung, wie ein so großes Netzwerk dies tut.
Können Sie im folgenden Zitat klarer erklären, was "öffentlich zugängliche Immobilien" bedeuten?
Wir haben eine Datenbank, die ein Protokoll des gesamten Datenverkehrs zu unseren öffentlich zugänglichen Eigenschaften enthält