SSL Heartbleed 취약성: 영향과 대응책

Heartbleed는 아마도 역사상 최악의 보안 취약성이라 할 수 있을 것이다. 더 안 좋은 점은 Heartbleed를 가능하게 만들고, 인기도 있는 OpenSSL 라이브러리가 지난 2년 이상 폭넓게 쓰였다는 점인데, 이 말은 이 취약점이 인터넷에 널리 퍼져있다는 의미이다.

게다가 더 문제가 되는 점은 Heartbleed의 존재를 알고 있는 공격자들은 누구나 간단하고 추적이 불가능한 메시지를 이용해 취약한 서버의 메모리 값을 빼낼 수 있다는 것이다.

그림 1: Heartbleed 탐침 적절하게 보호되지 못한 자원들은 SSL 프라이비트 키, 사용자 패스워드, 그리고 기타 매우 민감한 정보들을 포함하고 있을 수 있다.

간단하게 말해 Heartbleed는 최악의 시나리오에 무척 가깝다.

희소식

희소식이 있는데, 지난 2년 내에 당신의 HTTPS 애플리케이션을 F5 BIG-IP 애플리케이션 딜리버리 컨트롤러 (ADC)가 제공하고 있었다면 그 애플리케이션은 Heartbleed에 취약하지 않다는 것이다. F5 고객들과 다른 조직들을 대신해 해야 할 일이 아직 조금 더 있기는 하지만, F5는 즉각적인 대응책과 그 다음 단계들을 포함해 Heartbleed에 취약하지 않은 세상으로의 움직임을 이미 시작했다.

인터넷에 미치는 영향에 대한 분석

Heartbleed 취약성이 발표된 후에 Netcraft는 이 위협 표면의 핵심 파라미터들에 기반한 분석을 실시했다. Netcraft의 분석 결과에 따르면, 현재 SSL사이트 전체 중 약 15%가 Heartbleed에 노출되어 있는데, 이 말은 50만 개 이상의 프라이비트 키가 노출되어 있다는 뜻이다.

물론 각 SSL 키는 그들의 값에 따라 보안 수준이 다르다. 예를 들어 온라인 뱅킹 사이트의 프라이비트 키 보안은 뉴스 포털의 프라이비트 키보다는 훨씬 중요하다. 최상위 인증서 (root certificate) 승인 키들은 세상에서 가장 소중하다.

그렇다면 누가 취약한가?

Heartbleed 위험성을 최초로 발표할 때 어떤 사이트들이 안전하고 어떤 사이트들은 안전하지 않은지도 함께 발표되었다.

“다행스럽게 많은 수의 대형 소비자 사이트들은 SSL/TLS 터미네이션 (termination) 장비와 소프트웨어를 보수적으로 채택했기 때문에 구제가 되었다. 아이러니컬하게 규모가 작거나 진보적인 서비스들 또는 최신, 최선의 암호화 방식으로 업그레이드한 사이트들이 가장 큰 영향을 받았다.” - Heartbleed 연구자들 

어떤 사이트들이 가장 취약할 듯싶은지 알아내는 것은 꽤 간단한데, (아파치나 NGINX와 같은) 오픈소스 소프트웨어 서버의 최신 버전들을 사용하는 사이트들이 더 위험하다.

F5 ADC가 Heartbleed 대응책이다.

희소식에 대해 말하자면, F5 BIG-IP 디바이스나 소프트웨어가 Heartbleed에 대한 대비책으로 사용될 수 있는 방법이 3가지 있다.

첫째: 정상적인 SSL 프로파일들이 이미 Heartbleed를 방어하고 있다.

BIG-IP 플랫폼의 SSL 프로파일들이 태생적으로 보유한 SSL 터미네이션 능력을 통한 방어이다. 애플리케이션의 SSL을 종료하기 위해 F5의 BIG-IP Local Traffic Manager (LTM)를 사용하는 대다수의 사이트들은 이미 Heartbleed로부터 안전하게 보호받고 있다. 그 이유는 F5 트래픽 관리 마이크로커넬 내의 주 SSL 엔진은 F5 고유의 매우 최적화된, 손으로 직접 작성한 코드이기 때문이다. 따라서 프로토콜 서버를 대신해 F5 플랫폼이 SSL을 종료할 때는 애플리케이션에 필요한 방어를 이미 제공하는데, Heartbleed 연구가들이 취약성을 면한 “운이 좋은 소비자 사이트들”이라고 표현한 애플리케이션들이 바로 이것들이다. 즉, 비즈니스가 가동 시간 (uptime)에 많이 의존하고 용량과 서비스 제공을 위해 SSL 터미네이션 장비 (다시 말해, SSL-종료 로드밸런서)에 투자한 사이트들이다.

그림 3: BIG-IP LTM이 Heartbleed를 방어하는 방법

둘째: 하드웨어 보안 모듈들이 암호 경계를 제공

가장 안전한 SSL 키들은 금융권, 방위산업, 인증기관들이 사용하는 값이 큰 키들일 것이다. 이런 조직들은 종종 하드웨어 보안 모듈 (HSM)이라 불리는 FIPS-140 레벨3 암호 경계 내에 자신의 키를 보관하는데, 이것들은 메모리 해킹 툴들로부터 키들을 안전하게 지켜준다. 이런 기관들 중 많은 수가 통합 HSM과 함께 ADC를 사용한다.

그림 4: 네트워크 HSM 아키텍처 재미있게도 중앙 관리하에 있는 FIPS 140 암호 저장소 내에 SSL 키들이 보관되어 있는 완전히 새로운 형태의 네트워크HSM도 있다. ADC는 이런 디바이스들에게 SSL 세션 키 암호화를 해제하도록 요청하지만, SSL 세션 암호화의 나머지 부분들은 자신이 직접 처리한다.

셋째: F5 iRules가 나머지 방어를 책임진다. F5의 ADC는 다른 어떤 ADC도 갖지 못한 기능을 가지고 있는데, 완전히 프로그램이 가능하고, 데이터 플레인 스크립트 언어이다. iRules라고 불리는 이 프로그래밍 언어는 10만 명 이상의 활동적인 사용자들로 구성된 F5 DevCentral 개발자 커뮤니티가 지원하고 있다.

위에 기술된 조금 더 고전적인 SSL 종료 솔루션 두 가지 중 어떤 것도 사용할 수 없는 기관들은 SSL 커넥션을 스스로 암호해제 하지 않고 iRules를 이용해 대응하는 것이 또 다른 옵션이다.

iRules에 기반한 방어 시나리오에는 다음이 포함된다:

• 프라이비트 키가 원래의 서버 호스트로 가지 못하도록 제한하는 보안정책을 가진 서버군
• (SNI와 다른 키들을 사용하는) 멀티-테넌트 SSL 사이트를 위한 진입 지점
• 가상화된 SSL 사이트 군의 앞 단에 위치한 가상 ADC

이런 케이스들을 위해 F5는 Heartbleed 취약성을 완화시키는 두 종의 iRules를 작성했다. 문제 영역은 긍정오류 방지, 성능 보장, 보안이 환상적으로 혼합된 것인데, 이들은 평문(plain text)을 검사할 수 없는 단일 규칙 안에서 적절한 균형을 유지해야만 한다.

첫 번째 iRule은 클라이언트가 heartbeat 요청을 보내려는 시도를 모두 차단한다. 적법한 클라이언트는 heartbeat을 거의 보내지 않기 때문에 iRule이 악의적인 클라이언트를 모두 차단하며 BIG-IP 후단에 있는 서버에 공격이 도달하는 것을 방지한다.

두 번째의 iRule은 서버 메모리의 한 부분을 포함하고 있을지도 모르는 대규모 heartbeat 응답을 서버가 전송하는 것을 막는다.

만약 이 두 iRules 중 어떤 것도 충분하지 않다면, 각 기관은 자신 스스로 개발할 수도 있으며, 이런 일은 거의 매일 발생한다. 이것이 바로 iRules와 DevCentral의 힘이다.

(제 2부에 계속)