세 번째 KDC 스푸핑 취약점 Silverfort 연구원 – 이번에는 IBM QRadar에서 [CVE-2019-4545]

*****요아브 이엘린, Yaron Kassner, 도르 시걸 & Rotem Zach, Silverfort*****

KDC 스푸핑은 결코 오래되지 않습니다. 우리는 KDC 스푸핑 취약점을 공개했습니다. Cisco ASA 와 팔로알토 네트웍스 PAN-OS 2020년 XNUMX월로 돌아갑니다. 이제 우리는 IBM QRadar가 Kerberos 구현되었습니다.
KDC 스푸핑 취약성으로 인해 공격자는 QRadar에 대한 Kerberos 인증을 우회하여 결과적으로 시스템에 대한 관리 액세스 권한을 얻을 수 있습니다. 우리는 이 문제를 해결하기 위해 IBM 엔지니어와 긴밀히 협력해 왔으며, 그 결과 최근에 발행된 보안 게시판 . 이 블로그 게시물에서는 취약성에 대해 설명하고, Kerberos를 구현하는 개발자로서 이러한 취약성을 피하는 방법을 설명하고, QRadar를 사용하는 조직 및 Kerberos를 사용하는 기타 시스템의 완화에 대해 설명합니다.

취약점 설명

IBM QRadar Security Information and Event Management(SIEM)는 보안 팀이 엔터프라이즈 전체에서 위협을 감지하고 우선 순위를 지정하는 데 도움이 되며, 팀이 사고의 영향을 줄이기 위해 신속하게 대응할 수 있도록 하는 중요한 통찰력을 제공합니다.
취약점은 IBM의 Kerberos 프로토콜 구현에 있습니다. Kerberos는 온프레미스 인증을 위한 가장 일반적인 인증 프로토콜입니다. 의 인기로 인해 기업 네트워크에서 널리 사용됩니다. Active Directory, NTLM과 같은 약한 인증 프로토콜보다 선호됩니다.
IBM은 관리 액세스를 인증하기 위해 Kerberos 인증 프로토콜을 사용합니다. 따라서 Kerberos 인증을 우회하면 공격자가 적법한 자격 증명 없이도 IBM QRadar에 대한 관리 액세스 권한을 얻고 중요한 정보를 보고 잠재적으로 로그를 변경할 수 있습니다.
Kerberos 프로토콜이 작동하려면 다음 세 가지가 발생해야 합니다.

• 1. 사용자가 서버에 인증
  2. 서버가 클라이언트에 인증
  3. KDC는 서버에 대해 인증합니다.

분명히 서버에 대한 KDC 인증은 종종 간과됩니다. 요구 사항이 구성 요구 사항을 복잡하게 만들기 때문일 수 있습니다. 그러나 KDC가 서버에 대해 인증하지 않으면 프로토콜의 보안이 완전히 손상되어 네트워크 트래픽을 하이재킹한 공격자가 잘못된 비밀번호를 포함하여 모든 비밀번호를 사용하여 QRadar에 인증할 수 있습니다.

KDC 스푸핑 공격이 작동하는 방식에 대한 Kerberos 용어 및 배경 정보는 이 블로그 게시물의 끝 부분을 참조하십시오.

QRadar의 취약점을 발견한 방법

QRadar에 대한 관리자 액세스는 무단 액세스 및 시스템 변조를 방지하기 위해 강력한 인증으로 보호되어야 합니다. AD 인증 사용은 널리 사용되는 옵션입니다.
관리자가 QRadar에 인증할 때 여러 매개변수를 사용하여 관리자를 인증합니다(아래에서 가져온 구현 가이드의 스냅샷 참조). 여기에서 지금 확인해 보세요.). 먼저 QRadar는 AD에서 TGT를 요청합니다. TGT를 수신한 후 QRadar는 도메인 컨트롤러에 대한 LDAP 인증을 위한 서비스 티켓을 요청합니다. 성공하면 QRadar는 SASL을 사용하여 DC에 대한 LDAP 인증을 수행합니다. 서비스 티켓을 사용하여 사용자의 신원을 증명합니다.

위장 Kerberos/SASL 인증

공격자가 이러한 종류의 인증을 우회하기 위해 DC를 스푸핑하기 위해 취하는 단계는 다음과 같습니다. QRadar와 DC 간의 네트워크 통신을 하이재킹할 수 있는 능력이 있다고 가정해 보겠습니다. 이 경우 관리자의 사용자 이름과 동일한 사용자 이름과 선택한 암호를 사용하여 가짜 DC를 만들 수 있습니다. 그런 다음 QRadar에 대한 인증을 시작하고 선택한 사용자와 비밀번호를 사용합니다. QRadar는 Kerberos로 인증하고 Kerberos 통신을 하이재킹하고 선택한 암호에 해당하는 AS_REP를 반환합니다. 그리고 우리가 선택한 서비스 세션 키로 암호화된 서비스 티켓과 우리가 선택한 암호로 암호화된 우리가 선택한 세션 키로 구성된 TGS_REP. 이 단계에서 QRadar 측에서 수행되는 유일한 확인은 우리가 선택한 비밀번호에 의존하므로 이 시점에서 QRadar는 인증을 거부하지 않아야 합니다. 이제 QRadar가 서비스 티켓을 수신했으므로 DC에 대한 LDAP 요청을 시작할 수 있습니다. LDAP 트래픽도 하이재킹합니다. 이 시점에서 두 가지 옵션이 있습니다.
1. LDAP가 TLS 없이 사용되고 있습니다. 이 경우 LDAP 트래픽을 하이재킹할 수 있습니다. QRadar는 우리가 가지고 있는 서비스 티켓이 포함된 Kerberos AP_REQ 메시지와 함께 바인드 요청을 DC에 보냅니다. 선택한 서비스 세션 키를 기반으로 하는 AP_REP를 반환할 수 있으며 QRadar가 이를 수락합니다.
2. LDAPS가 구성되었습니다. 이 경우 DC를 대신하여 응답을 반환할 수 없습니다. TLS가 DC를 인증하는 데 사용되고 있기 때문입니다. 즉, QRadar 측에서 인증서가 구성되었다고 가정합니다.

QRadar에 대한 Kerberos/SASL/LDAPS 인증 스푸핑

옵션 2를 포기하기 전에 다음과 같은 이상한 동작을 발견했습니다. IP 주소를 서버 URL로 구성하면 인증이 계속 작동합니다. 이론적으로 IP 주소를 사용한 인증은 작동하지 않아야 합니다. Kerberos는 SPN이 명시적으로 구성되지 않은 경우 IP 주소에 대한 인증을 허용하지 않습니다.
TGS_REQ를 보낼 때 QRadar는 ldap/에 대한 티켓을 요청합니다. DC에는 해당 이름의 서비스 사용자 이름(SPN)이 없으므로 KRB_ERR_S_PRINCIPAL_UNKOWN 오류를 반환합니다. Kerberos 프로토콜에 따르면 QRadar는 이 시점에서 인증을 거부해야 합니다. 그러나 네트워크 캡처는 오류 이후에도 LDAP 요청이 열리고 QRadar에 의해 즉시 재설정됨을 나타냅니다. 그러면 사용자가 로그인할 수 있습니다. 우리는 QRadar가 Kerberos 애플리케이션 교환이 완료되기 전에도 인증이 성공한 것으로 간주한다는 결론을 내립니다. 이것은 쉽게 악용될 수 있습니다. 공격자로서 우리는 AS_REP를 스푸핑한 직후에 KRB_ERR_S_PRINCIPAL_UNKOWN을 보낼 수 있으며 QRadar가 우리가 선택한 비밀번호로 인증을 수락하도록 할 수 있습니다. 공격은 아래에 설명되어 있습니다.

QRadar의 추가 버그로 인해 반드시 존재하지 않는 사용자에 대해 AD에서 인증을 요청하게 됩니다. QRadar에는 기본 제공 로컬 관리 사용자가 있습니다. 관리 사용자로 인증을 시도할 때 QRadar는 먼저 Kerberos를 사용하여 DC에 대한 인증을 시도합니다. 이 사용자 이름은 AD에 존재할 필요가 없습니다. 사용자 이름이 공격자에게 미리 알려지기 때문에 이렇게 하면 공격이 더 쉬워집니다.

또한 이 버그는 그 자체로 취약점으로 간주될 수 있습니다. KDC Spoofing 여부와 관계없이 공격자가 헬프데스크 계정을 탈취하는 등 AD에서 사용자 생성 권한을 획득할 수 있다면 공격자는 AD에서 admin이라는 사용자를 생성할 수 있습니다. 그런 다음 공격자는 해당 사용자를 사용하여 QRadar에 인증할 수 있습니다.

착취

이제 우리는 QRadar가 취약하다는 것을 알았으므로 포트 88(Kerberos 포트)에서 QRadar와 KDC(이 경우 도메인 컨트롤러) 간의 트래픽을 자체 Windows Server로 리디렉션하여 공격을 시뮬레이션했습니다. Windows 서버에 가짜 도메인을 설정하고 실제 도메인에 QRadar 관리자와 동일한 UPN을 가진 사용자가 있는지 확인했습니다. 가짜 도메인에서 해당 사용자의 비밀번호를 "1"로 구성했습니다.

그런 다음 다음 상황을 시도했습니다.
– 일반 로그인(트래픽이 전환되지 않음) – 예상대로 관리자의 원래 암호로 로그인했습니다. 암호 "1"을 시도하면 로그인에 실패했습니다.
– 우리의 가짜 DC로 우회된 트래픽으로 로그인 – 관리자의 원래 암호로 로그인에 실패했지만 암호 "1"로 로그인은 성공했습니다.

IBM의 완화

이 취약점을 완화하기 위한 IBM의 접근 방식은 간단하고 안전합니다. QRadar에 대한 정확히 동일한 인증 기능을 LDAPS로 달성할 수 있으므로 권장 완화 방법은 단순히 Kerberos에서 LDAPS 인증으로 전환하는 것입니다. 그런 다음 IBM에서 패치를 설치해야 합니다. 패치는 인증이 실제로 LDAPS로 설정되었는지 확인하고 아직 LDAPS 인증으로 전환하지 않은 경우 실패합니다. 이는 패치 후 시스템이 안전한지 확인하기 위한 것입니다.

사용 중이라면 Silverfort QRadar에 대한 인증을 보호하려면 다음도 업데이트해야 합니다. Silverfort Kerberos TGT 요청이 아닌 LDAPS 인증을 보호하기 위한 QRadar의 정책.

예방 및 완화

보안 전문가를 위한 완화 단계

1. 스위치 인증QRadar에서 Kerberos에서 LDAPS로
2. QRadar를 고정 버전으로 업그레이드
3. 업데이트 Silverfort 그에 따른 QRadar 정책
4. Kerberos 인증을 지속적으로 모니터링합니다. AS_REQ만 요청하는 자원을 찾으십시오. TGS_REQ가 없으면 위험 신호입니다.
5. 사용 Silverfort의 오픈 소스 도구 서비스 티켓을 요청하지 않는 서비스에 대한 인증 로그를 검색합니다.
6. Kerberos 및 직접 구성한 시스템을 구현하는 내부 개발 응용 프로그램에 대한 개발자 권장 사항을 참조하십시오.

개발자로서

솔루션이 KDC 스푸핑에 취약하지 않도록 몇 가지 단계를 수행하는 것이 좋습니다.
1. Kerboros 구현에 암호 또는 키탭이 필요한지 확인: DC를 확인하려면 일종의 공유 비밀을 사용해야 합니다. 솔루션이 keytab 파일 구성을 활성화하지 않거나 서비스 계정 암호, 응용 프로그램은 분명히 KDC 스푸핑에 취약합니다.
2. Wireshark 실행 – Wireshark를 사용하여 인증 중에 전송된 Kerberos 요청을 확인합니다. TGS_REQ가 없으면 위험 신호입니다.
3. 인증 프로토콜을 직접 구현하려면 프로토콜 RFC를 부지런히 따라야 합니다. 더 쉬운 경로를 선택하고 이러한 프로토콜의 기존 구현을 사용하는 것이 좋습니다.
4. 타사 라이브러리를 올바르게 사용하십시오. 일부 타사 라이브러리는 KDC 스푸핑을 방지하기 위해 특정 구성이 필요합니다. 예를 들어, pam-krb3라는 Kerberos에 사용되는 공통 라이브러리에는 올바르게 작동하도록 구성된 keytab이 있어야 합니다. 다음은 문서의 관련 단락입니다(https://github.com/rra/pam-krb5/blob/master/README.md)

무엇 향후 계획?
우리는 또 다른 KDC 스푸핑 취약점을 발견했으며 곧 그것에 대해 글을 쓸 수 있기를 희망하지만 벤더가 패치를 게시하기 전에는 아닙니다. 그때까지 계속 지켜봐주십시오.

배경

Kerberos 프로토콜 개요

Kerberos 인증 프로토콜은 1980년대에 Steve Miller와 Clifford Neuman이 개발했습니다. 관리되는 네트워크에서 SSO(Single Sign-On)를 허용하고 Active Directory (AD) 구현으로 온프레미스 엔터프라이즈 환경을 위한 기본 인증 프로토콜로 전환되었습니다.
이 프로토콜은 사용자와 액세스한 서버에 대한 상호 인증을 제공하는 세 가지 교환으로 구성됩니다. 사용자가 로그인하면 자격 증명을 입력하고 AS(인증 서비스) 교환이 발생합니다. 사용자는 나중에 TGS(Ticket Granting Service) 교환 중에 특정 서비스에 대한 티켓을 얻는 데 사용되는 TGT(Ticket Granting Ticket)를 얻습니다. 그런 다음 클라이언트/서버 교환 중에 티켓을 사용하여 인증을 완료합니다.

1. 인증 서비스(AS) 교환

AS 교환 중에 사용자는 키 배포 센터(KDC)로 인증합니다. 그 대가로 사용자는 자격 증명을 다시 입력하지 않고 네트워크의 서비스를 인증하는 데 필요한 티켓과 키를 얻습니다. 사용자가 자격 증명을 처음 입력하면 클라이언트는 KDC의 AS(인증 서비스) 기능에 AS_REQ를 보냅니다. AS_REQ는 사용자 암호의 기능인 마스터 키로 서명된 메시지입니다. KDC의 일부인 인증 서비스는 KDC에서도 사용할 수 있는 마스터 키에 따라 AS_REQ를 확인합니다. AS_REQ의 유효성을 검사한 후 KDC는 로그온 세션 키와 KDC의 키로 암호화된 TGT(Ticket-Granting Ticket)가 포함된 AS_REP를 반환합니다. AS Exchange는 아래와 같습니다. TGT는 특정 서비스에 대한 액세스 권한을 얻기 위해 TGS 교환에서 사용됩니다.

2. TGS(Ticket-Granting Service) 교환

사용자가 네트워크의 서비스에 액세스하려고 시도하면 사용자는 TGS_REQ를 KDC의 TGS(Ticket Granting Server) 기능으로 보냅니다. 이 메시지는 AS 교환 중에 얻은 로그온 세션 키로 암호화됩니다. TGS_REQ는 TGS에 의해 확인된 다음 TGS_REP를 반환합니다. TGS_REP에는 서비스를 호스팅하는 서버의 마스터 키로 암호화된 서비스 세션 키와 서비스 티켓이 포함되어 있습니다. Unix 기반 시스템에서 서버의 마스터 키는 keytab 파일이라는 파일에 구성됩니다. 구성원 서버에 있는 서버의 마스터 키는 컴퓨터 계정의 암호에서 파생됩니다. TGS 거래소는 아래와 같습니다.

3. 클라이언트/서버 교환

이제 클라이언트는 서비스에 인증하는 데 필요한 모든 것을 갖추고 있습니다. 클라이언트는 서비스 세션 키로 암호화된 AP_REQ를 서비스로 보냅니다. 서비스는 서비스 세션 키를 해독하여 AP_REQ의 유효성을 검사합니다. 그런 다음 서버는 AP_REP 메시지를 반환하고 인증이 완료됩니다. 클라이언트 서버 교환은 다음과 같습니다.

스푸핑 방지 프로토콜

Kerberos 프로토콜이 올바르게 구현되면 KDC를 가장하려는 공격자가 인증을 우회할 수 없습니다. 공격자가 하이재킹된 AS_REQ에 대한 응답으로 유효한 AS_REP를 성공적으로 생성하더라도 공격자는 유효한 서비스 티켓을 조작할 수 없기 때문입니다. 서비스 티켓은 공격자가 가지고 있지 않은 키인 서버 키로 암호화되기 때문에 불가능합니다.

KDC 스푸핑이란 무엇입니까?

2000년 Dug Song은 취약점 Kerberos 프로토콜(송덕.2000. Kerberos KDC 스푸핑 취약성. 28월 XNUMX일.).
그는 Kerberos 클라이언트의 특정 구현 및 구성이 클라이언트/서버 교환을 실행하지 못하고 이전 교환의 성공을 기반으로 인증을 허용한다는 사실을 발견했습니다. 안타깝게도 이 동작은 안전하지 않으며 공격자가 악용할 수 있습니다. 클라이언트와 DC 간의 통신을 하이재킹할 수 있는 공격자는 다음 단계를 수행할 수 있습니다.
1. 가짜 KDC를 생성합니다.
2. 공격하려는 서비스에 액세스할 수 있는 사용자 이름을 얻습니다.
3. 공격자가 선택한 비밀번호로 가짜 KDC에 사용자를 생성합니다. 데모를 위해 이 암호를 "1"이라고 합니다.
4. 획득한 사용자 이름과 암호 "1"로 서비스에 인증합니다.
5. 클라이언트에서 DC로의 통신을 하이재킹하고 가짜 KDC로 전환합니다.
6. AS Exchange 동안 암호 "1"에 해당하는 AS_REP, 가짜 KDC 키 및 가짜 로그온 세션 키를 반환합니다.
7. TGS 교환 중에 모든 TGS_REP를 반환합니다.
8. 클라이언트는 애플리케이션 교환을 수행하지 않고 인증을 수락합니다.

KDC 스푸핑 공격은 공격자가 KDC에서 들어오고 나가는 트래픽을 하이재킹하고 KDC를 대신하여 응답할 수 있다고 가정합니다. 이는 다양한 기술을 사용하여 수행할 수 있습니다. 예를 들어, 공격자가 클라이언트와 동일한 물리적 네트워크 세그먼트 내에 있는 경우 네트워크 보안 해킹에 설명된 대로 ARP 스푸핑 공격을 수행할 수 있습니다(록 하트 2007). 또 다른 가능한 접근 방식은 스위치나 라우터와 같은 네트워킹 장치를 인수하고 거기에서 통신을 제어하는 ​​것입니다.