사고 & 취약점
Equifax 유출 사고(2017) — 패치되지 않은 Apache Struts 결함이 1억 4,700만 명을 유출시킨 경위
2017년 Equifax에서 약 1억 4,700만 명의 데이터가 유출되었습니다. 원인은 이미 패치까지 나와 있던 알려진 Apache Struts 결함(CVE-2017-5638 / CVSS 10.0)을 공개 시스템에 적용하지 않은 것, 그리고 만료된 모니터링 인증서가 76일간 유출을 가린 것입니다. 자산 인벤토리, 패치 SLA, 머신 모니터링이 대책입니다.
저희는 실제 공개 사고를 단순한 뉴스 재방송이 아니라 "이것을 어떻게 방어할 것인가"의 관점으로 읽습니다. 이 글은 공개 기록(규제 기관, 공식 발표, Apache Software Foundation, 보도)에 근거하며, 출처는 글 끝에 명시합니다.
- 대상
- Equifax(미국 주요 신용평가 기관)
- 공개
- 2017년 9월 7일(5~7월 침입 / 7월 29일 탐지)
- 분류
- 미적용 알려진 CVE(Apache Struts RCE)를 통한 침입 + 유출
- 규모
- 미국 약 1억 4,700만 명(이름, SSN, 생년월일, 주소. 일부 카드번호)
- 근본 원인
- 방치된 알려진 CVE + 자산 인벤토리 부재 + 탐지 공백(만료된 인증서)
- 진짜 대책
- 패치 SLA, 자산 인벤토리, 머신 모니터링, 건강한 탐지
무슨 일이 있었나(쉽게 풀이)
Equifax는 소비자가 자신의 신용 정보에 대해 이의를 제기하는 온라인 포털을 운영하고 있었습니다. 그 기반의 Apache Struts 구성 요소에는 외부에서 임의 코드 실행을 허용하는 심각한 결함이 있었습니다(CVE-2017-5638).
수정 패치는 결함이 공개된 바로 그날(2017년 3월 7일) 배포되었습니다. 그러나 대상 시스템은 패치되지 않은 채 방치되었습니다. 두 달 뒤 공격자는 그 알려진 구멍을 악용해 네트워크를 가로질러 측면 이동하고 개인 데이터를 대규모로 유출했습니다.
설상가상으로, 트래픽을 감시하던 장비가 만료된 인증서 때문에 오랫동안 멈춰 있어, 비정상적인 유출이 76일간 탐지되지 않았습니다. 7월 29일 인증서가 갱신된 순간 수상한 트래픽이 드러났습니다 — 알아채는 장치가 꺼져 있었던 것입니다.
'어려운 공격'이 아니라 '적용하지 않음'
여기서 악용된 구멍은 전 세계에 공개되어 있었고 이미 패치까지 나와 있었습니다. 피해를 일으킨 것은 공격의 정교함이 아니라 알려진 위험을 기한 내에 닫는 운영의 부재였습니다. 이 일은 1인 개발자에게도 조직에게도 똑같은 방식으로 일어납니다.
사슬은 곧 방어 지도다
중요한 것은 이것이 5단계 사슬이었고 각 단계마다 멈출 수 있는 지점이 있었다는 점입니다. 공격 레시피가 아니라 "어디서 끊을 수 있었는가"로 읽어 주십시오.
① 알려진 CVE가 공개됨(같은 날 수정 패치 배포)
⊘ 멈춤: 자신에게 해당되는 CVE를 기계로 탐지
② 공개 시스템이 미패치 상태로 방치됨
Struts가 어디서 동작하는지 파악하지 못해 그물망을 빠져나감.
⊘ 멈춤: 자산 인벤토리 + 패치 SLA(기한)
③ RCE를 통한 침입
미적용 구멍을 통한 임의 코드 실행.
⊘ 멈춤: 최소 권한. WAF는 보조 수단으로만
④ 평탄한 네트워크에서의 측면 이동, 대량 유출
취약한 분리가 하나의 침입을 광범위한 데이터로 닿게 함.
⊘ 멈춤: 네트워크 분리로 폭발 반경 축소
⑤ 76일간 미탐지(만료된 모니터링 인증서)
알아채는 장치가 꺼져 있었다.
⊘ 멈춤: 정기적인 인증서/모니터링 건강 점검
공개된 타임라인
2017-03-07
CVE-2017-5638이 공개되고 같은 날 수정 패치가 배포됨.2017-03–
사내 권고가 나갔지만 대상 시스템은 미패치 상태로 유지됨.2017-05–07
공격자가 미적용 구멍을 악용해 데이터를 유출함.2017-07-29
모니터링 인증서가 갱신된 직후 수상한 트래픽이 탐지됨.2017-09-07
공개 발표. 약 1억 4,700만 명이 영향을 받음.2019-07
FTC, CFPB, 주 정부와 최대 약 7억 달러 규모의 합의(동종 사건 최대 규모).
근본 원인은 하나의 '적용하지 않음'이 아니다
"패치를 잊었다"로 끝내면 반복됩니다. 실제로는 여러 계층이 순서대로 무너졌습니다.
당시의 상태
- 알려진 CVE 방치(수정 패치가 있었으나 공개 시스템에 미적용)
- 자산 인벤토리 부재(구성 요소가 어디서 동작하는지 파악 불가)
- 평탄한 네트워크(측면 이동과 데이터 확산 허용)
- 탐지 공백(만료된 인증서로 모니터링 멈춤)
마땅히 그래야 할 상태(예방)
- 패치 SLA: 공개부터 적용까지의 기한, KEV / 높은 CVSS 우선
- 자산 인벤토리: 의존성과 그 동작 위치를 기계로 추적
- 네트워크 분리: 침입의 폭발 반경 축소
- 건강한 탐지: 인증서와 모니터링이 살아 있는지 정기적으로 확인
'패치'는 일회성이 아니라 운영이다
핵심은 "언젠가 고친다"가 아니라 기한(SLA)을 두는 것입니다: 공개 후 N시간/일 이내에 적용. 그리고 대상을 놓치지 않으려면 무엇이 어디서 동작하는지를 기계가 알아야 합니다. 기억에 의존하면 Equifax처럼 "딱 한 대"가 남겨집니다.
여러분의 환경에서 막는 법
규모에 상관없이 작동하는, 우선순위 순서의 대책입니다. 하나의 원칙에 닻을 둡니다: 공개된 CVE를 방치하지 말 것.
자산 인벤토리를 유지한다(무엇이 어디서 동작하는가)
의존 라이브러리와 그것을 실행하는 서비스/컨테이너를 목록화하십시오. Equifax의 가장 큰 실수는 대상을 놓친 것이었습니다. 실제로 동작 중인 버전으로 판단하십시오.
패치 SLA를 정한다(공개부터 적용까지의 기한)
"치명적 CVE는 공개 후 N일 이내에 적용"을 미리 정하십시오. KEV(실제 악용 중)와 높은 CVSS를 우선하십시오. 기한이 있어야 "방치"가 눈에 보입니다.
기계가 모니터링하게 한다(손으로 쫓지 않기)
CVE를 수동으로 쫓는 것은 불가능합니다. Dependabot(GitHub)이나 osv-scanner로 락파일을 점검하고, 자신에게 해당되는 CVE만 자동 통지받으십시오. 의존성 모니터링을 구축하는 법을 참고하십시오.
격리와 탐지를 둔다(피해 이후의 보험)
네트워크를 분리해 측면 이동을 제한하고 비정상 대량 유출을 탐지하십시오. '모니터링과 인증서가 살아 있는가'를 운영에 포함하십시오 — 꺼진 경보는 경보가 아닙니다.
본 사이트는 이를 스스로 실천한다
본 사이트는 여기 쓴 그대로 자신의 의존성을 CVE 모니터링 아래 둡니다. Equifax의 교훈 — 사람이 잊을 수 없는 프로세스로 알려진 구멍을 닫는다 — 은 이 제품의 신념입니다. "언젠가 고친다"를 "기한 내에, 기계의 도움으로 고친다"로 바꾸십시오.
출처(공개 기록)
여기 담긴 사실은 다음 공개 정보에 근거하며, 방어적 교훈에 초점을 둡니다. 재현 절차나 페이로드는 다루지 않습니다.
- Apache Software Foundation, "Media Alert: Equifax Data Breach Due to Failure to Install Patches" (2017) — news.apache.org
- Equifax, "Releases Details on Cybersecurity Incident" (2017) — investor.equifax.com
- CFPB/FTC/주 정부 합의 발표 (2019) — consumerfinance.gov
- CSO Online, "Equifax data breach FAQ" — csoonline.com
이어서 읽기
- 용어: CVE란 무엇인가 · CVSS란 무엇인가 · RCE란 무엇인가
- 방어: 의존성을 기계로 모니터링하기(패치 운영)
- 사고: Capital One — SSRF가 1억 건 이상 유출
FAQ
QEquifax 유출 사고의 근본 원인은 무엇이었나요?
새롭고 정교한 공격이 아니라, '이미 패치까지 나와 있던 알려진 취약점(Apache Struts CVE-2017-5638 / CVSS 10.0)을 공개 시스템에 적용하지 않은 것'입니다. 게다가 해당 구성 요소가 어디서 동작하는지 파악하지 못했고, 만료된 인증서로 모니터링 장비가 멈춰 있어 유출을 76일간 알아채지 못했습니다.
Q패치가 존재했는데 왜 적용하지 않았나요?
공개 기록에 따르면 결함이 공개된 바로 그날(2017년 3월 7일) 수정 패치가 배포되었습니다. 사내 권고도 나갔지만, 대상이었던 온라인 분쟁 시스템에는 패치가 적용되지 않았습니다. '이 구성 요소가 어디서 동작하는가'에 대한 자산 인벤토리가 미흡해 누락된 것입니다.
Q소규모 프로젝트에도 교훈이 있나요?
그렇습니다. 규모와 관계없이 같은 세 가지가 적용됩니다. 알려진 CVE를 방치하지 말 것, 그 구성 요소가 여러분의 의존성에 있는지 알 것, 그리고 누락이 없도록 기계가 모니터링하게 할 것. CVE를 손으로 쫓는 것은 불가능합니다. Dependabot이나 osv-scanner가 감시하게 하십시오.