<aside> ➡️

Scenario 02는 여기서 종료되지 않는다. 하편에서는 Wazuh 상관분석 · WAF 탐지/차단 · IAM 최소권한 · Network Hardening · Falco Rule 정교화 · 중앙 로그 연계 · Scenario 02 전용 CI Gate를 검증한다. 목표는 이미 완료한 코드 Hardening을 반복하는 것이 아니라, 개별 탐지 → 상관분석 → 예방 통제 → 운영 가능한 SecOps 흐름으로 확장하는 것이다.

</aside>

1. 실습 목적

이번 실습의 핵심은 웹 취약점 하나를 단독으로 확인하는 것이 아니라, 애플리케이션 취약점이 클라우드 Workload 권한 악용으로 이어지는 과정 → Host/Cloud 로그에 남는 흔적 → 코드 Hardening 후 동일 공격이 실패하는지까지 하나의 흐름으로 직접 확인하는 것이었다.

JWT 검증 오류
   ↓
Broken Access Control
   ↓
/admin/diagnostic 접근
   ↓
OS Command Injection
   ↓
EC2 Web Process 권한으로 명령 실행
   ↓
EC2 Workload IAM Role 사용
   ↓
Secrets Manager GetSecretValue
   ↓
CloudTrail + Falco 증거 확보
   ↓
Code Hardening
(JWT 검증 + Server-side Authorization + shell=False/Allowlist)
   ↓
동일 공격 Re-attack
   ↓
위조 JWT / Command Injection 실패 확인 (401 / 400)
   ↓
[하편] Wazuh Correlation + WAF + IAM/Network 고도화

2. 취약 환경 구성

2.1 Terraform 기반 EC2 + IAM Workload 구성

Terraform으로 Amazon Linux 기반 EC2 인스턴스를 생성하고, 해당 인스턴스에 scenario02-web-profile을 연결했다. 부팅 시 python3-pip, git, awscli와 Flask·boto3·PyJWT 등을 설치하고, 취약한 app.py가 Web Server에서 실행되도록 구성했다.

이 구조에서 중요한 점은 공격자가 별도의 Access Key를 탈취하는 것이 아니라, 이미 EC2에 정상적으로 연결된 IAM Instance Profile의 권한을 Web Process가 그대로 사용할 수 있다는 것이다.

639236643342825092.png

2.2 취약한 관리자 Diagnostic API

/admin/diagnostic에는 다음 세 가지 취약 조건을 의도적으로 구성했다.

  1. jwt.decode(..., options={"verify_signature": False})로 JWT 서명 검증 생략
  2. Token의 role=admin Claim만 신뢰하는 Broken Access Control
  3. ping -c 1 {host} 문자열을 subprocess.run(..., shell=True)로 실행하는 OS Command Injection

즉, 공격자가 관리자 Claim을 가진 JWT를 위조하면 관리자 API에 접근할 수 있고, 이후 host Query Parameter에 Shell 구문을 삽입해 Web Process 권한으로 임의 명령을 실행할 수 있다.

639236643630183085.png

2.3 실습용 Security Group

실습 환경에서는 Flask App 접근을 위해 TCP 5000번 포트, 원격 관리 및 검증을 위해 TCP 22번 포트를 0.0.0.0/0에 개방했다. Egress 역시 전체 허용 상태로 구성했다.