von SeerLight
Der Aufbau eines jeden Dienstes erfordert zwangsläufig eine ständige Arbeit an der Sicherheit. Sicherheit ist ein kontinuierlicher Prozess, der die ständige Analyse und Verbesserung der Produktsicherheit, die Überwachung von Nachrichten über Schwachstellen und vieles mehr umfasst. Inklusive Audits. Audits werden sowohl intern als auch von externen Experten durchgeführt, die entscheidend zur Sicherheit beitragen können, weil sie nicht in das Projekt vertieft und aufgeschlossen sind.
In dem Artikel geht es um diese einfachste Sichtweise externer Experten, die dem Mail.ru Cloud Solutions (MCS)-Team beim Testen des Cloud-Dienstes geholfen haben, und um ihre Ergebnisse. Als „externe Kraft“ wählte MCS das Unternehmen Digital Security, das für seine hohe Fachkompetenz in Informationssicherheitskreisen bekannt ist. Und in diesem Artikel analysieren wir einige interessante Schwachstellen, die im Rahmen einer externen Prüfung gefunden wurden – damit Sie bei der Erstellung Ihres eigenen Cloud-Dienstes denselben Schaden vermeiden.
Описание продукта
ist eine Plattform zum Aufbau einer virtuellen Infrastruktur in der Cloud. Es umfasst IaaS, PaaS und einen Marktplatz mit vorgefertigten Anwendungsimages für Entwickler. Unter Berücksichtigung der MCS-Architektur war es notwendig, die Sicherheit des Produkts in folgenden Bereichen zu überprüfen:
- Schutz der Infrastruktur der Virtualisierungsumgebung: Hypervisoren, Routing, Firewalls;
- Schutz der virtuellen Infrastruktur der Kunden: Isolierung voneinander, einschließlich Netzwerk, private Netzwerke in SDN;
- OpenStack und seine offenen Komponenten;
- S3 unseres eigenen Designs;
- IAM: Multi-Tenant-Projekte mit Vorbild;
- Vision (Computer Vision): APIs und Schwachstellen bei der Arbeit mit Bildern;
- Webinterface und klassische Webangriffe;
- Schwachstellen von PaaS-Komponenten;
- API aller Komponenten.
Vielleicht ist das alles, was für die weitere Geschichte wesentlich ist.
Welche Art von Arbeit wurde durchgeführt und warum war sie notwendig?
Eine Sicherheitsüberprüfung zielt darauf ab, Schwachstellen und Konfigurationsfehler zu identifizieren, die zum Verlust personenbezogener Daten, zur Änderung vertraulicher Informationen oder zur Unterbrechung der Dienstverfügbarkeit führen können.
Während der Arbeit, die durchschnittlich 1–2 Monate dauert, wiederholen 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 identifiziert:
- Analyse der Authentifizierung im Dienst. Schwachstellen in dieser Komponente würden dazu beitragen, sofort in die Konten anderer Personen einzudringen.
- Untersuchung des Rollenmodells und der Zugriffskontrolle zwischen verschiedenen Konten. Für einen Angreifer ist die Möglichkeit, sich Zugriff auf die virtuelle Maschine einer anderen Person zu verschaffen, ein wünschenswertes Ziel.
- Clientseitige Schwachstellen. XSS/CSRF/CRLF/etc. Ist es möglich, andere Benutzer über bösartige Links anzugreifen?
- Serverseitige Schwachstellen: RCE und alle Arten von Injektionen (SQL/XXE/SSRF usw.). Serverschwachstellen sind im Allgemeinen schwieriger zu finden, führen jedoch zur Gefährdung vieler Benutzer gleichzeitig.
- Analyse der Benutzersegmentisolation auf Netzwerkebene. Für einen Angreifer erhöht die fehlende Isolation die Angriffsfläche gegenüber anderen Benutzern erheblich.
- Analyse der Geschäftslogik. Ist es möglich, Unternehmen zu täuschen und kostenlos virtuelle Maschinen zu erstellen?
In diesem Projekt wurde nach dem „Gray-Box“-Modell gearbeitet: Prüfer interagierten mit den Privilegien normaler Benutzer mit dem Dienst, besaßen jedoch teilweise den Quellcode der API und hatten die Möglichkeit, Details mit den Entwicklern zu klären. Dies ist normalerweise das bequemste und gleichzeitig recht realistische Arbeitsmodell: Interne Informationen können von einem Angreifer immer noch gesammelt werden, es ist nur eine Frage der Zeit.
Gefundene Schwachstellen
Bevor der Prüfer damit beginnt, verschiedene Nutzlasten (die Nutzlast, die zur Durchführung des Angriffs verwendet wurde) an zufällige Orte zu senden, muss er verstehen, wie die Dinge funktionieren und welche Funktionalität bereitgestellt wird. Es mag den Anschein haben, dass dies eine nutzlose Übung ist, da es an den meisten untersuchten Orten keine Schwachstellen gibt. Aber nur das Verständnis der Struktur der Anwendung und der Logik ihrer Funktionsweise ermöglicht es, die komplexesten Angriffsvektoren zu finden.
Es ist wichtig, Orte zu finden, die verdächtig erscheinen oder sich in irgendeiner Weise stark von anderen unterscheiden. Und auf diese Weise wurde die erste gefährliche Schwachstelle gefunden.
IDOR
IDOR-Schwachstellen (Insecure Direct Object Reference) gehören zu den häufigsten Schwachstellen in der Geschäftslogik, die es dem einen oder anderen ermöglichen, auf Objekte zuzugreifen, auf die der Zugriff eigentlich nicht erlaubt ist. IDOR-Schwachstellen bieten die Möglichkeit, Informationen unterschiedlicher Kritikalität über einen Benutzer zu erhalten.
Eine der IDOR-Optionen besteht darin, Aktionen mit Systemobjekten (Benutzer, Bankkonten, Artikel im Warenkorb) durchzuführen, indem Zugriffskennungen auf diese Objekte manipuliert werden. Dies führt zu den unvorhersehbarsten Folgen. Zum Beispiel die Möglichkeit, das Konto des Absenders von Geldern zu ersetzen, wodurch Sie diese anderen Benutzern stehlen können.
Im Fall von MCS haben Prüfer gerade eine IDOR-Schwachstelle im Zusammenhang mit nicht sicheren Identifikatoren entdeckt. Im persönlichen Konto des Benutzers wurden UUID-Identifikatoren für den Zugriff auf beliebige Objekte verwendet, die, wie Sicherheitsexperten sagen, beeindruckend unsicher (also vor Brute-Force-Angriffen geschützt) wirkten. Bei bestimmten Unternehmen wurde jedoch festgestellt, dass regelmäßig vorhersehbare Zahlen verwendet werden, um Informationen über die Benutzer der Anwendung zu erhalten. Ich denke, Sie können sich vorstellen, dass es möglich war, die Benutzer-ID um eins zu ändern, die Anfrage erneut zu senden und so Informationen unter Umgehung der ACL (Zugriffskontrollliste, Datenzugriffsregeln für Prozesse und Benutzer) zu erhalten.
Serverseitige Anforderungsfälschung (SSRF)
Das Gute an OpenSource-Produkten ist, dass es eine große Anzahl von Foren mit detaillierten technischen Beschreibungen der auftretenden Probleme und, wenn Sie Glück haben, einer Beschreibung der Lösung gibt. Doch diese Münze hat eine Kehrseite: Auch bekannte Schwachstellen werden ausführlich beschrieben. Im OpenStack-Forum gibt es zum Beispiel wunderbare Beschreibungen von Schwachstellen и , was aus irgendeinem Grund niemand so schnell beheben kann.
Eine häufige Funktionalität von Anwendungen besteht darin, dass der Benutzer einen Link an den Server senden kann, auf den der Server klickt (z. B. um ein Bild von einer bestimmten Quelle herunterzuladen). Wenn Sicherheitstools die Links selbst oder die vom Server an Benutzer zurückgegebenen Antworten nicht filtern, können Angreifer diese Funktionalität leicht nutzen.
SSRF-Schwachstellen können die Entwicklung eines Angriffs erheblich vorantreiben. Ein Angreifer kann Folgendes erhalten:
- eingeschränkter Zugriff auf das angegriffene lokale Netzwerk, beispielsweise nur über bestimmte Netzwerksegmente und unter Verwendung eines bestimmten Protokolls;
- voller Zugriff auf das lokale Netzwerk, wenn ein Downgrade von der Anwendungsebene auf die Transportebene möglich ist und dadurch vollständiges Lastmanagement auf Anwendungsebene;
- Zugriff zum Lesen lokaler Dateien auf dem Server (sofern das Schema „file:///“ unterstützt wird);
- und vieles mehr.
In OpenStack ist seit langem eine SSRF-Schwachstelle bekannt, die „blinder“ Natur ist: Wenn Sie den Server kontaktieren, erhalten Sie keine Antwort von diesem, sondern erhalten je nach Ergebnis der Anfrage unterschiedliche Arten von Fehlern/Verzögerungen . Auf dieser Grundlage können Sie einen Port-Scan auf Hosts im internen Netzwerk durchführen – mit allen nicht zu unterschätzenden Konsequenzen. Beispielsweise kann ein Produkt über eine Backoffice-API verfügen, auf die nur über das Unternehmensnetzwerk zugegriffen werden kann. Mit Dokumentation (Insider nicht vergessen) kann ein Angreifer SSRF verwenden, um auf interne Methoden zuzugreifen. Wenn Sie beispielsweise irgendwie in der Lage waren, eine ungefähre Liste nützlicher URLs zu erhalten, können Sie diese mit SSRF durchgehen und eine Anfrage ausführen – relativ gesehen, Geld von Konto zu Konto überweisen oder Limits ändern.
Dies ist nicht das erste Mal, dass eine SSRF-Schwachstelle in OpenStack entdeckt wurde. In der Vergangenheit war es möglich, VM-ISO-Images über einen direkten Link herunterzuladen, was ebenfalls zu ähnlichen Konsequenzen führte. Diese Funktion wurde jetzt aus OpenStack entfernt. Offenbar hielt die Community dies für die einfachste und zuverlässigste Lösung des Problems.
Und in Öffentlich verfügbarer Bericht des HackerOne-Dienstes (h1): Die Ausnutzung eines nicht mehr blinden SSRF mit der Möglichkeit, Instanzmetadaten zu lesen, führt zu Root-Zugriff auf die gesamte Shopify-Infrastruktur.
In MCS wurden an zwei Stellen SSRF-Schwachstellen mit ähnlicher Funktionalität entdeckt, die jedoch aufgrund von Firewalls und anderen Schutzmaßnahmen kaum auszunutzen waren. Auf die eine oder andere Weise hat das MCS-Team dieses Problem trotzdem behoben, ohne auf die Community zu warten.
XSS statt Shells laden
Obwohl Hunderte von Studien verfasst wurden, sind XSS-Angriffe (Cross-Site-Scripting) Jahr für Jahr immer noch der häufigste Angriff Web-Sicherheitslücke (bzw ?).
Datei-Uploads sind ein beliebter Ort für jeden Sicherheitsforscher. Es stellt sich oft heraus, dass Sie ein beliebiges Skript (asp/jsp/php) laden und Betriebssystembefehle ausführen können, in der Terminologie von Pentestern – „Shell laden“. Doch die Beliebtheit solcher Schwachstellen wirkt sich in beide Richtungen aus: Man erinnert sich an sie und es werden Abhilfemaßnahmen gegen sie entwickelt, so dass die Wahrscheinlichkeit, „eine Hülle zu laden“, in letzter Zeit gegen Null tendiert.
Das angreifende Team (vertreten durch Digital Security) hatte Glück. OK, im MCS wurden serverseitig die Inhalte der heruntergeladenen Dateien überprüft, nur Bilder waren erlaubt. Aber SVG ist auch ein Bild. Wie können SVG-Bilder gefährlich sein? Weil Sie JavaScript-Snippets darin einbetten können!
Es stellte sich heraus, dass die heruntergeladenen Dateien allen Benutzern des MCS-Dienstes zur Verfügung stehen, was bedeutet, dass ein Angriff auf andere Cloud-Benutzer, nämlich Administratoren, möglich ist.
Ein Beispiel für einen XSS-Angriff auf ein Phishing-Anmeldeformular
Beispiele für die Ausnutzung von XSS-Angriffen:
- Warum sollten Sie versuchen, eine Sitzung zu stehlen (vor allem, da es jetzt überall reine HTTP-Cookies gibt, die mithilfe von JS-Skripten vor Diebstahl geschützt sind), wenn das geladene Skript sofort auf die Ressourcen-API zugreifen kann? In diesem Fall kann die Nutzlast XHR-Anfragen verwenden, um die Serverkonfiguration zu ändern, beispielsweise den öffentlichen SSH-Schlüssel des Angreifers hinzuzufügen und SSH-Zugriff auf den Server zu erhalten.
- Wenn die CSP-Richtlinie (Content Protection Policy) das Einschleusen von JavaScript verbietet, kann ein Angreifer darauf verzichten. Erstellen Sie mithilfe von reinem HTML ein gefälschtes Anmeldeformular für die Website und stehlen Sie durch dieses fortgeschrittene Phishing das Administratorkennwort: Die Phishing-Seite des Benutzers landet unter derselben URL und ist für den Benutzer schwieriger zu erkennen.
- Schließlich kann der Angreifer arrangieren — Setzen Sie Cookies, die größer als 4 KB sind. Der Benutzer muss den Link nur einmal öffnen, und die gesamte Website wird unzugänglich, bis der Benutzer daran denkt, den Browser gezielt zu bereinigen: In den allermeisten Fällen weigert sich der Webserver, einen solchen Client zu akzeptieren.
Schauen wir uns ein Beispiel eines anderen erkannten XSS an, dieses Mal mit einem clevereren Exploit. Mit dem MCS-Dienst können Sie Firewall-Einstellungen in Gruppen zusammenfassen. Der Gruppenname war der Ort, an dem das XSS erkannt wurde. Seine Besonderheit bestand darin, dass der Vektor nicht sofort ausgelöst wurde, nicht beim Anzeigen der Regelliste, sondern beim Löschen einer Gruppe:
Das heißt, das Szenario stellte sich wie folgt dar: Ein Angreifer erstellt eine Firewall-Regel mit „load“ im Namen, der Administrator bemerkt dies nach einiger Zeit und leitet den Löschvorgang ein. Und hier funktioniert das bösartige JS.
Für MCS-Entwickler empfahl das Digital Security-Team zum Schutz vor XSS in heruntergeladenen SVG-Bildern (sofern diese nicht aufgegeben werden können):
- Platzieren Sie von Benutzern hochgeladene Dateien auf einer separaten Domain, die nichts mit „Cookies“ zu tun hat. Das Skript wird im Kontext einer anderen Domäne ausgeführt und stellt keine Bedrohung für MCS dar.
- Senden Sie in der HTTP-Antwort des Servers den Header „Content-disposition: attachment“. Dann werden die Dateien vom Browser heruntergeladen und nicht ausgeführt.
Darüber hinaus stehen Entwicklern mittlerweile viele Möglichkeiten zur Verfügung, die Risiken der XSS-Ausnutzung zu mindern:
- Mit dem Flag „Nur HTTP“ können Sie Sitzungs-Cookie-Header für bösartiges JavaScript unzugänglich machen.
- wird es für einen Angreifer viel schwieriger machen, XSS auszunutzen;
- Moderne Template-Engines wie Angular oder React bereinigen Benutzerdaten automatisch, bevor sie sie an den Browser des Benutzers ausgeben.
Schwachstellen bei der Zwei-Faktor-Authentifizierung
Um die Kontosicherheit zu verbessern, wird Benutzern immer empfohlen, 2FA (Zwei-Faktor-Authentifizierung) zu aktivieren. Tatsächlich ist dies eine wirksame Möglichkeit, einen Angreifer daran zu hindern, Zugriff auf einen Dienst zu erhalten, wenn die Anmeldeinformationen des Benutzers kompromittiert wurden.
Aber garantiert die Verwendung eines zweiten Authentifizierungsfaktors immer die Kontosicherheit? Bei der Implementierung von 2FA gibt es folgende Sicherheitsprobleme:
- Brute-Force-Suche des OTP-Codes (Einmalcodes). Trotz der Einfachheit der Bedienung kommt es auch bei großen Unternehmen zu Fehlern wie mangelndem Schutz vor OTP-Brute-Force: , .
- Schwacher Generierungsalgorithmus, beispielsweise die Fähigkeit, den nächsten Code vorherzusagen.
- Logische Fehler, etwa die Möglichkeit, das OTP einer anderen Person auf Ihrem Telefon anzufordern, wie dieser von Shopify.
Im Fall von MCS wird 2FA basierend auf Google Authenticator und implementiert . Das Protokoll selbst hat sich bereits bewährt, die Implementierung der Code-Verifizierung auf der Anwendungsseite ist jedoch eine Überprüfung wert.
MCS 2FA wird an mehreren Stellen verwendet:
- Bei der Authentifizierung des Benutzers. Es gibt einen Brute-Force-Schutz: Der Nutzer hat nur wenige Versuche, ein Einmalpasswort einzugeben, dann ist die Eingabe für eine Weile gesperrt. Dadurch wird die Möglichkeit einer Brute-Force-Auswahl von OTP blockiert.
- Beim Generieren von Offline-Backup-Codes zur Durchführung von 2FA sowie bei deren Deaktivierung. Hier wurde kein Brute-Force-Schutz implementiert, der es ermöglichte, wenn man ein Passwort für das Konto und eine aktive Sitzung hatte, Backup-Codes neu zu generieren oder 2FA komplett zu deaktivieren.
Wenn man bedenkt, dass sich die Backup-Codes im gleichen Bereich von String-Werten befanden wie die von der OTP-Anwendung generierten, war die Chance, den Code in kurzer Zeit zu finden, viel höher.
Der Prozess der Auswahl eines OTP zum Deaktivieren von 2FA mit dem „Burp: Intruder“-Tool
Erlebe die Kraft effektiver Ergebnisse
Insgesamt scheint MCS als Produkt sicher zu sein. Während des Audits konnte das Pentesting-Team keinen Zugriff auf Client-VMs und deren Daten erhalten und die gefundenen Schwachstellen wurden vom MCS-Team schnell behoben.
Aber hier ist es wichtig zu beachten, dass Sicherheit eine kontinuierliche Arbeit ist. Dienstleistungen sind nicht statisch, sie entwickeln sich ständig weiter. Und es ist unmöglich, ein Produkt vollständig ohne Schwachstellen zu entwickeln. Aber Sie können sie rechtzeitig erkennen und das Risiko eines erneuten Auftretens minimieren.
Nun wurden alle genannten Schwachstellen in MCS bereits behoben. Und um die Anzahl neuer Geräte so gering wie möglich zu halten und ihre Lebensdauer zu verkürzen, macht das Plattform-Team weiterhin Folgendes:
- führen regelmäßig Audits durch externe Unternehmen durch;
- Partizipation unterstützen und weiterentwickeln;
- sich für Sicherheit einsetzen. 🙂
Source: habr.com