Badlock: Samba에서의 SAMR 및 LSA 프로토콜 중간 가로채기 공격 (CVE-2016-2118)

Red Hat 제품 보안팀은 DCE/RPC-기반 SAMR 및 LSA 프로토콜에서 ( Microsoft Windows Active Directory 인프라에서 사용) 취약점을 인지하고 있습니다. 이러한 문제는 [CVE-2016-2118]에서 다루고 있습니다. (https://access.redhat.com/security/cve/CVE-2015-2118)

알림: 이는 프로토콜 관련 문제로 이 프로토콜을 구현하는 모든 애플리케이션에 영향을 미칩니다. (Samba - CVE-2016-2118 및 Microsoft Windows - CVE-2016-0128 포함)

배경 정보

DCE/RPC는 API 및 네트워크 프로토콜 모두를 정의하는 원격 프로시저 호출 메커니즘에 대한 사양입니다. SAM (Security Account Manager) 원격 프로토콜 (클라이언트-서버 간) 은 사용자 및 그룹이 포함된 계정 저장소 또는 디렉토리에 대한 관리 기능을 제공합니다. 프로토콜은 로컬 및 원격 Microsoft Active Directory 도메인에 대해 “계정 데이터베이스”를 제공합니다. LSA (Local Security Authority) (도메인 정책) 원격 프로토콜은 다양한 시스템 및 도메인 보안 정책을 관리하는데 사용됩니다. 이러한 프로토콜은 약간의 예외를 제외하고 원격 정책 관리 시나리오를 가능하게 합니다. SAMR 및 LSA 프로토콜 모두는 DCE 1.1 RPC 프로토콜을 기반으로 합니다.

이러한 프로토콜은 일반적으로 모든 Windows 설치 뿐 만 아니라 모든 Samba 서버에서 사용할 수 있습니다. 이는 SAM (Security Account Manager) 데이터 베이스를 유지 관리하는데 사용됩니다. 이는 모든 역할 (예: 독립형, 도메인 컨트롤러, 도메인 구성원)에 적용됩니다.

공격 내용 및 영향

클라이언트가 서버에 대해 개시한 인증된 DCE/RPC 연결은 중간 가로채기(man-in-the-middle ) 공격자가 서버 상의 SAMR 또는 LSA 서비스에 대해 인증된 사용자로 가장하여 사용될 수 있습니다. 그 결과 공격자는 모든 암호 및 기타 다른 기밀 정보를 유출할 수 있는 SAM (Security Account Manager) 데이터베이스에 대한 읽기/쓰기 권한을 얻을 수 있습니다.

이러한 경우 클라이언트가- 선택한 애플리케이션 프로토콜, 인증 유형 (예: Kerberos 또는 NTLMSSP) 및 인증 수준 (NONE, CONNECT, SIGN, SEAL)은 문제가 되지 않습니다. 중간 가로채기 (man-in-the-middle ) 공격자가 CONNECT로 인증 수준을 다운그레이드하여 연결을 탈취할 수 있습니다.

Red Hat Enterprise Linux 서버 및 Red Hat Gluster Storage에 탑재된 모든 Samba 패키지 버전은 본 결함에 의한 영향을 받습니다. Red Hat 제품 보안팀은 본 결함에 대해 중요한 보안 영향을 미치는 것으로 평가하고 있습니다.

영향받는 설정

• Samba 서버가 도메인 멤버로 있는 Active Directory 인프라는 본 결함에 취약합니다. 중간 가로채기(man-in-the-middle) 공격자는 클라이언트로 가장하여 도메인 멤버와 도메인 컨트롤러 사이의 DCE/RPC 트래픽을 가로채기하여 인증된 사용자 계정과 동일한 권한을 얻을 수 있습니다. 공격자는 사용자 암호 해시, 중요한 서비스 종료를 포함하여 AD 데이터베이스 내에서 기밀 정보를 확인하거나 수정할 수 있습니다.

• 파일 또는 인쇄 서버로 구성된 모든 Samba 서버도 본 결함에 취약합니다. 공격자는 결함을 악용하여 파일 또는 디렉토리에 있는 사용자 권한을 수정할 수 있습니다.

완화 방법

위험 완화 방법으로 수정 사항이 포함된 패키지가 적용될 때 까지 권한 계정을 사용하여 SMB/CIFS 서비스에 액세스하지 않습니다. 인증에 네트워크 통신이 필요하지 않도록 물리적 하드웨어 (콘솔, 서버)에 대한 관리 액세스를 제한합니다.

해결 방법

감사의 말

Red Hat은 본 문제에 대해 보고해 주신 Samba프로젝트에게 감사의 말씀을 전합니다. 업스트림에서는 원래 보고자인 Stefan Metzmacher (SerNet)에게도 감사의 말씀을 전합니다.

추가 정보

본 결함에 대한 보안 업데이트에서는 다음과 같이 smb.conf에 새로운 옵션을 소개하고 있습니다:

  allow dcerpc auth level connect (G)

이 옵션은 DCERPC 서비스가 인증 정보를 제공하지만
    메세지별 무결성 (SIGN) 또는 개인 정보 보호 (SEAL)를 제공하지 않는 DCERPC_AUTH_LEVEL_CONNECT와 함께 사용할 수 있는지에 대한 여부를 제어합니다.

   samr, lsarpc, netlogon과 같은 일부 인터페이스는 
    기본값이 no로 하드코딩되어 있으며 epmapper, mgmt, rpcecho는 기본값이 yes로 하드코딩되어 있습니다.

    동작은 인터페이스 이름 (예: lsarpc, netlogon, samr, srvsvc, winreg, or wkssvc)에 따라
    다음과 같이 지정하여 덮어쓰기할 수 있습니다
    'allow dcerpc auth level connect:interface = yes'.

    이 옵션은 특정 구현 -제한 사항보다 우선합니다.
    예:
    * drsuapi 및 backupkey 프로토콜에는 DCERPC_AUTH_LEVEL_PRIVACY가 필요합니다.
    * dnsserver 프로토콜에는 DCERPC_AUTH_LEVEL_INTEGRITY가 필요합니다.

    기본값: allow dcerpc auth level connect = no
    예: allow dcerpc auth level connect = yes

자주하는 질문

내 인프라에 있는 Samba 서버 및 Samba 클라이언트 모두를 업데이트해야 합니까?

최소한 Samba 서버를 업데이트해야 합니다. Badlock은 프로토콜 관련 결함이기 때문에 Samba 인프라 설정에 따라 서버 및 클라이언트 모두 영향을 받을 수 있습니다. Red Hat 제품 보안팀은 서버 및 클라이언트 모두를 업데이트할 것을 권장합니다.

업데이트된 패키지가 적용되더라도 이전의 오래된 Samba 버전을 실행하고 있는 기존 클라이언트가 있는 경우 문제가 될 수 있습니까?

이 보안 권고는 Samba 설정을 위해 사용된 일부 보안 옵션에 제한되어 있습니다. 따라서 Samba 서버를 업데이트하지만 클라이언트를 업데이트하지 않을 경우 설정을 손상시킬 수 있습니다. 상호 운용성을 지속하기 위해 (예: smb.conf 파일에서 allow dcerpc auth level connect = yes를 설정) 이전의 오래된 비보안 옵션으로 롤백할 수 있지만 이는 공격 벡터에 다시 노출 될 수 있으므로 Red Hat 제품 보안팀은 이러한 방법을 사용하는 것을 권장하지 않습니다.

내 Samba 서버 인스턴스는 Windows 도메인에 연결되어 있지 않습니다. 이러한 경우에도 여전히 취약점의 영향을 받게 됩니까?

예. 관리자가 비보안 클라이언트를 사용하여 Samba 서버와 통신하거나 보안 클라이언트를 사용하여 비보안 Samba 서버와 통신할 경우 중간 가로채기 공격자가 이 옵션을 사용하여 결함을 악용할 수 있습니다.

내 Samba 서버 및 클라이언트를 업데이트했습니다. 다시 시작해야 할 서비스가 있습니까?

아니요. 시스템에 업데이트가 적용되면 smb 서비스는 자동으로 다시 시작됩니다.

MITM 공격에 대응하기 위해 암호화하는 것이 보안 방법이 될 수 있습니까?

파일을 일반 텍스트로 전송하는 동안 SMB 프로토콜은 기본값으로만 인증 정보 및 명령을 암호화합니다. 보안 및 개인 정보 보호 관련 중요 상황에서 모든 통신을 보안하기 위해 암호화를 사용하는 것이 좋습니다. 암호화는 Samba 3.2 버전에 추가되어 있지만 Samba 클라이언트 용으로 제한됩니다. Microsoft는 Windows 8 및 Windows Server 2012에서 SMB 3.0에 SMB 암호화 지원을 추가했습니다. 하지만 이러한 암호 유형 모두 파일 전송과 같은 통신만을 보안하고 SMB 협상 및 명령을 실행한 후 작동합니다. 이러한 단계에는 위의 취약점이 포함되어 있기 때문에 Samba/SMB 암호화는 좋은 보안 방법이지만 취약점에 대한 보안 방법으로는 충분하지 않습니다.

참조 정보

http://badlock.org/