OpenSSL 취약점 하트블리드(HeartBleed), 왜 위험한가?

OpenSSL 취약점 ‘HeartBleed’ 발견

 

2014년 4월은 보안시장에서 큰 이슈가 많이 발생한 달입니다.

4월 8일(한국시간), 13년 동안 우리의 인터넷 생활을 함께 해 온 XP 운영체제의 업데이트 지원이 종료되었으며, 그 다음날인 9일, HeartBleed(CVE-2014-0160)라고 명명된 OpenSSL버그가 발견되었습니다. 

'하트블리드(HeartBleed)' 취약점이란?

HeartBleed란 OpenSSL 1.0.1 버전에서 발견된 매우 위험한 취약점 입니다. OpenSSL을 구성하고 있는 TLS/DTLS의 HeartBeat 확장규격에서 발견된 취약점으로, 해당 취약점을 이용하면 서버와 클라이언트 사이에 주고받는 정보들을 탈취할 수 있습니다.

* OpenSSL은 정해진 규격의 네트워크 보안 프로토콜을 범용 라이브러리로 구현하기 위한 목적으로 만들어졌으며, SSL이나 TLS를 이용한 암호화를 구현할 수 있습니다. 강력한 암호화 기능을 제공하기 때문에, 보안이 중요한 대형 포털서비스, 이메일 서비스, 금융권 등에서 데이터 통신 시 OpenSSL을 사용하고 있습니다.

HeartBleed 취약점은 OpenSSL 라이브러리의 구조적인 취약점입니다. OpenSSL의 확장규격 중 하나인 HeartBeat는 서버와 클라이언트 사이에 무슨 문제는 없는지 또는 안정적인 연결을 유지하기 위한 목적으로 일정 신호를 주고 받을 때 사용하는 확장규격입니다. 클라이언트는 HeartBeat 확장프로토콜을 이용하여 임의의 정보를 그 정보의 길이와 함께 서버에 전송합니다. 그 후 서버는 전달받은 정보를 다시 클라이언트에 전달해 주는 과정을 통해 자신의 존재 사실을 알려줍니다. 

 

이 때 클라이언트로부터 전달받은 정보와 그 정보의 길이가 일치하지 않는다면, 클라이언트의 요청에 서버는 응답을 하지 않는 것이 정상적인 동작입니다. 이번에 발견된 HeartBleed 취약점은 서버가 클라이언트로부터 전달받은 정보의 내용과 그 정보의 길이의 일치 여부를 검증하지 않은 채 정보를 보내주면서 문제가 발생된 것입니다. 

 

그림1. 정상적인 요청과 정상적인 반환값

그림2. payload의 길이를 조작하여 정보 유출

* 페이로드(Payload) :  실제 전송되는 데이터

쉽게 설명하자면, 클라이언트가 '사과 한 개가 담긴 사과박스'를 '사과가 10개 들어있다는 거짓 정보'와 함께 서버에 전달합니다. 이 정보를 받은 서버는 사과가 1개가 들어있는 박스를 확인하면 사과가 10개라는 정보는 거짓이기 때문에 그 요청에 응답을 해서는 안됩니다. 하지만 서버는 그러한 정보를 검증하지 않은 채 '사과 한 개가 있는 박스를 받았지만, 사과가 10개 있다고 착각'해 클라이언트로부터 전달받은 1개의 사과에 자신이 갖고 있던 사과 9개를 추가하여 클라이언트에게 전달하게 됩니다. 이것이 바로 HeartBleed 취약점이 발생되는 과정입니다.

클라이언트는 한번에 최대 64KB의 정보를 요청할 수 있습니다. 실제로 64KB에 들어갈 수 있는 정보는 매우 작습니다. 그러나 해당 취약점을 이용하여 시스템 메모리에 저장되어 있는 무의미한 작은 정보들을 지속적으로 유출시키면, 이러한 무의미한 정보들이 모여 하나의 완전한 유의미한 정보가 될 수 있습니다. 이러한 과정을 통하여 공격자는 시스템 메모리에 저장되어 있는 정보들을 유출시킬 수 있으며, 이 정보들에는 개인키, 관리자 정보 등 민감한 정보들도 포함되어 있습니다. 특히 개인키의 경우 암호화하여 전달되는 데이터를 모두 열람할 수 있는 핵심정보이기 때문에 사안이 매우 심각하다고 할 수 있습니다.

 

HeartBleed 명칭의 유래는 해당 취약점으로 공격할 때마다 작은 정보들이 새어 나오는 것을, 심장이 한번씩 뛸 때마다(HeartBeat) 심장에서 피가 한 방울씩 떨어지는 치명적인 심장출혈(HeartBleed)로 비유하여 명명한 것입니다.

영향받는 버전 

OpenSSL 1.0.1 ~ OpenSSL 1.0.1f

OpenSSL 1.0.2-beta, OpenSSL 1.0.2-beta1

영향받지 않는 버전

OpenSSL 1.0.1g

OpenSSL 1.0.0대 버전

OpenSSL 0.9.8대 버전

※ 패치방법

[시스템 측면 대응방안]

1. OpenSSL 버전을 1.0.1g 버전으로 업데이트

서비스 운영환경에 따른 소프트웨어 의존성 문제 고려, 업데이트 방법을 선택하고 반드시 먼저 테스트 수행

* 아래 보안 패치 방법은 CentOS/Fedora 및 Ubuntu의 예제로 각 운영체제 별로 업데이트 방법이 상이할 수 있음

-   CentOS/Fedora

(1) 전체 시스템 업데이트(OpenSSL을 포함한 시스탬 내의 소프트웨어 전부 업데이트) 

(2) OpenSSL 업데이트

 

- Ubuntu

(1) 전체 시스템 업데이트(OpenSSL을 포함한 시스탬 내의 소프트웨어 전부 업데이트)

(2) OpenSSL 업데이트 

2. 운영환경의 특수성 때문에 패키지 형태의 업데이트가 어려운 경우, Heartbeat를 사용하지 않도록 컴파일 옵션을 설정하여 재컴파일 가능

* OpenSSL 소스코드를 처음 다운받아 컴파일하는 경우 라이브러리   의존성 문제가 발생하여 추가적인 작업이 필요한 경우도 존재

[네트워크 보안 장비 측면 대응 방안]

취약점 공격 탐지 및 차단 패턴 적용 

* 아래의 Snort 탐지 룰(rule)을  참고하여 침입탐지시스템 및 침입차단 시스템에 패턴 업데이트 적용 권고

* 차단 패턴 적용은 서비스 및 네트워크 영향도를 고려하여 적용

 

[서비스 관리 측면 대응 방안] 

1. 서버 측 SSL 비밀키(Secret Key)가 유출되었을 가능성이 있기 때문에 인증서 재발급을 운영자가 검토

2. 취약점에 대한 조치 완료 후, 사용자들의 비밀번호 재설정을 유도하여 탈취된 계정을 악용한 추가 피해 방지 방안 고려

참고:

본 포스트의 이해를 돕고자 제작된 이미지는 다음 자료를 참고하였습니다.

서버와 클라이언트(그림1, 그림 2): http://www.forumsys.com/api-security/how-to-fix-openssl-heartbleed-security-flaw/

네트워크 보안 장비 측면 대응 방안: FBI