본문으로 건너뛰기
>_ITDITD웹 보안 플랫폼

사고 & 취약점

Heartbleed(CVE-2014-0160) — 암호화 통신의 토대에서 메모리가 새어 나왔을 때

2014년 HTTPS의 토대인 OpenSSL에 Heartbleed가 있었습니다. 서버 메모리, 심지어 개인 키와 세션까지 유출시켰습니다. '요청보다 많이 돌려주는' 버그의 작동 원리와, 전부 새어 나갔다고 가정하고 인증서를 재발급하며 모든 비밀 정보를 로테이션하라는 교훈을 다룹니다.

게시 2026-06-07 업데이트 2026-06-07 3분 읽기

여전히 여러분의 운영에 적용되는 교훈을 위해 한 획을 그은 사건을 되짚습니다 — 재현이 아니라 방어의 관점으로.

2014
발견
약 17%
'안전한' 웹 서버 중 영향받은 비율
개인 키
최악의 경우 유출
흔적 없음
탐지 난이도

무슨 일이 있었나 — "요청보다 많이 돌려준다"

TLS(HTTPS 뒤의 암호화)에는 킵얼라이브 "하트비트" 교환이 있습니다. 클라이언트가 약간의 데이터와 함께 길이("이것을 돌려달라")를 보내면 서버가 그대로 되돌려 주는 — 설계상 단순한 구조입니다.

OpenSSL의 구현은 주장된 길이를 검증하지 않았습니다. 몇 바이트만 보내면서 "64KB를 돌려달라"고 주장하면, 서버는 여러분의 데이터를 넘어 인접 메모리를 읽어 돌려줍니다. 거기에 개인 키나 세션이 있었다면 그것까지 새어 나갔습니다.

정상: 보낸 길이 = 돌려받은 길이

"'bird'(4자)를 돌려달라, 길이 4" → 서버: "bird"

↓ 길이를 검증하지 않으면…

Heartbleed: 작은 페이로드 + 거대한 주장 길이

"'bird'(4자)를 돌려달라, 길이 64KB" → 서버: "bird + 이웃한 메모리 64KB(키, 세션이 포함될 수 있음)"

정상이라면 보낸 만큼 돌려받는다. Heartbleed는 주장된 길이를 신뢰해 이웃한 메모리를 돌려주었다.

특별한 권한은 필요 없었고, 이를 반복하면 메모리 조각을 조금씩 긁어모을 수 있었습니다. 가장 토대가 되는 계층의 작은 버그가 전 세계 통신의 신뢰를 흔들었습니다.

'흔적 없는' 유출의 공포

Heartbleed는 평범한 접근 로그에 흔적을 거의 남기지 않아 "유출되었는가"와 "무엇이 새어 나갔는가"를 단언하기 어려웠습니다. 의심스러울 때는 최악의 경우를 가정해 행동하십시오.

타임라인

  1. 2014-04-07

    결함이 공개되고 같은 날 수정된 OpenSSL이 배포됨.
  2. 직후

    전 세계 서버가 대거 패치. 영향 범위의 넓이가 경각심을 불러일으킴.
  3. 이후

    많은 서비스가 "키가 유출되었다고 가정"하고 인증서를 폐기·재발급하며 사용자에게 비밀번호 변경을 요청.

왜 "패치만으로는" 끝이 아닌가

개인 키가 유출되었을 수도 있다면, 패치한 뒤에도 옛 키는 여전히 유효합니다. 그래서 대응은 두 갈래입니다 — 구멍을 닫고(패치), 유출되었다고 보고 자산을 로테이션(키, 인증서, 비밀 정보)하는 것입니다.

불충분한 대응

  • OpenSSL을 업데이트하고 "고쳤다"고 간주
  • 악용이 확인된 비밀 정보 하나만 로테이션
  • 같은 인증서를 계속 사용

올바른 대응

  • 업데이트하고 인증서를 폐기·재발급(개인 키 재생성)
  • 서버가 보유한 모든 비밀 정보, 키, 비밀번호를 로테이션
  • 사용자에게 비밀번호 변경을 안내

여전히 적용되는 교훈

1

전부 새어 나갔다고 보고 행동한다

확인된 것 하나만이 아니라 모든 비밀 정보, 키, 비밀번호를 로테이션하십시오. 흔적 없는 유출에서는 최악을 가정합니다.

2

인증서를 폐기하고 재발급한다

개인 키가 유출되었을 수도 있다면 인증서도 다시 만드십시오. 키를 로테이션하기 전까지는 과거의 유출이 살아 있습니다.

3

토대 소프트웨어도 모니터링한다

여러분의 앱뿐 아니라 OpenSSL 같은 "토대"의 CVE도 추적하십시오. 계층이 깊을수록 영향은 넓어집니다.

4

메모리 안전성을 중시한다

"요청보다 많이 읽는" 버그는 메모리 안전 설계와 언어로 구조적으로 줄어듭니다. 무엇 위에 구축할지 결정할 때 고려하십시오.

이어서 읽기

FAQ

QHeartbleed에서 무엇이 유출될 수 있었나요?
A

서버 메모리입니다. 최악의 경우 TLS 개인 키, 세션 내용, 로그인 데이터까지 유출될 수 있었습니다. 게다가 흔적을 거의 남기지 않아 '얼마나 새어 나갔는가'를 사후에 판단하기 어려웠습니다.

Q왜 '요청보다 많이 돌려주었나요'?
A

킵얼라이브(하트비트) 교환에서 서버가 상대가 주장한 길이를 검증하지 않고 신뢰했기 때문입니다. 몇 바이트만 보내면서 '64KB를 돌려달라'고 주장하면, 서버는 여러분의 데이터를 넘어 인접 메모리를 읽어 돌려주었습니다. 입력(길이)을 신뢰한 것이 구멍이었습니다.

Q대응에서 가장 중요한 것은 무엇이었나요?
A

패치 후, 전부 새어 나갔다고 보고 행동하는 것입니다. TLS 인증서를 폐기·재발급하고, 서버가 보유한 모든 비밀 정보와 비밀번호를 로테이션하는 것입니다. 애플리케이션만 패치하는 것으로는 부족했습니다.