CVE-2024-28752 : Apache CXF Aegis SSRF

CVE-2024-28752

CVE-2024-28752는 Apache CXF에서 Aegis DataBinding을 사용할 때 발생 가능한 SSRF(Server-Side Request Forgery) 취약점으로, 특정 형태의 웹서비스 요청을 통해 서버가 임의의 URL로 요청을 보내도록 유도될 수 있습니다.
운영 환경에서는 “취약점 설명”보다 우리 서비스가 Aegis DataBinding을 쓰는지와 CXF 버전이 안전한지를 빠르게 확정하는 것이 우선입니다. (실무 기준으로 보면, “Aegis 사용 여부 + 버전” 두 가지가 우선순위를 결정합니다.)

문서 범위: 일반오류형(확장형 매뉴얼) / 목표: 영향 확인 → 단기 완화 → 패치/복구 → 재발 방지

개요

핵심 요약
- 영향 조건: Apache CXF + Aegis DataBinding 사용 + 외부 입력이 해당 웹서비스 파라미터로 유입되는 구조
- 취약 범위(일반 안내): Apache CXF 4.0.4 / 3.6.3 / 3.5.8 이전 버전에서 Aegis DataBinding을 사용할 때 영향 가능
- 기본 DataBinding(JAXB 등)만 사용하는 경우는 영향이 없다고 안내되는 케이스가 많습니다.

운영 영향(대표 시나리오)
- 내부망 접근: 메타데이터/관리 콘솔/내부 API 등으로 서버가 요청을 보내도록 유도될 수 있음
- 정보 노출: 응답/에러 메시지/로그에 내부 자원 정보가 남을 수 있음
- 후속 공격: 내부 서비스 식별, SSRF를 발판으로 추가 취약점 탐색

우선순위
1) CXF 포함 여부 2) Aegis 사용 여부 3) 버전

- 스캐너가 “제품명” 대신 “이미지/패키지 경로” 기준으로 표시하는 경우가 많으니, 탐지 경로(Path)와 실제 배포 산출물(JAR/컨테이너)을 먼저 맞춰보세요.

환경

기록해야 할 항목(필수)
- 배포 형태: VM / 온프렘 / 컨테이너 / 쿠버네티스 / WAS 내장 여부
- CXF 포함 위치: 애플리케이션 JAR/WAR/ear 내부, lib 디렉터리, 별도 모듈/플러그인 등
- 노출 범위: 외부 공개 엔드포인트 여부, 인증/인가 방식, 내부 전용 여부
- 네트워크 정책: 아웃바운드(egress) 허용 범위(프록시/방화벽/네임스페이스 정책)

# (리눅스/컨테이너) CXF 관련 jar 탐색 예시
# - 경로는 환경에 맞게 조정
find / -type f -name "*.jar" 2>/dev/null | egrep -i "cxf|aegis" | head -n 50

# (애플리케이션 디렉터리 기준) 흔히 사용하는 탐색
find ./ -type f -name "*.jar" | egrep -i "cxf|aegis"

증상

자주 나타나는 징후
- 보안 스캐너/게이트에서 CVE-2024-28752 탐지로 빌드/배포가 차단됨
- CXF 라이브러리(cxf-core 등) 버전이 취약 범위로 표시됨
- 웹서비스 요청 처리 경로에서 예상치 못한 URL 접근 시도(프록시/방화벽 로그) 패턴이 보임

# (네트워크/방화벽 로그 관점) SSRF 의심 시 확인 포인트
# - 앱 서버가 외부/내부 특정 주소로 비정상적으로 요청을 보내는지
# - 평소 없던 DNS 조회/HTTP CONNECT/메타데이터 IP로의 접근 시도 여부

주의
- “탐지됨”은 “즉시 악용됨”과 동일하지 않습니다.
- 다만 SSRF는 네트워크 경계와 직결되므로, 외부 노출 + egress 허용 조합이면 우선순위를 높게 잡는 편이 안전합니다.

1차 점검

체크리스트(빠른 판정)
1) 우리 서비스(또는 제품/플러그인)에 Apache CXF가 포함되어 있는가?
2) 포함된 CXF 버전이 4.0.4 / 3.6.3 / 3.5.8 이전인가?
3) Aegis DataBinding을 실제로 사용하는가? (의존성 + 구성 + 코드 경로)
4) 해당 웹서비스 엔드포인트가 외부 입력을 받아 처리하는가?

# (JAR 버전 확인) 파일명으로 1차 확인 (정확하지 않을 수 있어도 빠름)
ls -al | egrep -i "cxf-.*\.jar|aegis.*\.jar"

# (MANIFEST/Maven metadata로 확인) jar 내부 메타 확인 예시
jar tf cxf-core*.jar | egrep -i "pom\.properties|MANIFEST\.MF" | head

# (pom.properties 확인 예시)
# jar xf cxf-core*.jar META-INF/maven/*/*/pom.properties
# cat META-INF/maven/*/*/pom.properties

Aegis 사용 여부(빠른 확인 힌트)
- 의존성에 cxf-rt-databinding-aegis 또는 “aegis” 관련 모듈이 포함되는지 확인
- Spring/XML/코드 설정에서 “Aegis” databinding을 명시하는 설정이 있는지 검색
- 운영에서 실제로 로딩되는 클래스/빈이 Aegis 경로를 타는지(로그/디버그/구성) 확인

# (리포지토리) Aegis 관련 키워드 검색 예시
grep -RIn --exclude-dir=target --exclude-dir=.git "aegis" .
grep -RIn --exclude-dir=target --exclude-dir=.git "databinding" .

심화 분석

위험도가 급상승하는 조건
- 외부에서 접근 가능한 SOAP/웹서비스 엔드포인트가 있고, 요청 파라미터가 다양한 타입(복합 객체 포함)을 받는 구조
- 서버가 내부망/메타데이터(클라우드)로 나갈 수 있는 egress가 열려 있음
- 프록시/방화벽에서 앱 서버의 아웃바운드가 광범위하게 허용됨

운영 관점에서의 결론 내리기
- “취약 버전이 포함됨”만으로도 보안 게이트는 막힐 수 있습니다.
- 하지만 실제 위험도는 Aegis 사용 여부와 외부 입력 연결이 좌우합니다.
- 그래서 분석 순서는 버전 확인 → Aegis 사용 확인 → 노출면(외부/내부) → egress가 가장 빠릅니다.

# (런타임 분석) JVM 옵션/클래스패스/컨테이너 이미지에서 실제 로딩 라이브러리 확인 힌트
# - 애플리케이션 시작 로그에 로딩된 모듈, classpath 출력 옵션을 활용
# - Aegis 관련 모듈이 실제로 로딩되는지 확인

# (네트워크 분석) 의심 시 서버에서 나가는 트래픽 확인(환경별로 접근 방식 상이)
# - egress 정책/프록시 로그/방화벽 로그에서 대상 URL/호스트 패턴 확인

공격자는 SSRF로 내부 자원에 접근을 시도합니다. 운영 환경에서는 “내부로 나갈 수 있느냐(egress)”가 1차 방어선입니다. 그래서 패치가 곧바로 어렵다면, egress를 줄이는 것만으로도 실질 위험도를 크게 낮출 수 있습니다.

복구

권장 복구 흐름
1) 패치 포함 버전으로 업그레이드(가장 확실)
2) 업그레이드 전까지 단기 완화(egress 제한 + 노출면 축소)
3) 배포 후 재스캔과 트래픽/로그 모니터링으로 해소 확인

업그레이드 가이드(일반)
- Apache CXF를 4.0.4 / 3.6.3 / 3.5.8 이상으로 올리는 방향을 우선 검토합니다.
- 제품/플러그인이 CXF를 번들링하고 있다면, 상위 제품의 업데이트(핫픽스/마이너 릴리즈)가 우선일 수 있습니다.

# (Maven) 의존성 트리에서 CXF 버전 확인 예시
mvn -q -DskipTests dependency:tree | egrep -i "org\.apache\.cxf|cxf-rt|cxf-core"

# (Gradle) 의존성 확인 예시
./gradlew -q dependencies | egrep -i "org\.apache\.cxf|cxf-rt|cxf-core"

# (컨테이너) 패치 적용 후 이미지 재빌드/재배포 기본 흐름
# - 조직 표준 이미지/레지스트리 정책에 맞게 수행
docker build -t your-image:patched .
docker run --rm your-image:patched java -version

단기 완화(업그레이드 전 임시)
- egress 제한: 앱 서버에서 외부/내부 임의 주소로 나가는 트래픽을 기본 차단하고, 필요한 목적지(프록시/외부 API)만 허용
- 노출면 축소: 외부 공개 웹서비스 엔드포인트를 내부망으로 제한하거나, 인증/인가를 강화
- Aegis 회피: 가능하면 Aegis DataBinding을 사용하지 않도록 구성 변경(기본 databinding 전환) 검토

단기 완화는 “리스크를 낮추는 조치”이고, 보안 감사/게이트를 통과하려면 최종적으로 “안전 버전 적용”이 필요할 때가 많습니다.

재발 방지

운영 프로세스
- 컴포넌트 인벤토리: CXF 포함 위치(앱/플러그인/번들)와 버전 기록
- 정기 업데이트: LTS/유지보수 라인 기준으로 분기별(또는 월별) 보안 패치 적용 루틴화
- 배포 게이트: 스캔 결과에 대한 예외 승인 절차(기간/책임/보완책) 명문화

기술적 가드레일
- egress 기본 차단 + 목적지 허용(프록시/방화벽/쿠버네티스 네트워크 정책)
- 외부 노출 웹서비스는 인증/인가·입력 검증·레이트 리밋을 기본 적용
- 모니터링: 앱 서버의 비정상 아웃바운드(DNS/HTTP) 탐지 알림 구성

릴리즈 체크(추천)
- 배포 전: 의존성 트리/이미지 스캔에서 CVE-2024-28752 해소 여부 확인
- 배포 후: 동일 조건 재스캔 + egress 로그/방화벽 로그에서 이상 트래픽 여부 확인
- 기록: “영향 모듈 / 버전 / 조치일 / 롤백 포인트 / 단기 완화(있다면)”를 변경관리 티켓에 남기기

결과

완료 기준
- (필수) 스캐너/CI 게이트에서 CVE-2024-28752 탐지가 해소됨
- (필수) 서비스 지표(에러율/지연/리소스) 이상 없음
- (권장) Aegis 사용 여부 판정 근거(구성/의존성/런타임 로딩)를 문서화 완료

다음에 비슷한 SSRF 계열 이슈가 나오면, “취약점 이름”보다 노출 엔드포인트 + egress + 실제 사용 구성을 먼저 보면 더 빠르게 정리됩니다.