[260130] [Theori] 2025 하반기 Hot🔥보안 사건 사고

2025 하반기 Hot🔥보안 사건 사고 - Theori 블로그

2025 하반기 Hot🔥보안 사건 사고 - Theori 블로그

 

1. Phrack Report: "APT Down - The North Korea Files"

2025년 8월 8일 국제 해커 매거진에 Phrack 72호에 APT Down-The North Korea Files 라는 제목의 기술 보고서가 공개됨. 'Saber', 'cyb0rg' 라는 활동명을 사용하는 해커가 게재한 해당 보고서는 대한민국의 공공.민간 영역을 대상으로 한 공격을 다룸, 공개 직후 보안 업계에 큰 파장을 일으킴.

 

해당 데이터에는 대한민국 정부 전자문서시스템 및 통신사 인프라와 연관된 것으로 보이는 자료 포함됨, 이는 대한민국 공공 시스템에 대한 장기간의 무단 접근 및 자료 열람 공격이 발생했다는 추측을 가능하게 함.

 

해당 정황은 정부 발표의 따라 사실로 확인됨. 국가정보원은 2025년 10월 17일 공개 발표를 통해 외부 해커가 6개의 인증서와 6개의 국내외 IP를 이용해 범정부 업무시스템인 온나라 시스템에 접속했다고 밝혔음. 또한, 해커들이 2022년 9월부터 2025년 7월까지 정부 원격접속시스템(G-VPN)을 통과하여 온나라시스템에서 자료를 열람한 사실을 확인하였다고 덧붙임.

행정안전부에 따르면 650명분의 공무원 인증서 파일 유출이 확인되었고, 이 중 12건은 GPKI 키와 비밀번호가 함께 포함된 사례였음. 다만, 대부분은 이미 유효기간이 만료된 인증서였고, 유효기간이 만료되지 않은 3명의 인증서에 대해서도 2025년 8월 13일 폐기 조치가 이루어졌음

 

국가정보원은 사건 설명 과정에서 원격접속 인증 체계의 미흡, 온나라시스템의 인증 로직 노출 가능성, 일부 부처 전용 서버에 대한 접근통제 미비 등 구조적 취약점을 언급하며 재발 방지의 필요성을 강조하였다. 특히 G-VPN을 통한 원격접속 이후 온나라시스템 접근 과정에서 추가적인 인증.행위 검증이 충분히 이루어지지 않았다는 점은, 장기간에 걸친 자료 열람이 가능했던 배경으로 분석됨.

 

이번 사건 핵심 요소

• 공무원 인증서(GPKI) 유출 및 재사용 가능성
• G-VPN을 경유한 원격접속 환경에서의 인증 단계 단순화
• 온나라시스템 인증 로직 및 접근 제어 구조의 노출
• 장기간(약 3년)에 걸친 비인가 자료 열람 탐지 실해

사건 인지 이후 대응 과정에서 비교적 신속한 기술적 조치가 병행되었다는 점은 긍정적 측면임.

• 행정안전부는, 온나라시스템 로그인 정보 재사용 차단 조치를 중앙부처 및 지방자치단체에 적용
• G-VPN 접속 시 GPKI 인증에 대한 전화 기반 2차 인증(ARS)를 의무화
• 국가정보원은, 악용된 IP 정보를 전 국가. 공공기관에 전파하여 차단 조치를 적용, 일부 부처의 전용 시스템 공격 여부도 추가로 확인하여 조사중

2. NPM Supply Chain Attack

Javascript와 Node.js 생태계 중심인 npm(Node Package Manager) 레지스트리는 2025년 기준 수백만 개의 패키지를 보유, 주간 다운로드 수가 수십억 건에 달하는 세계 최대 소프트웨어 저장소로 자리잡고 있음. 그러나, 이러한 방대한 연결성이 역설적으로 공격자에게 큰 규모의 공격 표면을 제공. 2025년 9월은 npm에서 심각도 높은 공급망 보안 사고들이 발생한 시기임. 이 시기 발생한 사건들은 오픈 소스 생태계의 암묵적 신뢰(Implicit Trust) 모델의 취약성을 보여줌.

 

[npm 패키지 연쇄 침해]

2025년 9월 8일, 전 세계적으로 널리 사용되는 다양한 npm 패키지에 악성 코드가 주입되는 사건이 발생. 패키지 메인테이너를 노린 피싱 공격에 의해 발생했다는 특징을 가짐.

 

qix라는 ID를 사용하는 메인테이너는 npm 지원팀(support@npmjs.help)을 사칭한 이메일을 수신함. 해당 이메일은 메인테이너의 2단계 인증 자격증명을 업데이트해야 한다는 명목으로 가짜 로그인 페이지 접속을 유도함. 공격자는 이와 같은 전형적인 중간자 공격(AiTM, Adversary-in-the-Middle) 기법을 통해, 실시간으로 메인테이너가 입력한 ID, 비밀번호, OTP(One-Time Password) 코드를 가로채어 실제 npm 세션을 탈취하는데 성공함.

 

공격자는 탈취한 세션을 통해 18개의 핵심 패키지에 대한 쓰기 권한을 획득함. 이들은 npm 생태계의 기초적인 역할을 하는 라이브러리로, 직접적으로 사용될 뿐만 아니라 수만 개의 다른 프로젝트에서 의존성으로 사용하고 있어 연쇄적 파급 효과를 낳았음.

 

해당 패키지들의 주간 다운로드 수 합계는 약 26억건에 달함 이는 npm 생테계 전체 트래픽의 상당 부분을 차지. 결과적으로, 공격자는 이와 같이 널리 사용되는 패키지를 감염시킴으로써, 별도의 해킹 과정 없이도 손쉽게 전 세계 수백만 대의 개발자 PC, CI/CD 서버, 이용자의 브라우저 환경에서 악성 코드를 주입할 수 있었음. 

 

[패키지 악성 코드 분석]

공격의 기술적 특징 중 가장 주목할 부분은 악성 코드의 동작 환경과 목표임. 서버 측 셸 권한을 획득하거나 랜섬웨어를 배포하는 전통적인 공격 방식과 달리, 이번 공격에서는 브라우저 환경에서 실행되며 암호화폐 지갑을 탈취하도록 설계된 Crypto Wallet Drainer 페이로드가 사용되었음. 해당 악성코드는 난독화된 Javascript 형태로 배포되었으며, 웹 애플리케이션의 번들에 포함된 상태로 전달되어 최종 이용자의 브라우저에서 실행될 때 활성화되도록 설계되었음.

 

1. 네트워크 API 후킹: 브라우저 API 중 하나인 window.fetch와 XMLHttpRequest.prototype.send를 오버라이딩하여, 발생하는 모든 비동기 웹 요청을 가로채고 감시할 수 있는 권한을 확보함

2. 트랜잭션 데이터 스캔: 이용자가 암호화폐 지갑을 이용해 트랜잭션을 시도할 때, 악성 코드는 해당 트랜잭션의 본분(Payload)를 검사함.이때, 이더리움이나 비트코인과 같은 주요 블록체인의 주소 패턴과 일치하는 문자열을 확인함.

3. 정규표현식과 패턴 매칭: 다양한 암호화폐 주소 탐색을 위해 정교한 정규표현식을 사용함. 또한, 단순한 주소 탐색 외에도 rpc, api, wallet 등의 키워드가 포함된 요청을 타겟팅하여 탐지 확률을 낮췄음

 

해당 악성 코드는 매우 교묘한 방식으로 트랜잭션 목적지 주소를 변조함.

목적지 주소를 단순히 공격자의 주소로 설정할 경우, 이용자는 육안으로 해당 변화를 인지할 수 있음.

이번 공격에서는 이를 회피하기 위해, 사전에 대량의 공격자 지갑 주소를 생성하고 해당 주소의 풀에 Levenshtein 거리(편집 거리) 알고리즘을 사용하여 문자열 간 차이가 최소화되는 주소를 탐색했음. 

이를 통해 피해자의 기존 목적지 수와 시각적으로 가장 유사한 주소를 실시간으로 선택함으로써, 이용자가 트랜잭션 승인 창에서 유사한 공격자의 주소를 확인하고 정상적인 거래로 오인하여 서명을 진행하도록 유도했음. 서명이 진행되면, 이용자의 자산은 공격자의 지갑으로 전송됨

 

추가로, 악성코드는 이용자가 트랜잭션에 서명하기 직전 데이터 자체를 변조하는 기능을 수행함. 이더리움이나 솔라나와 같은 네트워크 환경에서는 단순한 주소 변경 동작 외에도, approve 함수 호출 과정에서 승인 권한을 조작함으로써 공격자가 피해자 지갑의 자금에 지속적으로 접근할 수 있도록 백도어를 설치하는 행위가 확인됨. 이는 일회성 자산 탈취를 넘어, 장기적인 자금 탈취가 가능한 구조를 형성한다는 점에서 위험도가 높음.

 

[Shai-Hulud 웜과 자동화된 전파]

2025년 9월 15일, 개발자 환경을 공격하는 Shai-Hulud 웜이 등장함. 해당 웜은 시스템 자동화 역으로 이용하여 스스로 전파되는 방법을 채택함. npm 생태계에서 자가복제에 성공한 최초의 공급망 형 웜 공격 사례로 평가됨.

 

핵심 목표는, 개발자의 로컬 개발 환경과 CI/CD 파이프라인을 감염시킨 후, 해당 개발자가 유지보수하는 다른 npm 패키지로 감염을 확산하는 것임. 이를 통해 공격자는 개별 패키지를 하나씩 침해하지 않고, 단일 개발자 계정을 기점으로 대규모 확산을 유도할 수 있음

 

(웜의 동작 과정)

1. 초기침투: 웜은 감염된 패키지의 postinstall 혹은 preinstall 스크립트를 통해 실행. 해당 스크립트는 사용자가 npm install 명령을 실행할 때 별도의 확인 절차 없이 실행됨

2. 자격 증명 스캐닝: 실행된 웜은 환경 변수(env) 및 홈 디렉터리 설정을 스캔하여, 크리덴셜(ex. NPM_TOKEN, GITHUB_TOKEN, 클라우드 서비스의 API 키)을 수집함.

3. 자가 복제 및 배포: 유효한 NPM_TOKEN을 발견하면, 웜은 해당 토큰의 권한을 확인함. 패키지 배포 권한이 있는 경우, 해당 사용자가 메인테이너로 있는 다른 패키지 목록을 조회함. 이후, 해당 패키지에 악성 코드를 주입하고 버전을 수정하여 레지스트리에 배포함으로써 감염을 확산함.

 

특히 Github Actions와 같은 CI/CD 환경을 주요 공격 대상으로 삼음. CI/CD 환경은 배포 자동화를 위해 높은 권한의 API키와 시크릿을 환경 변수로 설정하는 경우가 많음. 웜은 이를 탈취하여 공격자 제어 서버로 전송하고, 공격된 저장소에 악성 워크플로우 파일을 생성하여 지속성을 학보했음. 이로 인해, 개발자가 로컬에서 악성 패키지를 삭제하더라도, 원격 저장소의 워크플로우가 다시 악성 코드를 실행하거나 시크릿을 유출하는 구조가 형성됨.

 

2025년 11월, 변종 Shai-Hulud 2.0은 더욱 공격적인 성향을 보였음.

• 해당 웜은 C2 서버와 통신할 수 없거나 특정 조건에서 실행이 차단될 경우, 감염된 시스템의 홈 디렉터리나 주요 파일 시스템을 삭제(rm -rf ~/*) 하도록 설계됨
• 단순한 정보 탈취를 넘어, 개발자의 작업물을 파괴하거나 빌드 서버를 마비시키는 가용성 침해(DoS) 공격으로 발전할 수 있음

공급망 공격이 데이터 탈취를 넘어 랜섬웨어와 유사한 파괴적 공격으로 진화할 수 있음을 보여준 사례임

 

더 이상 오픈 소스 생태계에서 암묵적 신뢰를 유지하기는 어려움. qix 계정 탈취 사건은 2FA와 같은 기술적인 보호조치가 인간의 심리를 파고드는 사회공학적 공격(AiTM) 앞에서 무력화될 수 있음을 보여줌. 개발 편의를 위해 구축된 CI/CD 파이프라인이 치명적인 공격 경로가 될 수 있음을 드러냄. 공격자는 이제 표면적인 서버의 방화벽을 뚫으려 노력하기보다, 수십억 건의 다운로드가 이루어지는 신뢰된 패키지 뒤에 숨어 개발자의 로컬 환경, 이용자의 브라우저, 기업의 빌드 서버를 겨냥함.

 

npm은 그 영향력을 쉽게 대체할 수 없는 현대 웹 개발의 핵심 인프라임. 우리가 사용하는 코드가 우리가 작성한 코드보다 위험할 수 있다는 사실을 인식하지 않는다면, 공급망 공격은 반복될 수밖에 없음. 편리함 뒤에 숨겨진 연결성의 위험을 끊임없이 검증하는 자세만이 오픈 소스 생태계에서 공급망 공격에 대응할 수 있는 실질적인 방어책이 될 것.

 

3. Personal Credit Data Leakage at Lotte Card

2025년 9월 18일, 롯데카드는 해킹에 의한 대규모 데이터 유출 사고를 공식 발표, 유출 데이터에는 고객의 기본적인 개인정보를 포함하여 온라인 결제 정보, CI(온라인상 고유식별번호), 비밀번호, 카드번호, CVC 등 유출 시 2차 피해를 야기할 수 있는 민감한 정보가 다량 포함됨

 

• 2025 8월 26일, 일부 서버가 악성 코드에 감염된 사실을 확인하고 자체적으로 전사서버에 대한 정밀 조사를 진행
• 조사 결과, 3개의 서버에서 2종의 악성 코드와 5종의 웹셸이 발견됨
• 8월 31일, 온라인 결제 서버에서 외부 공격자의 데이터 유출 시도를 확인함.
• 9월 1일, 약 1.7GB 규모의 데이터가 유출되었다는 내용으로 금융당국에 해킹 피해 사실을 신고함.
• 금융당국은 정확한 해킹 원인 및 피해 규모를 확인하기 위해 조사 착수
• 이 과정에서 실제 유출된 데이터 규모가 약 200GB에 달하고, 공격자가 CVE-2017-10271 취약점을 악용하여 서버에 침투했다는 사실을 확인함.

[CVE-2017-10271]

Oracle WebLogic Server에서 원격으로 코드를 실행할 수 있는 취약점. 공격자는 해당 취약점을 이용하여 특수하게 조작된 XML 데이터를 전송하는 것으로 별도의 인증이나 권한없이 서버를 완전히 장악할 수 있었음.

 

취약점의 근본 원인은 Java의 XMLDecoder 클래스에 있음.

 

• XML 스크립트(XML 형식으로 표현된 객체와 메서드 호출)를 실제로 구성하는 인터프리터 역할을 수행
• 따라서 신뢰할 수 없는 데이터를 해당 클래스로 파싱할 경우, 역직렬화 취약점이 발생하여 원격 코드 실행으로 이어질 수 있음.
• 10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0 버전의 Oracle WebLogic Server는 특정 엔드포인트(ex. /wls-wsat/CoordinatorPortType)에서 전달받은 XML 데이터를 XMLDecoder로 그대로 파싱하도록 설계되어 있어, 조작된 XML 요청을 전송하여 서버를 장악할 수 있는 취약점 발생함.

 

사고의 근본 원인은 하나의 취약점으로 한정하기는 어려움. 패치 거버넌스 미흡, 자산 식별 부족, 침입탐지체계의 한계 등이 복합적으로 작용하여 해당 사태가 발생했다고 보는 것이 적절함. 만약 서버가 보안 패치를 하여 CVE-2017-10271 에 취약하지 않더라도, 다른 서버를 통한 침투가 가능했다면 유사한 데이터 유출 시나리오가 재현될 수 있음.

 

이러한 이유로, 이 사례는 취약점 패치 그 자체보다는 운영 현실에 기반한 보안 관리가 중요하다는 메세지를 전달함. 

인터넷에 노출된 WAS에서 패치가 누락된 서버가 하나라도 남아 있으면, 그 지점은 전체 인스턴스의 공격 표면이자 데이터 유출의 시발점이 될 수 있음. 처음 침투한 서버가 핵심 시스템이 아니더라도, 내부 시스템 간 연결 구조를 따라 침투 범위를 확장할 경우 공격자는 매우 높은 확률로 민감 정보가 저장된 서버에 접근 가능.

 

[해당 사태 원인]

1. 보안 패치 누락

2. 인스턴스의 아웃바운드 트래픽 통제 미흡

3. 침입 탐지 및 자산 식별 미흡

 

실질적인 방어 체계를 구축하기 위해서는 각 기능의 이유와 목적, 환경과 위험을 정확히 이해하고 필요한 지점을 적절하게 리소스를 배분해야 함.

 

4. RediShell

2025년 10월 6일, 전 세계 인프라 환경에서 광범위하게 사용되는 Redis(Remote Dictionary Server)의 치명적인 보안 취약점이 Wiz에 의해 공개됨. RediShell로 명명된 CVE-2025-49844는 Redis에 내장된 Lua 스크립트 엔진에서 발생하는 Use-After-Free(UAF) 기반 메모리 손상 취약점임. 해당 취약점은 CVSS v3.1 기준 10.0점(Critical)을 기록하였으며, 악용 시 인증된 공격자가 Lua 샌드박스를 탈출하여 호스트 시스템에서 임의 코드를 실행(RCE)할 수 있는 것으로 알려짐.

 

[CVE-2025-49844]

Wiz Research 팀에 의해 발견.

2025년 5월 16일 Pwn20wn 베를린에서 보고됨, 해당 취약점은 Redis가 사용하는 Lua 5.1 인터프리터의 구현 결함에서 비롯된 것으로, Lua 스크립트를 해석하고 실행하는 과정에서 특정 메모리 객체의 생성과 해제 시점(생명주기)이 잘못 관리되어 발생함.

 

취약점의 핵심은 UAF.

UAF는 프로그램이 이미 해제된 메모리를 여전히 유효한 것으로 간주하고 메모리 주소를 가리키는 포인터를 사용하여 접근할 대 발생하는 취약점으로, 일반적으로 메모리 손상 및 제어 흐름 탈취로 이어질 수 있음.

 

RediShell의 경우, Lua 스크립트 실행 중 가비지 컬렉터(Garbage Collection, GC)의 동작 시점을 공격자가 조작하여 사용 중인 객체를 강제로 해제하면 발생함.

 

[공격 진행 단계]

1. 스크립트 주입: 인증된 공격자가 EVAL 명령어를 통해 악성 Lua 스크립트를 Redis에 전송함.

2. 힙 그루밍: Lua 스크립트 내에서 메모리 레이아웃을 조작하기 위해 다수의 객체를 할당하고 해제하는 과정을 수행함.(해당 과정은 UAF 발생 시 해제된 메모리 영역을 공격자가 원하는 데이터로 덮어쓰기 위한 단계)

3. GC 조작 및 UAF 유발: 공격자는 luaY_parser의 버그를 이용하여 메모리 참조 오류를 유발함. 스크립트를 통해 Lua의 파서가 특정 문자열이나 객체 처리 중, 강제로 GC가 동작하도록 함. 이때 Redis의 Lua 구현체제에 존재하는 결함으로 인해, 파서가 여전히 참조하고 있는 객체가 더 이상 사용되지 않는 객체로 오인되어 메모리에서 해제됨.

4. 메모리 오염(Memory Corruption): 해제된 메모리 공간(TString 메모리 공간)에 공격자의 데이터가 재할당되면, 파서는 해제된 이전 객체의 포인터를 사용하여 해당 데이터에 접근함. 이렇게 공격자의 데이터를 참조하여, 내부 데이터 구조가 손상되는 메모리 오염이 발생함.

5. 샌드박스 탈출: 내부 데이터 구조 손상을 바탕으로 공격자는 Lua 샌드박스 제약을 우회함. 차단된 함수에 접근하거나, 메모리 주소를 직접 조작하여 기계어 코드를 실행하고 샌드박스를 탈출할 수 있음.

6. 호스트 장악: 샌드박스를 탈출한 공격자는 Redis 프로세스 권한으로 호스트 운영체제에서 명령어를 수행할 수 있음.

 

해당 패치는 Lua 파서(lparser.c) 내 luaY_parser 함수에서 문자열 객체의 생명주기를 GC를 통해 관리하는 대신, 명시적으로 관리하도록 변경함.

 

• 기존 코드에서는 luaS_new(L,name) 호출로 생성된 문자열 객체가 스택에 고정되지 않은 상태로 luaX_setinput 함수에 전달됨.
• 이때 luaX_setinput 내부 또는 하위 호출에서 GC가 동작한다면,
• luaS_new로 생성된 문자열은 도달 불가능한 객체로 간주되어 해제될 수 있음
• 수정된 코드에서는 luaS_new 함수로 생성된 문자열을 luaX_setinput 함수 호출 전에 명시적으로 Lua 스택에 푸시함.
• 이로 인해 GC가 동작하더라도 해당 객체는 스택에 의해 참조되고 있는 상태로 유지되어 해제되지 않음.

RediShell 취약점의 파급력은 Redis 사용량에 비례함. 현재도 약 60,000여개의 Redis 인스턴스가 별도 인증 없이 인터넷에 노출되어 있으며, 공격자는 추가적인 자격증명 탈취 과정 없이 인스턴스에 접속하여 EVAL 명령만으로 원격 코드 실행을 할 수 있음. 

 

오픈소스 생태계와 인프라 보안에 중요한 시사점을 남겼음. 먼저, Lua 샌드박스와 같은 격리 메커니즘이 존재하더라도, 인터피리터 자체의 메모리 관리 결함이 있다면 샌드박스가 무력화될 수 있다는 한계를 보여줌. 또한, 해당 취약점 코드가 13년동안이나 발견되지 않고 존재했다는 점은, 오래된 코드가 안전한 코드라는 일반적인 통념을 깨뜨림.

이번 사례는 널리 사용되는 성숙한 프로젝트일지라도, 코드 검수와 퍼징 테스트가 지속적으로 이루어질 필요가 있음을 보여줌

 

5. Internal Data Breach at SK Shieldus

2025년 10월 17일, 해커조직이 다크웹을 통해 국내 대표 통합 보안 기업인 SK 쉴더스의 내부 데이터를 탈취했다고 주장함.

다크웹 게시글을 통해 약 24GB 규모의 내부 문서와 기술 자료를 확보했다고 밝힘. 게시글을 통해 정보를 단순히 공개하는 것에 그치지 않고, 정보 유출 위험을 무기로 기업을 압박하는 데이터 기반 협박(extortion) 방식으로 볼 수 있음.

 

유출 사건 공론화 이루 초기 대응과정에서, 해당 데이터가 실제 운영망이 아닌 허니팟 환경에서 유출된 것이라고 밝혔음. 

허니팟: 공격자의 공격 기법을 분석하기 위해 의도적으로 공격자를 유인하는 시스템으로, 초기 주장에 따르면 유출된 정보는 허니팟 공간에 존재하는 미끼 정보이므로 실제 고객 시스템 및 핵심 운영망의 침해는 발생하지 않은 것임.

 

하지만 확인 결과, 유출된 상당수가 단순한 더미 데이터가 아닌 실제 프로젝트 수행 과정에서 사용된 PoC 자료, 네트워크 설계도, 내부 운영 문서로 밝혀졌음. 실제 임직원의 개인정보가 포함되어 있었다는 점에서 유출된 자료를 단순한 미끼 정보로 보기 어렵다는 지적이 있었음.

 

추가조사 결과, 허니팟에 연결된 직원의 개인 이메일 계정을 통해 일부 업무 자료가 외부로 유출된 정황이 확인됨. 해당 상황에 대해 허니팟 구축용 가상머신에서 사용하는 크롬 브라우저에 실제 계정으로 자동 로그인이 되어 있어, 이메일 계정의 업무 관련 문서가 해커의 침투에 의해 유출될 것이라는 입장을 밝혔음. 이는 허니팟 환경이 실제 운영 정보와 충분히 분리되지 않았을 가능성을 시사함.

 

보안 연구를 목적으로 구성된 시스템이라 하더라도, 그 안에 실질적인 내부 정보나 고객 관련 정보가 포함되어 있다면, 공격자 관점에서는 그 자체로 가치있는 공격자산이 될 수 있음.

 

6. Cloudflare Outage

2025년 11월 12월, 전 세계 인터넷에 광범위한 영향을 미친 2차례의 대규모 서비스 장애가 발생함.

2개 사건의 원인은 모두 전 세계 CDN(콘텐츠 전송 네트워크) 및 보안 인프라 서비스를 제공하는 Cloudflare의 시스템 문제로 확인되었음

 

전세계 수많은 웹사이트의 트래픽이 통과하는 거대한 관문 역할을 함. 이용자가 웹사이트 접속을 시도하면, 해당 요청은 먼저 Cloudflare의 네트워크를 거치게 됨. 이 과정에서 Cloudflare는 HTTP/TLS 계층에서 연결을 수신하고, 핵심 프록시 시스템인 Frontline(FL) 을 통해 요청을 처리함.

 

이 프록시 시스템 내부에서는 아래와 같은 보안 기능이 모듈 형태로 동작

WAF(웹 방화벽): 악성 공격 차단

DDoS 방어 시스템: 대규모 트래픽 공격 방어

Bot Management: 머신러닝 기반 봇 트래픽 식별 및 관리

 

이들 모듈은 각 웹사이트에 설정된 규칙에 따라 트래픽을 검사한 후, 최종적으로 원본 서버로 요청을 전달하거나 캐시된 콘텐츠를 이용자에게 반환함.

 

[11월 18일 첫번째 장애]

Bot Management 시스템의 설정 파일 문제에서 시작되었음.

당시 엔지니어들은 데이터베이스 시스템의 보안 강화를 위해 권한 설정을 변경하는 작업을 진행하였고, 이 과정에서 예상치 못한 부작용이 발생함.

 

해당 시스템은 머신러닝을 기반으로 봇을 탐지하며, 이를 위해 Feature file 이라는 설정을 파일을 사용함. 해당 파일은 5분마다 데이터베이스 쿼리를 통해 자동으로 생성되어 전체 네트워크에 배포됨. 하지만 권한 변경 작업의 영향으로 데이터베이스 쿼리가 중복된 메타 데이터를 변환하게 되었고, 그 결과 동일한 설정 항목이 파일 내에 중복 생성되어 파일 크기가 2배이상 커졌음

 

이 결과, 시스템이 처리할 수 있는 피처의 최대 개수가 200개로 제한되어 있어 문제 발생. 평소에는 약 60개 수준의 피처만 사용하고 있었기에 이는 여유 있는 수치였지만, 중복 데이터로 인해 해당 제한을 초과하자 프록시 시스템 소프트웨어가 패닉 상태에 빠지며 중단되어 규모 장애로 이어짐.

 

[복구 작업]

1. 문제가 되는 피처 파일의 자동 생성 및 배포 중단

2. 이전에 정상 동작하던 구버전 파일을 네트워크 전체에 수동 재배포

3. 영향을 받은 프록시 시스템을 순차적으로 재시작하여 정상 파일 로드

 

[12월 5일 두번째 장애]

React 프레임워크 보안 취약점(CVE-2025-55182) 긴급 대응 과정에서 발생함. React Server Components 에서 발견된 취약점을 방어하기 위해, WAF가 검사하는 요청 본문의 최대 크기 제한을 기존 128KB에서 Next.js의 기본값인 1MB로 상향하는 작업을 진행했음.

 

해당 변경 사항을 배포하는 과정에서, 내부에서 사용하는 WAF 테스트 도구가 늘어난 버퍼 크기를 제대로 처리하지 못하는 문제가 발견되었음. 테스트 도구는 고객 트래픽에 영향을 주지 않는 내부 도구였기에 엔지니어들은 즉시 해당 도구를 비활성화함. 

그러나, 이 비활성화 조치가 수년간 코드 내부에 잠재되어 있던 버그를 촉발함.

-WAF 테스트 도구 규칙이 비활성화되며 분기로 인해 해당 규칙이 실행되지 않아, rule_result.execute 객체가 생성되지 않았음. 이 상태에서 코드는 존재하지 않는 객체(nil) 접근을 시도하였고, 이로 인해 nil 값 참조 오류(Attempt to index a nil value)가 발생했음.

 

이 오류로 인해 영향을 받은 서버들은 HTTP 500 오류를 반환하였으며, 다행이 Cloudflare 측에서 변경사항을 신속하게 롤백(원상복구) 하여, 장애 발생 약 25분만에 서비스는 정상화되었음.

 

현대 웹 생태계가 Cloudflare라는 하나의 플랫폼에 얼마나 깊이 의존하고 있는지 다시 한번 확인시켜주는 사례임. 아무리 규모가 크고 안정적인 서비스라도, 단일 실패 지점(SPOF)이 될 수 있기 때문에 서비스 안전성을 위해서는 만약의 상황에 대비한 인프라 다중화 및 의존성 분산이 필요함.

 

7. Personal Information Breach at Coupang

이번 사고는 외부 침입보다는 내부 시스템의 설계적 특성과 권한 관리의 이슈가 복합적으로 적용한 결과로 추정됨.

공격자는 해외 서버를 경유하여 장기간에 걸쳐 은밀하게 데이터를 조회한 것으로 파악됨. 중국 국적으로 추정되는 전직 직원이 퇴사 이후에도 회수되지 않은 API 접근 키와 인증 정보를 이용해 외부에서 무단 접속한 것으로 보고 있음.

 

1. 쿠팡의 내부 데이터베이스에서 이용자 식별값을 난수가 아닌, 1씩 증가하는 정수 형태로 설계되어 있었음. 해당 구조에서 공격자는 숫자를 순차적으로 대입해보는 것만으로도 대규모 데이터를 수집 가능.

2. 내부에서만 사용되어야 하는 API가 외부망에 노출되어 있었음. 해당 API는 순차적인 정수값을 매개로 인증 토큰을 발급하는 로직을 갖고 있었으며, 이로 인해 공격자는 복잡한 우회 기법 없이도 단순 반복 요청만으로 방대한 데이터를 조회 가능.

 

8. React2Shell

취약점은 React Server Components(RSC) Flight Protocol의 안전하지 않은 역직렬화로 인해 발생하며, 프로토타입 오염 공격에 의해 원격 코드 실행까지 이어질 수 있음.

특히, 공격자가 조작된 HTTP 요청을 보내는 것만으로 별도의 설정 없이 공격을 수행할 수 있어 위험도가 높음. React에 의존하는 프레임워크인 Next.js 역시 동일한 구조를 사용하고 있어 같은 취약점의 영향을 받음.

 

[React Server Components]

RSC가 등장하기 이전의 React 기반 애플리케이션은 JavaScript 번들 파일을 모두 클라이언트에게 전달한 후, 브라우저에 코드를 로딩하고 실행하는 구조였음. 해당 방식은 번들 크기에 따라 상당한 비용이 발생했음, 백엔드와 통신하기 위한 민감한 로직이 클라이언트 번들에 노출될 수 있다는 문제도 내포하고 있었음.

 

이러한 한계를 해결하기 위해 RSC 개념이 도입됨. RSC는 서버에서만 실행하는 React 컴포넌트를 생성하고, Flight Protocol을 통해 코드에 대한 노출 없이 서버의 실행 결과만을 클라이언트에 전달함. 

클라이언트가 서버 로직을 호출하는 주요 수단은 Server Action 이며, 클라이언트가 HTTP 요청을 전송하여 Server Action을 호출하면 서버는 요청 본문을 Flight Protocol 규칙에 따라 다시 파싱한 후 서버 함수를 실행함.

 

서버와 클라이언트의 실행 경계가 흐려진 현대 웹 아키텍처에서 입력 해석과 실행 흐름을 연결하는 과정의 중요성을 보여줌. 특히 서버 측에서 이용자의 입력을 구조적으로 재조립하고 이를 실행 흐름에 반영하는 구조에서는, 기본적인 검증 부재가 직접적인 코드 실행으로 이어질 수 있기에 더욱 주의할 필요가 있음.

 

마무리)

보안은 개별 기술의 문제가 아니라 연결된 구조 전체의 문제.

'지금의 시스템은 무엇을 신뢰하고 있는가', '신뢰는 어떤 조건에서 깨질 수 있는가', '그리고 그러한 상황에 대비해 어떤 구조와 기준을 준비해 두었는가' 라는 질문에 답하지 못한다면, 보안 사고는 언제든 반복될 수 있음.

 

소감: 해당 게시물을 리뷰하며, 2025년에 발생한 보안사고를 기술적으로 깊게 살펴볼 수 있었습니다. 특히, 쿠팡 보안 사고는 내부 직원분이 퇴사하고, API 키를 훔쳐 수행한 공격임을 알고 있는 정도로밖에 지식이 제한되어 있었는데, 해당 포스트를 통해, 단순히 공격자의 행위 뿐만 아니라, 데이터 식별자의 단순한 패턴과 API의 내부적으로 얼마나 잘 고착화되어있는지에 대한 감사가 정말 꾸준히 이루어져야 함을 인지하게 된 계기가 되었습니다. 보안은 시스템의 안전성을 살펴보는 것 뿐만이 아닌, 개발 과정에서도 Security 키워드를 잊지 않고, 융통성있게 살펴보아야 함을 더욱 간접적으로 느낄 수 있었습니다.