소개

적대적 사고방식은 레드 팀의 공격적인 오퍼레이터에게 꼭 필요한 자질입니다. 모든 평가에는 고유한 한계와 "트로피"가 있습니다. 운영자는 보안 계층화 모델, 최첨단 엔드포인트 탐지 및 대응 솔루션 등과 같은 환경의 한계에 맞춰야 합니다. 중요한 자산과 환경을 제어할 수 있는 가장 창의적인 방법입니다.

최근 평가에서는 다른 Red Team 참여와 마찬가지로 정찰 단계부터 시작했습니다. 이 단계에서는 고객 조직과 연결된 인터넷 연결 자산을 수집합니다. 정찰 데이터를 수집하고 분석한 후 우리는 공격 표면이 매우 좁고 악용할 수 있는 인터넷 연결 소프트웨어 버전이 없으며 사회 공학이 최후의 수단으로 예약되어 있음을 깨달았습니다. 우리가 찾은 일부 자산은 GlobalProtect VPN 포털로 확인되었습니다. 연결 및 인증을 여러 번 시도한 후 GlobalProtect 포털에 대한 인증이 다단계 인증으로 시행된 것으로 확인되었습니다. 이것이 조직의 내부 환경에서 발판을 마련할 수 있는 유일한 방법이었기 때문에 GlobalProtect 인터페이스를 더 자세히 조사하기로 결정했습니다.

GlobalProtect VPN 기본 사항

Palo Alto의 GlobalProtect VPN은 HTTPS 요청 및 응답과 구성의 XML 데이터 세트를 기반으로 합니다. VPN에는 최종 사용자가 관여하는 두 가지 주요 구성 요소인 포털 과 게이트웨이 가 있습니다 . 포털의 역할은 다음과 같습니다. 첫째, Windows 및 MacOS용 GlobalProtect 클라이언트를 호스팅하는 웹 서버 역할을 합니다. 둘째, 공식 Palo Alto의 클라이언트 구성과 사용 가능한 게이트웨이 목록을 제공합니다. 게이트웨이의 목적은 기업에 대한 최종 사용자 세션을 보호하기 위해 우리가 잘 알고 사랑하는 원시 SSLVPN 터널을 제공하는 것입니다.

공식 Palo Alto 클라이언트의 흐름은 다음과 같습니다.

1. 포털에 로그인
2. 구성 및 게이트웨이 목록 가져오기
3. 게이트웨이는 자동으로 선택되거나 사용자의 수동 선택에 의해 선택됩니다.
4. 게이트웨이에 로그인
5. 호스트 정보 프로필(HIP) 보고서 제공
6. 모든 것이 제대로 진행되면 VPN 및 보안 세션에 연결하십시오.

TL;DR MFA를 시행하는 것은 포털과 게이트웨이가 독립적인 구성 요소이기 때문에 모두 중요한 것 같습니다 .

인증 흐름에 뛰어들기

공식 GlobalProtect 클라이언트 에 처음 연결할 때 첫 번째 POST 요청이 다음을 가리키는 URL을 통해 포털로 전송되는 것을 볼 수 있습니다./global-protect/prelogin.esp

요청에는 "kerberos-support", "client-os", "os-version", "ipv6-support" 등과 같은 클라이언트의 환경 변수가 추가됩니다.

그런 다음 서버는 "PHPSESSID" 쿠키와 요청 상태가 포함된 XML 데이터 세트로 응답하고 성공하면 "MFA 토큰 입력" 또는 "Enter MFA 토큰"과 같은 클라이언트의 로그인 레이블도 첨부합니다. 비밀번호."

사용자가 자격 증명을 입력하면 클라이언트는 /global-protect/getconfig.esp자격 증명이 첨부된 이전 요청과 동일한 정보를 에 다음 요청을 보냅니다.

인증에 성공하면 서버는 수집할 서버 구성, 버전, 클라이언트의 호스트 정보 및 수행할 사용자 지정 검사(있는 경우)를 포함하는 XML 데이터 세트를 보냅니다. 사용자 지정 검사는 시스템이 규정을 준수하도록 설정해야 하는 특수 레지스트리 키와 같이 VPN 관리자가 만든 특수 규정 준수 검사입니다. 응답에는 게이트웨이 및 해당 구성 목록도 포함됩니다.

다음 요청은 게이트웨이를 대상으로 하며 포털이 시작될 때와 동일한 인증 시퀀스를 사용하지만 이번에는 게이트웨이의 엔드포인트를 대상으로 합니다 /ssl-vpn/prelogin.esp.

사전 로그인 단계는 포털과 동일하며 클라이언트의 환경 변수를 서버로 보냅니다. 서버는 상태, 인증 양식의 레이블로 응답하고 "PHPSESSID" 쿠키를 설정합니다.

세션 ID를 수신하고 인증한 후 다음 요청은 포털과 게이트웨이 인증을 구분합니다. 요청은 /ssl-vpn/login.esp사용자의 자격 증명이 추가된 상태로 로 전송되고 이에 대한 응답으로 서버는 MTU, DNS 도메인, 다음 요청에 사용될 "authcookie" 및 추가 구성 변수와 같은 제목 없는 여러 인수를 보냅니다.

그런 다음 클라이언트는 XML 데이터 세트를 올바르게 구문 분석하고 "authcookie"를 포함한 이러한 변수를 다음 요청에 추가합니다 /ssl-vpn/getconfig.esp. 서버는 응답 상태와 추가 구성 변수로 응답하지만 이번에는 사용할 암호, 게이트웨이 프로토콜, 사용할 기본 터널 IP 등과 같은 모든 제목이 지정되고 더 많은 변수가 전송됩니다.

마지막 단계는 /ssl-tunnel-connect.sslvpn사용자 이름과 "authcookie"가 추가된 에 대한 GET 요청입니다. 이렇게 하면 “ ”의 서버 응답으로 VPN 세션이 시작됩니다 START_TUNNEL.

MFA를 우회하는 한 가지 잘못된 구성

이전 장에서 살펴본 것처럼 VPN 시퀀스는 두 개의 개별 인증 흐름이 필요한 두 개의 독립적인 구성 요소에 의존합니다.
이들은 독립적이기 때문에 각 인증 시퀀스를 수동으로 사용할 수 있습니다. 즉, 게이트웨이 정보를 이미 알고 있는 경우 게이트웨이 목록을 얻기 위해 포털을 통과할 필요가 없으며 유효한 자격 증명으로 한 번만 인증할 수 있으며 여전히 VPN 연결을 얻을 수 있습니다.

이 최근 평가에서 우리는 게이트웨이가 도메인 자격 증명을 요청하는 동안 MFA 토큰이 포털에서만 요청된다는 것을 발견했습니다. IT 부서와 Palo Alto GlobalProtect 개발자는 외부 조정을 염두에 두지 않고 내부 클라이언트 사용에만 의존했습니다. 게이트웨이에서 MFA를 적용하지 않는 것은 공식 클라이언트를 사용할 때 안전하지만 다른 오픈 소스 또는 자체 구축 클라이언트를 사용할 때는 안전하지 않습니다. 이것은 Palo Alto의 VPN 솔루션의 취약점이 아니라 잘못된 구성으로 인한 것임을 언급하는 것도 중요한 부분입니다.

다행스럽게도 InfraDead 의 직원들은 여러 VPN 공급업체 및 기술을 지원하는 오픈 소스 VPN 클라이언트 OpenConnect를 개발하는 동안 이미 GlobalProtect에 대한 연구를 수행했으며 그중에는 Palo Alto GlobalProtect 가 있습니다 . 문서에서 다음과 같이 자세히 설명합니다.

“GlobalProtect VPN에는 실제로 포털과 게이트웨이라는 두 가지 서버 인터페이스가 있습니다. 대부분의 VPN에는 하나의 포털 서버와 하나 이상의 게이트웨이 서버가 있습니다. 포털 인터페이스를 호스팅하는 서버는 종종 게이트웨이 인터페이스도 호스팅 하지만 항상 그런 것은 아닙니다. 포털 인터페이스는 대부분 공식 클라이언트 소프트웨어가 따라야 할 중앙에서 부과된 보안/잠금 설정을 보냅니다. OpenConnect(최종 사용자에게 모든 권한을 부여하려고 함)와 같은 VPN 클라이언트에 분명히 유용한 포털에서 보낸 유일한 정보는 게이트웨이 목록입니다 .

일부 GlobalProtect VPN은 클라이언트가 게이트웨이에 액세스하기 전에 포털에 인증해야 하는 방식으로 구성되지만 다른 VPN에서는 포털과의 상호 작용이 필요하지 않습니다 . 공식 클라이언트의 동작을 복제하기 위해 OpenConnect는 먼저 지정된 서버의 포털 인터페이스에 연결을 시도합니다.

가 지정된 경우 --usergroup=gateway(또는 동등하게 /gateway서버 URL에 추가됨(예: https://vpn.company.com/gateway) OpenConnect는 포털 인터페이스를 건너뛰고 게이트웨이 인터페이스에 즉시 연결을 시도합니다 . 이것은 제공하는 목록에서 원하는 게이트웨이 서버를 제공하지 않는 등 GlobalProtect VPN 포털이 잘못 구성된 경우에 유용합니다.”

이 OpenConnect 기능은 값비싼 연구 및 코딩 시간을 절약해 주므로 매우 놀라운 기능이었습니다.

여기에 Portal이 필요하지 않습니다…

포털과 게이트웨이가 동일한 인터페이스에서 실행 중이었기 때문에 다른 게이트웨이(예: 동일한 서버의 다른 포트 또는 기타 외부 자산)를 찾을 필요가 없었습니다.

OpenConnect 클라이언트를 사용하여 포털을 우회하고 먼저 게이트웨이에 연결했습니다.
openconnect --protocol=gp --user=user_name https://vpn.company.com/gateway

엔드 포인트는 서버에 존재하지 않을 수 있지만 클라이언트가 실행되는 동안 폐기되고 플래그 역할만 하므로 엔드포인트가 아닌 엔드포인트와 /gateway통신을 시작합니다 ./ssl-vpn//global-protect/

VPN 클라이언트는 도메인 자격 증명을 묻는 메시지를 표시합니다.

성공! 내부 네트워크에 성공적으로 연결되었습니다!

이 평가에서는 조직의 도메인 컨트롤러와 연결하고 통신할 수 있었지만 공식 클라이언트에서 할 수 있는 많은 서비스 및 도메인 시스템과 통신할 수 없었습니다. 서로 다른 운영 체제와 클라이언트 간의 서로 다른 동작을 조사한 후 유효한 HIP 보고서를 제출해야 한다는 것을 깨달았습니다. 여기에서도 OpenConnect 개발자는 가짜 HIP 보고서를 생성하는 셸 스크립트를 자동화할 만큼 충분히 천재적이었습니다. GlobalProtectLogs.zip우리는 Windows 컴퓨터에서 하나를 복사했습니다(공식 클라이언트의 설정 창에 들어가서 문제 해결 탭에서 "로그 수집" 버튼을 클릭합니다. 그러면 사용자 디렉터리에 파일이 생성됩니다. 압축 폴더 안에 HIP 보고서가 있습니다. pan_gp_hrpt.xml”)
로 찾을 수 있습니다 ../openconnect/trojans/hipreport.sh.

가짜 보고서를 제출하려고 시도 하고 분할된 서비스에 도달하려고 시도합니다.
openconnect --protocol=gp --user=username --csd-wrapper=trojans/hipreport.sh https://vpn.company.com/gateway

MFA와 기계 분리를 모두 성공적으로 우회했습니다!

여기에서 Active Directory에 연결하고 조직의 내부 환경을 추가로 악용할 수 있었습니다.

빠른 수정

이 잘못된 구성을 완화하는 것은 매우 쉽습니다.

1. MFA는 포털과 게이트웨이 모두에 적용되어야 합니다.
2. 게이트웨이에 대한 직접 SSLVPN 연결 모니터링
3. 포털과 게이트웨이를 서로 다른 인터페이스 및 포트로 분리
4. 가능한 경우 SAML 인증만 허용

Red Team 운영자로서 우리는 항상 고객에게 부가 가치를 제공하는 것을 목표로 합니다. 모든 평가에는 고유한 장애물이 있지만 모든 것이 안전해 보일 때 더욱 주의를 기울이면 큰 도움이 됩니다. 처음에는 공격할 외부 자산이 없는 것처럼 보였고 MFA는 GlobalProtect VPN을 포함하여 인터넷에 노출된 모든 인터페이스에 시행되었습니다. 그러나 인터페이스에 대해 더 자세히 살펴보면 "평화로운" 사용자 상호 작용에 의존하는 것이 위험하다는 사실이 드러났습니다 .

GlobalProtect의 클라이언트는 안전하고 다르게 사용하도록 변경할 수 없지만 다른 VPN 프로그램은 가능합니다. 포털과 게이트웨이는 독립적인 구성 요소이므로 각 구성 요소를 개별적으로 인증할 수 있지만 게이트웨이에 MFA를 적용하지 않으면 공격자가 내부 엔터프라이즈 환경의 발판을 마련할 수 있습니다.

실제 경험에서 얻은 개인적인 지식을 공유하기 위해 CYE " CyberTalks " 시리즈 의 일부로 작성되었습니다 .