하트블리드

최근 수정 시각:

주의. 사건·사고 관련 내용을 설명합니다.

이 문서는 실제로 일어난 사건·사고의 자세한 내용과 설명을 포함하고 있습니다. 특정 사건사고 문서는 유머성 서술과 비하의 표현이 제한되며, 사실관계를 작성할 때에는 출처를 반드시 표시해야 합니다.

틀 적용 시 해당 사건·사고에 맞는 분류도 달아 주시기 바랍니다. 분류 목록은 분류:사건사고 문서에서 확인하실 수 있습니다.


Heartbleed(심출혈)

파일:external/heartbleed.com/heartbleed.png

1. 개요2. 설명
2.1. 이름의 유래2.2. 원리2.3. 버그가 만들어진 경위2.4. 어느 버전이 문제인가
3. 반응
3.1. IT 업계에서의 반응3.2. 금융 업계에서의 반응3.3. 한국에서의 반응
4. 비판5. 이후6. 기타7. 2015년 이후

1. 개요[편집]

2014년 IT와 금융 업계 등 사회 각지에 갑작스레 닥쳤던 대재앙급 보안 이슈이자, 이 이슈의 중심점인 보안 취약점의 별칭.

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

2. 설명[편집]

2.1. 이름의 유래[편집]

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

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

2.2. 원리[편집]

파일:heartbleed_explanation_translated_to_Korean.jpg

하트블리드 버그의 원리를 설명한 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.
- http://www.openssl.org/news/secadv_20140407.txt

문제가 있는 버전

해결 버전 또는 애초에 기능이 없는 버전

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, AppleOS X와는 관련이 없다.

4. 비판[편집]

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

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

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

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

당장 나무위키만 봐도, 결국 위키에 기여하는 자들은 특정 문서에 대해 집착이 매우 심하다. 그리고 그런 특정 문서만 관리를 받고 나머지는 방치된다. 주로 게임같은 문서에서 지나치게 주관적인 정보만 쓸려는 나머지 정확한 정보를 잘라내고 유치한 묘사를 섞어 쓰는 수준이하의 편집이 빈번하게 이루어지고 있으며, 반대로 특정 문서는 아예 토막글 수준으로 남거나, 기괴한 편집이 행해지고 있다. 그런데도 이를 막으려는 운영자는 극히 드물다.

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

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

오픈소스 커뮤니티 측에선 이런 결함이 발생하는건 기본적으로 오픈소스 커뮤니티에 대한 관심과 지원이 부족하기 때문이라고 변명했지만, 이 변명 자체가 말이 안되는게 오픈소스는 리뷰어들의 리뷰도 자유이기 때문에 제대로 체계화되고 편중되지 않은 점검 과정이 보장되지 않는다는 것이 문제의 핵심인 것이고 그런 면에서 오픈소스 프로젝트가 구조적인 약점을 가지고 있다는 것이 비판점이기 때문이다.[5]

이 모델이 잘 작동하기 위해서는 충분한 개발 인원과 기금 등의 자원이 필요한데 OpenSSL은 광범위하게 사용된 것에 비하여 가용 자원이 절대적으로 부족하여 충분한 리뷰조차 받을 수 없었다.

OpenSSL을 사용한 이들이 이걸 낼름 받아서 쓰기만 했지 OpenSSL에 별다른 피드백을 주지 않는 경우가 많다. 무책임한 이용자 문제로 볼 수 있지만 무작정 사용자들을 비난할 수도 없는 것이 애초 오픈소스의 시작 자체가 무임승차 비율이 높더라도 더 많이 노출되게 해서 그중에서 충실한 접근인원을 확보하고자 하는 이념 즉 게임으로 치면 F2P와 비슷한 접근법을 취하고 있는지라 무임승차 비율이 높다고 그들을 비난하는 것은 포인트가 빗나간 것이다. 그런식이면 코드를 일일이 분석하거나 취약점을 찾아내지 못하는 이들이면 오픈소스를 이용하면 안된다는 주장이랑 다를게 없다. 그리고 사실 이들 모두가 반드시 피드백을 한다면 그것도 그것 나름대로 일일이 대처하기 힘든것도 또다른 문제가 될 수 있다.[6]

결론은 오픈소스의 가장 근본적인 문제점들을 고스란히 드러낸 사건이라 볼 수 있다. 물론 이는 클로즈드 소스의 우월성을 입증하는 것이나 반대로 오픈소스의 열등함을 드러내는 것이 아니다. 이거가지고 말꼬리를 잡는 이들이 반론을 펼치는 경우가 있는데 오픈 소스 역시 제대로 관리될 수 있으며 클로즈드 소스의 최대 특징인 폐쇄성은 개발주체와 사용주체가 달라지는 경우 사용자 입장에서 개발자를 신뢰할 수 없다면 큰 단점으로 작용하게 된다.[7]

5. 이후[편집]

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

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

6. 기타[편집]

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

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

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

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

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

7. 2015년 이후[편집]

아직도 문제가 있는 버전의 OpenSSL을 사용하는 휴대폰 제조사가 있으며(!)[10] 지원 종료로 버그 픽스가 되지 않은 기종도 여전히 사용되고 있다! 룩아웃에서 제공하는 하트블리드 검출 툴을 이용하여 OpenSSL 버전을 확인할 수 있다.

[1] SSL 프로토콜 자체를 말하는 것이 아니다. 물론 SSL도 문제점이 있기는 하지만.[2] 가변 길이 데이터를 주고 받는 경우에는 의도적으로 왜곡된 정보가 들어올 수 있음을 항상 고려해야 한다. 또한, 배열에서 데이터를 카피할때는 항상 정해진 경계보다 많은 양을 복사하는 일이나 경계보다 많은 양의 데이터를 배열에 덮어씌우는 일도 보안 상 위험천만한 행위이다. 고전적이라면 고전적인 취약점이고 이를 유념하는 것은 보안 상의 기본적인 원칙인데 이런 원칙을 고려하지 않은 몇 줄의 코드가 재앙적인 결과를 불러왔다는 점은 눈여겨볼만 하다.[3] 어찌보면 문제점이 극도로 근본적인 것이었고, 그에 따라 IT전문매체에서 논하는 내용이 그만큼이나 밑도 끝도 없이 막연하고 어려웠기 때문에 대다수 평범한 사람들이 아예 이해를 못 해버린 것일 수 있다.[4] 개인정보 유출 사태는 해당 기업/관공서의 이용자에게만 영향을 끼친다면, 하트블리드 사태는 OpenSSL을 사용하는 사실상 모든 기업·인프라·기업·유저에게 영향을 끼친다.니네 게임+은행 계정 털릴수도 있다고 하면 이해를 할까[5] 오픈소스라서 더 빨리 발견된 것이라는 주장은 정신승리일 뿐이다. 그런식이면 클로즈드 소스는 실제 취약점이 있어도 악의적인 목적을 가진 크래커가 취약점을 발견하기도 힘들것이므로 상대적으로 더 안전하단 논리가 된다.[6] 또한 개발자들이 기업에게 사용을 강요한 적이 없다고 무관하다는 것은 그 주장이야말로 그야말로 무책임한 헛소리다. 이는 뻔뻔하기 그지없는 주장으로 당장 여기서 하트블리드 사태를 일으킨 Seglemann도 자신의 책임을 인정했는데 개발자들에게 면책 운운하는 건 그냥 실드 그 이상도 그 이하도 아니다. 그런 논리면 아무도 당신에게 인터넷 뱅킹, 홈페이지 가입을 강요한 적이 없고 크래커 역시 당신에게 보안허점을 만들도록 강요한 적 없다[7] 예를 들면 인텔 관리 엔진 관련 보안 이슈가 발생했음에도 AMD역시 펌웨어 소스코드를 공개하지 않는 것은 마찬가지라는 이유로 구글은 하드웨어 교체가 아닌 관리엔진을 대체할 NERF라는 자체 소프트웨어를 개발했다.[8] 재밌게도 오픈소스 진영에게 가장 많이 까이는 기업 중 하나인 마이크로소프트도 출자에 참여했다. 그 와중에 화웨이도 돈 내는데 삼성은 참가 안 했다고 이번에도 까인다.[9] Stagefright 취약점 처럼 MMS 문자 전송만으로 대상을 해킹할 수 있는 경우를 예로 들 수 있다. 이런 경우는 날이 가면 갈수록 늘어날 것이고 현재도 발견되지 않은 채로 이용되고 있는 것들이 많을 것이다.[10] 심지어 사태 이후에 출시된 기종인데도!