In Erinnerung an einen uralten Roblox-Hack: Auf einer nicht-produktiven Staging-Site konnten sich Benutzer registrieren, und es gab ein Banner mit der Aufschrift „Nichts hier ist dauerhaft“. Als dem Produktionskonto ein neues Administratorkonto hinzugefügt wurde, registrierte sich jemand auf der Staging-Site mit demselben Benutzernamen und übernahm mithilfe von Cookies und Tokens das Produktionskonto, wodurch die Site gefährdet wurde. Es ist schwer vorstellbar, dass solche Probleme selten sind: wenn kryptografische Tokens auf Basis von Benutzernamen oder Benutzer-IDs erzeugt werden, ohne unterschiedliche Geheimnisse für Produktion/Staging, wenn eine Staging-Site mit externen Diensten kommuniziert, die Produktionsberechtigungen verwechseln, usw.
Die Grenze zwischen Entwicklung und Produktion in Großunternehmen ist viel durchlässiger, als die Leute denken. Wenn man einen gewöhnlichen Tag betrachtet, meldet man sich am PC an, prüft E-Mails und meldet sich dann mit denselben Zugangsdaten im Azure-Portal an (alles wird vom selben Tenant unterstützt). Das Konto ist mit GitHub- und Cloud-Konten verknüpft.
Damit man in Teams oder OneDrive arbeiten kann, werden überall Gruppen und Teams mit schwer nachvollziehbaren Berechtigungen erstellt, und sie bleiben als kaum unterscheidbare Sicherheitsgruppen im Unternehmensverzeichnis zurück.
Manchmal erhält man automatische E-Mails mit der Frage, ob man etwas Benötigtes noch nutzt, aber die Nachrichten sind undurchsichtig, und in wirklich großen Unternehmen gibt es niemanden, den man fragen kann (der Helpdesk braucht zwei Tage zum Antworten, und man kann John Savill nicht einfach auf Twitter kontaktieren), also klickt man einfach auf Bestätigen und macht weiter.
Am Ende reißt die Struktur auf, und Angreifer haben an einer schwachen Stelle Glück und bekommen tenantübergreifend, was sie wollen.
Wie ein kluger CISO einmal sagte: Hacker brechen nicht ein, sie loggen sich ein.
In der Cybersecurity-Branche ist das allgemein als „whoopsie“ bekannt.
Der Forscher und Sicherheitsexperte Kevin Beaumont wies auf Mastodon darauf hin, dass ein Konto, das einer OAuth-App die Rolle „full_access_as_app“ zuweisen kann, Administratorrechte haben sollte. Er sagte, dass „jemand“ in der Produktionsumgebung einen ziemlich großen Konfigurationsfehler gemacht habe.
Ich kenne die Details des Systems nicht, aber ich glaube nicht, dass das das Problem sein dürfte, und ich bin überrascht, dass Experten sagen, es sei eines. Es sollte keine Möglichkeit geben, einen solchen Fehler zu machen. Designer und Administratoren sollten ihn unmöglich machen, und sie sollten dafür verantwortlich sein.
Trotz schicker Sicherheitszertifizierungen wirkt es so, als würden bei Amazon die wohlüberlegten Best Practices aus einem 36-Dollar-Buch vollständig ignoriert.
Was in diesem Beitrag fehlt: wie die Autoren „Produktion“ definieren und wie ein „nicht-produktives“ Konto Verwaltungsrechte für eine Produktionsdomäne haben kann.
Dieses Muster ist im gesamten MS-Ökosystem eher die Regel als die Ausnahme, aber dass Microsoft es selbst tut, ist besonders peinlich.
In einem Unternehmen wurden die Passwörter für alle Produktionsserver und Datenbanken in einer Textdatei im Code-Repository gespeichert, weil der Chefarchitekt sich die Passwörter nicht merken wollte. Als ich den CTO darauf hinwies, wie dumm das ist, bekam ich als Antwort: „Wir vertrauen unseren Mitarbeitern“ und „Wir haben das Sicherheitsaudit bestanden“.
Ich hasse es, wenn einem an einem neuen Arbeitsplatz „der Einfachheit halber“ weitreichende Berechtigungen zugewiesen werden. Das sollte man nicht tun. Man setzt nicht nur das Unternehmen Risiken aus, sondern lädt sich auch Verantwortung auf, die man nicht will. Man kann versehentlich etwas Wichtiges kaputtmachen, und wenn man gehackt wird, könnte man verdächtigt werden, es selbst getan zu haben, weil man die entsprechenden Rechte hatte.
Warum wird das als „Fehler“ betrachtet? Es könnte auch das Werk eines Spions sein, der bei Microsoft als Administrator arbeitet.
1 Kommentare
Hacker-News-Kommentare