Microsoft Exchange 서버가 CVE-2020-0688 취약점에 노출되었는지 확인하려면 IIS 로그를 살펴봐야 한다. 특히 /ecp/default.aspx 경로로 유입되는 POST 요청 중 __VIEWSTATE 매개변수가 비정상적으로 긴 사례를 분석하는 것이 중요하다. 공격에 성공했다면 HTTP 200 또는 302 응답 이후 시스템에서 cmd.exe나 powershell.exe 같은 쉘 프로세스가 실행된 흔적이 남는다.
CVE-2020-0688 개요 및 영향 범위
CVE-2020-0688은 Microsoft Exchange Server의 ECP(Exchange Control Panel) 웹 애플리케이션에서 발생하는 원격 코드 실행(RCE) 취약점이다. CVSS 점수는 8.8점으로 보안 위협 수준이 매우 높다. 공격자는 별도의 인증 없이 네트워크를 통해 대상 서버에 임의 명령어를 실행할 수 있어, 기업 내부망 전체로 공격이 확산될 위험이 크다.
근본 원인은 Exchange Server 설치 과정에서 생성되는 머신 키(Machine Key)가 정적이고 예측 가능하다는 점이다. 정상적인 환경의 ViewState 데이터는 서버만 아는 비밀 키로 암호화되어 조작이 불가능해야 한다. 하지만 키가 예측 가능해지면서 공격자가 유효한 ViewState 매개변수를 직접 생성해 전송할 수 있게 되었다. 결국 서버는 공격자가 조작한 직렬화 데이터를 신뢰해 실행하며, 이는 곧 시스템 권한 탈취로 이어진다.
Microsoft는 2020년 2월 11일에 보안 업데이트를 배포했다. 하지만 패치 이후에도 MetCSAH Metasploit 같은 공개 익스플로잇 프레임워크에 관련 모듈이 추가되면서, 업데이트가 누락된 레거시 시스템을 겨냥한 자동화 공격이 계속되고 있다. 특히 2023년과 2024년 현재까지도 구형 서버들은 랜섬웨어 감염 및 암호화폐 채굴 악성코드 유포의 주요 진입점으로 악용되는 실정이다.
CVE-2020-0688 탐지 방법 및 대응 방안의 기술적 분석
공격자는 주로 ECP 기본 페이지인 /ecp/default.aspx를 노린다. 먼저 대상 서버의 머신 키를 예측하거나 획득한 뒤, 악성 페이로드를 포함한 ViewState 데이터를 생성해 HTTP POST 요청을 보낸다. 서버가 이 데이터를 역직렬화(Deserialization)하는 과정에서 공격자가 의도한 코드가 실행되는 구조다.
보안 실무자는 단순히 패치만 적용해서는 안 된다. 공격자가 이미 취약점을 이용해 침입했다면, 패치 전 웹 쉘(Web Shell)을 설치해 지속적인 접근 권한을 확보했을 가능성이 높다. 따라서 패치 전후로 시스템 전체 파일의 무결성을 검사하고 예약된 작업(Scheduled Tasks)이나 알 수 없는 신규 계정 생성 여부를 정밀하게 포렌식해야 한다.
| 구분 | 정상 요청 특징 | CVE-2020-0688 공격 요청 특징 |
|---|---|---|
| 요청 경로 | / 다양한 ECP 경로 | /ecp/default.aspx 집중 발생 |
| __VIEWSTATE 값 | 표준 길이의 암호화 데이터 | 비정상적으로 매우 긴 Base64 인코딩 데이터 |
| __VIEWSTATEGENERATOR | 정상적인 세션/페이지 식별자 | 조작된 값 또는 비정상적인 형식의//////- |
| User-Agent | 일반적인 웹 브라우저 정보 | 비어 있거나 자동화 도구 특유의 패턴 |
| HTTP 응답 코드 | 200 OK / 302 Found (정상 흐름) | 500 Internal Server Error (실패) 또는 200 (성공) |
상세 로그 분석을 통한 침해 지표(IoC) 식별
정확한 탐지를 위해 IIS 로그 파일(C:\inetpub\logs\LogFiles\)과 Exchange ECP 관련 로그를 교차 분석해야 한다. 404(Not Found)나 500(Internal Server Error) 오류만 확인해서는 부족하다. 공격자가 여러 번의 시도 끝에 성공했다면 HTTP 200 또는 302 응답이 기록되며, 이때부터 본격적인 내부 침투가 시작되기 때문이다.
로그 분석 시 확인해야 할 핵심 포인트는 다음과 같다.
- HTTP POST 요청 분석:
/ecp/default.aspx경로로 들어오는 POST 요청 중__VIEWSTATE매개변수 길이가 일반적인 범위를 크게 벗어나는지 확인한다. - 매개변수 무결성 검사:
__VIEWSTATEGENERATOR값이 평소와 다르거나, 알려진 공격 도구의 기본 설정값이 포함되어 있는지 대조한다. - 프로세스 트리 추적: HTTP 200 응답 시점을 기준으로
w3wp.exe(IIS Worker Process)의 자식 프로세스에서cmd.exe,1또는powershell.exe`가 실행되었는지 확인한다. 이는 전형적인 RCE 성공// la la single//-지표다. - User-Agent 패턴 분석: 요청 헤더의 User-Agent가 누락되었거나 Python-requests, curl 등 스크립트 기반 도구의 흔적이 있는지 검토한다.
패치 불가능한 상황에서의 즉각적인 완화 조치
운영 환경 제약으로 즉시 보안 업데이트를 적용하기 어렵다면, 공격 경로를 차단하는 임시 조치를 시행해야 한다. 네트워크 레벨에서 ECP 경로 접근을 엄격히 제한하는 방법이 가장 효과적이다.
- 외부 접근 차단: 방화벽(Firewall)이나 웹 애플리케이션 방화벽(WAF)으로 외부 인터넷에서
/ecp경로로 직접 접근하는 것을 완전히 막는다. - 접근 제어 리스트(ACL) 적용: 관리자 전용 IP 주소만 ECP에 접근할 수 있도록 화이트리스트 기반 ACL을 설정한다.
- VPN 및 제로 트러스트 도입: ECP 접근 시 반드시 VPN을 거치거나 인증된 사용자만 접근 가능한 VPNless 솔루션을 사용하도록 강제한다.
- 실시간 모니터링 강화: YARA 룰이나 Snort 룰을 적용해 ViewState 조작 패턴이 single same l same-origin 정책 위반이나 비정상적인 직렬화 문자열을 실시간으로 탐지하고 알람을 설정한다.
- 최소 권한 원칙 적용: Exchange 서비스 계정의 권한을 최소화한다. RCE가 발생하더라도 공격자가 시스템 전체 권한을 얻거나 다른 서버로 횡적 이동(Lateral Movement) 하는 것을 방지하기 위함이다.
CVE-2020-0688은 오래된 취약점이지만, 관리되지 않는 레거시 서버를 통해 여전히 피해를 입히고 있다. 2020년 2월 11일 배포된 누적 업데이트를 적용하는 것이 근본적인 해결책이며, 패치 후에도 웹 쉘 설치 여부 같은 사후 침해 지표를 전수 조사해야 한다. 인프라 관리자는 정기적인 패치 관리 프로세스를 수립하고 로그 분석 기반의 탐지 체계를 구축해 유사한 RCE 공격에 대비해야 한다.