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
