von SeerLight
Der Aufbau eines jeden Dienstes erfordert ständige Arbeit an der Sicherheit. Sicherheit ist ein fortlaufender Prozess, der kontinuierliche Analysen und Verbesserungen des Produkts, die Überwachung von Schwachstellenmeldungen und vieles mehr umfasst. Dazu gehören auch Audits. Audits werden sowohl intern als auch von externen Experten durchgeführt, die entscheidend zur Sicherheit beitragen können, da sie nicht in das Projekt involviert sind und einen unvoreingenommenen Blick haben.
Dieser Artikel behandelt genau diesen unvoreingenommenen Blick externer Experten, die dem Team von Mail.ru Cloud Solutions (MCS) geholfen haben, einen Cloud-Dienst zu testen, und was sie dabei entdeckt haben. Als "externe Kräfte" wählte MCS die Firma Digital Security, die für ihre hohe Expertise in der Informationssicherheit bekannt ist. In diesem Artikel werden wir einige interessante Schwachstellen, die im Rahmen des externen Audits gefunden wurden, beleuchten, damit Sie ähnliche Stolpersteine vermeiden können, wenn Sie Ihren eigenen Cloud-Dienst erstellen.
Produktbeschreibung
— ist eine Plattform zum Aufbau virtueller Infrastruktur in der Cloud. Sie umfasst IaaS, PaaS und einen Marktplatz für fertige Anwendungs-Images für Entwickler. Unter Berücksichtigung der MCS-Architektur musste die Sicherheit des Produkts in folgenden Bereichen überprüft werden:
- Schutz der Infrastruktur der Virtualisierungsumgebung: Hypervisoren, Routing, Firewalls;
- Schutz der virtuellen Infrastruktur der Kunden: Isolation voneinander, einschließlich Netzwerk, private Netzwerke in SDN;
- OpenStack und seine offenen Komponenten;
- Eigenentwickeltes S3;
- IAM: multitenante Projekte mit Rollenmodell;
- Vision (Computer Vision): API und Schwachstellen im Umgang mit Bildern;
- Web-Interface und klassische Web-Angriffe;
- Schwachstellen von PaaS-Komponenten;
- API aller Komponenten.
Vielleicht alles Wesentliche für die weitere Geschichte.
Welche Arbeiten wurden durchgeführt und warum sind sie notwendig?
Das Sicherheitsaudit zielt darauf ab, Schwachstellen und Konfigurationsfehler zu identifizieren, die zu Datenschutzverletzungen, Modifikationen sensibler Informationen oder Störungen der Verfügbarkeit von Diensten führen können.
Im Rahmen von Arbeiten, die im Durchschnitt 1-2 Monate dauern, ahmen Auditoren die Aktivitäten potenzieller Angreifer nach und suchen nach Schwachstellen in der Kunden- und Serverseite des gewählten Dienstes. Im Kontext des Audits der Cloud-Plattform MCS wurden folgende Ziele festgelegt:
- Analyse der Authentifizierung im Dienst. Schwachstellen in diesem Bereich könnten sofortigen Zugriff auf fremde Konten ermöglichen.
- Untersuchung des Rollenmodells und der Zugriffskontrolle zwischen verschiedenen Konten. Für Angreifer ist der Zugang zu einer fremden virtuellen Maschine ein begehrtes Ziel.
- Schwachstellen der Client-Seite: XSS/CSRF/CRLF/etc. Gibt es möglicherweise die Möglichkeit, andere Benutzer über schädliche Links anzugreifen?
- Schwachstellen der Server-Seite: RCE und diverse Injektionen (SQL/XXE/SSRF usw.). Server-Schwachstellen sind in der Regel schwieriger zu finden, führen jedoch zur Kompromittierung vieler Nutzer auf einmal.
- Analyse der Isolation von Benutzersegmenten auf der Netzwerkebene. Für Angreifer erhöht das Fehlen von Isolation die Angriffsfläche erheblich auf andere Nutzer.
- Analyse der Geschäftslogik. Ist es möglich, das Geschäft zu täuschen und virtuelle Maschinen kostenlos zu erstellen?
In diesem Projekt wurde nach dem «Gray-box»-Modell gearbeitet: Die Prüfer interagierten mit dem Service mit den Rechten normaler Benutzer, hatten aber teilweise Zugriff auf den Quellcode der API und konnten Details mit den Entwicklern klären. Normalerweise ist dies das bequemste und gleichzeitig realistischste Arbeitsmodell: Interne Informationen können immer noch von Angreifern gesammelt werden, es ist nur eine Frage der Zeit.
Gefundene Schwachstellen
Bevor der Prüfer beginnt, verschiedene Payloads (Angreifermaterial, das für Angriffe verwendet wird) an zufällige Stellen zu senden, muss er verstehen, wie alles funktioniert und welche Funktionalitäten vorhanden sind. Es mag scheinen, dass dies eine sinnlose Beschäftigung ist, denn in den meisten untersuchten Bereichen wird es keine Schwachstellen geben. Doch nur das Verständnis der Struktur der Anwendung und der Logik ihrer Funktionsweise ermöglicht es, die schwierigsten Angriffsvektoren zu finden.
Es ist wichtig, verdächtige Stellen oder solche, die sich stark von anderen unterscheiden, zu identifizieren. Die erste gefährliche Schwachstelle wurde auf diese Weise gefunden.
IDOR
IDOR-Schwachstellen (Insecure Direct Object Reference, unsichere direkte Objektverweise) gehören zu den häufigsten Arten von Schwachstellen in der Geschäftslogik, die es ermöglichen, Zugang zu Objekten zu erhalten, auf die tatsächlich kein Zugriff erlaubt ist. IDOR-Schwachstellen schaffen die Möglichkeit, Informationen über Benutzer unterschiedlicher Kritikalität zu erhalten.
Eine Variante von IDOR ist die Durchführung von Aktionen mit Systemobjekten (Benutzern, Bankkonten, Waren im Warenkorb) durch Manipulation der Zugriff IDs dieser Objekte. Dies führt zu den unerwartetsten Konsequenzen. Zum Beispiel kann es die Möglichkeit schaffen, das Konto des Absenders von Geldtransfers zu manipulieren, was es ermöglicht, Gelder von anderen Benutzern zu stehlen.
Im Fall von MCS haben die Auditoren eine IDOR-Sicherheitsanfälligkeit entdeckt, die mit unsicheren Identifikatoren verbunden ist. Im Benutzer-Dashboard wurden UUID-Identifikatoren verwendet, um auf Objekte zuzugreifen, die, wie Sicherheitsexperten sagen, beeindruckend unveränderlich schienen (also gegen Brute-Force-Angriffe geschützt). Für bestimmte Entitäten wurde jedoch festgestellt, dass zur Abrufung von Informationen über die Nutzer der Anwendung gewöhnliche, vorhersagbare Nummern verwendet wurden. Ich denke, Sie ahnen, dass man die Benutzer-ID einfach um eins erhöhen und die Anfrage erneut senden konnte, um so Informationen zu erhalten und die ACL (Access Control List, Zugriffsregeln für Datenprozesse und Benutzer) zu umgehen.
Server Side Request Forgery (SSRF)
OpenSource-Produkte haben den Vorteil, dass es eine Vielzahl von Foren mit detaillierten technischen Beschreibungen auftretender Probleme gibt, und wenn Sie Glück haben, auch mit Lösungsansätzen. Aber diese Medaille hat auch eine Kehrseite: Es werden ebenso detailliert bekannte Sicherheitsanfälligkeiten beschrieben. Beispielsweise gibt es im OpenStack-Forum hervorragende Beschreibungen von Sicherheitsanfälligkeiten und , die aus unerklärlichen Gründen niemand beheben möchte.
Eine häufige Funktionalität von Anwendungen ist die Möglichkeit für den Benutzer, einen Link an den Server zu senden, über den der Server zugreift (zum Beispiel um ein Bild aus einer angegebenen Quelle herunterzuladen). Bei unzureichender Filterung der Links oder der Antworten, die vom Server an die Benutzer zurückgesendet werden, kann diese Funktionalität leicht von Angreifern ausgenutzt werden.
SSRF-Schwachstellen können einen Angriff erheblich vorantreiben. Der Angreifer kann Folgendes erhalten:
- eingeschränkten Zugriff auf das angegriffene lokale Netzwerk, zum Beispiel nur auf bestimmten Netzwerksegmenten und über einen bestimmten Protokoll;
- vollständigen Zugriff auf das lokale Netzwerk, wenn ein Downgrade vom Anwendungs- auf Transportebene möglich ist und somit die vollständige Kontrolle über die Last auf Anwendungsebene;
- Zugriff auf lokale Dateien auf dem Server (sofern das Schema file:/// unterstützt wird);
- und vieles mehr.
In OpenStack ist seit langem eine sogenannte SSRF-Schwachstelle bekannt, die einen „blinden“ Charakter aufweist: Bei der Anfrage an einen Server erhält man keine Rückmeldung, sondern verschiedene Arten von Fehlern oder Verzögerungen, abhängig vom Ergebnis der Anfrage. Auf dieser Basis kann eine Portscan-Überprüfung auf Hosts im internen Netzwerk durchgeführt werden, mit allen damit verbundenen Konsequenzen, die man nicht unterschätzen sollte. Beispielsweise kann ein Produkt eine API für das Backoffice enthalten, die nur aus dem Unternehmensnetzwerk zugänglich ist. Hat man die Dokumentation (denken wir an Insider) in Händen, kann ein Angreifer mithilfe von SSRF auf interne Methoden zugreifen. Wenn es gelungen ist, eine ungefähre Liste nützlicher URLs zu erhalten, kann man mit SSRF auf diese zugehen und eine Anfrage stellen – um es bildlich auszudrücken, Geld von einem Konto auf ein anderes zu überweisen oder die Limits zu ändern.
Dies ist nicht der erste Fall, in dem eine SSRF-Schwachstelle in OpenStack entdeckt wurde. In der Vergangenheit gab es die Möglichkeit, ISO-Images von VMs über einen direkten Link hochzuladen, was ebenfalls zu ähnlichen Folgen führte. Momentan wurde diese Funktion aus OpenStack entfernt. Offenbar hielt die Community dies für die einfachste und sicherste Lösung des Problems.
Und in In einem öffentlich zugänglichen Bericht von HackerOne (h1) führt die Ausnutzung der nicht mehr blinden SSRF mit der Möglichkeit, Metadaten der Instanz zu lesen, zu einem Root-Zugriff auf die gesamte Infrastruktur von Shopify.
In der MCS wurden an zwei Stellen mit ähnlicher Funktionalität SSRF-Schwachstellen entdeckt, die jedoch aufgrund von Firewalls und anderen Sicherheitsmaßnahmen kaum ausgenutzt werden konnten. Die MCS-Team hat dieses Problem dennoch behoben, ohne auf die Community zu warten.
XSS anstelle von 'Shells' hochladen
Trotz hunderter verfasster Studien ist XSS (Cross-Site-Scripting-Angriff) Jahr für Jahr immer noch die Web-Schwachstelle (oder ?).
Das Hochladen von Dateien ist ein beliebter Bereich für Sicherheitsforscher. Oft ist es möglich, ein beliebiges Skript (asp/jsp/php) hochzuladen und Betriebssystembefehle auszuführen, in der Terminologie von Pen-Testern – 'Shelled zu werden'. Aber die Popularität solcher Schwachstellen wirkt in beide Richtungen: Man erinnert sich daran und entwickelt Gegenmaßnahmen, sodass die Wahrscheinlichkeit, ein 'Shell' hochzuladen, in letzter Zeit gegen null tendiert.
Das angreifende Team (in Person von Digital Security) hatte Glück. In der MCS wurde auf der Serverseite der Inhalt der hochgeladenen Dateien überprüft, es waren nur Bilder erlaubt. Aber SVG ist ebenfalls ein Bild. Was kann an SVG-Bildern gefährlich sein? Dass man darin Fragmente von JavaScript einbetten kann!
Es stellte sich heraus, dass die hochgeladenen Dateien für alle Nutzer des MCS-Dienstes zugänglich sind – das bedeutet, dass Angriffe auf andere Cloud-Nutzer, insbesondere auf Administratoren, möglich sind.
Beispiel für die Implementierung eines Phishing-Login-Formulars durch eine XSS-Attacke
Beispiele für die Ausnutzung von XSS-Attacken:
- Warum versuchen, eine Sitzung zu stehlen (zumal es jetzt überall HTTP-Only-Cookies gibt, die vor Diebstahl durch JS-Skripte geschützt sind), wenn das hochgeladene Skript sofort auf die API der Ressource zugreifen kann? In diesem Fall könnte die Payload über XHR-Anfragen die Serverkonfiguration ändern, zum Beispiel einen offenen SSH-Schlüssel des Angreifers hinzufügen und SSH-Zugriff auf den Server erhalten.
- Wenn die CSP-Richtlinie (Content Security Policy) die Implementierung von JavaScript verbietet, kann ein Angreifer darauf verzichten. Mit reinem HTML lässt sich ein gefälschtes Anmeldeformular erstellen, um das Passwort des Administrators durch diese fortschrittliche Phishing-Methode zu stehlen: Die Phishing-Seite für den Benutzer erscheint unter der gleichen URL, was es dem Benutzer erschwert, sie zu erkennen.
- Schließlich kann der Angreifer verursachen, indem er Cookies mit einer Größe von mehr als 4 KB setzt. Der Benutzer muss nur einmal den Link öffnen – und die gesamte Website wird unzugänglich, bis man sich dazu erinnert, den Browser manuell zu leeren: In den meisten Fällen wird der Webserver sich weigern, einen solchen Client zu akzeptieren.
Betrachten wir ein weiteres Beispiel für eine entdeckte XSS, diesmal mit einer raffinierteren Ausnutzung. Der Dienst MCS ermöglicht es, Firewall-Einstellungen in Gruppen zu bündeln. In dem Gruppennamen wurde die entdeckte XSS gefunden. Ihre Besonderheit bestand darin, dass der Vektor nicht sofort aktiviert wurde, nicht beim Durchsehen der Regelübersicht, sondern beim Löschen der Gruppe:
Das Szenario sieht folgendermaßen aus: Ein Angreifer erstellt eine Firewall-Regel mit "Payload" im Namen, der Administrator bemerkt dies nach einer gewissen Zeit und initiiert den Löschprozess. Und genau hier kommt das schädliche JavaScript zum Einsatz.
Um sich gegen XSS in hochgeladenen SVG-Bildern (falls diese nicht vermieden werden können) zu schützen, empfahl das Team für digitale Sicherheit den Entwicklern von MCS:
- Die von Benutzern hochgeladenen Dateien auf einer separaten Domain zu hosten, die nichts mit der „Cookie“-Domain zu tun hat. Das Skript wird im Kontext einer anderen Domain ausgeführt und stellt keine Bedrohung für MCS dar.
- Im HTTP-Antwortheader des Servers den Header „Content-Disposition: attachment“ zurückzugeben. Auf diese Weise werden die Dateien vom Browser heruntergeladen, anstatt ausgeführt zu werden.
Darüber hinaus stehen den Entwicklern jetzt viele Möglichkeiten zur Verfügung, um die Risiken von XSS-Angriffen zu mindern:
- Durch das Setzen des „HTTP Only“-Flags können die Sitzungscookies für schädliches JavaScript unzugänglich gemacht werden;
- erschwert die Ausnutzung von XSS für den Angreifer erheblich;
- Moderne Template-Engines wie Angular oder React bereinigen automatisch Benutzerdaten, bevor sie im Browser des Benutzers ausgegeben werden.
Sicherheitsanfälligkeiten der Zwei-Faktor-Authentifizierung
Um die Sicherheit ihrer Konten zu erhöhen, wird Nutzern stets empfohlen, 2FA (Zwei-Faktor-Authentifizierung) zu aktivieren. Dies ist tatsächlich eine effektive Methode, um zu verhindern, dass Angreifer Zugriff auf den Dienst erlangen, falls die Anmeldedaten des Nutzers kompromittiert wurden.
Gibt es jedoch immer eine Garantie für die Sicherheit des Kontos beim Einsatz eines zweiten Authentifizierungsfaktors? Bei der Implementierung von 2FA können folgende Sicherheitsprobleme auftreten:
- Brute-Force-Angriffe auf den OTP-Code (Einmalpasswörter). Trotz der einfachen Nutzung treten solche Fehler, wie das Fehlen eines Schutzes gegen Brute-Force-Angriffe auf OTPs, auch bei großen Unternehmen auf: , .
- Schwache Generierungsalgorithmen, wie die Möglichkeit, den nächsten Code vorherzusagen.
- Logische Fehler, wie die Möglichkeit, OTPs von anderen auf das eigene Telefon anzufordern, wie bei Shopify.
In MCS basiert die 2FA auf Google Authenticator und . Das Protokoll hat sich bereits bewährt, jedoch sollte die Implementierung der Code-Überprüfung seitens der Anwendung überprüft werden.
In MCS wird 2FA an mehreren Stellen verwendet:
- Bei der Authentifizierung des Nutzers gibt es eine Schutzmaßnahme gegen Brute-Force-Angriffe: Der Nutzer hat nur eine begrenzte Anzahl an Versuchen, ein Einmalpasswort einzugeben, danach wird die Eingabe für eine bestimmte Zeit blockiert. Dies verhindert die Möglichkeit, OTP durch Ausprobieren zu finden.
- Bei der Generierung von Offline-Backup-Codes für die Durchführung von 2FA sowie dessen Deaktivierung gab es keinen Schutz gegen Brute-Force-Angriffe, was es ermöglichte, bei Kenntnis des Passworts für das Konto und einer aktiven Sitzung, die Backup-Codes neu zu generieren oder 2FA vollständig zu deaktivieren.
Da die Backup-Codes im gleichen Wertebereich wie die vom Programm generierten OTPs lagen, war die Chance, den Code in kurzer Zeit zu erraten, erheblich höher.
Der Prozess des Erratens von OTP zur Deaktivierung von 2FA mit Hilfe des Tools „Burp: Intruder“
Ergebnis
Insgesamt erwies sich MCS als sicheres Produkt. Während des Audits konnte das Penetrationstest-Team keinen Zugang zu den Kunden-VMs und deren Daten erlangen, und die gefundenen Schwachstellen wurden schnell vom MCS-Team behoben.
Es ist jedoch wichtig zu betonen, dass Sicherheit ein fortlaufender Prozess ist. Dienste sind nicht statisch; sie entwickeln sich ständig weiter. Ein Produkt vollständig ohne Schwachstellen zu entwickeln, ist unmöglich. Aber man kann diese rechtzeitig erkennen und die Wahrscheinlichkeit ihres Wiederauftretens minimieren.
Alle genannten Schwachstellen in MCS sind mittlerweile behoben. Um die Anzahl neuer Schwachstellen zu minimieren und ihre Existenzdauer zu verkürzen, arbeitet das Plattform-Team kontinuierlich daran:
- regelmäßige Audits durch externe Unternehmen durchzuführen;
- die Teilnahme zu unterstützen und weiterzuentwickeln;
- sich mit Sicherheit zu beschäftigen. 🙂
Quelle: habr.com
