AI Hacking - Wie Hacker künstliche Intelligenz bei Cyberangriffen einsetzen

Jetzt lesen
Wir verwenden künstliche Intelligenz für Website-Übersetzungen, und obwohl wir uns um Genauigkeit bemühen, kann es sein, dass sie nicht immer 100%ig präzise sind. Wir danken Ihnen für Ihr Verständnis.

Sicherheitsanalyse von Rack Ruby Framework: CVE-2025-25184, CVE-2025-27111, und CVE-2025-27610

von OPSWAT
Jetzt teilen

Durch eine umfassende Sicherheitsanalyse, die vom Red Team der OPSWAT durchgeführt wurde, identifizierten die Sicherheitsforscher Thai Do und Minh Pham mehrere Schwachstellen, die das Rack Ruby-Framework betreffen, insbesondere CVE-2025-25184, CVE-2025-27111 und CVE-2025-27610.  

Dieser Artikel bietet einen detaillierten Überblick über diese Schwachstellen, wobei der Schwerpunkt auf CVE-2025-27610 liegt. Er untersucht die Ursachen, bewertet die potenziellen Auswirkungen und skizziert wirksame Abhilfestrategien zur Sicherung von Anwendungen, die auf dem Rack-Framework basieren. 

Übersicht über das Rack

Rack ist eine modulare Schnittstelle, die Webserver mit Ruby-basierten Webanwendungen verbindet. Sie standardisiert die Interaktion zwischen diesen Komponenten, indem sie HTTP-Anfragen und -Antworten in einem einzigen Methodenaufruf zusammenfasst, was den Entwicklungsprozess vereinfacht und die Kompatibilität zwischen verschiedenen Frameworks und Servern fördert.  

Rack wird von vielen Ruby-Web-Frameworks und -Bibliotheken verwendet, z. B. Ruby on Rails und Sinatra. Es ist als Ruby Gem verfügbar. Die weite Verbreitung von Rack mit mehr als einer Milliarde Downloads weltweit unterstreicht seine integrale Rolle innerhalb des Ruby-Entwicklungsökosystems. Middleware-Komponenten wie Rack::Static und Rack::Sendfile verbessern die Effizienz durch die Bereitstellung statischer Inhalte und die Optimierung der Dateiübertragung. Aufgrund dieser umfassenden Integration haben Schwachstellen, die in Rack entdeckt werden, erhebliche Auswirkungen auf die Sicherheit und können zahlreiche Anwendungen und Systeme weltweit beeinträchtigen. 

Entdeckung von Sicherheitsschwachstellen in Rack

Bei einer kürzlich durchgeführten Sicherheitsuntersuchung des Rack-Middleware-Frameworks haben die OPSWAT Thai Do und Minh Pham mehrere Schwachstellen identifiziert, die ein erhebliches Sicherheitsrisiko für Ruby-basierte Webanwendungen darstellen:

  • CVE-2025-25184: Thai Do entdeckte eine Schwachstelle ermöglicht es Angreifern, Log-Injection über CRLF (Carriage Return Line Feed)-Zeichen, möglicherweise manipulieren Log-Einträge durchzuführen. 
  • CVE-2025-27111: Minh Pham entdeckte eine Sicherheitslücke, die es Angreifern ermöglicht, Log-Inhalte durch bösartige Header-Werte zu injizieren und zu manipulieren. 
  • CVE-2025-27610: Minh Pham hat außerdem eine Path Traversal-Schwachstelle identifiziert, die es Angreifern ermöglichen könnte, unbefugten Zugriff auf Dateien zu erlangen, die sich außerhalb des angegebenen statischen Dateiverzeichnisses befinden, was eine erhebliche Sicherheitsbedrohung darstellt.

Unter diesen Schwachstellen ist CVE-2025-27610 besonders schwerwiegend, da sie es nicht authentifizierten Angreifern ermöglichen könnte, vertrauliche Informationen abzurufen, einschließlich Konfigurationsdateien, Anmeldeinformationen und vertrauliche Daten, was zu Datenschutzverletzungen führen könnte. Diese Schwachstelle wurde mit einem CVSS-Score von 7,5 bewertet und damit als hochgradiges Risiko eingestuft.

Diagramm, das den Prozess der Entdeckung von Schwachstellen im Rack-Ruby-Framework zeigt

Rack::Static und lokale Dateieinschlussschwachstelle

Verstehen von Rack::Static 

Rack::Static ist eine unverzichtbare Middleware in Rack-Anwendungen, die in erster Linie dazu dient, statische Dateien wie JavaScript, CSS und Bilder effizient bereitzustellen. Durch den Einsatz von Rack::Static können Entwickler die Bereitstellung statischer Inhalte nahtlos in Ruby-Anwendungen integrieren, ohne sich auf eine zusätzliche Webserver-Konfiguration verlassen zu müssen.  

Bei der Konfiguration von Rack::Static sind zwei Optionen besonders wichtig: :urls und :root. Das richtige Verständnis und die Verwendung dieser Optionen vereinfachen und rationalisieren den Prozess der Bereitstellung statischer Dateien erheblich. 

1. Die Option :urls

Die Option :urls gibt an, welche URL-Pfade die Rack-Anwendung als statische Assets behandeln soll. Sie wird als Array von Strings bereitgestellt, die jeweils ein Pfadpräfix darstellen, das die Behandlung statischer Dateien auslöst. 

Zum Beispiel: 

Code-Screenshot zur Veranschaulichung der Konfiguration der Option Rack::Static :urls in einer Ruby-Anwendung

In dieser Konfiguration werden Anfragen an /images, /css oder /js abgefangen und von Rack::Static verarbeitet. Jede Datei, die diesen Pfaden entspricht, wird direkt aus dem Dateisystem bereitgestellt. 

2. Die Option :root

Die Option :root definiert das Basisverzeichnis, aus dem die statischen Dateien bereitgestellt werden. Dieses Verzeichnis ist relativ zum aktuellen Arbeitsverzeichnis Ihrer Rack-Anwendung. 

Siehe das vorherige Beispiel:

Code-Screenshot zeigt die Einrichtung der Option Rack::Static :root für die Bereitstellung statischer Dateien

Wenn eine Anfrage an /assets/logo.png gestellt wird, versucht Rack::Static, die Datei unter public/assets/logo.png bereitzustellen. 

Praktisches Beispiel

Die effektive Implementierung von Rack::Static durch die Optionen :urls und :root bietet eine organisierte und performante Methode zur Bereitstellung statischer Inhalte in Ruby-Webanwendungen: 

Code-Screenshot, der ein praktisches Beispiel für die Rack::Static-Konfiguration für statische Inhalte zeigt

In diesem Szenario werden die Anfragen an /assets/* und /favicon.ico automatisch von Rack::Static bearbeitet. Alle entsprechenden Dateien sollten im Verzeichnis public/assets bzw. public/favicon.ico vorhanden sein. 

CVE-2025-27610 Technische Einzelheiten

Während einer umfassenden Sicherheitsanalyse von Rack::Static entdeckte Minh Pham eine bedeutende Schwachstelle im Zusammenhang mit der unsachgemäßen Handhabung der Option :root. Insbesondere wenn der :root-Parameter nicht explizit definiert ist, setzt Rack diesen Wert standardmäßig auf das aktuelle Arbeitsverzeichnis, indem es ihm den Wert von Dir.pwd zuweist und es damit implizit als Web-Root-Verzeichnis für die Rack-Anwendung festlegt. 

Bezeichnenderweise verkettet Rack::Static eingehende URL-Pfade direkt mit dem angegebenen :root-Verzeichnis ohne ausreichende Validierung oder Bereinigung. Wenn die Option :root entweder undefiniert oder im Verhältnis zur Option :urls falsch konfiguriert ist, könnte ein nicht authentifizierter Angreifer diese Schwachstelle durch Path-Traversal-Techniken ausnutzen, um auf sensible Dateien außerhalb des vorgesehenen Webverzeichnisses zuzugreifen. 

Der folgende Abschnitt enthält eine detaillierte Analyse des Anforderungsbearbeitungsprozesses von Rack::Static und zeigt deutlich, wie diese Schwachstelle ausgenutzt werden kann.

Path Traversal und lokale Dateieinschluss-Schwachstelle in Rack::Static

Um ein tieferes Verständnis dafür zu gewinnen, wie die Middleware Rack::Static Anfragen verarbeitet, führte Minh Pham eine gründliche Analyse des Quellcodes von Rack durch. Während der Initialisierung der Klasse Rack::Static stellte er fest, dass Rack::Static standardmäßig Dateien aus dem aktuellen Arbeitsverzeichnis (Dir.pwd) bereitstellt, wenn die Option :root nicht explizit definiert ist. Folglich führt das Weglassen dieser Option dazu, dass die Middleware implizit das Verzeichnis verwendet, in dem die Anwendung ausgeführt wird.

Screenshot des Codes zeigt die Initialisierung von Rack::Static und die Zuweisung des Standardverzeichnisses :root
Code-Screenshot zur Veranschaulichung der Rack::Static-Aufrufmethode für HTTP-Anfragen

Nach der Initialisierung wurde festgestellt, dass die Aufrufmethode aufgerufen wird, wenn Rack::Static eine eingehende HTTP-Anfrage erhält.

Bildschirmfoto des Codes, das zeigt, wie Rack::Static die Dateiverwaltung an Rack::Files delegiert

Anschließend delegiert Rack::Static die Dateibereitstellung an Rack::Files, das versucht, die Datei auf der Grundlage des konstruierten Dateipfads, der sich aus dem konfigurierten :Root-Verzeichnis und dem vom Benutzer angegebenen PATH_INFO ergibt, zu finden und bereitzustellen.

Screenshot des Codes, der die Erstellung von Dateipfaden in Rack::Static unter Verwendung von :root und PATH_INFO zeigt

Zunächst untersucht die Middleware durch Aufrufen der Methoden can_serve(path) und overwrite_file_path(path) die env["PATH_INFO"], um festzustellen, ob die eingehende Anfrage mit einem der konfigurierten URL-Präfixe (z. B. /static, /public) übereinstimmt. 

Code-Screenshot mit Methoden zum Überprüfen und Überschreiben von Dateipfaden in Rack::Static

Wenn die Bedingung erfüllt ist, konstruiert Rack::Static den Dateipfad, indem es das konfigurierte Stammverzeichnis (:root) mit dem vom Benutzer angegebenen PATH_INFO kombiniert. Diese Konstruktion erfolgt ohne angemessene Normalisierung oder Bereinigung des Eingabepfads. Insbesondere verbindet die Middleware das PATH_INFO aus der eingehenden Anfrage direkt mit dem Verzeichnis, das durch die Option :root angegeben wird, wodurch eine Schwachstelle aufgrund einer unzureichenden Validierung des angegebenen Pfads entsteht

Code-Screenshot zur Veranschaulichung der anfälligen Dateipfadverkettung in Rack::Static

Minh Pham entdeckte, dass aufgrund des Fehlens einer ordnungsgemäßen Bereinigung oder Validierung in diesem Arbeitsablauf, wenn der vom Benutzer bereitgestellte PATH_INFO Verzeichnis-Traversal-Sequenzen enthält und die :root-Option nicht explizit definiert ist, der konstruierte Dateipfad zu einem Ort außerhalb des beabsichtigten Stammverzeichnisses führen könnte, was möglicherweise sensible Dateien offenlegt.

CVE-2025-27610 Machbarkeitsnachweis

Um diese Schwachstelle in Rack::Static zu demonstrieren, haben wir eine Ruby-basierte Webanwendung entwickelt, die Rack Version 3.1.10 verwendet. In Szenarien, in denen die Anwendung die Option :root nicht explizit definiert, kann ein nicht authentifizierter Angreifer diese Schwachstelle ausnutzen, um auf sensible Daten wie Anmeldeinformationen, Konfigurationsdateien oder Datenbankdateien zuzugreifen, was zu einem erheblichen Datenverlust führen kann. 

Im folgenden Video werden die erheblichen Auswirkungen dieser Sicherheitslücke ausführlich dargestellt:

Milderung und Anleitung

Um die oben beschriebenen Schwachstellen zu entschärfen, stellen Sie bitte sicher, dass Ihr System auf die neueste Version von Rack aktualisiert ist.

MetaDefender Core mit SBOM-Engine kann diese Sicherheitslücke erkennen.

OPSWAT MetaDefender CoreMetaDefender Core ist mit fortschrittlichen SBOM-FunktionenSoftware Bill of Materials) ausgestattet und ermöglicht es Unternehmen, einen proaktiven Ansatz bei der Bewältigung von Sicherheitsrisiken zu verfolgen. Durch das Scannen von Softwareanwendungen und deren Abhängigkeiten identifiziert MetaDefender Core bekannte Schwachstellen, wie CVE-2025-27610, CVE-2025-27111 und CVE-2025-25184, innerhalb der aufgelisteten Komponenten. Dies ermöglicht es den Entwicklungs- und Sicherheitsteams, Prioritäten bei den Patching-Maßnahmen zu setzen und potenzielle Sicherheitsrisiken zu minimieren, bevor sie von böswilligen Akteuren ausgenutzt werden können. 

Unten sehen Sie einen Screenshot von CVE-2025-27610, CVE-2025-27111 und CVE-2025-25184, die von MetaDefender Core mit SBOM erkannt wurden:

Dashboard-Screenshot zeigt MetaDefender Core bei der Erkennung von Rack Ruby-Framework-Schwachstellen

Bleiben Sie auf dem Laufenden mit OPSWAT!

Melden Sie sich noch heute an, um die neuesten Unternehmensinformationen zu erhalten, Geschichten, Veranstaltungshinweise und mehr.