WebLogic 12c 취약점 조치

WebLogic 12c 취약점 조치

대상 WebLogic 12c
이슈 CVE-2017-10271 관련 컴포넌트 점검 및 비활성화/삭제 요청 대응
핵심 wls-wsat / wls9_async_response 배치 여부 확인 + Admin·Management 디렉토리 내 존재 여부 확인
현재 확인 배치 X(미배치)로 보고됨

본 문서는 공문 요구사항(컴포넌트 비활성화 또는 삭제)에 맞춰, 시스템에서 실제로 해당 요소가 존재하는지 단계적으로 확인하고 필요 시 조치/재발 방지까지 이어지는 일반오류형(확장형) 대응 절차입니다.
문서 전반에서 CVE-2017-10271 및 WebLogic 12c 키워드는 점검 기준으로 반복 사용됩니다.

개요

CVE-2017-10271 관련 이슈 대응에서 중요한 점은 “실제 노출 면”을 먼저 확정하는 것입니다.
공문에서 요청하는 wls-wsat 및 wls9_async_response가 서버에 배치/활성화되어 있지 않다면, 불필요한 조치로 서비스 영향만 키울 수 있습니다.
따라서 WebLogic 12c 기준으로 아래 순서대로 확인합니다.

1) 배치(배포) 여부 확인
2) 파일/디렉토리 존재 여부 확인(Admin, Management 포함)
3) 설정/서비스 경로 상 호출 가능성 확인(노출면 확인)
4) 필요 시 비활성화 또는 제거 조치 수행
5) 재발 방지(정책/점검 자동화) 적용

환경

항목	값(예시/기록)
제품	Oracle WebLogic Server 12c
요청 취지	CVE-2017-10271 관련 컴포넌트(wls-wsat / wls9_async_response) 비활성화 또는 삭제
현황(초기 제보)	배치 X로 확인됨
확인 대상 경로	WebLogic 설치 디렉토리 + 도메인 디렉토리 + Admin/Management 관련 디렉토리

운영 환경마다 WebLogic 설치 경로(ORACLE_HOME), 도메인 경로(DOMAIN_HOME), 관리 서버 구성(AdminServer/Managed Server)이 다릅니다.
아래 명령/경로 예시는 “확인 포인트” 중심이며, 실제 경로는 서버 표준에 맞춰 대입합니다.

증상

공문 또는 보안 점검 항목에서 아래 요구가 발생합니다.

- CVE-2017-10271 대응 필요
- wls-wsat / wls9_async_response 컴포넌트 비활성화 또는 삭제 요청
- WebLogic 12c 서버 접속 후 Admin 및 Management 디렉토리 내 해당 컴포넌트 존재 여부 확인 요청

1차 점검

1차 점검 목표는 “배치/활성 여부”를 빠르게 확정하는 것입니다.
이미 배치 X로 보고되었더라도, 로그/파일 기준으로 재확인하여 증빙을 남겨야 합니다.

A. 애플리케이션/모듈 배치 여부 확인

- 콘솔에서 배포 목록 확인(가능한 경우)
- 도메인 내 배포(Deployments) 설정 파일/로그로 확인(콘솔 접근이 제한된 경우)
- Managed Server 별로 배치가 다를 수 있으므로 서버 단위로 확인

# (예시) 도메인 경로 추정
# echo $DOMAIN_HOME

# (예시) 도메인 내 배포 흔적 검색(리눅스)
find "$DOMAIN_HOME" -maxdepth 5 -type f -name "*.xml" -o -name "*.plan" 2>/dev/null | head

# (예시) 키워드 기반 검색(모듈/컴포넌트 명칭)
grep -RniE "wls-wsat|wls9_async_response|WSAT" "$DOMAIN_HOME" 2>/dev/null | head -n 50

B. URL/컨텍스트 노출 여부(간단 확인)

- 외부에서 접근 가능한 프록시/로드밸런서 경로 포함 확인
- 내부 관리 포트만 열려 있어도 내부망 경유 공격 가능성이 있으므로 “열림/차단”을 명확히 기록

# (예시) 서버에서 로컬로 확인
# curl -I http://localhost:7001/  (관리 포트/서비스 포트에 맞게 변경)

# (예시) 의심 경로가 있다면 상태 코드만 확인(경로는 환경에 맞게)
# curl -I http://localhost:7001/wls-wsat
# curl -I http://localhost:7001/wls9_async_response

심화 분석

심화 분석 목표는 “파일/디렉토리 존재 여부”를 명확히 하는 것입니다.
공문에서 요구한 Admin 및 Management 디렉토리(관리 영역) 관점에서도 확인 기록을 남깁니다.

A. 설치 경로(ORACLE_HOME) 및 미들웨어 구성 요소 확인

- WebLogic 설치 디렉토리(예: ORACLE_HOME 또는 MW_HOME)에서 관련 파일 존재 여부 확인
- 패치 적용 여부는 별도 체크리스트로 기록(패치 정책에 따라 수행)

# (예시) 설치 경로에서 관련 파일/폴더 검색
# 실제 경로 예: /u01/app/oracle/middleware  또는 /opt/oracle/middleware 등
MW_HOME="/path/to/middleware"

find "$MW_HOME" -maxdepth 8 -type d -iname "*wsat*" 2>/dev/null | head -n 50
find "$MW_HOME" -maxdepth 10 -type f -iname "*wls9*async*response*" 2>/dev/null | head -n 50

B. 도메인 및 관리 영역(Admin/Management) 디렉토리 확인

- 도메인 루트에서 Admin/Management 관련 디렉토리 및 설정 파일 확인
- 서버별(stage) 배포 디렉토리 또는 tmp/work 디렉토리에도 잔존 파일이 있을 수 있어 추가 확인

# (예시) 도메인 내 Admin/Management 관련 흔적 확인
# 환경에 따라 "servers/AdminServer", "servers/<managed>" 구성이 다름
find "$DOMAIN_HOME" -maxdepth 4 -type d -iname "*admin*" 2>/dev/null | head -n 50
find "$DOMAIN_HOME" -maxdepth 6 -type d -iname "*management*" 2>/dev/null | head -n 50

# (예시) 서버별 배포 스테이징/작업 경로에서 키워드 검색
find "$DOMAIN_HOME/servers" -maxdepth 6 -type d -iname "*stage*" -o -iname "*tmp*" -o -iname "*work*" 2>/dev/null | head -n 50
grep -RniE "wls-wsat|wls9_async_response|WSAT" "$DOMAIN_HOME/servers" 2>/dev/null | head -n 50

C. 분석 결론 정리(증빙 기준)

- 배치 X 결론을 내릴 경우, “검색 범위(경로)”와 “검색 키워드”를 함께 기록
- wls-wsat / wls9_async_response 파일이 존재하나 배치가 안 된 경우, 실행/노출 가능 경로를 추가 분석
- WebLogic 12c의 운영 방식(Managed Server별 배치 차이) 때문에 서버 단위 결론을 분리 기록

복구

아래 조치는 “존재/노출 가능성이 확인된 경우”에만 적용합니다.
현재 상태가 배치 X라면, 무리한 삭제 대신 “비활성화(노출 차단) + 증빙 유지”가 안전한 선택일 수 있습니다.

A. 우선순위: 노출면 차단

- 외부 접근 차단(방화벽/보안그룹/프록시 규칙) 우선 적용
- 관리 포트(Admin/Management)는 내부망/운영자 구간으로만 제한
- 의심 경로(/wls-wsat 등)가 라우팅되지 않도록 프록시 차단 규칙 적용

B. 컴포넌트 비활성화 또는 제거(운영 정책에 따라)

WebLogic 12c의 실제 조치 방법은 설치 구성/패치 레벨/도메인 구성에 따라 달라질 수 있습니다.
아래는 “조치 설계 시 체크 포인트”이며, 운영 표준 변경절차(검증/백업/롤백)를 반드시 따릅니다.

- 콘솔/구성 파일에서 해당 모듈이 배포되어 있다면: 우선 중지 → 배포 해제 → 재기동 후 재확인
- 파일 삭제가 필요한 경우: 백업(원본 보관) → 영향도(의존성) 확인 → 제거 → 재기동 → 헬스체크
- 조치 후에는 “URL/포트/배포목록/로그”로 동일 항목 재점검

# (예시) 조치 전 백업(경로는 환경에 맞게)
# tar -czf /backup/weblogic_component_backup_$(date +%Y%m%d).tgz "$DOMAIN_HOME" 2>/dev/null

# (예시) 조치 후 재점검(키워드 재검색)
grep -RniE "wls-wsat|wls9_async_response|WSAT" "$DOMAIN_HOME" 2>/dev/null | head -n 50

재발 방지

CVE-2017-10271 같은 이슈는 단발성 조치로 끝내기 어렵습니다.
WebLogic 12c 운영에서는 “노출면 최소화 + 정기 점검 자동화 + 변경관리”를 묶어서 재발을 줄입니다.

1) 관리 포트/콘솔 접근 통제(내부 전용, 최소 IP 허용)
2) 표준 점검 스크립트로 wls-wsat / wls9_async_response 문자열 주기 검색
3) 배포 목록(Deployments) 월간/분기별 증빙 확보
4) 패치 정책 수립: 적용 주기, 영향도 평가, 롤백 절차 문서화
5) 침해사고 대응 절차에 “컴포넌트 노출 점검” 항목 포함

오류 분석 흐름도

┌───────────────────────────────────────────┐
│ 시작: 공문/점검에서 CVE-2017-10271 대응 요청 │
└───────────────────────────────────────────┘
                 │
                 ▼
┌───────────────────────────────────────────┐
│ 1) 배치(배포) 여부 확인                    │
│ - 콘솔/설정/로그로 wls-wsat, wls9_async... │
└───────────────────────────────────────────┘
        │                         │
        │ 배치 O                  │ 배치 X
        ▼                         ▼
┌──────────────────────────┐   ┌──────────────────────────┐
│ 2) 노출면(포트/URL) 확인  │   │ 2) 파일/디렉토리 존재 확인 │
│ - 외부/내부 접근 경로     │   │ - Admin/Management 포함    │
└──────────────────────────┘   └──────────────────────────┘
        │                         │
        ▼                         ▼
┌──────────────────────────┐   ┌──────────────────────────┐
│ 3) 조치 결정              │   │ 3) 결론/증빙 정리          │
│ - 우선 차단 → 비활성화/제거│   │ - 검색 범위/키워드 기록    │
└──────────────────────────┘   └──────────────────────────┘
                 │
                 ▼
┌───────────────────────────────────────────┐
│ 4) 재점검                                  │
│ - 배포목록/URL/로그/키워드 재검색           │
└───────────────────────────────────────────┘
                 │
                 ▼
┌───────────────────────────────────────────┐
│ 5) 재발 방지 적용(통제/자동점검/변경관리)   │
└───────────────────────────────────────────┘

체크 포인트 요약: WebLogic 12c 환경에서 CVE-2017-10271 대응은 “배치 여부 → 존재 여부 → 노출면 → 조치 → 재점검” 순서가 안정적입니다.
특히 wls-wsat / wls9_async_response가 배치 X인 경우에도, Admin 및 Management 디렉토리 포함 검색 범위를 명확히 남기면 대응 품질이 올라갑니다.