Webanwendungen, die das Hochladen von Dateien erleichtern, sind für zahlreiche Unternehmen unverzichtbar geworden. Sie dienen als Portale für Kunden, Partner und Mitarbeiter, um verschiedene Arten von Dokumenten und Dateien auszutauschen. So könnte eine Personalabteilung ihren Nutzern ermöglichen, Lebensläufe hochzuladen, oder ein Unternehmen könnte seinen Partnern den Austausch von Dateien über eine spezielle Webplattform erleichtern.
Trotz verbesserter Sicherheitsmaßnahmen und strengerer Validierungsverfahren nutzen Angreifer weiterhin Schwachstellen mit ausgeklügelten Methoden aus. Auch scheinbar harmlose Dateien wie Bilder können manipuliert werden, um die Sicherheit eines Webservers zu gefährden.
Polyglotte Dateien sind Dateien, die als mehrere Typen gleichzeitig gültig sein können, was es Angreifern ermöglicht, Dateityp-basierte Sicherheitsmaßnahmen zu umgehen. Beispiele hierfür sind GIFAR, das sowohl als GIF- als auch als RAR-Datei funktioniert, JavaScript/JPEG-Polyglots, die sowohl als JavaScript als auch als JPEG interpretiert werden, und Phar-JPEG-Dateien, die sowohl als Phar-Archiv als auch als JPEG-Bild erkannt werden. Diese polyglotten Dateien können mit trügerischen oder leeren Dateierweiterungen unentdeckt bleiben, die Systemen vorgaukeln, es handele sich um einen harmlosen Dateityp (wie ein Bild oder eine PDF-Datei), während sie unentdeckten bösartigen Code enthalten.
Validierung des Dateiuploads
Das Zulassen von Dateiuploads durch Benutzer ohne ordnungsgemäße oder umfassende Validierung stellt eine erhebliche Bedrohung für Webanwendungen dar. Wenn ein Angreifer erfolgreich eine bösartige Datei hochlädt, z. B. eine Web-Shell, kann er möglicherweise die Kontrolle über den Server erlangen und sowohl das System als auch sensible Daten gefährden. Um diese Risiken zu mindern, wurden Best Practices entwickelt, die Entwicklern bei der Anwendung wirksamer Validierungsmaßnahmen helfen sollen. Diese Praktiken tragen dazu bei, die sichere Verarbeitung von Dateiuploads zu gewährleisten und so das Risiko eines Missbrauchs zu minimieren.
Zu den wichtigsten Bereichen für die Sicherung von Datei-Uploads gehören:
- Validierung von Erweiterungen: Implementieren Sie eine Block- oder Zulassungsliste für Dateierweiterungen, um sicherzustellen, dass nur zulässige Dateitypen akzeptiert werden.
- Bereinigung von Dateinamen: Generieren Sie beim Hochladen zufällige Zeichenfolgen für Dateinamen.
- Überprüfung des Inhaltstyps: Überprüfen Sie den MIME-Typ der hochgeladenen Datei, um sicherzustellen, dass sie dem erwarteten Format entspricht.
- Validierung des Bild-Headers: Bei Bild-Uploads können Funktionen wie getimagesize() in PHP verwendet werden, um die Gültigkeit der Datei durch Überprüfung des Headers zu bestätigen.
Umgehung des Datei-Upload-Filters
Trotz der Implementierung dieser Schutzmaßnahmen entwickeln Angreifer ihre Methoden zur Umgehung der Validierungsmechanismen ständig weiter. Techniken wie die Injektion von Null-Zeichen, doppelte Erweiterungen und leere Erweiterungen können die Validierung von Erweiterungen unterlaufen: Eine Datei kann mit einem Namen wie "file.php.jpg", "file.php%00.jpg", "file.PhP" oder "file.php/" erscheinen, um die Erkennung zu umgehen. Die Validierung des MIME-Typs kann umgangen werden, indem die anfänglichen magischen Bytes der Datei geändert werden, z. B. in GIF89a, den mit GIF-Dateien assoziierten Header, der dem System vorgaukelt, die Datei sei ein legitimes Format. Darüber hinaus kann eine bösartige .htaccess-Datei hochgeladen werden, um Serverkonfigurationen zu manipulieren und die Ausführung von Dateien mit nicht zugelassenen Erweiterungen zu ermöglichen.
Angriffe auf polyglotte Dateien
Trotz der Implementierung strenger Validierungsprozesse, die mehrere Sicherheitsmaßnahmen kombinieren, um die Technik zur Umgehung des Datei-Upload-Filters zu verhindern, stellen raffinierte Angriffe auf polyglotte Dateien oder polyglotte Bilder nach wie vor eine erhebliche Sicherheitsbedrohung dar. Diese Methode ermöglicht es Angreifern, Dateien - z. B. Bilder - zu erstellen, die der erwarteten Binärstruktur für Bilddateien entsprechen, aber gleichzeitig bösartigen Code ausführen können, wenn sie in einem anderen Kontext interpretiert werden. Die doppelte Natur dieser Dateien ermöglicht es ihnen, herkömmliche Validierungsmechanismen zu umgehen und Schwachstellen in bestimmten Szenarien auszunutzen.
Einfache polyglotte Datei mit ExifTool
Eine einfache Technik zur Erstellung eines polyglotten Bildes ist die Verwendung von ExifTool. Diese leistungsstarke Anwendung wurde entwickelt, um verschiedene Metadatenformate wie EXIF, XMP, JFIF und Photoshop IRB zu lesen, zu schreiben und zu ändern. Allerdings können böswillige Personen ExifTool nutzen, um schädliche Aktionen durchzuführen, einschließlich der Erstellung eines polyglotten Bildes in böswilliger Absicht. Durch die Verwendung von ExifTool zum Einbetten von bösartigem Code in die EXIF-Metadaten eines Bildes - insbesondere in Felder wie UserComment und ImageDescription - können Angreifer ein polyglottes Bild erzeugen und ihre Chancen auf eine erfolgreiche Ausnutzung erhöhen.
Im Folgenden werden die EXIF-Metadaten des Bildes dargestellt, die umfassende Informationen zu dem Bild enthalten.
Mithilfe von ExifTool kann ein Bedrohungsakteur bösartigen Code in die EXIF-Metadaten eines Bildes einbetten und so eine polyglotte Datei erstellen, die die Validierungsmechanismen umgehen kann.
Obwohl die MIME-Typ-Validierung den Upload von einfachen Web-Shell-Dateien einschränken kann, kann dieses polyglotte Image diese Einschränkungen umgehen und einem Angreifer den Upload einer polyglotten Web-Shell ermöglichen.
Der Angreifer kann anschließend die polyglotte Webshell ausnutzen, um die Kontrolle über den Webserver zu übernehmen.
Javascript/JPEG Polyglotte Datei
Eine polyglotte JavaScript/JPEG-Datei ist so aufgebaut, dass sie sowohl als JPEG-Bild als auch als JavaScript-Skript gültig ist. Um dies zu erreichen, muss ein böswilliger Akteur die interne Struktur einer JPEG-Datei genau kennen. Dieses Wissen ermöglicht die genaue Einbettung bösartiger Binärdaten in das Bild, so dass es von einer JavaScript-Engine verarbeitet werden kann, ohne seine Gültigkeit als JPEG-Bild zu beeinträchtigen.
Ein JPEG-Bild hat die folgende Struktur:
| Bytes | Name |
| 0xFF, 0xD8 | Anfang des Bildes |
| 0xFF, 0xE0, 0x00, 0x10, ... | Standard-Kopfzeile |
| 0XFF, 0XFE, ... | Bild Kommentar |
| 0xFF, 0xDB, ... | Quantisierungstabelle |
| 0xFF, 0xC0, ... | Beginn des Rahmens |
| 0xFF, 0xC4, ... | Huffman-Tabelle |
| 0xFF, 0xDA, ... | Beginn des Scans |
| 0xFF, 0xD9 | Ende des Bildes |
JPEG-Format - Quelle: https://github.com/corkami/formats/blob/master/image/JPEGRGB_dissected.png
In einer JPEG-Bildstruktur folgt auf den Header die Längeninformation. Wie im vorherigen Beispiel gezeigt, beginnt der Header mit der Sequenz 0xFF 0xE0 0x00 0x10, wobei 0x00 0x10 speziell die Länge des Segments angibt, also 16 Bytes. Die Markierung 0xFF 0xD9 kennzeichnet das Ende des Bildes.
Um eine polyglotte JavaScript/JPEG-Datei zu erstellen, müssen die Hexadezimalwerte des Bildes geändert werden, damit die JavaScript-Engine sie erkennen und verarbeiten kann.
Erstens kann in JavaScript die Folge 0xFF 0xD8 0xFF 0xE0 als Nicht-ASCII-Werte interpretiert werden, aber 0x00 0x10 ist ungültig und muss geändert werden. Der geeignete Ersatz für diese Hex-Werte ist 0x2F 0x2A, die hexadezimale Darstellung von /*, einer Syntax, die in JavaScript zum Öffnen eines Kommentars verwendet wird. Durch diese Ersetzung können die übrigen Binärdaten als Teil des Kommentars ignoriert werden.
Da jedoch 0x00 0x10 ursprünglich die Länge des JPEG-Headers darstellt, muss der JPEG-Header neu definiert werden, um seine Gültigkeit zu erhalten, wenn er in 0x2F 0x2A geändert wird, was in Dezimalzahlen 12074 entspricht. Um dies zu erreichen, müssen Null-Bytes hinzugefügt werden, und die JavaScript-Nutzlast sollte nach der 0xFF 0xFE-Markierung platziert werden, die einen Bildkommentar in der JPEG-Struktur anzeigt.
Wenn die Nutzlast beispielsweise */=alert(document.domain);/* lautet und 28 Byte lang ist, würden die erforderlichen Null-Bytes wie folgt berechnet: 12074 (neue Länge) - 16 (ursprüngliche Header-Länge) - 2 (für die 0xFF 0xFE-Markierung ) - 28 (Nutzdatenlänge) = 12.028 Null-Bytes.
Folglich würde der JavaScript-Code innerhalb des JPEG-Bildes folgendermaßen aussehen:
Schließlich muss die Sequenz 0x2A 0x2F 0x2F 0x2F (entspricht *///) kurz vor der JPEG-Endmarkierung 0xFF 0xD9 platziert werden. Dieser Schritt schließt den JavaScript-Kommentar ab und stellt sicher, dass die Nutzdaten korrekt ausgeführt werden, ohne die Struktur der JPEG-Datei zu stören.
Nach dieser Änderung kann das Bild immer noch als gültiges Bild interpretiert werden und enthält gleichzeitig ausführbaren JavaScript-Code.
Wenn eine HTML-Datei dieses Bild als JavaScript-Quellcode lädt, bleibt sie gültig und kann den eingebetteten JavaScript-Code ausführen:
Polyglotte Bilddateien stellen nicht nur für clientseitige Angriffe ein Risiko dar, sondern unter bestimmten Umständen auch für serverseitige Angriffe. Ein Beispiel hierfür ist die polyglotte Phar/JPEG-Datei, die sowohl als PHP-Archiv (Phar) als auch als JPEG-Bild interpretiert werden kann. Die Phar-Dateistruktur erlaubt die Einbettung von serialisierten Daten in Metadaten, was ein potenzielles Risiko für Deserialisierungsschwachstellen darstellt, insbesondere in bestimmten PHP-Versionen. Infolgedessen können Phar/JPEG-Polyglot-Dateien genutzt werden, um die Datei-Upload-Validierung zu umgehen und anfällige Server auszunutzen.
Das Phar-Dateiformat ist als stub/manifest/contents/signature aufgebaut und speichert in seinem Manifest die entscheidenden Informationen darüber, was im Phar-Archiv enthalten ist:
- Stub: Der Stub ist ein Teil des PHP-Codes, der ausgeführt wird, wenn auf die Datei in einem ausführbaren Kontext zugegriffen wird. Es gibt keine Einschränkungen für den Inhalt des Stubs, außer der Anforderung, dass er mit __HALT_COMPILER(); abschließt.
- Manifest: Dieser Abschnitt enthält Metadaten über das Archiv und seinen Inhalt, die auch serialisierte Phar-Metadaten im serialize()-Format enthalten können.
- Inhalt der Dateien: Die Originaldateien, die im Archiv enthalten sind.
- Unterschrift (optional): Enthält Signaturinformationen zur Integritätsprüfung.
Da der Stub keine inhaltlichen Beschränkungen über die Bestimmungen des __HALT_COMPILER() hinaus auferlegt, kann ein Bedrohungsakteur die hexadezimalen Werte eines Bildes in den Stub einschleusen. Indem er diese Werte an den Anfang der PHAR-Datei setzt, kann sie als gültiges Bild identifiziert werden. Folglich kann ein PHAR/JPEG-Polyglot leicht konstruiert werden, indem die hexadezimalen Bytes eines JPEG-Bildes an den Anfang angehängt werden, wie im folgenden Beispiel gezeigt:
Mit dieser Methode fungiert die generierte polyglotte Datei sowohl als gültiges Bild als auch als legitime PHAR-Datei und kann daher verwendet werden, um bestimmte Mechanismen zur Validierung des Dateiuploads zu umgehen.
Obwohl diese polyglotte Datei Datei-Upload-Filter umgehen kann, ist sie derzeit nicht in der Lage, den Webserver auszunutzen. Um einen Webserver mit einer PHAR-Datei oder einer PHAR-Polyglot-Datei erfolgreich auszunutzen und zu kompromittieren, müssen bösartige serialisierte Metadaten in das Manifest der Datei eingefügt werden.
Wenn auf die PHAR-Datei über den PHAR-Wrapper (phar://) in bestimmten PHP-Funktionen (PHP ≤7.x) zugegriffen wird, die mit Dateioperationen verbunden sind - wie file(), file_exists(), file_get_contents(), fopen(), rename() oder unlink() - wird die Funktion unserialize() für die serialisierten Metadaten ausgelöst. Durch die Verwendung von PHPGGC, einem weit verbreiteten Tool zur Erstellung von PHP-Gadget-Ketten, können Bedrohungsakteure die Deserialisierungsschwachstelle über eine PHAR-Polyglot-Datei ausnutzen und so den Webanwendungsserver kompromittieren.
Die Kombination von PHAR/JPEG-Polyglot-Dateien und Deserialisierungsschwachstellen ermöglicht es Angreifern, einen Webanwendungsserver zu infiltrieren, selbst wenn Datei-Upload-Filter implementiert sind. Diese Kompromittierung kann sogar während der Verarbeitung einer Bilddatei erfolgen.
Durch die Nutzung von polyglotten Dateien zur Umgehung von Datei-Upload-Filtern und das Anhängen des PHAR-Wrappers (phar://) an den Dateispeicherort können Angreifer den Webserver so manipulieren, dass er die Datei als PHAR-Archiv behandelt. Diese Manipulation kann anschließend eine Deserialisierungsschwachstelle auslösen, die zu Remotecodeausführung durch Dateibetriebsfunktionen führt.
Um die Risiken zu verdeutlichen, die mit polyglotten Dateien in Ihrer Anwendung verbunden sind, haben wir eine Umgebung simuliert, in der die Anwendung strenge Datei-Upload-Filter einsetzt, um das Hochladen von bösartigen Dateien oder Web-Shells zu verhindern. Trotz dieser Sicherheitsvorkehrungen kann ein polyglottes Bild den Validierungsprozess umgehen und in bestimmten Kontexten zu einer Remotecodeausführung führen, die letztlich den anfälligen Webanwendungsserver gefährdet.
Dieses Beispiel zeigt eine herkömmliche Webanwendung, die den Dateiaustausch zwischen Kunden, Partnern und Organisationen ermöglicht:
MetaDefender Core und MetaDefender ICAP Server schützt Ihre Webanwendungen vor diesen Bedrohungen und verbessert die Sicherheit Ihres Netzwerks und Ihrer Infrastruktur.
MetaDefender ICAP Server und MetaDefender Core schützen Ihren Webserver auf folgende Weise vor raffinierten Angriffen mit bösartigen PHAR/JPEG-Polyglot-Dateien:
Wenn eine polyglotte PHAR/JPEG-Datei in die Webanwendung hochgeladen wird, wird sie zunächst an MetaDefender Core über MetaDefender ICAP Server für einen umfassenden Bereinigungsprozess mit unserer Deep CDR ™ Technologie weitergeleitet. Im Gegensatz zu einfachen Dateityp-Prüfgeräten analysiert Deep CDR gründlich die Struktur der hochgeladenen Datei, entfernt Skripte, Makros und nicht richtlinienkonforme Inhalte und rekonstruiert die JPEG-Datei so, dass sie nur die erforderlichen Daten enthält.
Dieser Prozess entfernt schädliche PHAR-Inhalte, die nach der JPEG-Endmarkierung(0xFF 0xD9) angehängt werden, und stellt sicher, dass die bereinigte Datei ausschließlich ein JPEG ist. Dadurch ist die Webanwendung vor PHAR/JPEG-Polyglot-Angriffen geschützt. Selbst wenn ein Angreifer das Dateiverarbeitungsschema ändern kann, um einen PHAR-Wrapper einzuschleusen, kann er den Webserver nicht ausnutzen.
Unternehmen mit etablierter Netzwerksicherheitsinfrastruktur - egal ob sie WAFs (Web Application Firewalls), Proxies oder Ingress Controller einsetzen - können ihre Abwehrmechanismen jetzt durch MetaDefender ICAP Server verbessern.Diese Lösung schafft eine Schnittstelle zwischen den vorhandenen Webservern und MetaDefender Core , wobei ein transparenter Sicherheitskontrollpunkt für alle eingehenden Dateien eingerichtet wird. Jeder Inhalt, der über die Schnittstelle ICAP weitergeleitet wird, wird gescannt und verarbeitet, bevor er Ihren Webserver erreicht, um sicherzustellen, dass nur sichere und legitime Inhalte in Ihr Netzwerk gelangen und die Endbenutzer erreichen.
Dieser Ansatz bedeutet, dass Unternehmen ihre bestehenden Sicherheitsinvestitionen nutzen und gleichzeitig eine zusätzliche, leistungsstarke Schutzebene hinzufügen können. Unternehmen, die NGINX Ingress Controller verwenden, können MetaDefender ICAP Server über die Proxy-Konfiguration in ihre bestehende Infrastruktur integrieren.
OPSWATgeht über die traditionelle Erkennung von Bedrohungen hinaus. Anstatt verdächtige Dateien einfach nur zu markieren, neutralisiert MetaDefender Core aktiv potenzielle Bedrohungen und verwandelt gefährliche Dateien in sichere, nutzbare Inhalte. Wenn MetaDefender ICAP Server in Ihren Webserver integriert wird, bietet es umfassenden Schutz vor Zero-Day-Bedrohungen und polyglotten Angriffen.
Gestärkt durch ein "Vertraue keiner Datei. Vertraue keinem Gerät. ™"-Philosophie löst OPSWAT die Herausforderungen von Kunden auf der ganzen Welt mit patentierten Technologien auf jeder Ebene Ihrer Infrastruktur, die Ihre Netzwerke, Daten und Geräte schützen und bekannte und unbekannte Bedrohungen, Zero-Day-Angriffe und Malware verhindern.
