von SeerLight
Der Aufbau eines jeden Services beinhaltet notwendigerweise die kontinuierliche Arbeit an der Sicherheit. Sicherheit ist ein fortlaufender Prozess, der ständige Analyse und Verbesserung des Produktschutzes, Monitoring von Nachrichten über Schwachstellen 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 eingetaucht sind und einen unvoreingenommenen Blick haben.
Der Artikel handelt von genau diesem unvoreingenommenen Blick externer Experten, die dem Team von Mail.ru Cloud Solutions (MCS) geholfen haben, den Cloud-Service zu testen, und darüber, was sie gefunden haben. Als "externe Kräfte" wählte MCS das Unternehmen Digital Security, bekannt für seine hohe Expertise in der IT-Sicherheit. In diesem Artikel werden wir einige interessante Schwachstellen untersuchen, die im Rahmen des externen Audits gefunden wurden – um Ihnen ähnliche Probleme zu ersparen, wenn Sie Ihren eigenen Cloud-Service erstellen.
Produktbeschreibung
ist eine Plattform zum Aufbau von virtueller Infrastruktur in der Cloud. Sie umfasst IaaS, PaaS und einen Marktplatz für fertige Anwendungsbilder für Entwickler. In Anbetracht der Architektur von MCS musste die Sicherheit des Produkts in folgenden Bereichen überprüft werden:
- Schutz der Virtualisierungsumgebung: Hypervisoren, Routing, Firewalls;
- Schutz der virtuellen Infrastruktur der Kunden: Isolation untereinander, einschließlich Netzwerkintegration, private Netzwerke in SDN;
- OpenStack und seine offenen Komponenten;
- Eigenentwickeltes S3;
- IAM: multitenante Projekte mit Rollenmodell;
- Vision (maschinelles Sehen): API und Schwachstellen bei der Verarbeitung von Bildern;
- Web-Interface und klassische Web-Angriffe;
- Schwachstellen von PaaS-Komponenten;
- API aller Komponenten.
Vielleicht ist das 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 zu Verfügbarkeitsstörungen von Services führen können.
Im Rahmen der Arbeiten, die im Durchschnitt 1-2 Monate dauern, wiederholen die Prüfer die Aktionen potenzieller Angreifer und suchen nach Sicherheitslücken im Client- und Serverbereich des gewählten Dienstes. Im Kontext des Audits der Cloud-Plattform MCS wurden folgende Ziele festgelegt:
- Analyse der Authentifizierung im Dienst. Sicherheitslücken in diesem Bereich könnten es ermöglichen, sofort auf fremde Konten zuzugreifen.
- Untersuchung des Rollenmodells und der Zugriffstrennung zwischen verschiedenen Konten. Für einen Angreifer ist der Zugang zu einer fremden virtuellen Maschine ein erstrebenswertes Ziel.
- Sicherheitslücken im Clientbereich. XSS/CSRF/CRLF/etc. Gibt es möglicherweise die Möglichkeit, andere Benutzer über schädliche Links anzugreifen?
- Sicherheitslücken im Serverbereich: RCE und verschiedene Injections (SQL/XXE/SSRF usw.). Serveranfälligkeiten sind in der Regel schwieriger zu finden, führen jedoch zur Kompromittierung vieler Benutzer zugleich.
- Analyse der Isolierung von Benutzersegmenten auf Netzwerkebene. Für einen Angreifer erhöht das Fehlen von Isolierung die Angriffsfläche auf andere Benutzer erheblich.
- Analyse der Geschäftslogik. Kann man das Geschäft betrügen und virtuelle Maschinen kostenlos erstellen?
In diesem Projekt wurde nach dem „Gray-box“-Modell gearbeitet: Die Prüfer interagierten mit dem Dienst mit den Rechten normaler Benutzer, hatten jedoch teilweise Zugang zu den Quelltexten der API und konnten Details bei den Entwicklern nachfragen. Normalerweise ist dies das bequemste und gleichzeitig realistischste Arbeitsmodell: Interne Informationen können von einem Angreifer eingeschlossen werden, es ist nur eine Frage der Zeit.
Gefundene Sicherheitslücken
Bevor der Prüfer beginnt, verschiedene Payloads (Nutzlasten, mit denen der Angriff durchgeführt wird) an zufällige Stellen zu senden, ist es notwendig zu verstehen, wie alles funktioniert und welche Funktionalitäten vorhanden sind. Es mag nutzlos erscheinen, denn in den meisten untersuchten Bereichen wird es keine Sicherheitslücken geben. Doch nur das Verständnis der Struktur der Anwendung und der Logik ihres Betriebs ermöglicht es, die komplexesten Angriffsvektoren zu finden.
Es ist wichtig, Stellen zu finden, die verdächtig erscheinen oder sich stark von anderen unterscheiden. Die erste gefährliche Sicherheitslücke wurde genau auf diese Weise gefunden.
IDOR
IDOR-Schwachstellen (Insecure Direct Object Reference, unsichere direkte Objektverweise) gehören zu den häufigsten Anfälligkeiten in der Geschäftslogik, die es ermöglichen, auf verschiedene Weisen auf Objekte zuzugreifen, auf die tatsächlich kein Zugriff gewährt ist. IDOR-Schwachstellen bieten die Möglichkeit, Informationen über Nutzer mit unterschiedlichem Kritikalitätsgrad zu erhalten.
Eine Variante von IDOR besteht darin, Aktionen mit Objekten des Systems (Benutzern, Bankkonten, Artikeln im Warenkorb) durch Manipulation der Zugriffsidentifikatoren für diese Objekte auszuführen. Dies kann zu den unvorhersehbarsten Konsequenzen führen. Zum Beispiel besteht die Möglichkeit, das Konto des Absenders von Geldmitteln zu übernehmen, wodurch es anderen Benutzern gestohlen werden kann.
Im Fall von MCS haben Auditoren tatsächlich eine IDOR-Schwachstelle entdeckt, die mit unsicheren Identifikatoren verbunden ist. Im persönlichen Bereich des Nutzers wurden UUID-Identifikatoren verwendet, um auf beliebige Objekte zuzugreifen, die von Sicherheitsexperten als beeindruckend bruchfest (d.h. vor Brute-Force-Angriffen geschützt) angesehen wurden. Für bestimmte Entitäten wurde jedoch festgestellt, dass zur Abfrage von Informationen über die Benutzer der Anwendung ganz gewöhnliche vorhersehbare Nummern verwendet wurden. Ich denke, Sie ahnen, dass man die Benutzer-ID um eins erhöhen, die Anfrage erneut senden und so Informationen umgehen konnte, die durch die ACL (Zugriffskontrollliste, Regeln für den Datenzugriff für Prozesse und Benutzer) geschützt sind.
Server Side Request Forgery (SSRF)
OpenSource-Produkte haben den Vorteil, dass es eine enorme Anzahl von Foren gibt, die detaillierte technische Beschreibungen der auftretenden Probleme liefern und, wenn Sie Glück haben, Beschreibungen der Lösungen bieten. Aber diese Medaille hat eine Kehrseite: Auch bekannte Schwachstellen sind darin ausführlich beschrieben. Zum Beispiel gibt es im OpenStack-Forum großartige Beschreibungen von Schwachstellen und , die aus irgendwelchen Gründen niemand zu beheben scheint.
Eine häufige Funktionalität von Anwendungen ist die Möglichkeit für den Nutzer, einen Link an den Server zu senden, über den der Server weitergeht (zum Beispiel um ein Bild aus der angegebenen Quelle hochzuladen). Bei unzureichender Filterung der Links oder der von Server an die Benutzer zurückgegebenen Antworten können Angreifer diese Funktionalität leicht ausnutzen.
SSRF-Schwachstellen können die Entwicklung eines Angriffs erheblich vorantreiben. Ein Angreifer kann erhalten:
- eingeschränkten Zugriff auf das angegriffene interne Netzwerk, zum Beispiel nur auf bestimmten Netzwerksegmenten und über ein bestimmtes Protokoll;
- vollen Zugriff auf das lokale Netzwerk, wenn ein Downgrade vom Anwendungslevel auf das Transportschichtlevel möglich ist und damit die vollständige Kontrolle über den Lastenverkehr auf Anwendungsebene;
- Zugriff auf lokale Dateien auf dem Server (wenn das Schema file:/// unterstützt wird);
- und vieles mehr.
In OpenStack ist eine SSRF-Schwachstelle seit langem bekannt, die „blind“ ist: beim Zugriff auf den Server erhält man keine Antwort von ihm, sondern verschiedene Arten von Fehlern/Verzögerungen, abhängig vom Ergebnis der Anfrage. Auf dieser Grundlage kann ein Port-Scanning innerhalb des internen Netzwerks durchgeführt werden, mit allen damit verbundenen Konsequenzen, die man nicht unterschätzen sollte. Beispielsweise kann ein Produkt eine API für das Backoffice haben, die nur aus dem Unternehmensnetzwerk zugänglich ist. Mit der entsprechenden Dokumentation (vergessen wir nicht die Insider) kann ein Angreifer über SSRF auf interne Methoden zugreifen. Wenn es ihm zum Beispiel gelingt, eine ungefähre Liste nützlicher URLs zu erhalten, kann er diese mit SSRF durchgehen und Anfragen ausführen – hypothetisch Geld von einem Konto auf ein anderes überweisen oder Limits ändern.
Es ist nicht der erste Fall, in dem eine SSRF-Schwachstelle in OpenStack entdeckt wurde. In der Vergangenheit gab es die Möglichkeit, ISO-Abbilder von VMs über einen direkten Link hochzuladen, was ebenfalls zu ähnlichen Konsequenzen führte. Diese Funktion wurde mittlerweile aus OpenStack entfernt. Offensichtlich hielt die Community dies für die einfachste und zuverlässigste Lösung des Problems.
Und bei Im öffentlich zugänglichen Bericht vom Service HackerOne (h1) führt die Ausnutzung der nicht blinden SSRF mit der Möglichkeit, Metadaten der Instanz zu lesen, zum Erwerb von Root-Zugriff auf die gesamte Infrastruktur von Shopify.
In MCS wurden an zwei Stellen mit ähnlicher Funktionalität SSRF-Schwachstellen entdeckt, aber sie waren nahezu unmöglich auszunutzen aufgrund von Firewalls und anderen Sicherheitsmaßnahmen. So oder so hat das MCS-Team dieses Problem behoben, ohne auf die Community zu warten.
XSS anstelle des Hochladens von „Shells“
Trotz der Hunderten von durchgeführten Studien ist XSS (Cross-Site Scripting) nach wie vor die Web-Schwachstelle (oder ?).
Das Hochladen von Dateien ist ein beliebter Bereich für jeden Sicherheitsforscher. Oftmals kann man beliebige Skripte (asp/jsp/php) hochladen und OS-Befehle ausführen, was in der Terminologie von Pen-Testern als „Shell hochladen“ bezeichnet wird. Doch die Beliebtheit solcher Schwachstellen funktioniert in beide Richtungen: Man erinnert sich daran und entwickelt Abwehrmaßnahmen, sodass die Wahrscheinlichkeit, eine „Shell hochzuladen“, in letzter Zeit nahe Null tendiert.
Das Angriffsteam (vertreten durch Digital Security) hatte Glück. Okay, im MCS wurde auf der Serverseite der Inhalt der hochgeladenen Dateien geprüft; es waren nur Bilder erlaubt. Aber SVG ist auch ein Bild. Was könnte an SVG-Bildern gefährlich sein? Dass man darin JavaScript-Fragmenten einbetten kann!
Es stellte sich heraus, dass die hochgeladenen Dateien für alle Benutzer des MCS-Dienstes zugänglich sind – das bedeutet, man kann andere Benutzer der Cloud angreifen, insbesondere die Administratoren.
Beispiel einer Implementierung durch eine XSS-Attacke mit einem Phishing-Loginformular
Beispiele für die Ausnutzung von XSS-Attacken:
- Warum versuchen, eine Sitzung zu stehlen (zumal es jetzt überall HTTP-Only-Cookies gibt, die vor dem Diebstahl durch JS-Skripte geschützt sind), wenn das hochgeladene Skript sofort auf die API des Dienstes 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 dadurch SSH-Zugriff auf den Server erhalten.
- Wenn die CSP-Politik (Content Security Policy) das Einfügen von JavaScript verbietet, kann sich der Angreifer auch ohne dieses behelfen. Er kann mit reinem HTML ein gefälschtes Anmeldeformular erstellen und das Passwort des Administrators durch so fortschrittliches Phishing stehlen: Die Phishing-Seite für den Benutzer erscheint unter derselben URL, wodurch es für den Benutzer schwieriger wird, sie zu entdecken.
- Schließlich könnte der Angreifer einen veranstalten, indem er Cookies von mehr als 4 KB Größe setzt. Der Benutzer muss einfach einmal den Link öffnen – und die gesamte Website wird unzugänglich, bis er herausfindet, dass er den Browser manuell bereinigen muss: In den meisten Fällen wird der Webserver sich weigern, einen solchen Client zu akzeptieren.
Betrachten wir ein Beispiel für eine weitere entdeckte XSS, diesmal mit einer raffinierteren Ausnutzung. Der MCS-Dienst ermöglicht es, Firewall-Einstellungen in Gruppen zu bündeln. In der Gruppenbezeichnung wurde die entdeckte XSS gefunden. Ihr Charakter bestand darin, dass der Vektor nicht sofort ausgelöst wurde, nicht beim Anzeigen der Regelübersicht, sondern beim Löschen der Gruppe:
Das heißt, das Szenario war folgendes: Der Angreifer erstellt eine Firewallregel mit "Belastung" im Namen, der Administrator bemerkt dies nach einiger Zeit und initiiert den Löschprozess. Und genau hier führt der schädliche JS aus.
Um XSS in hochgeladenen SVG-Bildern zu verhindern (wenn auf sie nicht verzichtet werden kann), empfahl das Digital Security-Team den Entwicklern von MCS:
- Die von den Nutzern hochgeladenen Dateien auf einer separaten Domäne zu hosten, 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.
- Im HTTP-Antwortheader den Header „Content-disposition: attachment“ zu senden. Dann werden die Dateien vom Browser heruntergeladen und nicht ausgeführt.
Darüber hinaus stehen den Entwicklern jetzt viele Möglichkeiten zur Verfügung, um das Risiko der XSS-Ausbeutung zu mindern:
- mit dem Flag „HTTP Only“ können Sitzungscookies für bösartigen JavaScript unzugänglich gemacht werden;
- erleichtert die Ausbeutung von XSS erheblich für den Angreifer;
- moderne Template-Engines wie Angular oder React reinigen automatisch die Benutzerdaten, bevor sie im Browser des Nutzers ausgegeben werden.
Schwachstellen der Zwei-Faktor-Authentifizierung
Um die Sicherheit von Konten zu erhöhen, wird den Nutzern immer empfohlen, 2FA (Zwei-Faktor-Authentifizierung) zu aktivieren. Tatsächlich ist dies ein effektiver Weg, um zu verhindern, dass ein Angreifer Zugriff auf den Dienst erhält, wenn die Benutzeranmeldeinformationen kompromittiert wurden.
Aber gibt es immer eine Garantie für die Sicherheit des Kontos durch die Verwendung des zweiten Authentifizierungsfaktors? In der Implementierung von 2FA gibt es solche Sicherheitsprobleme:
- Brute-Force-Angriffe auf den OTP-Code (einmalige Codes). Trotz der Einfachheit der Ausnutzung sind solche Fehler, wie das Fehlen eines Schutzes gegen Brute-Force-Angriffe auf OTP, auch bei großen Unternehmen zu finden: , .
- Ein schwaches Generierungsalgorithmus, zum Beispiel die Möglichkeit, den nächsten Code vorherzusagen.
- Logische Fehler, zum Beispiel die Möglichkeit, OTP eines anderen auf sein eigenes Telefon anzufordern, wie es bei Shopify der Fall ist.
Im Fall von MCS wird 2FA basierend auf Google Authenticator und . Das Protokoll hat sich bereits bewährt, aber die Implementierung der Codeüberprüfung auf der Anwendungsseite sollte überprüft werden.
In MCS wird 2FA an mehreren Stellen verwendet:
- Bei der Benutzeranmeldung gibt es einen Schutz gegen Brute-Force-Angriffe: Der Benutzer hat nur wenige Versuche zur Eingabe des Einmalpassworts, danach wird die Eingabe für einige Zeit blockiert. Dies sperrt die Möglichkeit, OTP durch Ausprobieren zu erraten.
- Bei der Erstellung von Offline-Backup-Codes zur Durchführung von 2FA sowie deren Deaktivierung wurde kein Schutz gegen Brute-Force-Angriffe implementiert, was es ermöglichte, Backup-Codes neu zu generieren oder 2FA vollständig zu deaktivieren, wenn man das Passwort für das Konto und eine aktive Sitzung hatte.
Da die Backup-Codes im selben Wertebereich wie die vom Programm generierten OTPs lagen, waren die Chancen, den Code in kurzer Zeit zu erraten, viel höher.
Der Prozess des Erratens von OTP zur Deaktivierung von 2FA mit dem Tool „Burp: Intruder“
Ergebnis
Insgesamt erwies sich MCS als sicheres Produkt. Während des Audits gelang es dem Penetrationstest-Team nicht, auf die Kunden-VMs und deren Daten zuzugreifen, 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. Es ist unmöglich, ein Produkt vollständig ohne Schwachstellen zu entwickeln. Man kann jedoch Schwachstellen rechtzeitig identifizieren und die Wahrscheinlichkeit ihres Wiederauftretens minimieren.
Derzeit sind alle erwähnten Schwachstellen in MCS bereits behoben. Um die Anzahl neuer Schwachstellen zu minimieren und ihre Existenzdauer zu verkürzen, führt das Plattform-Team Folgendes fort:
- regelmäßige Audits durch externe Unternehmen durchzuführen;
- teilzuhaben und zu wachsen;
- sich um Sicherheit zu kümmern. 🙂
Quelle: habr.com
