Apache Camel 취약점 탐지 및 방어
핵심 요약
2025년 3월 9일, Apache Camel은 원격 코드 실행으로 이어질 수 있는 요청 헤더의 잘못된 필터링으로 인해 발생하는 취약점인 CVE-2025–27636을 공개했습니다.
이 취약점은 라이브러리에 존재하며, 직접 및 간접 의존성을 생성하고 탐지 및 방어를 복잡하게 만듭니다.
이 블로그 게시물에서 Akamai 연구원들은 취약점, 악용 기법, 탐지 전략에 대한 심층적인 세부 정보를 제공합니다.
Akamai Adaptive Security Engine Rapid Rule은 Akamai App & API Protector 고객을 자동으로 보호합니다.
또한 탐지를 위해 Akamai Guardicore Segmentation Insight 쿼리를 제공합니다.
- 영향을 받은 Akamai Hunt 고객은 이미 취약한 자산에 대한 자세한 매핑을 받았습니다.
- 업데이트: 2025년 3월 11일, Akamai SIG(Security Intelligence Group)는 Apache Camel 보안팀에 우회 경로를 보고했습니다. 2025년 3월 12일 Apache는 새로운 CVE인 CVE-2025-29891를 공개했습니다.
서론
2025년 3월 9일 취약점이 수정되었습니다. 이는 널리 사용되는 Java 라이브러리인 Apache Camel에서 발견된 것입니다. 이 취약점은 Apache에 의해 해결되었으며, 버전 4.10.2, 4.8.5, 3.22.4에서 수정되었습니다. 초기 보고서에 따르면 이 취약점은 심각한 영향을 미칠 수 있다고 주장되었지만, 개발자 팀은 이 취약점에 중간 수준의 심각도를 부여했습니다.
이 심각도 등급에도 불구하고, 해당 환경에서 수정된 버전을 실행하고 있다면 가능한 한 빨리 패치를 적용하는 것이 좋습니다. 그러나 버전 4.10.0, 4.10.1, 4.8.0~4.8.4, 3.10.0~3.22.3을 실행하는 애플리케이션은 여전히 영향을 받을 수 있습니다.
취약한 애플리케이션이 악용되려면 몇 가지 특정 전제 조건을 충족해야 합니다( 이 글의 뒷부분에서자세히 살펴보겠습니다). 그럼에도 불구하고 그 영향은 여전히 상당할 수 있습니다. 이 취약점은 악용하기가 매우 쉽고 원격 코드 실행을 포함하여 치명적인 결과를 가져올 수 있습니다.
라이브러리에 내재된 취약점의 특성과 함께 Camel의 보편성은 발견된 이 취약점의 심각성을 말해줍니다. 이 블로그 게시물은 기업의 대응 과정을 돕기 위한 것입니다.
취약점을 조사하고, 애플리케이션에 미칠 잠재적 영향을 설명하며, 취약점 악용 방식 분석을 통해 탐지 체계를 구축합니다. 또한, 이 취약점과 라이브러리에 숨어 있는 다른 취약점에서 비롯된 가장 어려운 과제 중 하나인 취약한 애플리케이션 식별 방법을 다룹니다.
Apache Camel이란 무엇일까요?
Apache Camel 은 다양한 시스템, 애플리케이션, 클라우드 서비스 간의 원활한 데이터 교환을 가능하게 하는 널리 사용되는 오픈 소스 통합 프레임워크입니다. 이 프레임워크는 다양한 기업 환경에서 메시지 라우팅, 변환, 연결을 간소화합니다. 많은 기업들이 중요한 비즈니스 워크플로우, API 통합, 마이크로서비스 오케스트레이션을 위해 Camel을 사용합니다.
CVE-2025-27636 분석
Apache Camel은 DefaultHeaderFilterStrategy.java 를 사용해 내부 헤더가 외부로 전달되는 것을 차단합니다. 이로써 공격자가 악용할 수 있는 민감한 라우팅 정보가 유출되는 것을 방지할 수 있습니다. 이러한 헤더의 예는 다음과 같습니다.
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
이 필터링은 다음과 같은 HTTP 기반 구성요소가 요청을 처리할 때 적용됩니다.
- camel-http 및 camel-http4(표준 HTTP 처리)
- camel-rest(REST DSL 취급)
- camel-cxf(Apache CXF 웹 서비스)
취약점은 Camel의 잘못된 요청 헤더 필터링에서 비롯됩니다. 수정하기 전에는 Apache Camel이 대소문자를 구분하는 필터링 룰을 사용했습니다(그림 1).
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
이 로직은 Camel 또는 org.apache.camel (정확히 표시된 대로)로 시작하는 헤더만 일치시킵니다. 예를 들어, 공격자가 대소문자를 바꾸어 CAmelHttpUri 또는 cAMELHttpResponseCode를 사용하면 헤더가 필터링되지 않습니다.
이는 공격자가 임의의 헤더를 요청에 삽입하고 Camel이 이를 내부 구성요소로 전달할 수 있음을 의미합니다. Apache가 자문에서 언급한 바와 같이, 이 취약점은 임의의 내부 방법에 대한 접속을 허용하지 않고, 오히려 bean URI에 선언된 동일한 bean에 있는 방법에 대한 접속만 허용한다는 점에 유의해야 합니다. 이는 악용을 위한 특정 전제 조건 중 하나입니다. 즉, 취약한 버전의 Apache Camel을 실행한다고 해서 애플리케이션이 자동으로 취약해지는 것은 아닙니다.
위협 테스트
취약점을 입증하기 위해 원격으로 악용될 수 있는 취약한 애플리케이션 샘플 을 만들었습니다. 이 애플리케이션은 HTTP 포트 80에서 수신 대기하고, 요청을 받으면 Camel의 “Exec” 구성요소를 사용해 whoami 명령을 실행하고 그 결과를 클라이언트에 반송합니다.
curl을 사용해 간단한 요청을 호출하면 예상한 결과가 반환됩니다: 취약점이 노출됨(그림 2).
Fig. 2: Normal application operation that returns the result of the whoami command
코드에서 볼 수 있듯이 whoami 명령은 정적으로 정의되어 있어 코드가 비교적 안전해 보입니다. 문제는 Exec이 지원하는 가능한 내부 메시지 헤더를 검사하는 경우 발생합니다. CamelExecCommandExecutable 헤더를 조사해 보면, 코드의 정적 URI에 정의된 실행 파일을 재정의하는 것을 볼 수 있습니다(그림 3).
Fig. 3: Apache Camel Exec component documentation
Apache Camel은 대소문자가 일치하는 내부 헤더(예: CamelExecCommandExecutable)를 필터링할 것입니다. 그러나 CVE-2025-27636은 CAmelExecCommandExecutable (또는 다른 대소문자 차이)를 입력해 필터를 우회하고 서버에서 임의의 명령을 실행할 수 있게 합니다 (그림 4).
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
이와 비슷한 방식으로, 실행된 명령에 매개변수를 제공하기 위해 CAmelExecCommandArgs 를 지정할 수도 있습니다(그림 5).
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
이것은 이 취약점을 악용하는 방법을 보여주는 간단한 예입니다. 공격자는 임의의 내부 헤더를 삽입할 수 있는 기능을 이용해 서버에서 사용하는 Camel 구성요소에 따라 다양한 애플리케이션을 감염시킬 수 있습니다.
Apache Camel은 CVE-2025-27636을 어떻게 해결했습니까?
대소문자 일관성을 강제함으로써 이 문제를 해결했습니다 . 이로써 공격자가 필터를 우회하기 위해 대소문자를 조작할 수 있는 기능이 제거됐습니다. 예를 들어 CAmelHttpUri 는 camelhttppuri가 되어 이제 필터와 일치하므로 포착될 것입니다.
.toLowerCase() 소개
GitHub 커밋은 DefaultHeaderFilterStrategy.java 의 헤더 필터링 로직을 업데이트해 toLowerCase(Locale.ENGLISH) 를 포함시켜 모든 헤더 이름이 필터를 적용하기 전에 소문자로 변환되도록 했습니다(그림 6).
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
이러한 수정은 인젝션을 차단하는 것과 더불어 최적화된 검사로 효율성을 유지합니다. 첫 번째 검사는 일반적인 “Camel”과 “camel”의 경우를 신속하게 처리합니다. .toLowerCase() 검사는 필요할 때만 실행되므로 불필요한 성능 비용이 발생하지 않습니다.
취약한 애플리케이션 탐지
네트워크 전체에서 취약한 Apache Camel 인스턴스를 모두 파악하는 것은 쉽지 않습니다. Apache Camel은 다양한 곳에 통합되어 있기 때문에 보안팀은 광범위한 자산을 평가해야 합니다. 여기에는 보안팀 직원이 인식하지 못하는 라이브러리가 사용되는 애플리케이션이 포함될 수 있습니다.
라이브러리는 간접적인 의존성으로 존재할 수 있습니다. 즉, 소스 코드에 명시적으로 포함되지 않고 다른 소프트웨어 패키지를 통해 도입되는 것입니다. 따라서 탐지 및 방어 작업의 복잡성이 커집니다.
Apache Camel은 이름에 “camel”이 포함된 JAR 파일이 있는지 디렉터리를 재귀적으로 스캔해 Java 애플리케이션 내에서 식별할 수 있습니다. Camel 관련 JAR 파일이 발견되면 해당 매니페스트 파일을 검사해 사용 중인 버전을 확인할 수 있습니다.
추출된 버전을 통해 보안팀은 Apache의 보안 권고 와 상호 참조해 잠재적인 취약점을 평가할 수 있습니다. 영향을 받는 버전은 다음과 같습니다.
- 4.10.0 — 4.10.2 이전 취약
- 4.8.0 — 4.8.5 이전 취약
- 3.10.0 — 3.22.4 이전 취약
탐지 자동화
Akamai는 취약한 애플리케이션을 쉽게 식별할 수 있도록 디렉토리를 재귀적으로 스캔하고, Apache Camel JAR 파일을 탐지하고, 잠재적으로 취약한 애플리케이션을 출력하는 PowerShell 및 Bash 스크립트 를 개발했습니다. Windows와 Linux 모두에 대한 옵션을 포함시켰습니다. 영향을 받은 Akamai Hunt 고객들은 이미 취약한 자산에 대한 자세한 매핑을 받았습니다.
Akamai Guardicore Segmentation을 통한 탐지
Akamai는 Akamai Guardicore Segmentation 고객들을 위해 취약한 자산을 식별할 수 있는 Insight 쿼리를 구축했습니다. 파일 버전에 대한 검색 결과가 “Version not found”인 경우, 반환된 해시를 VirusTotal에서 확인하거나 jar 내부의 매니페스트 파일을 통해 올바른 버전을 찾을 수 있습니다.
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
Akamai App & API Protector를 통한 방어
2025년 3월 7일 금요일, Akamai의 위협 연구팀은 App & API Protector 고객을 위해 Adaptive Security Engine Rapid Rule을 배포했습니다.
3000911 v2 - Apache Camel (CVE-2025-27636) 공격 탐지 - 기본 조치: 거부
기본 조치로 “Akamai 관리”를 설정하고 Rapid Rule을 활성화한 고객은 이 위협으로부터 자동으로 보호됩니다. 기본 조치로 “알림”으로 설정하고 Rapid Rule을 사용하는 고객은 룰 트리거를 평가하고 룰 조치를 거부로 설정해야 합니다.
Rapid Rule 3000911은 Camel의 내부 필터링 로직을 피할 수 있는 헤더에 대해 트리거되도록 설계되었습니다(그림 7). 이 룰은 정상적인 고객 운영에 영향을 미치지 않도록 일반 Camel 헤더에 대해서는 트리거되지 않습니다.
Fig. 7: Rapid Rule 3000911 triggering on attack payload
관찰된 공격 트래픽
Akamai Security Intelligence Group 이 관찰한 현재 공격 페이로드는 취약점을 악용하기보다는 취약점을 확인하려는 시도일 뿐입니다. 관찰된 페이로드의 대부분은 취약점을 확인하기 위해 두 가지 다른 전략을 사용하고 있습니다.
먼저, 페이로드가 OOB(Out-Of-Band) 비컨 도메인인 CAmELDestinationOverrideUrl 헤더 이름의 사용을 살펴보았습니다. 이 트래픽은 상업적 취약점 스캐닝 벤더에서 발생하며, 페이로드 URL은 해당 벤더의 도메인으로 다시 비컨을 보냅니다(그림 8).
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
둘째, 페이로드가 서버로부터 특정 HTTP 응답 상태 코드를 이끌어 내기 위해 CAmelHttpResponseCode 헤더를 사용하는 것을 확인했습니다(그림 9). 페이로드가 성공적으로 수행된 경우, 서버로부터 반환된 HTTP 응답 상태 코드가 페이로드에 제공된 코드와 일치합니다.
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
마지막으로, 위의 두 가지 페이로드가 모두 ca%4d%45%6cHttpResponseCode 와 같은 간단한 URL 인코딩을 사용해 탐지를 회피하려는 시도를 하는 것을 확인했습니다(그림 10). 그러나 이러한 시도는 여전히 Adaptive Security Engine에 의해 탐지되고 차단됩니다.
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
업데이트: CVE-2025-29891
Akamai SIG는 Citi 사이버 보안 운영팀과 협력해 CVE-2025-27636을 유발한 것과 동일한 필터링 문제로 인해 발생하는 추가적인 악용 기법을 확인했습니다. 취약한 애플리케이션을 테스트하는 과정에서 요청 헤더 외에도 쿼리 문자열과 게시물 본문 매개변수가 유효한 공격 경로를 제공한다는 것을 확인했습니다.
그림 11에서 CAmelExecCommandExecutable 쿼리 매개변수를 지정하면 원래 헤더 기법과 마찬가지로 임의의 명령 실행으로 이어지는 것을 볼 수 있습니다.
Fig. 11: Command injection in either a header or a parameter using CAmelExecCommandExecutable
Akamai SIG는 이 우회 방법을 Apache Camel 보안팀에 보고했습니다. Apache Camel 보안팀은 발견된 내용을 검증하고 새로운 CVE: CVE-2025-29891을 만들었습니다. CVE-2025-27636의 Apache Camel에 있는 코딩된 수정 사항도 이 우회 기법을 수정하지만, 2025년 3월 12일에 Akamai는 문제를 해결하기 위해 업데이트된 App & API Protector Rapid Rule 3000911 v3 를 출시해야 했습니다.
CVE-2025-27636을 수정하기 위한 원래 패치도 이 문제를 해결하므로 최신 버전의 Apache Camel을 사용하는 애플리케이션은 이 악용 기법에 취약하지 않습니다.
Akamai는 GitHub 리포지터리를 업데이트했으며 여기에는 CVE-2025-29891과 그 악용에 대한 세부 정보도 포함되어 있습니다.
이전 취약점의 악용은 요청 헤더를 검사함으로써 탐지할 수 있지만 이 문제는 요청 매개변수도 필터링해야 합니다.
요약
라이브러리 내의 취약점은 애플리케이션에 직접적인 영향을 미칠 뿐만 아니라 알려지지 않은 곳에 숨어 있을 수 있기 때문에 탐지 및 방어가 매우 어렵습니다. Apache Camel은 널리 사용될 뿐만 아니라, 올바른 툴 세트를 갖춘 공격자가 이를 활용해 원격으로 코드를 실행할 수 있기 때문에 심각성이 높아집니다. Apache가 권장하는 조치를 따르고 가능한 한 빨리 환경에 패치를 적용하는 것 이 좋습니다.
Akamai Security Intelligence Group은 고객과 보안 커뮤니티 전체를 위해 이와 같은 위협에 대한 모니터링, 보고, 방어를 계속할 것입니다. Akamai Security Intelligence Group의 최신 뉴스를 확인하려면 리서치 홈페이지 를 방문하거나 소셜 미디어를 팔로우하세요.