오픈SSL 내 '하트블리드' 버그, 프라이빗 키 유출로 인해 대부분의 웹서비스 위험 노출

컴퓨터 보안 전문가들은 관리자에게 민감한 통신을 암호화하기 위해 수백만의 웹사이트에서 사용되는 소프트웨어 라이브러리에서 발견된 심각한 결함을 패치할 것을 충고했다.

하트블리드(Heartbleed)라고 불리는 이 결함은 오픈SSL(OpenSSL)의 여러 버전에 들어있다.

SSL(Secure Sockets Layer) 또는 TLS(Transport Security Layer) 암호화를 할 수 있는 암호 라이브러리를 포함하고 있다. SSL 또는 TLS은 대부분의 웹사이트에서 사용자의 브라우저가 안전하다는 상징을 표현하는 데 사용한다.

2011년 12월에 최초로 소개된 하트블리드 결함은 4월 7일에 발표한 OpenSSL 1.0.1g에서 해결됐다. 이 문제를 발견했던 연구원들에 따르면, 오픈SSL의 취약한 버전은 1.0.1에서 1.0.1f까지다. 오픈SSL 1.0.0과 0.9.8을 포함되지 않는다.

연구원들은 "공격자들이 이 결함이 악용한다면 사용자와 웹서비스 사이를 지나는 모든 정보를 모니터링하거나 또는 심지어 암호화된 트래픽 과거 이력까지도 수집할 수 있다"고 설명했다.
또한 "공격자들은 이 결함을 통해 통신 도청을 허용하고 서비스와 사용자에게 각 상대방으로 흉내내어 직접 데이터를 훔칠 수 있다"고 전했다.

하트브리드 버그는 코데노미콘(Codenomicon)이라는 한 컴퓨터 보안 업체의 연구원 3명과 구글에서 보안 관련 업무를 하는 닐 메타에 의해 발견됐다.

이 문제의 여파는 엄청나다. 지금 현재 많은 운영체제가 이 버그를 내포한 오픈SSL 버전을 갖고 있을 것으로 추정되기 때문이다.

이 연구원들은 취약 버전의 오픈SSL을 갖고 있는 운영체제들은 데비안 위지(debian wheezy), 우분투(Ubuntu) 12.04.4 LTS, 센트(Cent)OS 6.5, 페도라(Fedora) 18, 오픈(Open)BSD, 프리(Free)BSD 8.4, 넷(Net)BSD 5.0.2 그리고 오픈수세(OpenSUSE) 12.2 등이라고 밝혔다.

데비안 스퀴즈의 버전인 올드스테이블(oldstable)과 수세 리눅스 엔터프라이즈 서버는 이번 하트브리드 버그 문제에서 벗어나 있다.

또한 오픈SSL은 웹 서버(Web servers)에서 가장 널리 사용되는 두 가지인 아파치(Apache), 그리고 엔진X(nginx)에 들어간다. 이 코드 라이브러리들은 이메일 서버, 채팅 서버, VPN(virtual private networks), 그리고 다른 네트워킹 어플라이언스를 보호하는데 사용된다.

다른 보안 전문가에 따르면, CVE-2014-0160 패치가 TLS 하트비트 확장형을 조정해 연결 서버에서 64k에 해당하는 메모리를 보기 위해 사용할 수 있다는 점을 문제는 놓치고 있다.

이 취약점은 공격자에게 트래픽을 암호화하는데 사용되는 프라이빗 키(private keys)를 획득할 수 있게끔 한다. 이 키들을 획득한 공격자는 과거에 수집했던 트래픽에 대한 암호화를 풀 가능성이 있다.

공격자들은 이 공격을 반복하면서 64k 분량의 메모리에 접속할 수 있을 뿐만 아니라 재연결을 유지하고 있으면 임의의 숫자를 계속 넣는 동안 64k 분량의 정보를 지속적으로 받을 수 있다.

이렇게 공식적으로 알려진 이 버그에 대해 관리자들은 SSL 업데이트 버전을 적용하고 취약점이 있는 키들을 파기하고 새로운 키를 재발행해야 한다.

이에 대해 빛스캔 전상훈 이사는 "프라이빗 키는 한 마디로 만능 열쇠"라며, "메모리 정보를 계속 읽어오게 되면 결국 프라이빗 키 정보까지도 알아낼 수 있는데, 이렇게 되면 암호화를 여는 열쇠를 획득하게 되는 셈"이라고 설명했다.

전상훈 이사는 "아파치와 엔진X를 사용하는 웹서비스의 전세계 웹서비스의 66%를 차지하는데, 심하게 말하면 이는 재앙"이라고 규정했다.

전 이사는 "패치가 나온다 하더라도 전체 서비스에 적용하는 것은 신속하게 되기가 어렵다"며, "연결된 구조와 의존 관계 등을 면밀히 고려하지 않으면 또다른 장애와 직결되기 때문"이라고 설명했다.

전상훈 이사는 자신의 블로그에서 이번 하트블리드 버그에 대한 대응책을 밝혔다. 우선 기업이나 서비스의 상황을 살펴 보면 단순한 패치로 문제가 해결되기 어려우며, 우선적으로 자사가 SSL 이용하는 부문에서 오픈SSL을 사용하는지 확인하고 패치하는 것이라고 전했다.

1. SSL 버전 확인 - 패치 적용, 기본
2. 업그레이드 불가한 곳은 OpenSSL 하트비트(Heartbeat) 옵션 제거 후 재컴파일 및 사용
3. 중요도가 높거나 사용자가 많은 대외 서비스의 경우, 서비스 SSL 인증서 재발행 필요
4. 전체 IP 대역에서의 443 포트 활용 및 SSL 활용 유무 체크: SSL 하트비트 취약점을 이용해 메모리 값을 불러 올 수 있는 진단 프로그램을 전체 활용
5. 보안 제품, VPN, 메일 등 모든 제품에서의 SSL 옵션 사용하는 곳들도 동일하게 확인

전 이사는 "이 과정에서 서비스나 네트워크의 간헐적인 중단이 예상되며, 대부분의 보안 장비들이 SSL 지원을 하고 있으니 모두 체크 사항에 포함된다"고 말했다. editor@itworld.co.kr