Microsoft Security Bulletin MS10-049 - 긴급

완화란 취약점의 악용 심각도를 낮출 수 있는 설정, 일반적인 구성 또는 최선책, 기본 상태를 지칭합니다. 다음과 같은 완화 요소가 현재 상황에서 유용할 수 있습니다.

• SSL을 통한 콘텐츠는 호스팅하지 않지만 HTTP(일반 텍스트) 연결을 통한 서버 콘텐츠는 호스팅하는 웹 사이트는 영향을 받지 않습니다.
• IIS(인터넷 정보 서비스) 6 및 IIS 7은 클라이언트에서 시작되는 재협상을 허용하지 않습니다. 이 경우 공격 영역이 상당히 감소됩니다. 사용자가 사용자 이름 및 암호를 입력하는 SSL 사이트는 취약하지 않습니다. IIS 6 및 IIS 7에서 스푸핑을 허용하는 가장 가능성이 높은 시나리오는 상호 인증 수행을 위해 클라이언트쪽 인증서를 사용하는 경우입니다. 이는 일반적인 시나리오가 아닙니다.
• 이러한 고객은 공격자가 로컬 서브넷 공격 또는 DNS 스푸핑과 같은 다른 취약점을 악용하여 MITM(Man-in-the-Middle) 공격을 수행할 수 있는 경우에만 영향을 받습니다.

대안이란 기본적인 취약점을 수정하지는 않지만 업데이트를 적용하기 전에 알려진 공격 경로를 차단하는 데 유용한 설정 또는 구성 변경을 지칭합니다. Microsoft는 다음과 같은 대안을 테스트했으며, 대안으로 인한 기능 저하 여부를 해당 항목에서 설명합니다.

• IIS 6 이상에서 SSLAlwaysNegoClientCert 사용

  IIS 6 이상을 실행하는 웹 서버는 클라이언트 인증서를 요청하는 상호 인증의 요구로 인해 영향을 받으며, SSLAlwaysNegoClientCert 설정을 사용하여 보안을 강화할 수 있습니다. 따라서 처음 연결하면 IIS에 클라이언트 인증을 요구하는 대화 상자가 표시되고, 서버에서 시작하는 재협상은 요구하지 않습니다.

  대안의 영향: 이 플래그를 설정하면 SSL 보호 웹 사이트에서 모든 요소를 로드하기 전에 클라이언트에서 인증을 해야 합니다. 이로 인해 브라우저에는 SSL 보호 웹 사이트에 연결 시 클라이언트 인증을 묻는 대화 상자가 항상 표시됩니다. SSL 보호 콘텐츠에 상호 인증이 필요하지 않은 경우, 인증서를 선택하라는 메시지가 표시된 사용자는 인증할 클라이언트 인증서를 선택하지 않고 대화 상자를 닫아 SSL 연결을 통해 콘텐츠를 볼 수 있습니다.

  IIS 6:

  향상된 권한의 관리자 명령 프롬프트의 "c:\inetpub\adminscripts" 폴더에서 다음 명령을 실행합니다.

  adsutil.vbs SET w3svc/<N>/SSLAlwaysNegoClientCert true

  여기에서 <N>은 구성할 웹 사이트의 번호를 나타냅니다(즉 '기본 웹 사이트'가 1이면 다음 웹 사이트는 2가 됨). 예를 들어 IIS에서 만든 '기본 웹 사이트'를 보호하기 위해 다음 명령을 사용할 수 있습니다.

  adsutil.vbs SET w3svc/1/SSLAlwaysNegoClientCert true

  IIS 7:

  "Enable_SSL_Renegotiate_Workaround.js"라는 파일에 다음 텍스트를 저장합니다.

  var vdirObj=GetObject("IIS://localhost/W3svc/1");
// 이 행의 1을 구성할 웹 사이트의 번호로 교체

WScript.Echo("Value of SSLAlwaysNegoClientCert Before: " + vdirObj.SSLAlwaysNegoClientCert);
vdirObj.Put("SSLAlwaysNegoClientCert", true);
vdirObj.SetInfo();
WScript.Echo("Value of SSLAlwaysNegoClientCert After: " + vdirObj.SSLAlwaysNegoClientCert);

  향상된 권한의 관리자 명령 프롬프트에서 다음 명령을 실행합니다.

  cscript.exe enable_ssl_renegotiate_workaround.js

이 취약점을 악용하면 어느 작업까지 가능합니까?  
이 취약점은 스푸핑 취약점입니다. 이 취약점을 악용한 공격자는 TLS/SSL 보호된 연결에 정보를 적용할 수 있으며, 이를 통해 트래픽을 효과적으로 보내 인증된 클라이언트에 스푸핑을 시도할 수 있습니다.

취약점의 원인은 무엇입니까?  
TLS 프로토콜(RFC 2246의 설명 참조)은 재협상의 기능을 설명하며, 이를 통해 각 피어는 한 시점에서 보호된 연결의 매개 변수를 다시 협상할 수 있습니다. 이러한 연결에서 MITM(Man-in-the-Middle) 공격을 위해 DNS 스푸핑 또는 로컬 서브넷 공격과 같은 다른 공격을 이용할 수 있는 공격자는, 설정되어 있는 유효한 TLS 세션에 응용 프로그램 특정 명령을 추가하기 위해 이와 같은 재협상 기능을 악용할 수 있습니다.

특정 시나리오의 경우, 서버는 TLS/SSL 인증 클라이언트 컨텍스트에서 해당 명령을 실행할 수 있습니다. Windows에서 TLS 및 SSL은 Secure Channel(SChannel) 보안 패키지를 통해 구현됩니다.

IIS 6.0 이상의 기본 설치가 이 취약점의 영향을 받지 않는 이유는 무엇입니까?
이 취약점은 각 연결 피어가 TLS/SSL 매개 변수를 다시 협상할 수 있도록 허용된 경우에만 악용될 수 있습니다. IIS는 클라이언트에서 시작되는 TLS/SSL 재협상을 방지합니다. 또한 IIS는 인증서 기반의 상호 인증(기본이 아닌 설정) 사용하도록 구성된 경우 서버쪽 재협상 시도만 시작하게 됩니다.

실제 TLS/SSL 연결이 IIS 서버에서 바로 종료되지 않고 타사 SSL 종결자 또는 리버스 프록시에서 종료되는 배포 환경에서 해당 연결은 여전히 이 취약점의 영향을 받게 될 수 있습니다.

MITM(Man-in-the-Middle) 공격이란 무엇입니까?
MITM(Man-in-the-Middle) 공격은 두 통신 사용자가 알지 못하게 공격자가 공격자의 컴퓨터를 통해 두 사용자 사이의 통신을 다시 라우팅할 때 발생합니다. 이러한 통신에서 각 사용자는 의도한 상대방과만 통신 중이라고 생각하면서 자신도 모르게 공격자와 트래픽을 주고 받게 됩니다. 이 취약점의 경우 MITM(Man-in-the-Middle) 공격자는 클라이언트와 서버 사이에서 암호화된 통신을 읽거나, 해독하거나 변경할 수 없습니다. MITM(Man-in-the-Middle) 공격자는 클라이언트 컨텍스트에서 실행되는 TLS 세션에 요청을 만들 수 있습니다.

상호 인증이란 무엇입니까?
상호 인증이란 모든 응용 프로그램 트래픽이 클라이언트와 서버 간 연결을 통해 전송되기 전에, 클라이언트 프로세스를 통해 서버에게 자신의 ID를 입증하고 서버는 클라이언트에게 자신의 ID를 입증하는 보안 기능입니다.

상호 인증을 사용하려면 모든 응용 프로그램 기능을 실행하기 전에 클라이언트 및 서버는 각자의 ID를 서로 입증해야 합니다. ID는 공개 키 인프라 및 디지털 인증과 마찬가지로 암호를 통해 입증할 수 있습니다.

TLS란 무엇입니까?
TLS(Transport Layer Security) 핸드셰이크 프로토콜은 보안 세션을 구축하거나 다시 시작하는 데 필요한 인증 및 키 교환을 담당합니다. 보안 세션을 구축할 때 핸드셰이크 프로토콜은 다음 사항을 관리합니다.

암호 그룹 협상

서버 및 클라이언트(옵션)의 인증

세션 키 정보 교환

자세한 내용은 TechNet 문서 How TLS/SSL works(TLS/SSL 작동 방식) (영문)를 참조하십시오.

SSL이란 무엇입니까?
SSL이란 TLS(Transport Layer Security) 프로토콜의 선행 작업으로, TLS와 동일한 기능을 수행하며 공개 및 비밀 키 기술의 조합을 사용하는 보안 네트워크 통신을 지원합니다.

자세한 내용은 TechNet 문서 How TLS/SSL works(TLS/SSL 작동 방식) (영문)를 참조하십시오.

TLS/SSL 재협상이란 무엇입니까?
재협상이란 TLS 및 SSL 프로토콜 기능으로, 이를 통해 각 피어는 보안 키 등 암호 연결용 매개 변수를 다시 협상할 수 있습니다.

SChannel 보안 패키지란 무엇입니까?   
Secure Channel(Schannel) 보안 패키지는 SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 인터넷 표준 인증 프로토콜을 구현하는 SSP(보안 지원 공급자)입니다. 이러한 구성 요소는 웹 탐색과 같은 여러 일반 인터넷과 네트워크 응용 프로그램을 지원하는 보안 통신을 구현하는 데 사용됩니다. SChannel은 클라이언트와 서버 간에 보안 통신을 지원하기 위한 인증 서비스를 제공하는 보안 패키지의 일부입니다.

자세한 내용은 MSDN 문서, Secure Channel (영문)을 참조하십시오.

공격자는 취약점을 악용하여 무엇을 할 수 있습니까?  
취약한 배포 환경에서 공격자는 이 취약점을 이용하여 유효한 TLS/SSL 인증 세션의 컨텍스트에서 클라이언트에서 서버로 전송되는 합법적인 요청에 내용을 추가할 수 있습니다. 이 취약점을 사용하여 공격자가 클라이언트와 서버 사이에서 암호화된 트래픽을 읽거나, 해독하거나 변경할 수는 없습니다.

공격자는 이러한 취약점을 어떻게 악용합니까?  
공격자는 클라이언트와 서버 간에 MITM(Man-in-the-Middle) 공격을 설정하여 이 취약점을 악용할 수 있으며, 이에 따라 SSL 재협상 시도가 발생하는 즉시 연결이 중단될 수 있습니다. 이 시점에서 공격자는 보호된 경로에 제한된 데이터 집합을 적용할 수 있으며, 이 때 서버는 이를 신뢰할 수 있는 클라이언트에서 발생하는 것으로 해석할 수 있습니다.

취약점으로 인해 주로 공격 받을 위험이 있는 시스템은 무엇입니까?  
이 취약점은 주로 웹 브라우저 및 해당 웹 서버에 대해 사용되는 클라이언트에 영향을 미치지만, 이 공격의 일부는 기타 TLS/SSL 보호 프로토콜에 영향을 미칠 수 있습니다.

업데이트는 어떤 기능을 수행합니까?  
업데이트는 RFC 5746을 구현하여 이 취약성을 해결합니다. 이 RFC는 TLS 재협상을 재협상이 수행된 원본 TLS 연결에 암호화로 연결한 TLS 확장을 소개합니다. 이를 통해 인증을 수행한 후 검증하여 공격을 방지할 수 있습니다.

이 보안 공지를 게시했을 때 이 취약점이 공개되어 있었습니까?  
예. 이 취약점은 공개되었습니다. 이 취약점에는 CVE(Common Vulnerability and Exposure) 번호 CVE-2009-3555 (영문)가 지정되었습니다.

이 보안 공지를 게시했을 때 Microsoft는 이 취약점이 악용되었다는 보고를 받았습니까?  
아니요. Microsoft는 이 보안 공지를 처음에 게시했을 때 이 취약점이 고객을 공격하는 데 공개적으로 사용되었다는 정보를 확인하지 못했습니다.

이 취약점에 대해 확인된 완화 요소가 없습니다.

이 취약점에 대한 대안을 확인하지 못했습니다.

이 취약점을 악용하면 어느 작업까지 가능합니까?  
이 취약점은 원격 코드 실행 취약점입니다. 이 취약점을 악용한 공격자는 영향을 받는 시스템을 원격으로 완전히 제어할 수 있습니다. 이렇게 되면 공격자가 프로그램을 설치할 수 있을 뿐 아니라 데이터를 보거나 변경하거나 삭제할 수 있고 모든 사용자 권한이 있는 새 계정을 만들 수도 있습니다. 이 취약점을 악용하면 원격 코드 실행보다는 서비스 거부 조건이 발생할 가능성이 큽니다.

취약점의 원인은 무엇입니까?  
이 취약점은 SChannel에서 서버가 보낸 인증서 요청 메시지에 대한 유효성 검사를 충분히 수행하지 못해 발생합니다.

SChannel 보안 패키지란 무엇입니까?   
Secure Channel(Schannel) 보안 패키지는 SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 인터넷 표준 인증 프로토콜을 구현하는 SSP(보안 지원 공급자)입니다. 이러한 구성 요소는 웹 탐색과 같은 여러 일반 인터넷과 네트워크 응용 프로그램을 지원하는 보안 통신을 구현하는 데 사용됩니다. SChannel은 클라이언트와 서버 간에 보안 통신을 지원하기 위한 인증 서비스를 제공하는 보안 패키지의 일부입니다.

자세한 내용은 MSDN 문서, Secure Channel (영문)을 참조하십시오.

TLS란 무엇입니까?
TLS(Transport Layer Security) 핸드셰이크 프로토콜은 보안 세션을 구축하거나 다시 시작하는 데 필요한 인증 및 키 교환을 담당합니다. 보안 세션을 구축할 때 핸드셰이크 프로토콜은 다음 사항을 관리합니다.

암호 그룹 협상

서버 및 클라이언트(옵션)의 인증

세션 키 정보 교환

자세한 내용은 TechNet 문서 How TLS/SSL works(TLS/SSL 작동 방식) (영문)를 참조하십시오.

SSL이란 무엇입니까?
SSL이란 TLS(Transport Layer Security) 프로토콜의 선행 작업으로, TLS와 동일한 기능을 수행하며 공개 및 비밀 키 기술의 조합을 사용하는 보안 네트워크 통신을 지원합니다.

자세한 내용은 TechNet 문서 How TLS/SSL works(TLS/SSL 작동 방식) (영문)를 참조하십시오.

공격자는 취약점을 악용하여 무엇을 할 수 있습니까?  
이 취약점을 악용한 공격자는 이론적으로는 영향을 받는 시스템을 완전히 제어할 수 있습니다. 그러나 이 취약점을 악용하려는 시도의 대부분은 서비스 거부를 유발합니다. 시스템을 다시 시작하기 전까지는 시스템에서 SSL 또는 TLS를 사용하는 웹 사이트나 리소스에 연결할 수 없습니다.

공격자는 이러한 취약점을 어떻게 악용합니까?  
공격자는 인터넷 웹 브라우저를 통해 이 취약점을 악용하도록 설계된 특수하게 조작된 웹 사이트를 호스팅한 다음 사용자가 이 웹 사이트를 보도록 유도할 수 있습니다. 공격자는 강제로 사용자가 이러한 웹 사이트를 방문하도록 할 수 없습니다. 대신 공격자는 사용자가 전자 메일 메시지 또는 메신저 요청의 링크를 클릭하여 공격자의 웹 사이트를 방문하도록 유도하는 것이 일반적입니다.

취약점으로 인해 주로 공격 받을 위험이 있는 시스템은 무엇입니까?  
이 취약점으로 악의적인 동작이 발생하려면 사용자가 로그온하여 해당 웹 사이트를 방문해야 합니다. 따라서 워크스테이션이나 터미널 서버와 같이 SSL 또는 TLS를 사용하는 인터넷 웹 브라우저나 응용 프로그램을 빈번히 사용하는 시스템은 이 취약점으로 인한 공격을 받을 위험이 가장 큽니다.

업데이트는 어떤 기능을 수행합니까?  
이 업데이트는 서버에서 반환한 SSL 응답에 대한 추가 유효성 검사를 수행합니다.

이 보안 공지를 게시했을 때 이 취약점이 공개되어 있었습니까?  
아니요. Microsoft는 조정된 취약점 공개를 통해 이 취약점 관련 정보를 입수하였습니다.

이 보안 공지를 게시했을 때 Microsoft는 이 취약점이 악용되었다는 보고를 받았습니까?  
아니요. Microsoft는 이 보안 공지를 처음에 게시했을 때 이 취약점이 고객을 공격하는 데 공개적으로 사용되었다는 정보를 확인하지 못했습니다.

참조 표

다음 표에는 이 소프트웨어에 대한 보안 업데이트 정보가 포함되어 있습니다. 추가 정보는 이 섹션의 배포 정보에서 찾아 볼 수 있습니다.

참고 지원되는 Windows XP Professional x64 Edition 버전의 경우 이 보안 업데이트는 지원되는 Windows Server 2003 x64 Edition 버전의 보안 업데이트와 같습니다.

참조 표

다음 표에는 이 소프트웨어에 대한 보안 업데이트 정보가 포함되어 있습니다. 추가 정보는 이 섹션의 배포 정보에서 찾아 볼 수 있습니다.

참조 표

다음 표에는 이 소프트웨어에 대한 보안 업데이트 정보가 포함되어 있습니다. 추가 정보는 이 섹션의 배포 정보에서 찾아 볼 수 있습니다.

참조 표

다음 표에는 이 소프트웨어에 대한 보안 업데이트 정보가 포함되어 있습니다. 추가 정보는 이 섹션의 배포 정보에서 찾아 볼 수 있습니다.

참조 표

다음 표에는 이 소프트웨어에 대한 보안 업데이트 정보가 포함되어 있습니다. 추가 정보는 이 섹션의 배포 정보에서 찾아 볼 수 있습니다.

참조 표

다음 표에는 이 소프트웨어에 대한 보안 업데이트 정보가 포함되어 있습니다. 추가 정보는 이 섹션의 배포 정보에서 찾아 볼 수 있습니다.