SSL/TLS는 인터넷 상에서 주고받는 민감정보를 보호하는 역할을 하고 있으나 관련 보안 이슈로 위협 지속 발생
보안에 취약한 SSL 2.0과 SSL 3.0의 사용을 자제하고 TLS 1.0 이상 사용 권장
SSL/TLS와 관련된 소프트웨어 문제로 인해 민감정보 유출 가능성을 염두에 두고 최신 보안 패치 적용 필요
보안 점검 툴로 SSL/TLS 보안 취약점 여부를 정기적으로 모니터링해야 함
SSL/TLS란?
SSL/TLS는 각각 Secure Sockets Layer와 Transport Layer Security의 약자로서 인터넷과 같은 네트워크 통신 환경에서 주고받는 데이터를 암호화해주는 규약임(1)
웹, 이메일, 파일전송, 인스턴스 메시지, VoIP 등 다양한 애플리케이션에서 암호화된 통신을 위해 사용되고 있음
SSL은 인터넷 대중화 초창기인 1990년대 초 Netscape 社가 브라우저와 웹서버 간 암호화 통신을 위해 만든 스펙이었는데, 심각한 보안 문제로 SSL 1.0은 발표되지 않았으며 SSL 2.0과 SSL 3.0은 각각 1995년과 1996년에 발표되었음
SSL 2.0은 메시지 인증으로 MD5 사용하는 등 여러 보안 이슈로 인해 2011년부터 사용 금지(PROHIBITED)(2) 되었으며 SSL 3.0은 POODLE(3) 공격 등에 취약하여 2015년부터 사용 제한(DEPRECATED)(4)됨
인터넷 표준화기구인 IETF(5)는 SSL 3.0을 바탕으로 좀 더 보안이 강화된 TLS 1.0 표 준을 발표하였으며 (1999년), 이후 TLS 1.1(2006년)과 TLS 1.2(2008년)를 공개하였으며, 현재 TLS 1.3의 초안 작업 진행 중임
구글을 비롯해 주요 기업들이 SSL/TLS 기반의 Secure HTTP 사용을 권장(6)하고 있으며, 규모가 작은 기업이나 개인을 위해 무료 SSL 인증서를 발급해 주는 기관도 등장(7)
1995년 SSL 2.0이 처음 등장했을 때부터 규약 자체의 설계 결함과 실제 구현에서의 오류로 인해 보안 이슈가 끊이지 않고 있음
민감한 정보 유출 등의 보안 사고를 예방하기 위해 SSL/TLS에 대한 최근 보안 이슈 정리 필요
최근 3년 SSL/TLS 주요 보안 이슈
HEIST 공격 (2016년 8월, Black Hat 발표)
HEIST(HTTP Encrypted Information can be Stolen through TCP-Windows)는 브라우저에 대한 사이드-채널 공격(side-channel attack)(8)을 통해 SSL/TLS로 암호화된 데이터의 정확한 크기를 알아내는 공격
• 이미 알려진 이전 공격과 HEIST의 차이점은 중간자 공격(man-in-the-middle attack, MITM)(9) 없이 사용자의 브라우저만 있으면 웹사이트의 광고 등에 몰래 숨겨 놓은 악성 JavaScript를 이용하여 공격 가능
HEIST를 이용하여 암호화된 데이터 크기를 정확히 알아내기만 하면 압축-기반 공격(compressionbased attack)(10)이나 크기-노출 공격(size-exposing attack) 등에 취약해져 사용자계정, 패스워드, 의료데이터 등 민감한 정보가 탈취될 가능성이 높아짐
JavaScript의 Fetch API(데이터 전송 시작)와 타이밍 API(데이터 전송 종료)를 사용하면 첫 번째 TCP window(11) 안에 암호화된 데이터가 전송 완료되었는지 아니면 두 번째 TCP window 안에 전송 완료 되었는지를 알아낼 수 있음
• 그림 1의 A는 첫 번째 TCP window에서 데이터 전송이 완료되었기 때문에 데이터 전송 시간을 나타내는 T2 - T1이 1 ms 내외로 매우 짧음
• 반면 그림 1의 B는 두 번째 TCP window에서 데이터 전송이 완료되기 때문에 ACK를 받기 위한 시간(라운드 트립, round trip)이 추가되어 T2 – T1가 상대적으로 길어짐
• 결국 T2 – T1 시간의 길고 짧음을 이용(브라우저의 사이드 채널 공격)하여 첫 번째 TCP window에서 데이터 전송 완료되었는지 아니면 두 번째 TCP window에서 완료되었는지 알 수 있음
그림 2와 같이 reflected content의 크기를 변화시켜가면서 첫 번째 TCP window에 딱 맞게 암호화된 데이터 크기를 조절하면 실제 리소스의 크기를 알아낼 수 있음
HEIST 공격을 막기 위한 최선책은 브라우저 설정에서 제3자 쿠키를 비허용하고 JavaScript 시용을 비활성화하는 방법 밖에 없음
• 대부분의 브라우저는 제3자 쿠키 허용과 JavaScript 사용 활성화가 기본설정으로 되어 있어 다수의 사용자가 위험에 노출될 가능성 있음
DROWN 공격(2016년 3월, CVE-2016-0800)
“Decrypting RSA with Obsolete and Weakened eNcryption”의 약자로서 2011년부터 사용금지된 SSL 2.0의 취약점을 이용한 Bleichenbacher RSA 패딩 오라클 공격(12)
• RSA 키교환 단계에서 암호화된 세션키(서버와 클라이언트 간 데이터를 암호화하는 대칭키)를 해독하는 공격
• 2016년 3월 당시 전 세계 33% 서버가 DROWN 공격에 취약하다고 보고됨(13)
그림 4에서와 같이 SSL 2.0 프로토콜에서 사용된 RSA 개인키(private key)와 동일한 개인키를 사용하는 RSA 키교환 기반의 TLS 연결은 DROWN 공격에 의해 암호화된 통신이 해독될 수 있음
• DROWN 공격은 SSL 2.0에서 사용한 RSA 개인키를 유출하는 것이 아니라 Bleichenbacher RSA패딩 오라클 공격을 통해 암호화된 세션키를 해독함
• SSL 2.0과 동일한 개인키를 사용하는 RSA 키교환 기반의 TLS 연결은 해독된 세션키를 이용하여 복호화 할 수 있기 때문에 클라이언트와 서버 간 비밀 통신을 엿볼 수 있음
이미 사용 금지된 SSL 2.0 프로토콜 문제로서 모든 서버와 클라이언트가 SSL 2.0를 지원하지 않도록 설정하는 것이 가장 바람직한 해결 방법임
• 추가로 RSA 키 교환 방식 대신 Diffie-Hellman 또는 Elliptic Curve Diffie-Hellman을 사용하는 것이 안전하며, SSL 2.0 프로토콜이 HTTPS 뿐만 아니라 SMTP, IMAP, POP3 등에서도 사용되지 않도록 각별한 주의 필요
FREAK 공격(2015년 1월, CVE-2015-0204)
“Factoring attack on RSA-EXPORT Keys”의 약자로서 공격자는 중간자 공격(man-in-the-middle attack, MITM)을 통해 SSL 연결시 보안이 취약한 “수출 등급” RSA 알고리즘을 사용하도록 유도한 후 brute-force 공격(14)으로 RSA키를 알아내는 공격
과거 미국에서는 자국 소프트웨어 수출시 암호화 수준을 낮추도록 규제하였는데 이를 “수출 등급(export-grade)” 암호화 알고리즘이라 함
• RSA_EXPORT는 512비트의 암호화키를 사용하는 수출 등급의 RSA 암호화 알고리즘으로서 현재 주로 사용되는 2,048비트 이상의 암호화키에 비해 brute-force 공격에 취약
• 과거에는 수출 등급의 암호화 알고리즘도 어느 정도 안전하였으나 컴퓨팅 성능의 비약적인 발전으로 더 이상 안전하지 못한 상황 발생(아마존 웹서비스를 이용하여 512비트의 RSA 키는 7 ~ 12시간 정도면 깨진다고 함)
FREAK 취약점 발견 당시 미국 정부 사이트는 물론 전 세계 주요 웹사이트가 취약점에 노출되어 있었음
공격 시나리오는 그림 5와 같음
• 공격자는 중간자 공격을 통해 표준 RSA 암호화 알고리즘 목록 요청(Standard RSA cipher suite)을 수출등급 RSA 암호화 알고리즘 목록 요청(Export RSA cipher suite)으로 바꿔버림
• 서버는 long-term 키로 서명된 수출등급 RSA 키로 응답하게 되고, OpenSSL 버그로 인해 이러한 약한 키를 받아들이게 됨
• 약한 키는 brute-force 공격으로 깨지게 되고 이후 공격자는 서버와 클라이언트 간 주고받는 내용을 복호화하여 볼 수 있음
OpenSSL 0.9.8zd 이전 버전과 OpenSSL 1.0.0 ~ 1.0.0p 버전, OpenSSL 1.0.1 ~ 1.0.1k 버전 등이 취약하기 때문에 최신 버전으로 패치해야 함
패치가 적용되기 전까지는 “RSA_EXPORT Cipher Suites” 비활성화 필요
참고로 https://tools.keycdn.com/freak와 https://freakattack.com/에서 각각 웹사이트와 브라우저의 취약 여부를 확인할 수 있음
POODLE 공격(2014년 10월, CVE-2014-3566)
“Padding Oracle On Downgraded Legacy Encryption”의 약자로서 그림 6와 같이 의도적으로 TLS 연결을 SSL 3.0으로 낮춰 SSL 3.0의 취약점을 이용하여 암호문을 해독하는 공격
SSL 3.0은 Netscape사가 웹에서 암호화된 통신을 위해 1996년 발표한 스펙으로써 패딩 오라클 공격(Padding Oracle Attack)에 취약하여 2015년 RFC 7568에 의해 공식적으로 사용 제한(DEPRECATED) 됨
POODLE 공격은 SSL 3.0의 CBC(Cipher Block Chaining) 암호 모드의 취약점을 통해 패딩 오라클 공격을 수행하여 주고받는 암호문을 해독할 수 있음
공격자는 SSL 3.0의 패딩 오라클 취약점을 이용하기 위해 중간자 공격을 통해 TLS 연결 시도를 모두 무시(drop)하고 SSL 3.0 연결을 유도함
SSL 3.0으로 연결되면 자바스크립트를 이용하여 브라우저가 특정 사이트의 인증정보(쿠키, 토큰 등)를 탈취할 수 있으며 패딩 오라클 공격으로 암호문을 해독할 수 있음
POODLE 공격을 대처하는 최선책은 더 이상 SSL 프로토콜을 지원하지 않는 것
• 서버는 웹서버 설정을 통해 SSL 3.0 프로토콜 미지원 조치
• 클라이언트는 브라우저 설정을 통해 SSL 3.0 연결 제한 조치
그림 7에서와 같이, POODLE 공격이 발견되기 직전, Trustworthy의 SSL Pulse 프로젝트에 참여한 웹사이트의 98%가 SSL 3.0 프로토콜 지원을 지원하였으며 2016. 8월 현재 22%의 웹사이트에서 여전히 SSL 3.0 프로토콜을 지원하고 있음
Heartbleed 취약점 (2014년 4월, CVE-2014-0160)
TLS/DTLS(15)에서 keep-alive 기능을 제공하는 Heartbeat Extension 스펙(16)이 OpenSSL 라이브러리에서 잘못 구현되어 공격자는 웹서버의 시스템 메모리 내용을 탈취할 수 있음
• 이러한 취약점에 Heartbleed(심장출혈)라는 별명이 붙게 된 이유는 공격자가 스펙과 다른 Heartbeat을 서버에 지속적으로 보내면 이러한 취약점을 갖고 있는 서버의 응답에 민감한 정보가 조금씩 흘러나오기 때문임
Heartbeat의 정상적인 사용 방법은 그림 9에서와 같이 클라이언트가 서버에 “bird”라는 내용(payload)을 보내면서 payload의 크기가 4byte라고 알려주면, 서버는 응답시 클라이언트로부터 받은 4byte의 “bird”를 되돌려줌
그림 10에서와 같이 공격자가 Heartbleed 취약점을 갖고 있는 서버에 “bird”라는 payload와 함께 payload의 크기가 500byte라고 의도적으로 거짓 정보를 보내면, 서버는 응답시 “bird”를 포함한 메모리의 500byte값을 클라이언트에 보냄
• “bird”뒤에 추가로 보내진 내용에 서버의 중요한 정보가 포함될 수 있음
공격자는 Heartbleed 취약점을 이용하여 한 번에 최대 64KB까지 서버의 메모리 값을 탈취할 수 있기 때문에 지속적으로 공격할 경우 서버의 SSL 개인키나 세션쿠키, 사용자계정/암호 등 민감한 정보를 얻을 수 있음
Heartbleed 취약점은 OpenSSL 라이브러리 1.0.1 ~ 1.0.1f 버전에서 발생(해당 취약점이 발표된 2014.4 당시 웹서버의 약 17%, 약 50만대의 서버가 Heartbleed 취약점에 노출(17))
Heartbleed 문제를 해결하기 위해서는 웹서버의 OpenSSL 라이브러리를 1.0.1g 이상 버전으로 업그레이드해야 함
• OpenSSL 1.0.1 ~ 1.0.1f를 사용해야만 하는 경우, Heartbeat을 보낼 때 보내는 내용(payload)과 payload의 크기 값을 확인하는 패치 적용 필요(18) • Heartbleed 취약점에 노출된 경우, SSL 인증서를 무효화(revoke)하고 재발행해야 함
앞에서 언급한 SSL/TLS 주요 보안 이슈 이외 Logjam 공격(2015년), Padding oracle 공격(2014년), Triple handshake 공격(2014년), CSS injection(2014년), Lucky 13 공격(2013년), BREACH 공격(2013년), CRIME 공격(2012년), BEAST 공격(2011년), STARTTLS Command Injection(2011년) 등이 있음(19)
시사점
프로토콜 설계의 결함이 있는 SSL 2.0과 SSL 3.0은 더 이상 사용하지 말고 TLS 1.0 이상 사용을 권장
OpenSSL 등 관련된 소프트웨어의 버그로 인해 민감정보가 유출될 수 있으므로 항상 최신 보안 패치를 적용해야 함
SSL Server Test(20) 등의 보안 점검 도구를 통해 서버의 SSL/TLS 보안 취약점 여부를 정기적으로 검사해야 함
(8) 암호 체계의 물리적인 구현 과정의 정보를 기반으로 하는 공격 방법이다. 예를 들어, 소요 시간 정보, 소비 전력, 방출하는 전자기파, 심지어는 소리를 통해서 시스템 파괴를 위해 악용할 수 있는 추가 정보를 얻을 수 있음 (출처 : Wikipedia)
(9) 네트워크 통신을 조작하여 통신 내용을 도창하거나 조작하는 공격 기법 (출처 : Wikipedia)
(10) BREACH(2013년), CRIME(2012년)가 대표적인 압축 기반 공격
(11) 두 개의 네트워크 호스트간의 패킷의 흐름을 제어하기 위한 방법 (출처 : Wikipedia)
(12) Bleichenbacher RSA 패딩 오라클 공격 : 패딩 오라클 공격(Padding Oracle Attack)은 블록 암호화에서 사용되는 패딩(padding)이 올바른지 여부에 따라 서버의 응답이 달라지는 현상을 이용한 공격 방법을 말하며, Bleichenbacher RSA 패딩 오라클 공격은 Bleichenbacher의 RSA에 대한 패딩 오라클 공격 방법을 말함 (출처 : Bleichenbacher, D. “Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1.” Annual International Cryptology Conference. Springer Berlin Heidelberg, 1998.)
(13) https://drownattack.com/
(14)특정한 암호를 풀기 위해 가능한 모든 값을 대입하는 것을 의미(출처 : Wikipedia)
(15) DTLS : Datagram Transport Layer Security의 약자로써 데이터그램 기반의 통신에서 암호화 통신을 위한 프로토콜
