Silverfort 연구원, F5 Big-IP에서 KDC 스푸핑 취약점 발견 [CVE-2021-23008]

작년에 우리는 XNUMX개의 KDC(Key Distribution Center) 스푸핑 취약점을 보고했습니다. Cisco ASA, 팔로알토 네트웍스 PAN-OS 과 IBM QRadar. 우리는 다른 하나가 올 것이라고 언급했으며 이제 F5가 수정 사항을 발행했습니다., 이번에는 Big-IP에서 식별한 네 번째 KDC 스푸핑 취약점을 게시합니다. KDC 스푸핑 취약성으로 인해 공격자는 Big-IP 액세스 정책 관리자에 대한 Kerberos 인증을 우회하고 보안 정책을 우회하며 민감한 워크로드에 대한 무제한 액세스 권한을 얻을 수 있습니다. 경우에 따라 Big-IP 관리 콘솔에 대한 인증을 우회하는 데에도 사용할 수 있습니다. 우리는 이 문제를 해결하기 위해 F5 엔지니어와 긴밀히 협력해 왔으며, 그 결과 최근 발표된 주의보. 이 블로그 게시물에서는 취약점에 대해 간략하게 설명하고 구현 시 이러한 결함을 방지하는 방법을 설명합니다. Kerberos, Big-IP 및 기타 Kerberos 기반 시스템을 사용하는 고객을 위한 완화 단계에 대해 논의합니다.

취약점 설명

F5 Big-IP Application Delivery Services는 안전하고 확장 가능한 방식으로 애플리케이션을 제공하는 솔루션입니다. 핵심 구성 요소 중 하나는 APM(액세스 정책 관리자)으로, 액세스가 적절하게 인증되고 승인되도록 정책을 관리하고 적용합니다. APM은 때때로 Big-IP 관리 콘솔에 대한 액세스를 보호하기 위해 사용되기도 합니다.

취약점은 F5의 Kerberos 프로토콜 구현에 있습니다. Kerberos는 온프레미스 인증을 위한 가장 일반적인 인증 프로토콜입니다. 의 인기로 인해 기업 네트워크에서 널리 사용됩니다. Active Directory, NTLM과 같은 약한 인증 프로토콜보다 선호됩니다.

APM 정책에서 요구하는 인증을 위한 인증 프로토콜로 Kerberos를 사용할 수 있습니다. 사용자가 Big-IP를 통해 애플리케이션에 액세스하면 캡티브 포털이 표시되고 사용자 이름과 비밀번호를 입력해야 할 수 있습니다. 사용자 이름과 암호는 Kerberos 프로토콜을 사용하여 AD에 대해 확인되어 사용자가 자신이 누구인지 확인합니다. 따라서 Kerberos 인증을 우회하면 공격자가 적법한 자격 증명 없이도 Big-IP 애플리케이션에 액세스할 수 있습니다.

Kerberos 프로토콜이 작동하려면 다음 세 가지가 발생해야 합니다.

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

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

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

다음은 액세스 정책에 대한 AD 인증 구성 지침의 스크린샷입니다. F5 웹사이트.

이 구성 후에 사용자가 프록시 뒤에 있는 앱에 인증을 시도하면 사용자 이름과 비밀번호를 입력하라는 메시지가 표시됩니다. 사용자가 암호를 입력하면 제품은 Kerberos를 사용하여 DC(도메인 컨트롤러)를 인증합니다. 그러나 APM은 서비스 티켓을 요청하지 않고 성공적인 AS_REP에 따라 액세스 권한을 부여합니다.
다른 시나리오와 달리 F5 키를 사용하면 관리자 사용자 이름과 암호를 구성할 수 있습니다.

이론적으로 이 암호는 DC를 인증하고 취약성을 방지하는 데 사용될 수 있습니다. 그러나 이러한 목적으로는 사용되지 않고 기본 또는 중첩된 그룹 가져오기, 사용자에게 암호 변경 프롬프트 또는 복잡성 확인 또는 암호 재설정 수행을 위한 목적으로만 사용됩니다.

위장 Kerberos 인증

공격자가 이러한 종류의 인증을 우회하기 위해 DC를 스푸핑하기 위해 취할 수 있는 단계는 다음과 같습니다. Big-IP와 DC 사이의 네트워크 통신을 하이재킹할 수 있는 능력이 있다고 가정해 봅시다. 이 경우 관리자의 사용자 이름과 동일한 사용자 이름과 선택한 암호를 사용하여 가짜 DC를 만들 수 있습니다. 그런 다음 Big-IP에 대한 인증을 시작하고 선택한 사용자와 비밀번호를 사용합니다. Big-IP는 Kerberos로 인증하고 Kerberos 통신을 하이재킹하고 선택한 암호에 해당하는 AS_REP를 반환합니다. 그리고 우리가 선택한 서비스 세션 키로 암호화된 서비스 티켓과 우리가 선택한 암호로 암호화된 우리가 선택한 세션 키로 구성된 TGS_REP. 이 단계에서 Big-IP 측에서 수행되는 유일한 확인은 우리가 선택한 암호에 의존하기 때문에 Big-IP는 인증을 허용합니다.

착취

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

그런 다음 다음 시나리오를 시도했습니다.

• 일반 로그인(트래픽이 전환되지 않음) – 예상대로 사용자의 원래 비밀번호로 로그인했습니다. 암호 "1"을 시도하면 로그인에 실패했습니다.
• 가짜 DC로 우회된 트래픽으로 로그인 – 관리자의 원래 암호로 로그인하는 데 실패했지만 암호 "1"로 로그인하면 작동했습니다.

예방 및 완화

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

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

개발자 용

솔루션이 KDC 스푸핑에 취약하지 않도록 몇 가지 단계를 수행하는 것이 좋습니다.

1. Kerberos 구현에 암호 또는 키탭이 필요한지 확인합니다. DC의 유효성을 검사하려면 일종의 공유 비밀을 사용해야 합니다. 솔루션에서 keytab 파일 구성을 활성화하지 않거나 서비스 계정 암호, 응용 프로그램은 분명히 KDC 스푸핑에 취약합니다.
2. Wireshark 실행 - Wireshark를 사용하여 인증 중에 전송된 Kerberos 요청을 확인합니다. TGS_REQ가 없으면 위험 신호입니다.
3. 인증 프로토콜을 직접 구현하려면 프로토콜 사양을 부지런히 따라야 합니다. 더 쉬운 경로를 선택하고 이러한 프로토콜의 기존 구현을 사용하는 것이 좋습니다.
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) 교환

사용자가 네트워크의 서비스에 액세스하려고 시도하면 사용자는 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 스푸핑 취약성. 8 월 28.).

그는 Kerberos 클라이언트의 특정 구현 및 구성이 클라이언트/서버 교환을 실행하지 못하고 이전 교환의 성공을 기반으로 인증을 허용한다는 사실을 발견했습니다. 안타깝게도 이 동작은 안전하지 않으며 공격자가 악용할 수 있습니다. 클라이언트와 DC 간의 통신을 하이재킹할 수 있는 공격자는 다음 단계를 수행할 수 있습니다.

1. 가짜 KDC를 만듭니다.
2. 공격하려는 서비스에 액세스할 수 있는 사용자 이름을 얻습니다.
3. 공격자가 선택한 비밀번호로 가짜 KDC에 사용자를 만듭니다. 예를 들어 이 암호를 "1"이라고 합시다.
4. 획득한 사용자 이름과 암호 "1"로 서비스에 인증합니다.
5. 클라이언트에서 DC로의 통신을 하이재킹하고 가짜 KDC로 전환합니다.
6. AS 교환 중에 암호 "1"에 해당하는 AS_REP, 가짜 KDC 키 및 가짜 로그온 세션 키를 반환합니다.
7. TGS 교환 중에 모든 TGS_REP를 반환합니다.
8. 클라이언트는 애플리케이션 교환을 수행하지 않고 인증을 수락합니다.

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

감사의 글

이 취약점에 대한 연구 및 발견은 발견 당시 Exclusive Networks에서 근무했던 Thierry Van Steirteghem과의 공동 노력이었습니다.