Sicherheitsüberprüfung der MCS Cloud Platform

SkyShip Dusk von SeerLight

Der Aufbau eines Dienstes beinhaltet notwendigerweise ständige Sicherheitsarbeiten. Sicherheit ist ein kontinuierlicher Prozess, der die kontinuierliche Analyse und Verbesserung der Produktsicherheit, die Überwachung von Nachrichten über Schwachstellen und vieles mehr umfasst. Einschließlich - Audits. Audits werden sowohl alleine als auch von externen Experten durchgeführt, die die Sicherheit erheblich verbessern können, da sie nicht in das Projekt eingebunden sind und eine klare Sicht haben.

Der Artikel handelt von diesem sehr unbeliebten Aussehen externer Experten, die dem Team von Mail.ru Cloud Solutions (MCS) beim Testen des Cloud-Dienstes geholfen haben, und von dem, was sie gefunden haben. Als "externe Kräfte" entschied sich MCS für Digital Security, bekannt für seine hohe Expertise in der Sicherheitsgemeinschaft. In diesem Artikel werden einige interessante Schwachstellen analysiert, die im Rahmen eines externen Audits festgestellt wurden, damit Sie bei der Erstellung Ihres Cloud-Dienstes denselben Rake erhalten.

Produktbeschreibung

Mail.ru Cloud Solutions (MCS) ist eine Plattform zum Aufbau einer virtuellen Infrastruktur in der Cloud. Es umfasst IaaSs, PaaSs, einen Marktplatz mit vorgefertigten Anwendungsimages für Entwickler. In Anbetracht der Architektur von MCS war es notwendig, die Sicherheit des Produkts in den folgenden Bereichen zu überprüfen:

• Schutz der Infrastruktur der Virtualisierungsumgebung: Hypervisoren, Routing, Firewalls;
  
• Schutz der virtuellen Infrastruktur der Kunden: Isolation voneinander, einschließlich Netzwerk, privater Netzwerke in SDN;
  
• OpenStack und seine offenen Komponenten;
  
• S3 eigene Entwicklung;
  
• IAM: mandantenfähige Projekte mit Vorbild;
  
• Vision (Machine Vision): API und Schwachstellen bei der Arbeit mit Bildern;
  
• Webinterface und klassische Webangriffe;
  
• Schwachstellen von PaaS-Komponenten;
  
• API aller Komponenten.
  

Vielleicht ist alles, was für die nachfolgende Geschichte wesentlich ist, alles.

Welche Art von Arbeit wurde durchgeführt und warum werden sie benötigt?

Ein Sicherheitsaudit zielt darauf ab, Schwachstellen und Konfigurationsfehler zu identifizieren, die zum Verlust personenbezogener Daten, zur Änderung vertraulicher Informationen oder zu einer Verletzung der Verfügbarkeit von Diensten führen können.

Während der durchschnittlich 1-2 Monate dauernden Arbeit wiederholen die Prüfer die Aktionen potenzieller Angreifer und suchen nach Schwachstellen in den Client- und Serverteilen des ausgewählten Dienstes. Im Rahmen der Prüfung der MCS-Cloud-Plattform wurden folgende Ziele ermittelt:

1. Analyse der Authentifizierung im Dienst. Sicherheitslücken in dieser Komponente würden dazu beitragen, sofort auf die Konten anderer Personen zuzugreifen.
   
2. Die Untersuchung des Vorbilds und der Zugriffskontrolle zwischen verschiedenen Konten. Für einen Angreifer ist die Möglichkeit, auf die virtuelle Maschine eines anderen zuzugreifen, ein willkommenes Ziel.
   
3. Clientseitige Schwachstellen. XSS / CSRF / CRLF / etc. Vielleicht ist es möglich, andere Benutzer über böswillige Links anzugreifen?
   
4. Sicherheitslücken auf der Serverseite: RCE und alle Arten von Injektionen (SQL / XXE / SSRF usw.). Server-Schwachstellen sind normalerweise schwieriger zu finden, führen jedoch dazu, dass viele Benutzer gleichzeitig Kompromisse eingehen.
   
5. Analyse der Netzwerksegmentisolation von Benutzersegmenten. Für einen Angreifer erhöht der Mangel an Isolation die Angriffsfläche für andere Benutzer erheblich.
   
6. Analyse der Geschäftslogik. Ist es möglich, ein Unternehmen zu täuschen und kostenlos virtuelle Maschinen zu erstellen?
   

In diesem Projekt wurde die Arbeit nach dem Gray-Box-Modell durchgeführt: Auditoren interagierten mit den Diensten mit den Rechten normaler Benutzer, besaßen jedoch teilweise den Quellcode der API und hatten die Möglichkeit, Details mit den Entwicklern zu klären. In der Regel ist dies das bequemste und zugleich recht realistische Arbeitsmodell: Insiderinformationen können von einem Angreifer immer noch gesammelt werden, dies ist nur eine Frage der Zeit.

Sicherheitslücken gefunden

Bevor der Auditor verschiedene Nutzdaten (Nutzdaten, die zum Angriff verwendet werden) an zufällige Orte sendet, müssen Sie verstehen, wie dies funktioniert und welche Funktionen angeboten werden. Es scheint, dass dies eine vergebliche Übung ist, da es an den meisten untersuchten Orten keine Schwachstellen gibt. Nur ein Verständnis der Struktur der Anwendung und der Logik ihrer Funktionsweise ermöglicht es jedoch, die komplexesten Angriffsvektoren zu finden.

Es ist wichtig, Orte zu finden, die verdächtig erscheinen oder sich von anderen unterscheiden. Auf diese Weise wurde die erste gefährliche Sicherheitslücke gefunden.

IDOR

IDOR-Schwachstellen (Insecure Direct Object Reference, unsichere direkte Links zu Objekten) sind eine der häufigsten Schwachstellen in der Geschäftslogik, die es auf die eine oder andere Weise ermöglichen, auf Objekte zuzugreifen, auf die der Zugriff tatsächlich nicht zulässig ist. IDOR-Schwachstellen bieten die Möglichkeit, Benutzerinformationen mit unterschiedlichem Kritikalitätsgrad abzurufen.

Eine der IDOR-Optionen besteht darin, Aktionen mit Systemobjekten (Benutzer, Bankkonten, Waren im Warenkorb) auszuführen, indem die Zugriffskennungen für diese Objekte bearbeitet werden. Dies führt zu den unvorhersehbarsten Folgen. Zum Beispiel die Möglichkeit, das Konto des Absenders zu ersetzen, wodurch Sie es anderen Benutzern stehlen können.

Im Fall von MCS haben Prüfer gerade die IDOR-Sicherheitsanfälligkeit entdeckt, die mit Nicht-System-IDs verbunden ist. Im persönlichen Konto des Benutzers wurden für den Zugriff auf Objekte UUIDs verwendet, die, wie Sicherheitsleute sagen, eindrucksvoll nicht grob waren (dh vor Brute-Force-Angriffen geschützt waren). Für bestimmte Entitäten wurde jedoch festgestellt, dass gewöhnliche vorhersagbare Zahlen verwendet werden, um Informationen über Anwendungsbenutzer zu erhalten. Ich denke, Sie erkennen, dass Sie die Benutzer-ID um eins ändern, die Anforderung erneut senden und so Informationen erhalten können, die die ACL umgehen (Zugriffssteuerungsliste, Datenzugriffsregeln für Prozesse und Benutzer).

Serverseitige Anforderungsfälschung (SSRF)

OpenSource-Produkte sind gut, weil sie eine Vielzahl von Foren mit einer detaillierten technischen Beschreibung der auftretenden Probleme und, wenn Sie Glück haben, einer Beschreibung der Lösung haben. Diese Münze hat jedoch eine Kehrseite: Bekannte Sicherheitslücken werden ebenfalls detailliert beschrieben. Zum Beispiel enthält das OpenStack-Forum wunderbare Beschreibungen der Schwachstellen [XSS] und [SSRF] , die aus irgendeinem Grund niemand in Eile beheben muss.

Häufige Anwendungsfunktionen sind die Fähigkeit des Benutzers, einen Link an den Server zu senden, dem der Server folgt (z. B. um ein Bild von einer bestimmten Quelle herunterzuladen). Aufgrund der unzureichenden Sicherheitsfilterung der Links oder Antworten, die vom Server an die Benutzer zurückgegeben werden, können Angreifer diese Funktionalität problemlos nutzen.

SSRF-Schwachstellen können die Angriffsentwicklung erheblich vorantreiben. Ein Angreifer kann bekommen:

• eingeschränkter Zugriff auf das angegriffene lokale Netzwerk, beispielsweise nur in bestimmten Netzwerksegmenten und in einem bestimmten Protokoll;
  
• vollständiger Zugriff auf das lokale Netzwerk, wenn ein Downgrade von der Anwendungsebene auf die Transportebene und damit ein vollständiges Lastmanagement auf Anwendungsebene möglich ist;
  
• Zugriff auf das Lesen lokaler Dateien auf dem Server (wenn das Schema file: /// unterstützt wird);
  
• und vieles mehr.
  

OpenStack ist seit langem für seine "blinde" SSRF-Sicherheitsanfälligkeit bekannt: Wenn Sie auf den Server zugreifen, erhalten Sie keine Antwort, aber je nach Ergebnis der Anforderung werden unterschiedliche Arten von Fehlern / Verzögerungen angezeigt. Auf dieser Grundlage können Sie Ports auf Hosts im internen Netzwerk scannen, mit allen daraus resultierenden Konsequenzen, die nicht zu unterschätzen sind. Beispielsweise kann ein Produkt über eine API für das Backoffice verfügen, die nur über das Unternehmensnetzwerk verfügbar ist. Ein Angreifer, der über eine Dokumentation verfügt (Insider nicht vergessen), kann interne Methoden mithilfe von SSRF verwenden. Wenn Sie beispielsweise eine ungefähre Liste nützlicher URLs erhalten haben, können Sie diese mithilfe von SSRF durchgehen und eine Anforderung ausführen - relativ gesehen, Geld von Konto zu Konto überweisen oder Limits ändern.

Dies ist nicht der erste Fall, bei dem SSRF-Schwachstellen in OpenStack erkannt werden. In der Vergangenheit war es möglich, VM-ISO-Images über einen direkten Link herunterzuladen, was ebenfalls zu ähnlichen Konsequenzen führte. Diese Funktion ist derzeit aus OpenStack entfernt. Anscheinend hielt die Community dies für die einfachste und zuverlässigste Lösung des Problems.

In diesem öffentlich zugänglichen Bericht des HackerOne (h1) -Dienstes führt die Nutzung eines nicht blinden SSRF mit der Fähigkeit, Instanzmetadaten zu lesen, zum Root-Zugriff auf die gesamte Shopify-Infrastruktur.

In MCS wurden an zwei Stellen mit ähnlicher Funktionalität SSRF-Schwachstellen entdeckt, die jedoch aufgrund von Firewalls und anderen Schutzmaßnahmen kaum ausgenutzt werden konnten. Auf die eine oder andere Weise hat das MCS-Team dieses Problem trotzdem behoben, ohne auf die Community zu warten.

XSS statt Shells zu laden

Trotz Hunderten von Studien ist XSS (Cross-Site Scripting Attack) von Jahr zu Jahr immer noch die häufigste Web-Sicherheitslücke (oder Attacke ?).

Das Herunterladen von Dateien ist ein beliebter Ort für jeden Sicherheitsforscher. Oft stellt sich heraus, dass Sie ein beliebiges Skript (asp / jsp / php) laden und Betriebssystembefehle in der Terminologie von Pentestern ausführen können - „Load Shell“. Die Popularität solcher Sicherheitslücken wirkt sich jedoch in beide Richtungen aus: Sie werden in Erinnerung behalten und Tools gegen sie entwickelt. In letzter Zeit ist die Wahrscheinlichkeit, dass die Shell geladen wird, auf Null gesunken.

Das angreifende Team (vertreten durch Digital Security) hatte Glück. OK, in MCS wurde auf der Serverseite der Inhalt der heruntergeladenen Dateien überprüft, nur Bilder waren zulässig. SVG ist aber auch ein Bild. Und was können gefährliche SVG-Bilder sein? Weil Sie JavaScript-Fragmente darin einbetten können!

Es stellte sich heraus, dass die heruntergeladenen Dateien allen Benutzern des MCS-Dienstes zur Verfügung stehen. Dies bedeutet, dass Sie andere Benutzer der Cloud angreifen können, nämlich Administratoren.


Ein Beispiel für die Verwendung eines Phishing-Anmeldeformulars mithilfe eines XSS-Angriffs

Beispiele für die Ausnutzung eines XSS-Angriffs:

• Warum sollten Sie versuchen, eine Sitzung zu stehlen (zumal jetzt überall nur HTTP-Cookies mit js-Skripten vor Diebstahl geschützt sind), wenn das heruntergeladene Skript sofort auf die Ressourcen-API zugreifen kann? In diesem Fall kann die Nutzlast die Serverkonfiguration durch XHR-Anforderungen ändern. Fügen Sie beispielsweise den öffentlichen SSH-Schlüssel des Angreifers hinzu und erhalten Sie SSH-Zugriff auf den Server.
  
• Wenn die CSP-Richtlinie (Content Protection Policy) die Implementierung von JavaScript verbietet, kann ein Angreifer darauf verzichten. Erstellen Sie in reinem HTML das gefälschte Anmeldeformular der Website und stehlen Sie das Administratorkennwort durch ein derart erweitertes Phishing: Die Phishing-Seite für den Benutzer befindet sich unter derselben URL, und es ist für den Benutzer schwieriger, sie zu erkennen.
  
• Schließlich kann ein Angreifer einen Client DoS einrichten - Cookies setzen, die größer als 4 KB sind. Es reicht aus, wenn der Benutzer den Link einmal öffnet und die gesamte Site nicht mehr zugänglich ist, bis Sie speziell raten, den Browser zu bereinigen: In den allermeisten Fällen weigert sich der Webserver, einen solchen Client zu akzeptieren.
  

Schauen wir uns ein Beispiel für ein weiteres enthülltes XSS an, diesmal mit schwierigerer Bedienung. Mit dem MCS-Dienst können Sie Firewall-Einstellungen in Gruppen zusammenfassen. XSS wurde im Gruppennamen entdeckt. Seine Besonderheit war, dass der Vektor nicht sofort funktionierte, nicht beim Anzeigen der Regelliste, sondern beim Löschen der Gruppe:



Das heißt, das Szenario war wie folgt: Ein Angreifer erstellt eine Firewall-Regel mit einem "Laden" im Namen. Der Administrator bemerkt dies nach einer Weile und leitet den Löschvorgang ein. Und hier erfüllt sich auch der böswillige JS.

Für die MCS-Entwickler empfahl das Digital Security-Team zum Schutz vor XSS in herunterladbaren SVG-Bildern (falls diese nicht aufgegeben werden können):

• Hostdateien, die von Benutzern in einer separaten Domain hochgeladen wurden, haben nichts mit „Cookies“ zu tun. Das Skript wird im Kontext einer anderen Domäne ausgeführt und stellt keine Bedrohung für MCS dar.
  
• Geben Sie in der HTTP-Antwort des Servers den Header "Inhaltsdisposition: Anhang" an. Dann werden die Dateien vom Browser heruntergeladen und nicht ausgeführt.
  

Darüber hinaus stehen Entwicklern jetzt viele Möglichkeiten zur Verfügung, um die Risiken des Betriebs von XSS zu verringern:

• Mit dem Flag "Nur HTTP" können Sie die Sitzungsheader von Cookies für böswilliges JavaScript unzugänglich machen.
  
• Eine korrekt implementierte CSP-Richtlinie erschwert den Betrieb von XSS für einen Angreifer erheblich.
  
• Moderne Template-Engines wie Angular oder React löschen Benutzerdaten automatisch, bevor sie im Browser des Benutzers angezeigt werden.
  

Sicherheitslücken bei der Zwei-Faktor-Authentifizierung

Um die Kontosicherheit zu erhöhen, wird Benutzern immer empfohlen, 2FA (Zwei-Faktor-Authentifizierung) zu aktivieren. Dies ist in der Tat ein wirksamer Weg, um zu verhindern, dass ein Angreifer Zugriff auf den Dienst erhält, wenn die Benutzeranmeldeinformationen kompromittiert wurden.

Aber garantiert die Verwendung des zweiten Authentifizierungsfaktors immer die Sicherheit des Kontos? In einer 2FA-Implementierung gibt es solche Sicherheitsprobleme:

• Grobe Suche nach OTP-Code (Einmalcodes). Trotz der einfachen Bedienung treten Fehler wie der fehlende Schutz gegen das OTP-Tier auch bei großen Unternehmen auf: im Fall Slack , im Fall Facebook .
  
• Schwacher Generierungsalgorithmus, zum Beispiel die Fähigkeit, den folgenden Code vorherzusagen.
  
• Logische Fehler, zum Beispiel die Möglichkeit, das OTP einer anderen Person auf Ihrem Telefon anzufordern, wie dies bei Shopify der Fall war.
  

Im Fall von MCS wird 2FA basierend auf Google Authenticator und Duo implementiert. Das Protokoll selbst wurde bereits im Laufe der Zeit getestet, aber die Implementierung der Codeüberprüfung auf der Anwendungsseite ist eine Überprüfung wert.

Das MCS 2FA wird an mehreren Stellen eingesetzt:

• Bei der Benutzerauthentifizierung. Hier besteht Schutz vor Brute Force: Der Benutzer hat nur wenige Versuche, ein Einmalkennwort einzugeben, dann wird die Eingabe für eine Weile blockiert. Dies blockiert die Möglichkeit, OTP-Busting durchzuführen.
  
• Beim Generieren von Offline-Sicherungscodes zum Ausführen von 2FA sowie beim Deaktivieren. Hier wurde kein Schutz gegen Brute Force implementiert, wodurch es möglich wurde, Sicherungscodes neu zu generieren oder 2FA vollständig zu deaktivieren, wenn ein Kennwort für das Konto und eine aktive Sitzung vorhanden waren.
  

In Anbetracht der Tatsache, dass sich die Sicherungscodes im gleichen Bereich von Zeilenwerten befanden wie die von der OTP-Anwendung generierten, war die Chance, den Code in kurzer Zeit abzurufen, viel höher.


Der Prozess der Auswahl von OTP zum Deaktivieren von 2FA mit dem Werkzeug Burp: Intruder

Ergebnis

Im Allgemeinen erwies sich MCS als Produkt als sicher. Während des Audits konnte das Pentester-Team nicht auf die Client-VMs und deren Daten zugreifen, und die gefundenen Schwachstellen wurden vom MCS-Team schnell behoben.

Hierbei ist jedoch zu beachten, dass Sicherheit kontinuierliche Arbeit ist. Services sind nicht statisch, sie entwickeln sich ständig weiter. Und ein Produkt völlig ohne Schwachstellen zu entwickeln, ist unmöglich. Sie können sie jedoch rechtzeitig finden und die Wahrscheinlichkeit ihrer Wiederholung minimieren.

Jetzt sind alle genannten Schwachstellen in MCS bereits behoben. Um die Anzahl der neuen zu minimieren und ihre Lebensdauer zu verkürzen, setzt das Plattformteam dies fort:

• regelmäßige Audits durch externe Unternehmen durchführen;
  
• Unterstützung und Entwicklung der Teilnahme am Bug Bounty-Programm Mail.ru Group ;
  
• Sicherheit tun. :) :)