보안 연구원 Silverfort에이전트 없는 인증 플랫폼 제공업체인 는 해커가 Cisco ASA(Adaptive Security Appliance)를 제어할 수 있는 심각한 취약점을 식별했습니다. 모든 ASA 버전이 영향을 받습니다. Cisco에 취약점을 공개한 후 Cisco는 지원되는 모든 ASA 버전을 수정했으며 권고를 발표하다 그 위에. 취약점(CVE-2020-3125)에는 8.1점 만점에 10점의 CVSS 위험 점수가 할당되었으며 이는 "높음"으로 간주됩니다. 이는 취약점으로 인해 공격자가 다음을 우회할 수 있기 때문입니다. Kerberos Cisco ASA에 대한 인증. Silverfort 취약점을 발견한 것으로 알려진 연구원은 다음과 같습니다: Yoav Iellin, Yaron Kassner, 도르 시걸 & Rotem Zach.

Cisco는 ASA의 모든 버전에서 이 취약점을 수정했습니다. 악용으로부터 보호하려면 기업에서 최신 ASA 버전으로 업그레이드하는 것이 좋습니다.

이 문서에서는 KDC 스푸핑 취약점을 간략하게 설명하고 이를 사용하여 Cisco ASA에 대한 인증을 우회하는 방법을 보여줍니다. Kerberos를 구현하는 개발자는 물론 네트워크에 이미 이러한 솔루션을 구현한 기업으로서 이러한 취약점을 방지하는 방법을 설명합니다.

취약점 설명

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

Cisco는 웹 관리 콘솔이나 SSH를 통해 VPN, 방화벽 세션 열기, 관리 액세스 등 다양한 ASA 인터페이스에서 Kerberos 인증 프로토콜을 사용합니다. 따라서 Kerberos 인증을 우회하면 공격자가 Cisco 어플라이언스를 장악하고 보안을 우회하며 다른 네트워크에 액세스할 수 있습니다.

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

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

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

배경

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 스푸핑 취약성. 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. 또 다른 가능한 접근 방식은 스위치나 라우터와 같은 네트워킹 장치를 인수하고 거기에서 통신을 제어하는 ​​것입니다.

Cisco ASA의 취약점을 발견한 방법

우리는 추가할 방법을 찾고 있었습니다. 다단계 인증 (MFA) Cisco ASA 및 Anyconnect VPN에 액세스하는 관리자에게 제공됩니다. Kerberos를 인증 프로토콜로 사용하도록 Cisco를 구성한 후 인증 로그를 검사했습니다. Silverfort의 콘솔. Silverfort 네트워크의 모든 인증 활동에 대한 완전한 가시성을 제공합니다. Silverfort의 로그에는 Cisco ASA가 서비스 티켓을 요청하지 않고 TGT를 요청한 것으로 나타났습니다.

구성 가이드로 돌아갔습니다. 시스코. 2007. PIX/ASA: ASDM/CLI 구성 예를 통한 VPN 클라이언트 사용자를 위한 Kerberos 인증 및 LDAP 권한 부여 서버 그룹. 30월 XNUMX일. ; Kerberos 인증을 구성하는 데 필요한 매개변수를 살펴보았습니다.

위에서 본 것처럼 Kerberos 인증을 위한 비밀번호나 키탭 구성을 입력할 수 있는 곳이 없습니다. 비밀번호나 키 탭은 KDC에 대해 신뢰할 수 있는 방식으로 인증하기 위해 Kerberos에서 사용하는 '비밀'을 생성하므로 올바른 구현을 위해 필요합니다. '비밀'이 없으면 인증을 암호화하여 신뢰할 수 없습니다.

우리는 다른 Cisco 인터페이스에 대해서도 동일한 작업을 시도했으며 방화벽 세션을 열 때, 관리 인증을 할 때, 심지어 SSH를 사용하여 VM에 액세스할 때에도 동일한 취약점이 존재한다는 것을 확인했습니다. 다양한 인증 프로토콜에 대한 Cisco 지원을 요약한 표의 Kerberos 열 아래를 참조하십시오.

착취

다음으로 우리는 이 취약점이 악용될 수 있는지 확인하고 싶었습니다. 이를 위해 우리는 DC용 Kerberos 트래픽을 하이재킹하여 서버로 전환했습니다. 자체 KDC 논리를 개발하는 대신 단순히 불량 서버에 AD 도메인 서비스를 설치하여 서버를 도메인 컨트롤러로 승격시켰습니다. 물론 원래 도메인의 관리자가 아니기 때문에 새로운 가짜 도메인을 만들었습니다.

첫 번째 도메인(이 예에서는 Bob)의 Cisco 관리자에 대한 사용자 이름을 알고 있으므로 가짜 도메인에 Bob이라는 사용자를 생성했습니다. 우리는 가짜 도메인에서 해당 사용자의 비밀번호를 "1"로 구성했습니다.

그런 다음 다음 상황을 시도했습니다.

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

예방 및 완화

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

1. 우선 Cisco ASA를 고정 버전으로 업그레이드하고 다음 항목에 자세히 설명된 필수 구성 변경을 수행합니다. 시스코 자문
2. Kerberos 인증을 지속적으로 모니터링하십시오. AS_REQ만 요청하는 자원을 찾으십시오. TGS_REQ가 없으면 위험 신호입니다.
3. Silverfort의 Silverfort의 오픈 소스 도구 서비스 티켓을 요청하지 않는 서비스에 대한 인증 로그를 검색합니다.
4. Kerberos 및 직접 구성한 시스템을 구현하는 내부 개발 응용 프로그램에 대한 개발자 권장 사항을 참조하십시오.
5. Silverfort Palo Alto Networks의 단계별 인증 기능을 활용하고 있는 고객은 업데이트해야 합니다. Silverfort PAN-OS를 업그레이드한 후 TGT 정책에서 서비스 티켓 정책으로의 MFA 정책.

개발자로서

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

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