Fragen? Antworten! Siehe auch: Alternativlos
Ich hatte ja schon erzählt, dass sie ihr FTP-Passwort auf Github in ein öffentlichen Repository eingecheckt hatten.
Stellt sich raus: Das war gut getarnt. Es war "solarwinds123". Wenn das jemand in einem Repo findet, geht er doch mit Sicherheit davon aus, dass das ein Fake-Passwort ist, ein Dokumentations-Stellvertreter. Niemand wäre so dermaßen inkompetent, DAS als Passwort zu nehmen!
Ja gut, aber das FTP-Passwort reicht ja noch nicht, um den Buildserver zu kompromittieren. Oh warte, auch auf dem Buildserver war das Passwort solarwinds123 (war der Updateserver, nicht der Buildserver). Und wenn dir das zu kompliziert ist: Der User "nobody" hat auch Zugang zum Buildserver und wird nicht nach einem Passwort gefragt. (das war ein Missverständnis, damit war Citrix gemeint)
Gut, der CEO muss weg. Keine Sorge, ist in Arbeit. Sein Nachfolger steht auch schon fest:
Sudhakar Ramakrishna, the former chief executive of Pulse Secure.Pulse Secure? Nenn micht altmodisch, aber von einer Firma mit diesem Track Record würde ich niemanden einstellen wollen.Auf der anderen Seite ist das bei Solarwinds wahrscheinlich auch egal. Die hatten die trojanisierten Updates auch Tage später noch auf ihrem Updateserver online.
Lustigerweise hatte Solarwinds als Best Practices dokumentiert, dass man ihren Scheiß beim Schlangenöl ausschließen soll. Nicht dass das Schlangenöl was gebracht hätte, klar, denn die DLLs waren ja digital signiert, und Schlangenöl skippt gewöhnlich digital signierte Dateien. Denn die sind ja digital signiert!1!! (Mal abgesehen davon, natürlich, dass Schlangenöl grundsätzlich nicht funktioniert)
Update: OK da läuft gerade einiges durcheinander. Das war nicht der Buildserver, von dem Reuters berichtet hat, sondern der Updateserver. Das klingt als sei es dasselbe, ist es aber nicht. Der Buildserver ist die Kiste, die den Quellcode nimmt, den Compiler anwirft, Binaries erzeugt, und die dann signiert. Der Updateserver ist ein FTP-Server irgendwo, auf dem die Dateien dann zum Download liegen. Mit dem Passwort zum FTP-Server wäre also geklärt, wie man da Fake-Updates aufspielt, aber nicht wie man eine korrekte digitale Signatur aufbringen konnte. Dieser Key liegt im Allgemeinen nicht auf dem Updateserver. Gut, auszuschließen ist das natürlich auch nicht, bei einer Firma, die "firmenname123" als Passwort nimmt.
Das Statement von Microsoft zu der Nummer liest sich übrigens nochmal deutlich apokalyptischer, die reden da von dem SAML-root-Cert, mit dem man beliebige andere SAML-Tokens ausstellen kann, die dann Zugriff unter einem beliebigen Account auf beliebige Geräte in der Firma haben. Das ist sozusagen der absolut schlimmste denkbare Fall, was jemand in die Hände bekommen kann. Das liegt auch nicht auf dem Buildserver sondern noch weiter hinten in der Infrastruktur. Mit diesen SAML-Tokens kamen die dann nicht nur innerhalb der Firma an alle Infrastruktur ran sondern auch auf alle deren Cloud-Infrastruktur. SAML ist die Basis für Single-Sign-On-Infrastrukturen. Die Tokens sehen dann aus wie normale Tokens. Wenn sowas einmal passiert ist, kannst du auch nicht mehr den Checkins in den Repositories trauen. Laut SEC Filing hatten die Angreifer diese Art von Totalzugriff seit März. Die Firma kannst du nur noch planieren und komplett neu aufsetzen nach sowas.
Im Übrigen gilt das im Prinzip auch für alle Kunden von denen. Denn mit so einer Monitoring-Software würdest du ja alle Server monitoren wollen, inklusive deiner eigenen SSO-Infrastruktur. Im Grunde kannst du da jetzt nur mit der großen Abrissbirne einmal die gesamte Kundenbasis von denen zum Parkplatz machen und dann nochmal von 0 anfangen und neue Gebäude bauen. (Danke, Kris)