Mongo Bleed (CVE-2025-14847) 쉽게 이해하기

2026-01-21 penta_kr Insight

2025년 말, 글로벌 사이버 보안 커뮤니티를 뒤흔든 사건이 발생했습니다. 전 세계에서 가장 널리 사용되는 NoSQL 데이터베이스인 MongoDB에서 심각한 메모리 유출 취약점 ‘Mongo Bleed(CVE-2025-14847)‘가 발견된 것입니다.

이 사건은 2014년 세상을 공포에 떨게 했던 OpenSSL의 ‘Heartbleed‘ 사태를 떠올리게 합니다. 공격자가 서버에 특별히 조작된 패킷을 보내기만 하면, 서버가 가진 민감한 메모리 정보를 아무런 인증 없이 밖으로 ‘흘려보내는(Bleed)’ 특성이 매우 유사하기 때문입니다.

오늘날 대부분의 기업은 간단한 보안 정책만으로도 충분히 데이터를 보호할 수 있다고 믿습니다. 하지만 Mongo Bleed는 그 믿음을 근본적으로 무너뜨렸습니다.

Mongo Bleed에 대한 기술적 설명

발생 원리

공격자는 MongoDB 서버에 zlib으로 압축되었다고 주장하는 특수 패킷을 전송합니다. 이때 패킷 내부의 ‘압축 해제 후 예상 크기’를 실제보다 훨씬 크게 조작합니다. MongoDB 서버는 이 요청을 처리하는 과정에서 경계 검사를 제대로 수행하지 않고, 조작된 크기만큼의 메모리 영역을 응답 버퍼에 담아 공격자에게 되돌려줍니다.

유출 데이터

유출 대상은 서버의 힙(Heap) 메모리입니다. 힙 메모리는 프로그램이 실행되는 동안 동적으로 할당되는 공간으로, 여기에는 다음과 같은 ‘날것(Plaintext)’ 정보들이 포함되어 있습니다.

다른 사용자의 쿼리 요청 및 결과 데이터
데이터베이스 관리자 및 사용자의 세션 토큰
서버 설정 파일에 포함된 클라우드(AWS, Azure) 액세스 키

위험성

Mongo Bleed(CVE-2025-14847) 취약점은 사전 인증(Pre-authentication) 단계에서 공격이 가능합니다. 즉, ID와 패스워드를 몰라도 네트워크에 접근만 가능하다면 누구나 서버의 데이터를 탈취할 수 있다는 의미입니다.

암호화해도 Mongo Bleed 공격의 영향을 받을까요?

MongoDB를 암호화했더라도 적용한 암호화 방식에 따라 공격의 영향을 받을 수 있습니다. 많은 보안 담당자들은 전송 구간을 TLS로 암호화하거나 디스크(TDE)를 암호화하는 방식을 택합니다. 하지만 이런 암호화 방법만으로는 Mongo Bleed와 같은 메모리 단계의 취약점 공격에서 자유로울 수 없습니다.

전송 중 암호화(In-Transit Encryption)의 한계

TLS/SSL은 데이터가 오가는 경로를 암호화합니다. 하지만 이 경로의 끝단인 데이터베이스 서버 내부로 들어오는 순간, 데이터는 처리를 위해 복호화됩니다. Mongo Bleed와 같은 공격은 경로 자체가 아닌 서버 메모리를 직접 공격하기 때문에, 복호화된 순간 데이터가 유출될 수 있습니다.

저장 시 암호화(At-Rest Encryption/TDE)의 한계

TDE(Transparent Data Encryption)는 디스크에 저장된 파일을 암호화하여 물리적 도난을 방지합니다. 하지만 DB 엔진이 데이터를 검색하거나 수정하려면 반드시 디스크에서 메모리로 데이터를 로드해야 하며, 이때 데이터는 다시 평문(Plaintext) 상태가 됩니다. 즉, 공격자가 메모리를 읽어버리면 데이터가 유출될 수 있습니다.

필드 레벨 암호화(FLE)의 장점

필드 레벨 암호화란 특정 필드의 데이터를 애플리케이션 단에서 암호화한 후 서버에 전송하는 방식입니다. Mongo Bleed 취약점과 같은 메모리 유출 공격에 대응하는 근본적인 대책은 서버 메모리조차 믿지 않는 필드 레벨 암호화입니다. 펜타시큐리티의 데이터 암호화 플랫폼 D.AMO는 애플리케이션 단의 필드 레벨 암호화에서 탁월한 방어 능력을 발휘합니다.

펜타시큐리티 D.AMO

D.AMO는 전 계층 암호화가 가능한 플랫폼입니다. D.AMO의 암호화 방식 중 하나는 중요 데이터를 애플리케이션 단에서 암호화하여 DBMS와의 전송 구간에서 암호화된 상태로 데이터를 전송하는 것입니다. 따라서 메모리상의 데이터를 보호할 수 있고, 데이터 전송 시의 안전성이 확보되어 공격을 무력화할 수 있습니다.

또한 D.AMO를 사용하면 DB 데이터에 영향을 주지 않고 암호화가 가능하여, DB 운영을 중단하지 않고도 강력한 암호화를 적용할 수 있습니다. 애플리케이션 단에서 적용되는 암호화 방식은 DB의 성능에 부하를 주지 않아 효율적으로 운영할 수 있습니다.

키 관리의 중요성

암호화 방식도 중요하지만, 결국 암호화는 키 관리를 통해 보호되어야 합니다. 만약 암호화에 사용된 키를 암호화 연산을 수행한 애플리케이션이나 DB에 저장해 두면, 공격자가 키를 탈취하여 복호화할 수 있는 위험이 있습니다. D.AMO의 키 관리 시스템인 D.AMO KMS를 사용하면 키가 논리적·물리적으로 분리되어 안전하게 보관되므로, 공격이 발생하더라도 데이터를 안전하게 보호할 수 있습니다.

Mongo Bleed 공격은 우리에게 무엇을 남겼는가

보안 사고는 언제 발생할 것인가의 문제입니다. 이번 Mongo Bleed와 같은 취약점은 앞으로도 계속해서 나타날 것입니다.

클라우드 환경의 확대, AI의 등장 등으로 인해 사이버 환경에서 데이터가 갖는 중요도는 계속해서 높아지고 있습니다. 이제 방화벽이나 침입 탐지 시스템 같은 보호 시스템에만 투자해서는 안 됩니다.

이번 Mongo Bleed 사태를 계기로, 데이터의 생명주기 전체를 보호할 수 있는 D.AMO와 같은 암호화 플랫폼을 활용하는 것이 현대 보안의 정답입니다.

Tags:D.AMO Mongo bleed 디아모 암호화 키 관리 펜타시큐리티 필드 레벨 암호화(FLE)