하트블리드 사태

(Heartbleed에서 넘어옴)
주의. 사건·사고 관련 내용이 있습니다.

이 문서에는 실제로 발생한 사건·사고에 대한 자세한 내용과 설명을 포함합니다. 불법적이거나 따라하면 위험한 내용도 포함할 수 있으며, 일부 이용자들이 불쾌할 수 있으니 열람에 주의하시기 바랍니다. 또한, 실제 사건·사고를 설명하므로 충분히 검토 후 사실에 맞게 수정하시기 바랍니다.

또한, 이 틀을 적용하시려면 적용한 문서의 최하단에 해당 사건·사고에 맞는 분류도 함께 달아주시기 바랍니다. 분류 목록은 분류:사건사고 문서에서 확인하실 수 있습니다.

Heartbleed(심출혈)

1 개요

2014년 IT와 금융 업계 등 사회 각지에 갑작스레 닥친 대재앙급 보안 이슈.

2014년 4월 1일에 핀란드의 보안 회사 "코데노미콘"에서 상당수의 웹사이트에서 사용되는 OpenSSL의 보안 결함을 발견하고 이를 발표하면서 세간에 널리 알려진 사태이다.[1]

2 설명

2.1 왜 Heartbleed(심출혈)라 불리는가?

대다수의 웹사이트는 사용자 컴퓨터와 서버 컴퓨터가 정보를 교환할 때 OpenSSL이라는 오픈소스 소프트웨어를 사용한다. 사용자측 컴퓨터와 서버측 컴퓨터가 웹사이트에서 정보를 주고받을 때마다 암호화 및 암호화 해제라는 일련의 과정을 거치는 것이다. 여기서 주고받는 정보란 사용자가 해당 웹사이트에서 입력해서 서버로 보내는 모든 정보를 일컬으며, 웬만한 IT 서비스나 카드사, 금융 쪽의 암호 시스템은 대부분 OpenSSL에 의존하고 있다고 보면 된다.

사용자가 웹사이트에서 서버와 정보를 주고받지 않아도 연결은 계속 유지시킬 필요가 있는데, 이때 "하트비트(심장박동)"라고 불리는 OpenSSL 통신신호가 사용된다. 이 사태의 원인은 하트비트의 취약점을 이용하는 것이기 때문에 "하트블리드(심출혈)"라고 명명됐다.

2.2 원리

하트블리드 버그의 원리를 설명한 xkcd 1354화 번역본

그 여파와는 달리 원리는 허탈할 정도로 간단하다. 파이썬 기준으로 약 300줄이면 취약점을 이용할 수 있다.

사용자측에서 무작위 데이터를 담은 하트비트 패킷을 웹서버에 보낼 때, 이 패킷이 얼마만큼의 데이터를 보내는 것인지 명시한다. 서버는 패킷을 전송받은 후 정확히 같은 양의 데이터를 돌려보내면서 연결이 되어있음을 확인하는 방식이다.

여기서 문제가 발생한다. 사용자의 컴퓨터가 얼마만큼의 데이터를 보냈는지 거짓으로 명시할 경우 황당한 일이 생기는 것이다. 예를 들어 1바이트의 정보를 보내면서 서버에는 64킬로바이트를 보냈다고 한다. 그럼 서버는 같은 양의 64킬로바이트를 다시 보내줘야 하는데 실제로 받은건 1바이트의 정보 뿐이라는 모순이 발생한다.[2] 그래서 서버는 메모리에 저장된 다른 정보까지 끌어와 패킷을 채운 후 사용자에게 재전송해준다. 여기엔 웹서버에 특정한 정보를 보여달라는 요청에 대한 쿼리가 포함되며, 유저 아이디나 암호, 심지어는 암호키까지 온갖 정보가 포함될 수 있다. 이 결함을 이용해 반복적인 전송과 응답 과정에서 정보를 축적할 수 있게 되는 것이다. 심지어는 대화 내용 같은 정보까지도 모두 유출될 수 있다. 일종의 버퍼 오버플로우 취약점이다.

2.3 버그가 만들어진 경위

이 끔찍한 버그는 2011년 12월 31일 11시 59분에 Robin Seggelmann이라는 엔지니어가 OpenSSL에 Heartbeat를 넣었을 때 같이 삽입되었다. 그의 말에 따르면 가변 길이 체크를 간과하고 코드를 제출한 것이 원인이 되었다고 한다. 물론 이런 실수는 코드 리뷰 단계에서 걸러지는게 일반적이지만 불행히도 이번 버그는 리뷰어조차도 발견하지 못하고 통과되어 릴리즈된 게 화근이 되었다. 그는 이번 사태에 대한 책임이 자신에게 있다고 밝혔으며, 코드가 충분히 많은 사람에게 리뷰되지 못했다고 한다.

2.4 어느 버전이 문제인가

A missing bounds check in the handling of the TLS heartbeat extension can be

used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.
- [1]

문제가 있는 버전해결 버전 또는 애초에 기능이 없는 버전
OpenSSL 1.0.2-beta
OpenSSL 1.0.1 – OpenSSL 1.0.1f		OpenSSL 1.0.2-beta2 (upcoming)
OpenSSL 1.0.1g
OpenSSL 1.0.0 (and 1.0.0 branch releases)
OpenSSL 0.9.8 (and 0.9.8 branch releases)

버그를 해결하려면 서버 관리자가 1.0.1g 버전을 사용하거나 DOPENSSL_NO_HEARTBEATS 같이 취약한 기능을 비활성화 한 상태로 OpenSSL을 재컴파일하면 된다.

3 반응

3.1 IT 업계에서의 반응

페이스북과 구글, 야후 등 주요 업계는 자신들이 제공하는 서비스가 상당부분 OpenSSL에 의존함을 인정하고 이에 대한 보안 패치를 제공하겠다고 밝혔다.그리고 구글은 혼자서 조용히 패치했다고 한다

모바일 OS 쪽에선 안드로이드 운영체제의 4.1.x 젤리빈이 취약한 것으로 알려져 있다. 4.1.x를 포함한 그 이하 버전이 모두 취약한지에 대해선 논란이 가중되고 있으나 4.1.1 버전은 확실히 취약하다는게 밝혀졌다. 일단은 4.1.x를 포함한 그 이하 버전의 안드로이드 기기들은 가능하면 4.2 이상으로 업그레이드하는 것이 권장된다. 구글에서 하트블리드 관련 보안 패치를 제공했다고 하는데, 이것에 대한 적용 여부는 결국 제조사들의 재량에 달려 있다.

애플은 4월 10일에 iOS, 매킨토시 OS X, 주요 웹 기반 서비스(iCloud 등의 서비스 포함)는 하트블리드 결함에서 안전하다고 밝혔다. 사실 애플은 이미 2012년에 OpenSSL은 불안정하다는 이유로 개발자 웹사이트에서 그 사용을 권장하지 않으며 대체제를 사용해야 한다고 명시한 바 있다. 원래부터 OpenSSL은 iOS에선 아예 포함이 안되고, OS X에선 지원만 하고 마는 정도였다고. 당시엔 OpenSSL이 거의 표준처럼 여겨지고 광범위하게 사용되고 있었을 때여서 개발자와 사용자들이 입을 모아 애플은 폐쇄적이라고 대차게 깠었는데 이렇게 될 줄이야(...). 선지자

보안업체 카스퍼스키에선 "이 사태의 가장 무서운 점은 '그동안 어떤, 얼마나 많은 정보가 빠져나갔는지 알 수가 없고 누가 정보를 빼나갔는지에 대한 추적도 불가능하다'라는 것"이라고 밝혔다.

미국의 저명한 컴퓨터 보안 전문가 브루스 슈나이어가 자신의 블로그에서 이 사태를 두고 대재앙급(catastrophic)이라고 일컬었다. 보안 위협에 점수를 1부터 10까지 매긴다고 치면, 하트블리드는 11이라고. 서글픈 건 본인도 인정했듯이 저 블로그도 OpenSSL을 사용하기 때문에 보안에 취약하다는 점이다(…).

3.2 금융 업계에서의 반응

금융 업계 쪽에선 그야말로 소리 없는 테러를 당한 것과 다름없다. 거의 모두 별 생각없이 OpenSSL에 의존해왔기 때문에 누구 잘못이랄 것도 없이 시스템상 근본적인 취약점이 드러난 것이기 때문이다. 그야말로 난리가 났다. IT 업계에 비하면 대처가 좀 느린 편이고 아예 입장을 밝히지 않는 기업들도 많다.

3.3 한국에서의 반응

한국에선 반응이 시큰둥한 편이었다. 워낙 어마어마한 이슈다 보니 외신은 물론이거니와 국내에서도 상당히 수준 높은 기사들이 많이 올라오고 있었는데, 이에 대한 한국 내 대다수 사람들의 반응은 "별 것도 아닌 걸 가지고 기자들이 괜시리 이슈화한다"였다.[3] 여기에는 한국 금융사나 이동통신사 등에 의한 정보유출 및 관리실패 사건이 최근 들어 너무나도 빈번히 일어난 점도 한 몫했다. 즉, 심심하면 유출되는게 개인 정보고 사실 더 유출될 것도 없는(?) 상태다 보니 반응이 없는게 당연할지도... 하지만 이쪽이 훨씬 심각한 이슈다.[4]

한편 공인인증서 체계와 이번 사태를 비교하는 견해가 있는데, OpenSSL을 사용하는 취약점의 경우 서버측의 문제이고, 공인인증서를 사용하는 시스템의 경우 쿠키와 같이 개인을 식별할 수 있는 클라이언트측의 문제로, 양쪽이 공히 보안과 연관이 있기는 하나 기술적으로는 이 둘을 직접 비교할 수 없다. OpenSSL의 문제는 리눅스와 같이 OpenSSL을 사용하는 서버에만 영향이 있으며, RHEL 같은 오래된 리눅스나 자체 암호화 라이브러리를 사용하는 Microsoft Windows, Apple의 OS X와는 관련이 없다.

4 비판

이 중대한 사태에 대해 오픈소스 커뮤니티가 제공하는 소프트웨어의 신뢰도와 질에 대해 우려와 비판의 목소리가 높아지고 있다. 굳이 직접적인 비난의 화살을 돌려야한다면 이 사태의 원인은 당연히 OpenSSL 관련 개발자들에게 있기 때문이다.

오픈소스는 보는 눈이 많기 때문에 보안에 안전하다고 한다. 하지만 오픈소스라고 해서 보는 눈이 많은 것도 아닌게 인기가 있는 코드는 많은 사람이 보지만 그렇지 않으면 주목을 못받고 방치되는게 일반적이기 때문이다.

또한 오픈소스에서 문제를 발견한 첫번째의 사람이 오픈소스 보안문제를 공개하리라는 보장 또한 없다. 다만 보는 사람이 많다는 확률상의 문제일 뿐으로 인기가 없는 코드를 우연히 본 사람이 문제를 발견할 경우 오히려 이를 독점적으로 악용할 여지 또한 충분히 존재하는 것이다. 즉 보는 눈이 많다는 것이 꼭 소스 보완이나 보안적 문제의 조기 종결을 의미하는 것은 아니다.

더욱이 이번건은 사용자가 많은 오픈소스 임에도 불구하고 하트블리드 사태는 엄연히 일어났고 2년간 방치된 상태였다. 결국 많은 사람들이 소스를 본다는 건 누군가 소스를 책임지고 고친다와는 다른 이야기다. 오픈소스는 기업이 책임지는 소위 '클로즈드 소스'에 비해 지원이나 참여인원, 책임지는 사람이 적은 것은 당연한 일이다. 이 때문에 오픈소스라는 방식 자체의 한계와 결함이 단순한 이론이 아닌 현실로 드러난 것이라고 보는 시각도 있다.

당장 나무위키만 봐도, 결국 위키에 기여하는 것은 특정 문서에 대한 관심이 많은 사람들이다. 그리고 그런 특정 문서만 관리를 받고 나머지는 방치된다. 특정 문서는 지나치게 정확성을 유지하려한 나머지 정확한 정보도 잘려나가고, 반대로 특정 문서는 아예 토막글 수준으로 남거나, 아니면 기괴한 편집이 행해진다.

관리를 주도하며 관리 의무를 부여받고 전담 모니터링을 할 수 없는 경우 이런 문제에서 자유로울 수가 없다.

참고할 만한 오픈소스 관련 비판글
오픈이 다시 한번 승리했다?
하트블리드가 어떻게 인터넷을 망가뜨렸는가 - 그리고 다시 이런 일이 일어날 이유

5 옹호

오픈소스 커뮤니티 측에선 이런 결함이 발생하는건 기본적으로 오픈소스 커뮤니티에 대한 관심과 지원이 부족하기 때문이라는 입장이다.

개발자가 완벽할 수는 없기에 오픈소스이든 클로즈드 소스든 보안상 구멍들은 생길 수밖에 없다.[5] 그리고 의외의, 어처구니 없는 원인으로 발생한 사고들은 끊임없이 있어왔으며, 이번 사태가 오픈소스가 관리가 잘 되지 않기 때문이라고 일반화하는 것은 부당한 일이다.

오픈소스라고 무작정 관리가 되지 않는다는 것은 잘못된 편견이다. 오픈소스는 수많은 기여자들에 의해 모니터링되는 것으로 허점을 발견하며, 일단 허점이 보고되면 너도나도 나서서 고치려 하기 때문에 대응이 더 빠른 경우도 많다.[6] 오히려 오픈소스는 공개적으로 많은 사람에 의하여 리뷰될 수 있어서 이런 등잔 밑이 어둡다는 말이 딱 맞는 버그를 찾을 수 있었다고도 볼 수 있다. 이런 황당한 버그들은 오히려 찾기 어려운 경우가 있다. 버그 같은 경우도 누구나 지켜볼 수 있도록 오픈되었기 때문에 늦게나마, 어쩌면 오히려 빨리 발견된 것일 수도 있다. 클로즈드 소스였다 해도 발견을 보장할 수 없으며, 오히려 발견되지 못해 영원히 묻히거나 발견되더라도 관리책임자가 사적 이익을 위한 백도어로 쓰기 위해 일부러 묻어 버렸을지도 모를일이다.

그러나 이 모델이 잘 작동하기 위해서는 충분한 개발 인원과 기금 등의 자원이 필요한데 OpenSSL은 광범위하게 사용된 것에 비하여 가용 자원이 절대적으로 부족하여 충분한 리뷰조차 받을 수 없었다.[7] 이런 상황에서 대다수의 기업들이 OpenSSL을 범용 기준으로 삼고 광범위하게 사용한 것 자체는 개발자들과는 무관하다. 오픈소스의 개념을 다시 한번 생각해본다면 이해할 수 있을 것이다. 오픈소스 개발자들이 기업들에게 사용을 강요한 것이 아니고 대체품의 개발을 방해한 것도 아니다.

6 이후

하트블리드 사태 이후로 빡친 OpenBSD 개발 멤버들이 OpenSSL의 fork로 LibreSSL을 만들었다. 이 파생본의 목적은 OpenSSL의 잠재적인 위험이 있는 소스들을 쳐내고 OpenBSD의 보안 가이드라인에 맞추어서 더 안전한 소스로 갈아엎는 것이다. 거의 보안을 병적으로(...) 중시하는 OpenBSD 커뮤니티가 참여하기에 LibreSSL의 보안은 기대해봐도 좋을 듯. 또한, 구글도 BoringSSL이라는 fork를 만들어서 OpenSSL과 LibreSSL 개발자와 연계하여 버그 픽스를 진행하고 있다.

한편, 전술한 것처럼 오픈소스의 지속적인 관리를 위한 가용 자원을 확보, 공급하려는 목적으로 Core Infrastructure Initiative가 발족되었다. 아마존, 어도비, 인텔, 구글, 시스코, 후지쯔, 퀄컴 등 같은 IT 업계의 어마어마한 거물[8]들이 최소 360만 달러 이상의 자금(정확한 규모는 밝혀지지 않았다)을 출자했으며, 이 자금의 관리는 리눅스 재단이 맡게 되었다.

7 기타

북미 씨넷에서 주요 웹사이트의 하트블리드 대처 현황을 실시간으로 업데이트하고 있다. 여기서 확인하면 된다.

웹사이트 주소를 입력하고 하트블리드와 관련이 있는지 없는지를 체크하는 웹사이트도 있다. 궁금한 웹사이트 주소를 입력하고 확인해보도록 하자.

전세계 인터넷을 지켜보기로 유명한 NSA가 이 버그를 이미 알고 있었다는 일부 언론의 지적이 있었다. CNET 당연히 그들은 부인했다. 과연 믿을 사람이 있을지 궁금하다. 하트비트 업데이트 당일부터 알아내서 사용했을지도

이 사태 이후로 광범위하게 적용되는 일부 위험한 취약점들에 대해 이름 붙이기 열풍(...) 이 생겼다. Heartbleed 사례를 보고 그 이후부터 Shellshock, GHOST, Winshock, POODLE, FREAK, .... 등 취약점에 다채로운(?) 이름을 붙이는 게 유행이 되었다. 긍정적인 효과로, 이후 소프트웨어 취약점이 언론에 꽤 널리 퍼져서 사람들에게 경각심을 조금이나마 더 주게 되었다. 물론 지금봐선 그다지 효과는 없는 듯

마치 Heartbleed 사태 이후 심각한 취약점들이 점점 늘어나고 있다는 착각이 들 수도 있지만, 실제로는 그 이전에도 CVE 외에 특별한 명칭이 따로 붙지 않았을 뿐이지 심각한 취약점은 이미 많았다. 즉 이런 기사처럼 특히나 최근에 취약점이 예전에 비해 점점 더 많이 발견된다는 듯한 말은 맞지 않다. 정확히 말하면 언론에 알려지는 취약점이 늘어났다고 봐야할 것이다. 예나 지금이나 매년 심각한 취약점은 무수히 발견되고 있고 이는 10년 넘게 특별히 변하지 않았다. 다만 안드로이드/iOS 와 같이 수많은 사람들이 이용하게 된 모바일 플랫폼이 생기면서, 이런 플랫폼에서 발견되는 취약점은 그 위험도가 더 크기 때문에 예전보다 좀 더 부각되는 면은 있다. 실생활에 수많은 사람들이 이용하는 컴퓨팅 플랫폼이 늘어날 수록, 심각한 취약점은 점점 늘어날 것이고 나중에는 이러한 취약점 하나로 원하는 타겟을 별 다른 유저 인터렉션이 필요 없이 정확히 공격할 수 있게 될 수도 있다.[9]

8 2015년

아직도 문제가 있는 버전의 OpenSSL을 사용하는 휴대폰 제조사가 있으며(!)[10] 지원 종료로 버그 픽스가 되지 않은 기종도 여전히 사용되고 있다! 룩아웃에서 제공하는 하트블리드 검출 툴을 이용하여 OpenSSL 버전을 확인할 수 있다.
  1. ↑ SSL 프로토콜 자체를 말하는 것이 아니다. 물론 SSL도 문제점이 있기는 하지만.
  2. ↑ 가변 길이 데이터를 주고 받는 경우에는 의도적으로 왜곡된 정보가 들어올 수 있음을 항상 고려해야 한다. 또한, 배열에서 데이터를 카피할때는 항상 정해진 경계보다 많은 양을 복사하는 일이나 경계보다 많은 양의 데이터를 배열에 덮어씌우는 일도 보안 상 위험천만한 행위이다. 고전적이라면 고전적인 취약점이고 이를 유념하는 것은 보안 상의 기본적인 원칙인데 이런 원칙을 고려하지 않은 몇줄의 코드가 재앙적인 결과를 불러왔다는 점은 눈여겨볼만 하다.
  3. ↑ 어찌보면 문제점이 극도로 근본적인 것이었고, 그에 따라 IT전문매체에서 논하는 내용이 그만큼이나 밑도 끝도 없이 막연하고 어려웠기 때문에 대다수 평범한 사람들이 아예 이해를 못 해버린 것일 수 있다.
  4. ↑ 개인정보 유출 사태는 해당 기업/관공서의 이용자에게만 영향을 끼친다면, 하트블리드 사태는 OpenSSL을 사용하는 사실상 모든 기업·인프라·기업·유저에게 영향을 끼친다.
  5. ↑ Java나 MS가 만든 제품들도 보안구멍이 계속 밝혀져 지속적으로 패치를 하고 있다.
  6. ↑ 일례로 같은 오픈소스 진영인 OpenBSD 커뮤니티는 코드를 한 라인 라인 읽어서 보안성을 체크하고 이걸 몇번 반복하는 커뮤니티이다. 그래서 그 오랜 개발 기간동안 remote 보안 헛점이 2번 밖에 생기지 않은 철통같은 보안성을 자랑한다.
  7. ↑ OpenSSL을 사용한 이들이 이걸 낼름 받아서 쓰기만 했지 OpenSSL에 별다른 피드백을 주지 않았다. 비록 오픈소스라고는 하나, 이같은 노골적인 무임승차는 부당한 일이다.
  8. ↑ 재밌게도 오픈소스 진영에게 가장 많이 까이는 기업 중 하나인 마이크로소프트도 출자에 참여했다. 그 와중에 화웨이도 돈 내는데 삼성은 참가 안 했다고 이번에도 까인다.
  9. ↑ Stagefright 취약점 처럼 MMS 문자 전송만으로 대상을 해킹할 수 있는 경우를 예로 들 수 있다. 이런 경우는 날이 가면 갈수록 늘어날 것이고 현재도 발견되지 않은 채로 이용되고 있는 것들이 많을 것이다.
  10. ↑ 심지어 사태 이후에 출시된 기종인데도!