Eine aus einem GitHub-Branch entfernte Zugangsinformation blieb 18 Monate lang öffentlich abrufbar – und funktionierte weiterhin.
Zu den hervorgehobenen Erkenntnissen gehörte eine im WIRED-Bericht vom 10. Nov. über die Untersuchung des Codes des britischen öffentlichen Sektors durch den ControlPlane-Forscher Chris Nesbitt-Smith. Nach dem Scan von 349 Codebasen in 33 Organisationen meldete er mehr als 100 gravierende Schwachstellen; in etwa zwei Dritteln der untersuchten Codebasen wurden Schwächen festgestellt.
Für Sicherheitsteams liefern die veröffentlichten Informationen konkrete Lehren zum Widerruf offengelegter Geheimnisse, zur Begrenzung von Anwendungsberechtigungen und zur Prüfung, wer einen Datensatz ändern kann. Die Erkenntnisse beschreiben die Stichprobe des Forschers und keine regierungsweite Schwachstellenquote. Die hervorgehobenen Probleme wurden inzwischen behoben.
Eine gelöschte Datei hinterließ eine weiterhin gültige Zugangsinformation
In seiner Veröffentlichung zum Planning Inspectorate erklärt ControlPlane, dass ein exportiertes Azure-Synapse-Notebook eine vollständige Anwendungsanmeldinformation für Microsoft Entra ID enthielt. Die Integration musste eine HR-Datei aus SharePoint abrufen, doch ihre Berechtigungen erstreckten sich auf sämtliche SharePoint-Websites des Mandanten und die OneDrive-Konten der Beschäftigten.
Das Entfernen der Datei aus dem Branch machte die Zugangsinformation nicht ungültig. Laut den Forschern blieb ein verwaister Commit über die Infrastruktur für Rohinhalte von GitHub zugänglich.
ControlPlane zufolge verifizierte das Unternehmen den Zugriff anhand von Metadaten und einer Prüfung der Schreibberechtigung, die ohne Datenänderung fehlschlagen sollte. Die Behörde widerrief das Geheimnis etwa 20 Minuten, nachdem sie am 26. Aug. den Bericht erhalten hatte.
Das Planning Inspectorate teilte WIRED mit, seine Überwachung habe die Aktivitäten des Forschers bereits erkannt und es habe bestätigt, dass kein Datenleck stattgefunden habe. Ein potenzieller Zugriff sollte daher von einem bestätigten Diebstahl unterschieden werden.
Der Fall vereint drei Fehler: die Veröffentlichung eines Geheimnisses, die Vergabe weitreichenderer Berechtigungen an eine Integration als nötig und die fortbestehende Nutzbarkeit dieses Zugriffs nach der Bereinigung des Repositorys. Ähnliche Risiken wurden in einer Untersuchung zu KI-Unternehmen, die Geheimnisse auf GitHub preisgeben festgestellt, darunter Zugangsdaten in gelöschten Forks und Entwickler-Repositorys.
Weitere Veröffentlichungen zeigen andere Fehler bei der Zugriffskontrolle
Die veröffentlichten Fälle gehen über Repository-Zugangsdaten hinaus. Die Berichte von ControlPlane beschreiben Schwächen in browserseitig ausgeliefertem Code, Beschaffungsformularen und der Kontoverknüpfung:
| Dienst | Ergebnis der Untersuchung durch ControlPlane | Gemeldete Behebung |
| Offenes Datenportal der schottischen Regierung | Ein langlebiges Administratortoken, das in öffentlichem JavaScript eingebettet war, konnte Informationen zu Administratorkonten offenlegen und Konfigurationsänderungen ermöglichen. | Der Betreiber nahm den Dienst dauerhaft außer Betrieb, nachdem festgestellt worden war, dass er nicht mehr benötigt wurde. |
| Get Help Buying for Schools des Department for Education | Wer über eine gültige Anfragekennung verfügte, konnte die Anfragedetails einschließlich der Kontakt-E-Mail-Adresse ändern und die Anfrage ohne Anmeldung absenden. | Der Zugriff auf Datensätze und damit verbundene Aktionen waren an die aktive Sitzung gebunden. |
| Lehreranwendungsdienst des Department for Education | Der Code zur Kontoverknüpfung konnte eine bestehende Anmeldeverknüpfung überschreiben, ohne eine widersprüchliche Identität abzulehnen. | Es wurde eine Prüfung hinzugefügt, die widersprüchliche Verknüpfungen ablehnt. |
Diese Erkenntnisse und Behebungen sind in den einzelnen Veröffentlichungen von ControlPlane dokumentiert.
Die Veröffentlichung zum schottischen Portalveranschaulicht, warum eine Umgebungsvariable zur Build-Zeit ein Geheimnis nicht privat hält, wenn ihr Wert in JavaScript kompiliert wird, das an Browser gesendet wird. Eine auf diese Weise ausgelieferte Administratorzugangsinformation steht Besuchern zur Verfügung.
Diese Offenlegung ähnelt dem übergreifenden Problem hartcodierter Geheimnisse in herunterladbaren Android-Apps: An Nutzer verteiltes Material kann ebenfalls von Angreifern untersucht werden.
Der Befund zur Schulbeschaffungbetraf einen anderen Fehler. Eine lange, zufällige Anfragekennung diente praktisch als Berechtigung zum Ändern des Datensatzes. Nach Angaben von ControlPlane behob das Ministerium das Problem am 10. Juli.
Der Bericht zur Verknüpfung von Lehrerkontenenthält eine wichtige Einschränkung. Beim Test wurde eine neue Anmeldung mit dem eigenen Konto der Forscher verknüpft; ein separater Weg zur Kontenübernahme oder der Austausch der Anmeldung eines anderen Bewerbers wurde nicht nachgewiesen. Die Veröffentlichung beschreibt ein im Code identifiziertes Risiko und eine anschließende Korrektur.
Was Sicherheitsteams jetzt überprüfen sollten
Die unmittelbare Reaktion auf eine offengelegte Zugangsinformation sollte bei dem Dienst erfolgen, der sie ausgestellt hat. Die Leitlinien zur Behebung von GitHubstellen den Widerruf oder die Rotation an die erste Stelle – vor jeder Entscheidung, die Repository-Historie umzuschreiben.
Sicherheits- und Entwicklungsteams sollten diese Veröffentlichungen nutzen, um vier Bereiche zu überprüfen:
- Gültigkeit von Zugangsdaten: Bestätigen Sie, dass jedes zuvor offengelegte Passwort, Token oder Anwendungsgeheimnis widerrufen oder rotiert wurde. Eine geschlossene Repository-Warnung oder eine gelöschte Datei belegt nicht, dass der Zugriff beendet ist.
- Anwendungsberechtigungen: Vergleichen Sie den Zugriff jeder Integration mit ihrer tatsächlichen Aufgabe. Ein Workflow, der eine einzelne HR-Datei liest, sollte kritisch geprüft werden, wenn er in nicht zugehörigen Websites und im Speicher der Beschäftigten schreiben kann.
- Öffentliche Build-Artefakte: Untersuchen Sie Produktions-JavaScript, exportierte Notebooks und herunterladbare Pakete auf eingebettete Geheimnisse. Beziehen Sie neben den Prüfungen des Quellcodes auch die Release-Artefakte ein.
- Eigentümerschaft von Datensätzen: Testen Sie, ob das Ändern einer Anfragekennung es einer Sitzung ermöglicht, den Datensatz einer anderen Sitzung zu lesen oder zu ändern. Überprüfen Sie Gast-Workflows und Konflikte bei der Kontoverknüpfung ausdrücklich.
Priorisieren Sie Zugangsdaten, die weiterhin gültig sind und auf sensible Systeme zugreifen können, und untersuchen Sie anschließend ihre Verwendung anhand der verfügbaren Identitäts- und Dienst-Auditprotokolle. Dokumentieren Sie Lücken bei der Abdeckung historischer Protokolle, damit die Bewertung des Vorfalls widerspiegelt, was tatsächlich festgestellt werden kann.
Die Schwachstelle in Google DevSite mit einem offengelegten Authentifizierungsgeheimniszeigt, wie ein durchgesickertes Geheimnis zusammen mit einer weiteren Schwachstelle einen folgenschwereren Angriffsweg schaffen kann. Die Behebung sollte daher sowohl die Zugangsinformation als auch das Anwendungsverhalten umfassen, das ihr vertraute.
Bitten Sie die Teams bei der nächsten Überprüfung nachzuweisen, dass eine alte offengelegte Zugangsinformation fehlschlägt, eine Integration nicht auf nicht zugehörige Ressourcen zugreifen kann und ein Datensatz Anfragen einer nicht autorisierten Sitzung ablehnt. Diese Prüfungen liefern Belege dafür, dass sich der zugrunde liegende Zugriff geändert hat.
Mehr lesen: Offengelegte Geheimnisse und schwache Zugriffskontrollen spielten auch bei einer Operation gegen öffentliche Dienste eine Rolle. Erfahren Sie, wie ein Hacker 12 KI-Agenten einsetzte, um Taiwans Notfalldienste anzugreifenund was Verteidiger aus den Erkenntnissen lernen können.