Schwachstellen in Apache Camel erkennen und minimieren
Zusammenfassung
Am 9. März 2025 hat Apache Camel CVE-2025–27636offengelegt, eine Schwachstelle, die durch falsches Filtern von Anfrageheadern verursacht wird und zu Remotecodeausführung führen kann.
Diese Schwachstelle liegt in einer Bibliothek, wodurch sowohl eine direkte als auch eine indirekte Abhängigkeit entsteht und die Erkennung und Abwehr erschwert wird.
In diesem Blogbeitrag informieren die Forscher von Akamai detailliert über die Schwachstelle, Exploit-Techniken und Erkennungsstrategien.
Eine Schnellregel der Akamai Adaptive Security Engine schützt Kunden von Akamai App & API Protector automatisch.
Außerdem können Kunden mit Akamai Guardicore Segmentation eine Insight-Abfrage zur Erkennung durchführen.
- Betroffene Kunden von Akamai Hunt haben bereits eine detaillierte Zuordnung anfälliger Ressourcen erhalten.
- AKTUALISIERUNG: Am 11. März 2025 meldete die Akamai Security Intelligence Group (SIG) dem Sicherheitsteam von Apache Camel ein Umgehung. Am 12. März 2025 hat Apache eine neue CVE veröffentlicht: CVE-2025-29891.
Einführung
Am 9. März 2025 wurde eine Schwachstelle in Apache Camel, einer weit verbreiteten Java-Bibliothek, behoben. Dies geschah durch Apache selbst. Betroffen waren die Versionen 4.10.2, 4.8.5 und 3.22.4. Obwohl die Schwachstelle laut ersten Berichten schwerwiegende Auswirkungen haben könnte, hat das Entwicklerteam sie als mäßig schwerwiegend eingestuft.
Trotz dieser Bewertung wird ein schnellstmögliches Patchen dringend empfohlen, wenn die oben genannten Versionen in Ihrer Umgebung ausgeführt werden. Jedoch können Anwendungen mit den Versionen 4.10.0, 4.10.1, 4.8.0 bis 4.8.4 und 3.10.0 bis 3.22.3 weiterhin betroffen sein.
Um ausgenutzt werden zu können, muss die anfällige Anwendung bestimmte Voraussetzungen erfüllen (die wir später in diesem Beitraguntersuchen). Dennoch könnten die Auswirkungen erheblich sein. Die Schwachstelle ist leicht auszunutzen und könnte verheerende Folgen haben, einschließlich Remotecodeausführung.
Angesichts der Allgegenwärtigkeit von Camel und der Tatsache, dass Schwachstellen in Bibliotheken eingebettet sind, sollte die Schwere dieser Entdeckung nicht unterschätzt werden. Mit diesem Blogbeitrag wollen wir Unternehmen bei der Reaktion darauf unterstützen.
Wir werden die Schwachstelle untersuchen und ihre potenziellen Auswirkungen auf Anwendungen erläutern, ihre Ausnutzung analysieren, um Erkennungsmechanismen zu entwickeln, und uns mit der vielleicht schwierigsten Herausforderung befassen, die diese und andere Schwachstellen in Bibliotheken mit sich bringen: der Identifizierung anfälliger Anwendungen.
Was ist Apache Camel?
Apache Camel ist ein weit verbreitetes Open-Source-Integrations-Framework, das einen nahtlosen Datenaustausch zwischen verschiedenen Systemen, Anwendungen und Clouddiensten ermöglicht. Es vereinfacht die Nachrichtenweiterleitung, Umwandlung und Konnektivität in verschiedenen Unternehmensumgebungen. Viele Unternehmen vertrauen bei wichtigen Geschäftsabläufen, API-Integrationen und der Orchestrierung von Microservices auf Camel.
CVE-2025-27636 unter der Lupe
Apache Camel verwendet DefaultHeaderFilterStrategy.java , um zu verhindern, dass interne Header extern weitergeleitet werden. Dadurch wird vermieden, dass vertrauliche Routinginformationen über Header verbreitet werden, die von Angreifern missbraucht werden könnten. Beispiele für diese Header sind:
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
Diese Filterung findet Anwendung, wenn HTTP-basierte Komponenten Anfragen verarbeiten, wie z. B.:
- camel-http und camel-http4 (Standard-HTTP-Verarbeitung)
- camel-rest (REST-DSL-Verarbeitung)
- camel-cxf (Apache CXF-Web-Dienste)
Die Schwachstelle ist auf die falsche Filterung von Anfrageheadern durch Camel zurückzuführen. Vor der Behebung verwendete Apache Camel eine Filterregel, die zwischen Groß- und Kleinschreibung unterschied (Abbildung 1).
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
Diese Logik stimmte nur mit Headern überein, die mit Camel oder org.apache.camel begannen (genau wie abgebildet). Wenn ein Angreifer die Groß-/Kleinschreibung geändert und zum Beispiel CAmelHttpUri oder cAMELHttpResponseCodeverwendet hat, würde der Header nicht gefiltert werden.
Das bedeutet, dass ein Angreifer beliebige Header in unsere Anfragen einspeisen und sie von Camel an interne Komponenten weiterleiten lassen könnte. Wir möchten hervorheben, wie Apache in seinem Hinweis erwähnt, dass die Schwachstelle keinen Zugriff auf beliebige interne Methoden zulässt, sondern nur auf solche, die sich im selben Bean befinden, das in der Bean-URI deklariert ist. Dies ist eine der spezifischen Voraussetzungen für die Ausnutzung, d. h., dass eine Anwendung nicht automatisch anfällig ist, nur weil eine anfällige Version von Apache Camel ausgeführt wird.
Testen der Bedrohung
Um die Schwachstelle zu demonstrieren, haben wir eine gefährdete Beispielanwendung erstellt, die per Remotezugriff angegriffen werden kann. Die Anwendung hört auf HTTP-Port 80 und verwendet nach Erhalt einer Anfrage die Camel-Komponente„Exec“, um den Befehl „whoami“ auszuführen und das Ergebnis an den Client zurückzugeben.
Wenn Sie eine einfache Anfrage mit curl ausführen, wird das erwartete Ergebnis zurückgegeben: die Schwachstelle wird offengelegt (Abbildung 2).
Fig. 2: Normal application operation that returns the result of the whoami command
Wie wir im Code sehen können, ist der Befehl „whoami“ statisch definiert, sodass der Code relativ sicher erscheint. Die Probleme treten auf, wenn wir die möglichen von Exec unterstützten internen Nachrichtenheader untersuchen. Wenn wir den Header CamelExecCommandExecutable untersuchen, sehen wir, dass er die im statischen URI im Code definierte ausführbare Datei überschreibt (Abbildung 3).
Fig. 3: Apache Camel Exec component documentation
Apache Camel würde interne Header herausfiltern, die der Groß-/Kleinschreibung entsprechen, wie z. B. CamelExecCommandExecutable. CVE-2025-27636 würde jedoch eine Umgehung des Filters durch Eingabe von CAmelExecCommandExecutable (oder eines anderen Unterschieds in der Groß-/Kleinschreibung) ermöglichen und beliebige Befehle auf dem Server ausführen (Abbildung 4).
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
Auf gleiche Weise können wir auch CAmelExecCommandArgs angeben, um Parameter für den ausgeführten Befehl bereitzustellen (Abbildung 5).
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
Dies ist ein einfaches Beispiel, das zeigt, wie diese Schwachstelle ausgenutzt werden könnte. Durch die Möglichkeit, beliebige interne Header einzuspeisen, können Angreifer eine Vielzahl von Anwendungen kompromittieren, je nachdem, welche Camel-Komponenten vom Server verwendet werden.
Wie hat Apache Camel CVE-2025-27636 behoben?
Das Problem wurde durch ein Erzwingen einheitlicher Groß-/Kleinschreibung behoben. Auf diese Weise können Angreifer die Groß- und Kleinschreibung nicht manipulieren, um den Filter zu umgehen. So wurde beispielsweise CAmelHttpUri zu camelhttpuri, was nun dem Filter entspricht und daher abgefangen werden würde.
Wir stellen vor: .toLowerCase()
GitHub Commit hat die Header-Filterlogik in DefaultHeaderFilterStrategy.java aktualisiert, um toLowerCase(Locale.ENGLISH) einzuschließen und sicherzustellen, dass alle Headernamen vor der Anwendung des Filters in Kleinbuchstaben umgewandelt werden (Abbildung 6).
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
Nach der Behebung sind Sie auch vor Injektion geschützt und können für gleichbleibende Effizienz optimierte Prüfungen durchführen. Bei der ersten Prüfung werden normale „Camel“- und „camel“-Fälle schnell bearbeitet. Die .toLowerCase() -Prüfung wird nur bei Bedarf ausgeführt, um unnötige Performance-Kosten zu vermeiden.
Erkennung anfälliger Anwendungen
Es kann schwierig sein, jede anfällige Instanz von Apache Camel in einem Netzwerk zu identifizieren. Sicherheitsteams müssen eine Vielzahl von Ressourcen bewerten, da Apache Camel an zahlreichen Stellen integriert ist. Das können Anwendungen sein, in denen die Bibliotheken verwendet werden, ohne dass Sicherheitsspezialisten davon wissen.
Die Bibliothek kann als indirekte Abhängigkeit vorhanden sein. Das heißt, sie ist nicht explizit im Quellcode enthalten, sondern wird stattdessen über ein anderes Softwarepaket eingeführt. Das erhöht die Komplexität und erschwert die Erkennung und natürlich auch die Abwehr.
Apache Camel kann in Java-Anwendungen oft dadurch identifiziert werden, dass Verzeichnisse rekursiv nach JAR-Dateien durchsucht werden, die „camel“ im Namen enthalten. Sobald eine Camel-bezogene JAR-Datei gefunden wurde, kann ihre Manifestdatei untersucht werden, um die verwendete Version zu ermitteln.
Mit der extrahierten Version können Sicherheitsteams sie mit der Sicherheitsempfehlung von Apache abgleichen, um potenzielle Schwachstellen zu bewerten. Folgende Versionen sind betroffen:
- 4.10.0 – anfällig vor 4.10.2
- 4.8.0 – anfällig vor 4.8.5
- 3.10.0 – anfällig vor 3.22.4
Automatische Erkennung
Um anfällige Anwendungen leichter identifizieren zu können, haben wir PowerShell- und Bash-Skripte entwickelt, die Verzeichnisse rekursiv durchsuchen, JAR-Dateien von Apache Camel erkennen und potenziell anfällige Anwendungen ausgeben. Wir haben Optionen für Windows und Linux hinzugefügt. Betroffene Kunden von Akamai Hunt haben bereits eine detaillierte Zuordnung ihrer anfälligen Ressourcen erhalten.
Erkennung mit Akamai Guardicore Segmentation
Für Kunden von Akamai Guardicore Segmentation haben wir eine Insight- Abfrage erstellt, die anfällige Ressourcen identifizieren kann. Wenn das Abfrageergebnis für die Dateiversion „Version nicht gefunden“ lautet, kann der zurückgegebene Hash entweder in VirusTotal oder über die Manifestdatei im Java-Archiv geprüft werden, um die richtige Version zu ermitteln.
Windows
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '..\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Linux
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '/../%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/../%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Abwehr mit Akamai App & API Protector
Am Freitag, dem 7. März 2025, implementierte das Threat Research Team von Akamai eine Schnellregel der Akamai Adaptive Security Engine für Kunden von App & API Protector :
3000911 v2 – Apache Camel (CVE-2025-27636) Angriff erkannt – Standardaktion: Ablehnen
Kunden, bei denen Schnellregeln mit der Standardaktion „Von Akamai verwaltet“ aktiviert sind, werden automatisch vor dieser Bedrohung geschützt. Kunden, bei denen Schnellregeln mit der Standardaktion „Warnung“ aktiviert sind, sollten alle ausgelösten Regeln überprüfen und die Reaktion auf „Ablehnen“ einstellen.
Schnellregel 3000911 ist so konzipiert, dass sie bei Headern auslöst, die von der internen Filterlogik von Camel nicht erkannt worden wären (Abbildung 7). Bei normalen Camel-Headern wird die Regel nicht ausgelöst, um Auswirkungen auf legitime Kundenvorgänge zu verhindern.
Fig. 7: Rapid Rule 3000911 triggering on attack payload
Erfasster Angriffstraffic
Die aktuellen Angriffs-Payloads, die von der Akamai Security Intelligence Group beobachtet werden, versuchen lediglich, die Schwachstelle zu bestätigen, nicht auszunutzen. Die Mehrheit der erfassten Payloads verwendet zwei verschiedene Strategien zur Bestätigung der Schwachstelle.
Zunächst haben wir die Verwendung des Headernamens CAmELDestinationOverrideUrl beobachtet, bei dem die Payload eine OOB-Beaconing-Domain (Out-of-Band) ist. Dieser Traffic stammt von einem kommerziellen Anbieter von Schwachstellenscans und die Payload-URL leitet die Daten an dessen Domain weiter (Abbildung 8).
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
Dann haben wir beobachtet, dass Payloads den Header CAmelHttpResponseCode verwenden, um zu versuchen, einen bestimmten HTTP-Antwortstatuscode vom Server abzurufen (Abbildung 9). Wenn die Payload erfolgreich war, würde der vom Server zurückgegebene HTTP-Antwortstatuscode mit dem in der Payload bereitgestellten Code übereinstimmen.
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
Schließlich haben wir gesehen, wie beide der oben genannten Payloads versucht haben, die Erkennung durch einfache URL-Codierung wie ca%4d%45%6cHttpResponseCode zu umgehen (Abbildung 10). Diese Versuche werden jedoch weiterhin von der Adaptive Security Engine erkannt und blockiert.
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
AKTUALISIERUNG: CVE-2025-29891
Die Akamai SIG hat in Zusammenarbeit mit Citi Cyber Security Operations einen weiteren Exploit-Vektor ermittelt, der auf dasselbe Filterproblem zurückzuführen ist, das CVE-2025-27636 verursacht hat. Beim Testen unserer anfälligen Anwendung haben wir festgestellt, dass neben Anfrageheadern auch Abfragezeichenfolgen und Post-Textparameter einen gültigen Angriffspfad darstellen.
In Abbildung 11 sehen wir, dass der angegebene Abfrageparameter CAmelExecCommandExecutable zur Ausführung willkürlicher Befehle führt, genau wie der ursprüngliche Headervektor.
Fig. 11: Command injection in either a header or a parameter using CAmelExecCommandExecutable
Die Akamai SIG hat die Umgehung dem Sicherheitsteam von Apache Camel gemeldet. Sie haben die Ergebnisse bestätigt und eine neue CVE erstellt: CVE-2025-29891. Die codierten Fehlerbehebungen in Apache Camel von CVE-2025-27636 beheben auch diese Umgehung, aber Akamai musste eine aktualisierte Schnellregel 3000911 v3 für App & API Protector am 12. März 2025 freigeben, um die Lücke zu schließen.
Der ursprüngliche Patch zur Behebung von CVE-2025-27636 löst dieses Problem ebenfalls, sodass Anwendungen, die die aktuelle Versionen von Apache Camel verwenden, nicht anfällig für diesen Exploit-Vektor sind.
Wir haben unser GitHub-Repositoryaktualisiert, das nun auch Details zu CVE-2025-29891 und dessen Ausnutzung enthält.
Obwohl die Ausnutzung der vorherigen Schwachstelle durch die Überprüfung von Anfrageheadern erkannt werden konnte, müssen bei diesem Problem auch Anfrageparameter gefiltert werden.
Zusammenfassung
Schwachstellen in Bibliotheken wirken sich nicht nur direkt auf Anwendungen aus, sondern können sich auch an unbekannten Stellen verbergen, wodurch sie deutlich schwerer zu erkennen und abzuwehren sind. Apache Camel ist nicht nur weit verbreitet, sondern kann von einem Angreifer mit den richtigen Tools auch zur Remotecodeausführung genutzt werden, was den Schweregrad des Problems erhöht. Es wird empfohlen, dass Sie die von Apache vorgeschlagenen Maßnahmen befolgen und Patches so schnell wie möglich für Ihre Umgebung aufspielen.
Die Akamai Security Intelligence Group wird weiterhin sowohl für unsere Kunden als auch für die gesamte Sicherheitscommunity solche Bedrohungen überwachen, Berichte darüber erstellen und Maßnahmen zur Abwehr entwickeln. Weitere aktuelle Neuigkeiten der Akamai Security Intelligence Group finden Sie auf unserer Forschungs-Homepage und in den sozialen Medien.