Wie kann ein einfaches -Tag ein hohes Risiko für ein Unternehmen darstellen?

Sicherheit mit realen Beispielen ist immer interessant.

Heute sprechen wir über den SSRF-Angriff, bei dem Sie den Server zwingen können, über das img-Tag beliebige Anforderungen an das Internet zu stellen.



Daher war ich kürzlich an Penetrationstests für zwei Projekte gleichzeitig beteiligt. Bei zwei von ihnen wurde diese Sicherheitsanfälligkeit aufgedeckt. Screenshots werden direkt aus den Berichten entnommen, daher werden alle unnötigen Informationen verschmiert.

Angriffsbeschreibung

Angriffsname: Der Server stellt während der Erstellung eines PDF-Dokuments beliebige Anforderungen an das Internet.

Beschreibung: PDF wird auf der Serverseite aus einer vollständig gerenderten HTML-Seite mit allen externen Ressourcen generiert. Die Dokumente enthielten vom Benutzer eingegebene Daten. Ohne ordnungsgemäße Filterung können Sie Ihre externen Ressourcen beim Server-Rendering ersetzen. In diesem Fall sei es die Datei it-band.by/10gb.blob (angeblich 10 GB groß).

Schlimmstes Szenario:

1. Ddos greifen von innen an, wenn das System 100 Gigabyte Daten zum Rendern herunterladen muss, um mehrere PDF-Dokumente gleichzeitig zu rendern. Dies führt zu einem Mangel an Netzwerk- oder Speicherressourcen, was wiederum zu einem Systemausfall führen kann.
2. Ein böswilliger Benutzer kann den Server als Plattform verwenden, um andere Ressourcen anzugreifen.
3. Ein böswilliger Benutzer erhält die externen IP-Adressen interner Server für direkte Angriffe unter Umgehung von Webanwendungsfirewalls (WAF) und Balancern.

Risikobewertung (Wahrscheinlichkeit * Auswirkung): Mittel (5) * Hoch (7) = Hoch (35) (in beiden Systemen wurde das Risiko als hoch eingestuft, wenn auch mit unterschiedlichen Verhältnissen)

Was ist interessant:

1. Ein System verwendete wkhtmltopdf, um html2pdf zu rendern, das zweite führte Firefox aus, lud die Seite dort und machte einen Screenshot. In jedem Fall rendern beide Systeme sofort beide Seiten, führen dort den gesamten Code aus und erstellen erst dann PDF daraus.
2. Der XSS-Serverschutz wurde auf beiden Systemen installiert, aber anstatt das Escape der Eingabedaten zu verwenden, verwendeten beide Systeme die HTML-Bereinigung, mit der alle Iframes, Skripte, CSS, Formulare usw. gelöscht wurden. Die HTML-Reinigung in beiden Systemen wird jedoch als img src="https://it-band.by/10Gb.blob?t=12345.1"/ sicherer HTML-Code betrachtet.

Gehen Sie nun die Schritte und Screenshots durch

1) Erstellen Sie eine solche Datei lokal, um sie später ganz oder teilweise auszufüllen.



2) Am Anfang müssen Sie anfällige Benutzerfelder finden.

System 1. Es konnte kein einziges img-Tag eingefügt werden





System 2. Ich habe es geschafft, ungefähr 20 Tags sofort einzufügen



3) Als nächstes generieren wir das PDF-Dokument.

System 1. Generiertes PDF



System 2. Generiertes PDF



4) Und jetzt klettern wir auf unseren Server, um zu sehen, ob es Anfragen für unsere große 10Gb.blob-Datei gab.

System 1. Wir erhalten die Server-IP-Adresse und -Software, mit deren Hilfe das PDF-Dokument erstellt wurde. Nmap zeigte anhand der gefundenen IP-Adresse einen weiteren offenen Port an, den noch niemand zuvor gesehen hatte.



System 2. Es ist ersichtlich, dass der Server versucht hat, 20 Dateien mit 10 Gigabyte herunterzuladen. Wir erhalten auch die Adresse eines der Server und die verwendete Version von Firefox.



Das Ergebnis. In beiden Systemen wurden bereits Fehler behoben. Im ersten System erfolgt das Escaping anstelle der HTML-Bereinigung sowohl während der Verarbeitung von Benutzerdaten als auch während der Erstellung eines PDF-Dokuments. Im zweiten System werden alle absoluten Verknüpfungen zu externen Ressourcen während der Benutzerdatenverarbeitung unterbrochen.

Aktualisiert.

Während ich zur Veröffentlichung des Artikels kam, wurden Fälle von 2 weiteren Systemen hinzugefügt.

Ein anderes System (nennen wir System 3) hat die Prüfung für diese Art von Sicherheitsanfälligkeit nicht an zwei Stellen gleichzeitig bestanden: über HTML Injection und CSS Injection.

System 3. HTML-Injektion mit 20-maligem Herunterladen eines Live-Bildes 13 MB (insgesamt 260 MB)



System 3. CSS-Injektion



System 3. Was sehen wir auf dem angreifenden Server beim Rendern einer PDF (alle 20 Downloads eines 13-MB-Bildes sind erfolgreich)?



Was war die Ausgabe für System 3:

1) Erhalten Sie die Adressen der Server, die rendern, und was sie zum Rendern verwenden. In diesem Fall HeadlessChrome.

2) Die Erstellung eines PDF-Dokuments dauerte ca. 5 Minuten, dann fiel das Chrom einfach ab. Stellen Sie sich vor, wenn Sie 10.000 solcher Anforderungen ausführen, reagieren die Generierungsserver für eine Weile im Prinzip nicht mehr auf Anforderungen anderer Benutzer.

System 4. Der SSRF-Angriff wurde hier nicht über das img-Tag ausgeführt, sondern über XSS, als meine Lieblingsnutzlast während des Renderns auf dem Server ausgeführt wurde und der Server beim Generieren des PDF-Dokuments beliebigen Javascript-Code startete. Im Vergleich zu früheren Fällen ist es möglich, komplexere Angriffe auf andere Systeme auszuführen.



System 4. Gerendertes PDF mit beliebigem JS-Code, der auf der Serverseite ausgeführt wird



Voraussetzung 1. Systeme erfordern die Entwicklung nicht nur der Regeln der eingehenden, sondern auch der ausgehenden Firewall oder die Entwicklung einer Infrastruktur mit separaten Netzwerksegmenten oder Servern, auf die im Allgemeinen kein Zugriff nach außen besteht.

Prämisse 2. Wenn Sie selbst die kleinste Sicherheitsanfälligkeit finden, müssen Sie immer nach den Worst-Case-Szenarien für deren Verwendung und Auswirkungen auf das Unternehmen suchen. Unternehmen können nur mit Risiken arbeiten, die technische Seite ist für sie leider von geringem Interesse.

Die oben genannten Informationen werden nur zu Bildungs- und Bildungszwecken bereitgestellt. Eine Vorgehensweise für ihre Systeme ist nicht erforderlich.

Denis Koloshko, CISSP, Penetrationstester