Was ist SSRF (Serverseitige Anforderungsfälschung)? Beispiele und Prävention

Jeden Tag tauchen Tausende neuer Sicherheitslücken auf, die Hackern neue Möglichkeiten eröffnen. Die Bösewichte machen keine Pausen oder Urlaube! Sie arbeiten aktiv daran, Ihre Systeme zu kompromittieren.

In der sich ständig weiterentwickelnden Bedrohungslandschaft kann nicht oft genug betont werden, wie wichtig es ist, den neuesten Sicherheitslücken immer einen Schritt voraus zu sein. Dieses Mal befassen wir uns mit der Schwachstelle der serverseitigen Anforderungsfälschung. Ohne weitere Umschweife wollen wir uns ansehen, wie SSRF funktioniert, wie Sie SSRF-Schwachstellen in Ihren Anwendungen aufdecken können und welche Schritte Sie unternehmen sollten, um sie zu verhindern.

Was ist Serverseitige Anforderungsfälschung?

Die Sicherheitslücke, die offiziell als Serverseitige Anforderungsfälschung (SSRF) bezeichnet wird, ist in den OWASP Top 10 als ein großes Sicherheitsrisiko für Anwendungen aufgeführt. Hacker verschiedenster Art nutzen die SSRF-Schwachstelle, um Serverfunktionen zu missbrauchen und beliebige ausgehende Anfragen von einem Server zu senden.

Durch die Kodierung einer URL, die Manipulation von HTTP-Headern und die Beeinflussung der URL-Pfadüberquerung können Bedrohungsakteure unbefugte Anfragen an eine bestimmte URL stellen. SSRF-Schwachstellen können zur Unterbrechung von Diensten und in einigen Fällen zur vollständigen Übernahme des Systems führen.

Arten von Serverseitige Anforderungsfälschung-Angriffen

Wenn Sie sich den Kopf zerbrechen und sich fragen, was die verschiedenen SSRF-Angriffe sind, möchten wir Ihnen helfen, die Dinge zu klären. Je nachdem, wie der Server auf die ursprüngliche Anfrage antwortet, gibt es drei Arten von SSR:

Blinde SSRF

Blind SSRF tritt auf, wenn der Host-Server keine sichtbaren Daten an Cyber-Akteure zurückgibt. Ransomware-Kriminelle zielen darauf ab, wichtige Dateien zu ändern oder zu löschen, Servereinstellungen zu modifizieren und Benutzer- oder Dateiberechtigungen anzupassen, anstatt nur bestimmte Daten vom Server zu stehlen. Es wird nichts vom Server an den Betrüger gesendet, was es zu einer anspruchsvollen Aufgabe macht, diese Angriffe zu erkennen, bevor der Schaden angerichtet ist.

Im Allgemeinen sind blinde SSRF-Angriffe am schwersten auszunutzen, können aber zu einer Dienstverweigerung (DoS) und einer vollständigen Remotecodeausführung auf dem Server oder anderen Backend-Komponenten führen.

Halbblinde SSRF

In diesem Szenario gibt die halbblinde Instanz nur einen Teil der Daten über eine resultierende Anfrage zurück. Infolgedessen erhält der Angreifer Zugang zu bestimmten geheimen Daten, aber nicht zum gesamten Datensatz. Dies könnte Informationen wie Fehlermeldungen oder Antwortzeiten umfassen. Halbblinde SSRF reicht oft aus, um die Schwachstelle zu validieren, aber es werden keine sensiblen Daten preisgegeben.

Nicht-blinde SSRF

Nicht-blinde SSRF-Angriffe sind in der Regel am schädlichsten, da Daten von einer beliebigen URL abgerufen und an böswillige Entitäten zurückgegeben werden können, die die Anfrage gestellt haben. Nach einem erfolgreichen SSRF-Angriff erhalten die böswilligen Akteure Zugang zu eingeschränkten Netzwerkressourcen, die sie für weitere Angriffe nutzen können.

Wie können Bedrohungsakteure SSRF ausnutzen?

SSRF-Schwachstellen können in verschiedenen Softwaretypen, Programmiersprachen und Plattformen auftreten, solange die Software in einer vernetzten Umgebung arbeitet. Einfach ausgedrückt: Wenn Angreifer das serverseitige Anforderungsziel kontrollieren können, öffnet dies die Tür für eine Fülle von Sicherheitslücken, die es ihnen möglicherweise ermöglichen:

  • Umgehen der IP-Whitelist
  • Einschleusen bösartiger HTTP-Anfragen in das Zielsystem
  • Umgehung von Firewall-Kontrollen
  • Ausführen von Remote Code Execution (RCE)
  • Ausweichen auf andere Unternehmensnetzwerke, um andere Schwachstellen auszunutzen
  • Entführung und Umleitung legitimer HTTP-Anfragen an einen vom Angreifer kontrollierten Server
  • Scannen von Netzwerken, die mit dem verwundbaren Server verbunden sind, intern oder extern
  • Auslesen von Konfigurationsdateien oder sensiblen Daten vom Webserver
  • Initiierung eines DDoS-Angriffs (Distributed Denial of Service) durch Senden von Anfragen an externe Ressourcen
  • Zugriff auf Statusseiten und Interaktion mit APIs als Webserver
  • Abrufen sensibler Informationen, wie Kennwörter oder API-Schlüssel
  • Missbrauch des Vertrauens zwischen dem anfälligen Server und anderen Systemen

SSRF-Angriffe sind besonders tückisch, weil sie oft mit anderen Schwachstellen gekoppelt sind. Diese Kombination ermöglicht es Angreifern, auf dem Server Fuß zu fassen, der als Grundlage für weitere Angriffe dient.

Häufig besteht das Hauptziel eines SSRF-Angriffs darin, eine Reihe von Dokumenten oder eine Datenbank mit Unternehmensdaten zu stehlen. Dies kann zum Verlust des Kundenvertrauens, zu Umsatzeinbußen, rechtlichen Verpflichtungen und finanziellen Strafen führen.

Wie erkennt man SSRF?

Was genau können wir tun, um diese Schwachstelle aufzudecken? Im Zusammenhang mit SSRF sollten die folgenden Schritte unternommen werden, um solche Schwachstellen zu entdecken:

  • Identifizieren Sie potenzielle Eingaben für die Erstellung von URLs oder die Initiierung von Anfragen an externe Server, wie GET- oder POST-Parameter und Header.
  • Testen Sie jede Eingabe, indem Sie eine Reihe von verschiedenen URLs oder IP-Adressen als Eingaben ausprobieren. Dies sollte auch interne Ressourcen, localhost und andere spezielle Werte umfassen.
  • Untersuchen Sie, wie die Anwendung auf die verschiedenen Eingaben reagiert, und suchen Sie insbesondere nach Anzeichen für SSRF-Schwachstellen. Prüfen Sie auf Anzeichen wie die Möglichkeit, auf interne Ressourcen zuzugreifen oder Daten zu extrahieren.
  • Protokollieren Sie alle entdeckten Schwachstellen, wobei Sie die Eingabe, die die Schwachstelle verursacht hat, die Art der Schwachstelle und ihre potenziellen Auswirkungen genau angeben.

Beispiele aus der Praxis

Nachdem wir nun die Grundlagen von SSRFs kennen, wollen wir einige Vorfälle solcher Angriffe untersuchen, die im wirklichen Leben stattgefunden haben.

Kapital Eins

Ein gutes Beispiel für einen SSRF-Angriff war, als Capital One gehackt wurde und die Daten von etwa 106 Millionen Menschen in den Vereinigten Staaten und Kanada ins Internet gelangten. Wie kam es zu dem Einbruch?

Aufgrund einer Fehlkonfiguration der Web Application Firewall gelang es dem Hacker, eine Antwort mit Anmeldeinformationen zu erhalten. Dadurch konnte der Hacker eine Verbindung zu dem Server herstellen, auf dem Capital One seine Daten speicherte, und auf Kundendaten zugreifen.

Microsoft Exchange

Kürzlich wurde entdeckt, dass die Hafnium-Bedrohungsgruppe die E-Mail-Software von Microsoft Exchange Server infiziert hat. Die Sicherheitslücke in Microsoft Exchange aus dem Jahr 2021 betraf vier Schwachstellen, aber insbesondere die SSRF-Schwachstelle ermöglichte es böswilligen Entitäten, sich als Exchange-Server zu authentifizieren und Remote-Code über PowerShell auszuführen. Dies ist ein weiteres Beispiel dafür, wie eine kompromittierte vertrauenswürdige Quelle die Angriffe eskalieren lassen kann.

Die von China aus operierende Gruppe hatte es auf E-Mail-Systeme abgesehen, die von 30 000 US-amerikanischen Anwaltskanzleien, Hochschuleinrichtungen, Forschern für Infektionskrankheiten, politischen Denkfabriken, Verteidigungsunternehmen und Nichtregierungsorganisationen genutzt werden.

Dienste von Microsoft Azure

Am 17. Januar 2023 wurden Sicherheitslücken entdeckt, die die Dienste von Microsoft Azure für SSRF-Angriffe anfällig machen. Zwei Schwachstellen erforderten keine Authentifizierung, so dass Bedrohungsakteure sie ohne ein Azure-Konto ausnutzen konnten. Nach der Identifizierung der Schwachstellen in Azure API Management, Azure Functions, Azure Machine Learning und Azure Digital Twins hat Microsoft die Probleme umgehend angegangen und behoben.

Glücklicherweise wurde in diesem Fall eine zusätzliche Eingabevalidierung für die anfälligen URLs rechtzeitig implementiert, und die Schwachstellen verursachten keine Schäden an Azure-Diensten oder der Infrastruktur. Dennoch hat das Unternehmen das Risiko von Server-seitigen Request Forgery-Angriffen erkannt.

SSRF Prävention und Schadensbegrenzung

Ohne die richtigen vorbeugenden Prozesse ist die Sicherheit Ihrer Anwendungen ein großes Fragezeichen. Wie bei den meisten Schwachstellen ist Vorbeugung der beste Ansatz, um SSRF-Schwachstellen zu beseitigen.

  • Führen Sie eine Eingabevalidierung durch. Vertrauen Sie den Eingaben nicht blind – überprüfen Sie immer ihre Authentizität.
  • Führen Sie eine Whitelist der Domänennamen oder IP-Adressen, auf die Ihre Anwendung zugreifen muss. Minimieren Sie die Angriffsfläche. In internen Netzwerken bedeutet dies in der Regel, dass ein Server Anfragen, die URLs aus einer vorgegebenen Liste enthalten, durchlassen und alle anderen Anfragen zurückweisen sollte.
  • Verwenden Sie URL-Kodierung. Die ordnungsgemäße Kodierung und Dekodierung von Benutzereingaben ist ein zusätzlicher Abwehrmechanismus, der das Risiko verringert, dass bösartige URLs vom Server verarbeitet werden.
  • Führen Sie Penetrationstests durch, die ein menschliches Element zur Ausnutzung von Schwachstellen beinhalten. Sie können auch Sicherheitstest-Tools verwenden, um Simulationstests durchzuführen.
  • Deaktivieren Sie ungenutzte URL-Schemata. Mit diesem Ansatz lassen Sie nur die URL-Schemata zu, die von Ihrer Anwendung für Anfragen verwendet werden, und schränken im Gegenzug die Möglichkeiten des Angreifers ein, Anfragen mit potenziell gefährlichen Schemata wie file://, phar://, gopher://, data:// oder dict:// zu stellen.
  • Durchsetzung des Prinzips der geringsten Privilegien, wobei das System nur autorisierten Benutzern Zugriff gewährt.
  • Trennen Sie das Netz ab. Indem Sie interne Netzwerke von externen Netzwerken abtrennen, verringern Sie die Angriffsfläche und erschweren Hackern den Zugriff auf interne Systeme.
  • Als bewährte Sicherheitspraxis sollten Sie Fehlkonfigurationen abschwächen.
  • Informieren Sie Ihre Mitarbeiter über die mit SSRF verbundenen Risiken und über Möglichkeiten, diese zu beseitigen.
  • Dokumentieren Sie die von Ihnen entdeckten SSRF-Schwachstellen und lernen Sie daraus, um die Testverfahren zu verbessern und zukünftige Vorfälle zu verhindern.
  • Regelmäßige Software-Updates bieten eine zusätzliche Präventionsmaßnahme.

Vorbeugen ist in der Tat klüger, als darauf zu warten, dass die Angreifer zuerst zuschlagen.

Wie kann QAwerk helfen?

Penetrationstests sind ein wichtiger Schritt im Lebenszyklus des Schwachstellenmanagements, um die Sicherheit Ihrer Systeme zu erhöhen. Mit Hilfe der Penetrationstester von QAwerk können Sie hochentwickelte Bedrohungen einfach und schnell abwehren.

Wir sind dafür da, Ihre Netzwerke, Server und Anwendungen zu durchsuchen, um Schwachstellen zu finden, zu analysieren und zu melden. Unsere erfahrenen Tester führen Black-, Gray- und White-Box-Pen-Tests durch, um Sicherheitslücken aufzudecken. Dank unseres umfassenden Fachwissens können wir selbst die schwer fassbaren Schwachstellen identifizieren.

Einpacken

SSRF-Schwachstellen können unerwartet auftreten und die Sicherheit Ihres Unternehmens gefährden. Um dies zu verhindern, sollten regelmäßig Penetrationstests durchgeführt werden. Dadurch wird es für Bedrohungsakteure, die versuchen, in Ihre Systeme einzudringen, schwieriger.

Penetrationstests sind ein proaktiver Prozess, der nicht vernachlässigt werden sollte. Behalten Sie das im Hinterkopf und bleiben Sie sicher mit QAwerk!