중요: DROWN 취약점 관련 정보 - CVE-2016-0800

Red Hat 제품 보안팀은 SSLv2 프로토콜에서 중요한 영향을 미치는 것으로 평가되는 취약점을 인지하였습니다. 이는 CVE-2016-0800로 지정되어 있으며 DROWN (Decrypting RSA using Obsolete Weakened eNcryption)이라고 하는 크로스 프로토콜 (cross-protocol) 공격에 사용됩니다.

개요

SSLv2 (Secure Sockets Layer 프로토콜 버전 2.0)는 일치하는 RSA 개인키에 대한 정보 없이 RSA 암호화 텍스트를 해독하는데 사용할 수 있는 Bleichenbacher RSA 패딩 오라클 공격에 취약하다는 것이 보안 연구진에 의해 발견되었습니다. 이는 공격자가 개인키가 있는 서버에서의 응답을 관찰하고 이러한 키를 사용하여 공격자의 암호화 텍스트를 해독하여 수행됩니다. 연구진은 이러한 SSLv2 약점을 이용하는 새로운 프로토콜 버전 (SSLv3 또는 모든 현재 TLS (Transport Layer Security) 버전 (1.0 - 1.2))을 사용하여 SSL/TLS 세션의 암호를 해독할 수 있는 새로운 크로스 프로토콜 (cross-protocol) 공격에 대해서도 설명하고 있습니다. 본 결함은 SSLv2 프로토콜 문제이며 모든 프로토콜 구현에 영향을 미칩니다. 본 결함은 일반적 DROWN이라 합니다.

또한 OpenSSL 암호화 및 SSL/TLS 라이브러리에 있는 SSLv2 프로토콜 구현에서 DROWN 형태의 공격을 보다 효율적으로 실행할 수 있는 결함이 발견되었으며 이러한 취약점을 특별한 DROWN 이라고 합니다. 본 취약점은 CVE-2016-0703 및 CVE-2016-0704로 지정되어 있으며 이미 최근에 CVE-2015-0293의 수정 대상의 일부로 수정되어 있습니다.

이러한 공격에 대한 보다 자세한 내용은 다음 문서 DROWN: Breaking TLS using SSLv2에서 확인하실 수 있습니다.

배경 정보

SSLv2 프로토콜에는 이미 알려진 보안 문제가 다수 있으며 1996년에 대체 가능한 SSLv3가 공개된 이후 안전성이 결여된 프로토콜로 간주되었습니다. 또한 RFC 6176를 통해 2011년 부터 공식적으로 사용되지 않았습니다. 최신의 SSL/TLS 클라이언트가 이러한 프로토콜 버전을 전혀 지원하지 않거나 사용 가능한 새로운 버전을 사용함에 따라 인터넷에서 이러한 프로토콜은 제한적으로 사용되고 있습니다. 하지만 여러 SSL/TLS 서버는 DROWN 공격의 공개 이전에 나온 아주 오래된 클라이언트의 연결을 허용하기 위해 아직도 이 프로토콜을 사용하고 있습니다. 새로운 프로토콜 버전을 지원하는 클라이언트에서는 이러한 보안 연결 위협에 대한 보고 내용은 없었습니다.

DROWN 공격으로 인해 영향을 받는 설정

SSLv3 또는 TLSv1.x에 더하여 SSLv2 프로토콜이 활성화된 서버와 RSA 키 교환 암호 방식을 사용하는 서버는 DROWN 공격에 취약합니다. SSLv2를 활성화하지 않는 서버라도 SSLv2를 사용하는 서비스 또는 다른 서버와 RSA 개인키를 공유하는 경우 서버에 취약점이 있을 수 있습니다. 예를 들어 IMAP 서버와 같이 SSLv2가 활성화된 서비스가 동일한 호스트에서 실행 중인 웹 서버와 RSA 키를 공유하는 경우 웹 서버에 SSLv2가 활성화되어 있지 않더라도 여전히 해당 웹서버의 HTTPS 세션을 해독하기 위해 DROWN 공격이 사용될 수 있습니다. 이 공격을 효율적으로 수행하기 위해서는 약한 SSLv2 암호를 사용하거나 SSLv2 EXPORT 암호가 필요합니다.

Diffie-Hellman 또는 Elliptic Curve Diffie-Hellman과 같은 RSA 이외의 키 교환 방식을 사용하는 SSL/TLS 연결은 DROWN 공격을 사용하여 암호를 해독할 수 없습니다.

공격 설명 및 영향

보안 연구진에 따르면 DROWN 공격은 다음과 같은 단계로 구성되어 있습니다:

• 먼저 공격자는 프로토콜 버전 및 RSA 암호 방식을 사용하는 클라이언트와 서버 사이의 특정 SSL/TLS 세션 수를 기록해야 합니다. 이렇게 기록된 세션 중 하나가 해독되게 됩니다. 연구진에 따르면 약 1,000 세션이면 공격 실행에 충분하다고 합니다.

• 다음으로 공격자는 서버에 많은 SSLv2 연결을 오픈합니다. 이러한 연결 중 일부의 경우 공격자는 40-비트 (SSLv2 EXPORT 암호 중 하나가 사용될 수 있을 경우) 또는 56-비트 (DES를 사용하는 암호화 제품군의 경우) 세션 키에 대해 무차별 암호 대입 공격을 실행합니다. 연구진은 이를 실행하는데 약 40,000 개의 연결이 필요하다고 추정하고 있습니다.

• 그 후 공격자는 원래 기록된 핸드 셰이크 중 하나에서 "premaster secret" 데이터를 해독할 수 있습니다. 이러한 데이터는 대칭 세션 키를 생성하는데 사용되므로 기록된 SSL/TLS 세션 전체를 해독합니다. 추가적인 중요 데이터는 인증 정보나 쿠기와 같은 암호 해독 세션에서 얻을 수 있습니다.

연구진에 따르면 1,000 개의 기록된 핸드셰이크, 40,000 SSLv2 연결, 2⁵⁰ 오프라인 계산을 사용하는 2048 비트 RSA 키를 사용하여 서버와의 TLS 1.2 핸드셰이크를 해독할 수 있다고 합니다. 연구진이 공격을 실시하는데 퍼블릭 클라우드 제공자의 자원을 사용하여 440 USD의 비용으로 8 시간 미만의 시간이 소요되었습니다.

또한 특정 DROWN 공격의 사용으로 14,000 까지 SSLv2 연결 수를 감소시키고 단일 워크스테이션을 사용하여 3 분 이내에 수행할 수 있다고 합니다. 이러한 취약점을 이용하여 활성 중간자 (MITM: man-in-the-middle) 공격을 수행하고 TLS 서버를 위장하여 TLS 클라이언트에 연결할 수 있습니다.

SSLv2 지원되는 SSL 및 TLS 라이브러리

Red Hat 제품에는 SSLv2 프로토콜 지원을 구현하는 다음과 같은 구성요소가 포함되어 있습니다. 이러한 지원은 애플리케이션이 SSL/TLS 라이브러리를 사용하는 방법에 기반하여 사용할 수 있습니다.

OpenSSL에서 SSLv2

OpenSSL을 사용하는 애플리케이션은 어떤 SSL/TLS프로토콜 버전을 사용할 것인가를 라이브러리에 알리기 위해 연결 방식을 선택해야 합니다. OpenSSL 연결 방식은 단일 프로토콜 버전을 사용하거나 특정 방식인 SSLv23을 사용하여 라이브러리가 지원하는 모든 프로토콜 버전을 활성화할 수 있습니다. 이는 가장 일반적으로 사용되는 연결 방식입니다. SSLv2 프로토콜은 이러한 방식이 선택되면 자동으로 활성화됩니다. 애플리케이션 차원에서 SSLv2를 비활성화하기 위해서는 관련 SSL_CTX 또는 SSL 개체에 있는 SSL_OP_NO_SSLv2 옵션을 명시적으로 설정해야 합니다. 대부분의 애플리케이션은 이와 같이 무조건적으로 또는 설정에 따라 실행되지만 일부 애플리케이션은 활성화된 프로토콜의 기본 설정을 사용합니다. 따라서 OpenSSL 라이브러리를 사용하는 애플리케이션은 SSLv2를 활성화한 상태에서 실행될 가능성이 높습니다.

본 문제를 해결하려면 Red Hat 제품에 포함된 OpenSSL에 다음과 같은 변경 사항을 적용해야 합니다:

• SSLv23 연결 방식을 사용할 때 SSLv2 프로토콜은 더이상 기본값으로 활성화되지 않습니다.
  40 비트 (EXPORT) 또는 56 비트 (단일 DES) 대칭 암호화 키를 사용하는 모든 SSLv2 암호 그룹은 현재 비활성화되어 있어 더이상 사용할 수 없습니다. 다음과 같은 암호 그룹은 더이상 사용할 수 없습니다:
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
    Red Hat Enterprise Linux 4 및 5의 모든 업데이트에 있는 openssl 패키지의 OpenSSL 버전은 OPENSSL_ENABLE_SSL2 환경 변수를 확인하고 이러한 변수가 지정되어 있을 경우 SSLv23 연결 방식을 사용할 때 SSLv2는 기본값으로 활성화되어 있습니다. 필요한 경우 이러한 환경 변수는 SSLv2를 다시 활성화하는데 사용할 수 있습니다.

SSLv2 연결 방식은 SSLv23 연결 방식의 변경에 의해 영향을 받지 않으므로 SSLv2 프로토콜을 사용하여 연결을 설정하기 위해 여전히 사용될 수 있습니다.

또한 Red Hat Enterprise Linux 6 및 7에 탑재된 OpenSSL 버전에 있는 DEFAULT 암호 목록에는 모든 SSLv2 암호 그룹이 제외되어 있으므로 이러한 기본값으로 비활성화된 암호 그룹 사용을 강제하는 클라이언트에서 서버가 SSLv2 연결을 허용하게 할 수 없습니다. 본 문제는 CVE-2015-3197로 지정되어 있으며 DROWN 문제 해결을 위한 업데이트에서 수정되어 있습니다.

NSS (Network Security Services)에서 SSLv2

NSS 암호화 라이브러리는 SSLv2 프로토콜을 구현하지만 기본값으로 활성화되어 있지 않습니다. 애플리케이션은 사용할 SSLv2를 활성화하기 위해 라이브러리에게 명시적으로 요청해야 합니다. Red Hat Enterprise Linux 7에 탑재된 NSS 버전은 SSLv2 프로토콜 활성화를 허용하지 않습니다. NSS 라이브러리를 사용하는 애플리케이션은 활성화된 SSLv2로 실행되지 않습니다.

NSS 라이브러리는 기본값으로 SSLv2를 사용하지 않기 때문에 DROWN 문제를 해결하기 위해 즉각적인 업데이트가 예정되어 있지 않습니다. Red Hat Enterprise Linux 6의 향후 업데이트에서는 Red Hat Enterprise Linux 7에서 이를 비활성화하는 방법과 유사하게 프로토콜을 비활성화할 것으로 예상합니다.

SSLv2 지원되지 않는 SSL 및 TLS 라이브러리

Red Hat 제품에는 일부 TLS 또는 SSL 프로토콜 버전을 구현하지만 SSLv2 지원을 구현하지 않는 다음과 같은 구성 요소가 포함되어 있습니다. 따라서 이러한 구성 요소는 본 문제에 영향을 받지 않습니다. 이러한 영향을 받지 않는 라이브러리를 사용하는 애플리케이션은 SSLv2를 지원하는 SSL/TLS 라이브러리를 사용하는 다른 애플리케이션과 RSA 개인키를 공유하고 있을 경우 DROWN 공격에 의해 영향을 받을 수 있습니다.

• GnuTLS
• OpenJDK (java-1.6.0-openjdk, java-1.7.0-openjdk, java-1.8.0-openjdk 패키지)
• Oracle JDK (java-1.6.0-sun, java-1.7.0-oracle, java-1.8.0-oracle 패키지)
• IBM JDK (java-1.6.0-ibm, java-1.7.0-ibm, java-1.7.1-ibm, java-1.8.0-ibm 패키지)

해결 방법

Red Hat은 고객이 영향을 받는 시스템의 위험 기반 우선 순위 분석을 수행하고 문제를 수정하기 위해 사용 가능한 패치를 즉시 적용하는 것이 좋습니다. 업데이트 후 시스템을 재부팅하는 것이 영향을 받는 모든 서비스가 업데이트된 OpenSSL 라이브러리를 사용하게 하는 가장 안전한 방법입니다. 재부팅이 불가능할 경우 패치 적용 후 OpenSSL에 의존하는 모든 네트워크 서비스를 다시 시작해야 합니다.

감사의 말

Red Hat은 본 문제에 대해 보고해 주신 OpenSSL 프로젝트에게 감사의 말씀을 전합니다. 업스트림에서는 원래 보고자인 Nimrod Aviram 및 Sebastian Schinzel에게도 감사의 말씀을 전합니다.

자주 하는 질문

**애플리케이션 X에서 SSLv2를 어떻게 비활성화합니까?

다양한 Red Hat Enterprise Linux 버전에 탑재된 여러 애플리케이션에서 활성화된 프로토콜 버전과 같이 SSL/TLS 관련 설정을 변경하는 방법에 대한 설명은 지식 베이스 문서 Securing Application 'X' in RHEL 'Y' ? 에서 참조하십시오.

본 문제로 인해 서버 키나 인증서를 다시 생성해야 합니까?

아니요. DROWN은 RSA 개인키를 직접적으로 공개하지 않지만 SSL/TLS 연결 핸드셰이크 동안 생성된 개별 세션키가 공격의 대상이 되어 대칭 암호화에 사용됩니다. 이러한 키의 손상으로 인해 특정 SSL/TLS 세션 암호가 해독될 수 있습니다. 따라서 서비스가 DROWN 공격에 취약하다고 감지되는 경우에도 서비스키나 인증서를 다시 생성할 필요가 없습니다.

Red Hat 제품에 탑재된 Apache httpd 웹 서버 버전에서 SSLv2를 사용할 수 있습니까?

Apache httpd 웹 서버는 다음 모듈 중 하나를 사용하여 HTTPS 서비스를 제공할 수 있습니다:

• mod_ssl - 이 모듈은 OpenSSL 암호화 라이브러리를 사용하고 있으며 Apache httpd 웹 서버 배포판의 일부로 포함되어 있습니다.
• mod_nss - 이 모듈은 NSS 암호화 라이브러리를 사용하고 있으며 Apache httpd 프로젝트와는 별도로 배포 및 개발됩니다.

이러한 모듈 모두는 Red Hat 제품에 포함되어 있습니다.

mod_ssl을 사용하는 httpd의 기본 설정은 다음과 같습니다:

httpd24컬렉션, Red Hat Software Collections에 있는 Red Hat JBoss Web Server 3와 Red Hat Enterprise Linux 7에 탑재된 httpd 버전은 업스트림 httpd 버전 2.4를 기반으로 하며 SSLv2 프로토콜을 사용하도록 설정할 수 없습니다.

Red Hat Enterprise Linux 5 및 6, Red Hat JBoss Web Server 1 및 2, Red Hat JBoss Enterprise Application Platform 6에 탑재된 httpd 버전은 업스트림 httpd 버전 2.2를 기반으로 합니다. 이러한 버전은 SSLv2를 사용하도록 설정할 수 있지만 프로토콜은 기본 설정으로 비활성화되어 있습니다. /etc/httpd/conf.d/ssl.conf 설정 파일에는 SSLv2를 비활성화하는 다음과 같은 설정 지시문이 포함되어 있습니다:

SSLProtocol all -SSLv2

Red Hat Enterprise Linux 4에 탑재된 httpd 버전은 업스트림 httpd 버전 2.0을 기반으로 합니다. 기본 설정은 SSLv2를 활성화하고 있으며 위의 /etc/httpd/conf.d/ssl.conf 설정 파일에 나열된 것과 동일한 SSLProtocol 지시문을 추가하고 httpd 서비스를 다시 시작하여 비활성화할 수 있습니다.

mod_nss를 사용하는 httpd의 기본 설정은 다음과 같습니다:

Red Hat Enterprise Linux 5, 6, 7에 탑재된 mod_nss 버전은 기본값으로 SSLv2를 사용하지 않습니다. /etc/httpd/conf.d/nss.conf 설정 파일에는 mod_nss 패키지 버전에 따라 SSLv3 이상 버전 또는 TLSv1.0 이상 버전 만을 활성화하는 다음과 같은 설정 지시문 중 하나가 포함되어 있습니다:

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

알림: SSLv3 프로토콜에는 이미 알려진 문제가 있으므로 해당 버전을 비활성화할 것을 권장합니다. Red Hat 제품의 다양한 구성 요소에 SSLv3 프로토콜을 비활성화하는 방법에 대한 보다 자세한 내용은 관련 문서 POODLE: SSLv3 취약점 (CVE-2014-3566)에서 참조하십시오.

Red Hat Enterprise Linux에 탑재된 메일 SMTP 서버에서 SSLv2가 활성화되어 있습니까?

Red Hat Enterprise Linux 5, 6, 7에 있는 Postfix 및 Sendmail 메일 서버의 기본 설정에는 SSL/TLS 암호화가 활성화되어 있지 않습니다.

시스템 관리자가 Postfix에서 SSL/TLS를 사용하는 경우 SSLv2는 편의적 암호화를 사용하여 기본값으로 강제 암호화를 사용하지 않을 수 있습니다. Red Hat Enterprise Linux 6 및 7에서 smtpd_tls_protocols 설정 옵션을 사용하여 편의적 암호화로 SSLv2를 비활성화할 수 있습니다.

시스템 관리자가 Sendmail에서 SSL/TLS를 사용하는 경우 SSLv2는 기본값으로 활성화됩니다. Red Hat Enterprise Linux 5, 6, 7에서 ServerSSLOptions 설정 옵션을 사용하여 SSLv2를 비활성화할 수 있습니다.

Postfix 및 Sendmail에서 SSL/TLS를 설정하는 방법은 위의 "애플리케이션 X에서 SSLv2를 어떻게 비활성화합니까?" 질문에 있는 링크에서 참조하십시오.

EAP 6.4 설치를 업데이트해야 합니까?
EAP는 Java 암호화 공급자 (JSSE) 또는 네이티브 공급자 (APR/OpenSSL)를 사용하여 설정할 수 있습니다. Apr/OpenSSL 공급자를 사용하고 있을 경우 다음 절차를 따르십시오:

• Red Hat Enterprise Linux
  OpenSSL 버전을 업그레이드합니다.
• Windows 또는 Solaris
  openssl 라이브러리 업데이트는 고객 서비스 플랫폼에서 사용할 수 있습니다. 이 업데이트는 libssl 및 libeay 라이브러리와 openssl 애플리케이션을 대체합니다.

EAP 6.4는 APR/OpenSSL을 사용하여 Windows 에서 테스트되었으며 기술적으로 OpenSSL 라이브러리를 업데이트해야 하지만 기본값으로 EAP 6.4는 TLSv1을 사용하여 SSLv2 및 SSLv3에 대한 암호 요청을 거부합니다. EAP는 현재 이러한 결함에 취약점이 없는 것으로 예상하고 있습니다.

EAP 5.2 설치를 업데이트해야 합니까?
EAP는 Java 암호화 공급자 (JSSE) 또는 네이티브 공급자 (APR/OpenSSL)를 사용하여 설정할 수 있습니다. Apr/OpenSSL 공급자를 사용하고 있을 경우 다음 절차를 따르십시오:

• Red Hat Enterprise Linux
  OpenSSL 버전을 업그레이드합니다.
• Windows 또는 Solaris
  openssl 라이브러리 업데이트는 고객 서비스 플랫폼에서 사용할 수 있습니다. 이 업데이트는 libssl 및 libeay 라이브러리와 openssl 애플리케이션을 대체합니다.

EAP 5.2는 이 결함의 취약성을 평가하기 위해 Windows에서 테스트되고 있습니다.

EWS 2.1설치를 업데이트해야 합니까?
본 결함은 APR/OpenSSL이 보안 공급자로 설정된 WIndows 및 Solaris 설치에만 영향을 미칩니다. EWS 2.1은 현재 SSLv2 및 SSLv3을 지원합니다.
Apr/OpenSSL 공급자를 사용하고 있을 경우 다음 절차를 따라야 합니다:

• Red Hat Enterprise Linux
  OpenSSL 버전을 업그레이드합니다.
• Windows 또는 Solaris
  openssl 라이브러리 업데이트는 고객 서비스 플랫폼에서 사용할 수 있습니다. 이 업데이트는 libssl 및 libeay 라이브러리와 openssl 애플리케이션을 대체합니다.

A: EWS 2.1은 본 결함에 영향을 받으며 고객 서비스 포털에서 업데이트를 사용할 수 있습니다. 본 결함은 APR/OpenSSL이 보안 공급자로 설정된 WIndows 및 Solaris 설치에만 영향을 미칩니다. JSSE 기본 설정은 영향을 받지 않으며 고객 서비스 포털에서 업데이트를 사용할 수 있습니다.

EWS 3.0.2 설치를 업데이트해야 합니까?
본 결함은 APR/OpenSSL이 보안 공급자로 설정된 WIndows 및 Solaris 설치에만 영향을 미칩니다. EWS 3.0.2는 현재 SSLv2 및 SSLv3을 지원합니다. EWS 3.0.3이 출시되면 SSLv2 또는 SSLv3가 더이상 제공되지 않을 예정입니다.

Apr/OpenSSL 공급자를 사용하고 있을 경우 다음 절차를 따라야 합니다:

• Red Hat Enterprise Linux
  OpenSSL 버전을 업그레이드합니다.
• Windows 또는 Solaris
  openssl 라이브러리 업데이트는 고객 서비스 플랫폼에서 사용할 수 있습니다. 이 업데이트는 libssl 및 libeay 라이브러리와 openssl 애플리케이션을 대체합니다.

tomcat-native 패키지의 상태는 어떠합니까?

tomcat-native 패키지는 본 결함에 의한 영향을 받지 않습니다. tomcat-native 패키지는 OpenSSL 라이브러리를 제공하는 시스템에 의존합니다.