VPN 의존 - VPN 악용 이후 기법 탐색
핵심 요약
이 블로그 게시물에서 Akamai 연구원들은 간과되고 있는 VPN 악용 이후 위협, 즉 공격자가 VPN 서버를 감염시킨 후 침입을 더 확대하는 데 사용할 수 있는 기법을 집중적으로 설명합니다.
이번 리서치 결과에는 Ivanti Connect Secure 및 FortiGate VPN에 영향을 미치는 몇 가지 취약점이 포함되어 있습니다.
이 취약점 외에도 Ivanti Connect Secure 및 FortiGate 제품과 잠재적으로 다른 VPN 서버에도 영향을 미칠 수 있는 일련의 수정 불가능한 기법을 자세히 설명합니다.
Akamai의 리서치에 따르면, 많은 경우 감염된 VPN 서버를 통해 공격자가 네트워크의 다른 중요 자산을 쉽게 제어할 수 있습니다.
이 블로그 게시물은 이러한 리스크에 대한 인식을 높이고, 보안팀 직원이 VPN 악용 이후 기법의 리스크를 최소화하기 위해 따라야 할 모범 사례를 제시하는 것을 목적으로 합니다.
서론
우리는 모두 VPN 서버에서 심각한 취약점이 발견되었다는 이야기를 들어본 적이 있습니다. 이 취약점은 인터넷에서 악용되며, 관리자는 서둘러 패치를 적용하고, 소셜 미디어는 패닉에 빠집니다.
작년은 VPN 보안에 있어 매우 힘든 한 해였습니다. 격 월 로 중대한 취약점이 패치되거나 공격자에 의해 악용된 이후에 발견되는 것만 같았습니다. 이러한 종류의 활동은 2023년에 많이 증가했지만, 새로운 것은 아닙니다. 공격자들은 오랫동안 VPN 서버를 악용하려고 시도해 왔습니다. 인터넷을 통해 접속할 수 있고 넓은 공격표면을 노출하며 보안 및 모니터링이 부족한 경우가 많기 때문입니다.
역사적으로 VPN 서버는 주로 초기 접속이라는 단일 목적을 달성하기 위해 악용되어 왔습니다. 공격자는 인터넷 기반 VPN 서버를 감염시켜 내부 네트워크로 침입하는 전초기지로 활용했습니다.
이 접근 방식이 매우 효과적이기는 하지만 Akamai는 이렇게 자문했습니다. 'VPN 서버에 대한 제어를 네트워크의 게이트웨이로만 보아야 할까?'
Akamai는 다른 가능한 것이 있는지 알아보고 싶었습니다.
다음 블로그 게시물에서는 다른 수단(취약점, 도난된 인증정보 등)으로 이미 VPN 서버를 유출한 공격자가 추가 목표를 달성하기 위해 사용할 수 있는 VPN 악용 이후 기법을 살펴봅니다.
VPN 의존
공격자가 악용 이후 기술을 수행하기 위해 사용하는 주요 접근 방식은 디바이스의 OS를 표적으로 삼는 것입니다. 공격자는 원격 코드 실행(RCE)을 확보한 후 디바이스 OS에 사용자 지정 임플란트를 드롭할 수 있습니다. 이 시점부터 공격자는 VPN의 모든 측면을 제어할 수 있습니다. 예를 들어, 민감한 정보를 유출하는 기능을 연결하거나, 로그를 조작해 탐지를 회피하거나, 디바이스에서 지속성을 유지하기 위해 시스템 설정을 수정할 수 있습니다.
이 접근 방식에는 많은 장점이 있지만, 비용이 많이 든다는 가장 큰 단점이 있습니다. 어플라이언스는 일반적으로 사용자 지정 강화 OS에서 실행되기 때문에 VPN 디바이스에 대한 사용자 지정 임플란트를 개발하고 유지 관리하는 데 상당한 노력이 필요할 수 있습니다. 즉, VPN 악용 이후 기법은 일반적으로 최상위 국가급 공격자만 사용했습니다.
다른 접근 방식 모색
Akamai는 다른 접근 방식, 즉 '더 쉬운' 형태의 VPN 악용 이후 기법을 모색하기로 결정했으며, OS에서 실행되는 사용자 지정 임플란트에 의존하는 대신 디바이스의 기존 기능을 악용하기로 했습니다. Akamai는 자문했습니다. '공격자가 VPN 관리 인터페이스만 사용해 무엇을 할 수 있을까?'
'VPN 의존'이라고 부르는 이 접근 방식에는 적어도 두 가지 장점이 있습니다.
이러한 종류의 접속 권한은 전체 RCE보다 더 쉽게 얻을 수 있습니다. 인증 우회 취약점, 취약한 인증정보 또는 피싱을 통해 관리 인터페이스에 대한 접속 권한을 얻을 수 있기 때문입니다.
이 접근 방식은 사용자 지정 페이로드를 개발하는 수고를 피할 수 있기 때문에 더 비용 효율적일 수 있습니다.
테스트 대상으로는 시중에 나와 있는 두 가지 대표 VPN 서버인 Ivanti Connect Secure와 FortiGate를 선택했습니다. Akamai는 두 가지 CVE와 VPN 서버를 제어하는 공격자가 네트워크의 다른 중요 자산을 장악하는 데 사용할 수 있는 일련의 수정 불가능한 기법을 발견했으며, 이는 잠재적으로 VPN 감염이 전체 네트워크 감염으로 전환되게 할 수 있습니다.
이번 리서치 결과는 FortiGate와 Ivanti에 집중했지만, 발견된 기법의 변형이 다른 VPN 서버 및 엣지 디바이스와 관련이 있을 수 있다고 봅니다.
원격 인증 서버 악용
VPN 서버가 처리하는 가장 흥미로운 자산 중 하나는 외부 인증정보입니다. VPN 서버는 인증을 위해 로컬 사용자 사용을 지원하지만, 많은 경우 외부 인증 서버를 사용합니다.
관리자는 사용자별로 별도의 인증정보 집합을 유지 관리하는 대신 기존 ID 공급업체를 사용해 사용자를 인증하도록 선택할 수 있습니다. 사용자는 자신의 ‘일반’ 인증정보를 VPN 서버로 전송하고 원격 인증 서버를 통해 유효성을 검사합니다(그림 1).
그림 1: 원격 인증 서버를 사용해 사용자 인증
이 목적을 위해 여러 종류의 인증 서버를 사용할 수 있으며, 두 가지 주요 옵션은 LDAP와 RADIUS입니다.
Akamai는 공격자가 이 행동을 이용해 이러한 외부 인증정보를 감염시켜 네트워크의 추가 리소스에 대한 접속 권한을 공격자에게 제공할 수 있는 몇 가지 기법을 파악했습니다.
LDAP 인증정보 가로채기
VPN에 매우 널리 사용되는 인증 서버 옵션 중 하나는 LDAP이며, 가장 일반적으로는 AD(Active Directory) 도메인 컨트롤러입니다. 이 설정을 사용하면 사용자는 자신의 도메인 인증정보를 통해 VPN에 접속할 수 있으므로 매우 편리한 선택입니다.
LDAP 인증 서버를 설정할 때 VPN이 사용자 정보를 쿼리하도록 AD 서비스 계정의 인증정보가 제공됩니다. FortiGate 내 이 설정의 예시는 그림 2에서 확인할 수 있습니다.
그림 2: FortiGate GUI에서 LDAP 인증 서버 설정
사용자가 LDAP 인증정보를 사용해 FortiGate 또는 Ivanti에 인증을 시도하면 VPN은 LDAP 서버에 연결해 이를 확인합니다. 두 가지의 정확한 구현 방식은 약간 다르므로 둘 다 살펴보겠습니다.
FortiGate LDAP 인증
인증정보의 유효성을 검사하기 위해 FortiGate는 인증정보를 사용해 원격 서버에 인증을 시도합니다. 이 프로세스는 간편 인증 을 사용해 수행됩니다. 즉, FortiGate는 비밀번호를 일반 텍스트로 서버에 전송 합니다(그림 3).
그림 3: LDAP 단순 바인딩으로 일반 텍스트 사용자 비밀번호 노출
이 과정에서 두 가지 인증정보 집합이 전송되는데, FortiGate에 설정된 LDAP 서비스 계정의 인증정보와 인증하는 사용자가 제공한 인증정보입니다. 둘 다 일반 텍스트로 전송됩니다.
기본 설정은 LDAP이지만, FortiGate는 일반 텍스트 통신을 방지해야 하는 LDAPS와 TLS도 지원합니다.
Ivanti LDAP 인증
Ivanti의 LDAP 인증 구현은 약간 다르며 일반 LDAP와 Active Directory의 두 가지 LDAP 인증 서버를 지원합니다(그림 4).
그림 4: LDAP 및 Active Directory 서버를 포함한 Ivanti 인증 서버 옵션
LDAP 인증 서버
LDAP 인증 서버를 사용하는 경우 프로세스는 FortiGate의 프로세스와 매우 유사합니다. 즉, 일반 LDAP를 사용하는 경우 간단한 바인딩이 수행되고 AD 서비스 계정과 인증하는 사용자 인증정보가 모두 일반 텍스트로 전송됩니다(그림 5).
그림 5: 일반 텍스트로 LDAP 인증정보를 전송하는 Ivanti
그러나 LDAP 인증 서버를 설정할 때 기본 설정은 TLS이며 LDAPS도 지원됩니다. 따라서 Ivanti 인스턴스는 일반 LDAP를 사용할 가능성이 작습니다.
AD 인증 서버
설정할 수 있는 두 번째 LDAP 인증 서버 종류는 AD 서버입니다. 이 옵션을 사용하면 Kerberos를 사용해 인증이 수행되므로 비밀번호가 전송되지 않습니다(그림 6).
그림 6: Kerberos를 사용한 보안 LDAP 인증
일반 텍스트 LDAP 인증정보 캡처
FortiGate와 Ivanti 모두 일반 LDAP를 사용해 사용자를 인증하는 경우, VPN으로 전송된 모든 인증정보가 감염될 수 있습니다. 이러한 감염은 VPN과 LDAP 서버 사이에 있는 공격자 또는 VPN 서버를 제어하는 공격자에 의해 수행될 수 있습니다.
디바이스에 임플란트를 드롭하지 않고 어떻게 인증정보를 캡처할 수 있을까요? 다행히 FortiGate와 Ivanti에는 모두 패킷 캡처 기능이 내장되어 있습니다. 공격자는 이 기능을 사용해 LDAP 패킷을 캡처함으로써 VPN을 통과하는 모든 인증정보를 가로챌 수 있습니다(그림 7).
그림 7: FortiGate 또는 Ivanti의 패킷 캡처 기능을 사용해 LDAP 통신 캡처
보안 프로토콜을 사용하는 경우 서버에서 일반 텍스트 인증정보가 전송되지 않습니다. 그럼에도 불구하고 VPN을 제어할 수 있는 공격자는 여전히 쉽게 캡처할 수 있습니다. VPN을 제어할 수 있다면 설정을 수정해 일반 LDAP로 다시 다운그레이드하는 것을 막을 방법이 없습니다.
일반 LDAP 서버의 경우, 설정을 일반 LDAP로 변경하면 됩니다. Ivanti의 AD 서버를 다운그레이드하려면 AD 연결 세부 정보를 사용해 기존 서버 대신 새로운 일반 LDAP 서버를 설정할 수 있습니다. 두 경우 모두 이러한 변경은 사용자에게 투명해야 하며 VPN이 비밀번호를 일반 텍스트로 전송하게 됩니다.
결론은 이렇습니다. 설정에 관계없이 LDAP 인증을 사용하면 VPN을 감염시킨 공격자가 쉽게 인증정보를 획득하고 도메인으로 피벗할 수 있습니다.
악성 인증 서버 등록
앞서 언급했듯이, 원격 사용자를 인증할 때 VPN은 적절한 인증 서버에 연락해 제공된 인증정보의 유효성을 검사합니다. Akamai는 이 인증 과정을 악용해 VPN에 사용자가 제공한 인증정보 를 감염시키는 방법을 발견했습니다.
이 기법은 VPN이 사용자를 인증할 때 사용할 악성 인증 서버를 등록하는 방식으로 작동합니다. 이 기법을 구현하는 방법을 이해하는 데 도움이 되도록 먼저 두 가지 VPN의 인증 프로세스에 대한 세부 사항을 설명하겠습니다.
FortiGate 사용자 그룹
FortiGate 사용자에게는 서로 다른 권한이 부여될 수 있으며, 서로 다른 정책이 적용됩니다. 각 사용자를 개별적으로 관리하는 대신 사용자를 사용자 그룹, 즉 정책 및 권한을 적용할 수 있는 사용자 집합에 포함할 수 있습니다.
이러한 그룹을 설정할 때 원격 인증 서버에 있는 그룹, 즉 원격 그룹의 사용자를 포함할 수 있습니다. 예를 들어, 특정 AD 그룹의 사용자를 포함할 수 있습니다(그림 8).
그림 8: FortiGate 사용자 그룹 설정
Akamai는 원격 그룹을 사용할 때 발생하는 흥미로운 행동을 관찰했습니다. 로컬 FortiGate 사용자와 LDAP 서버에 있는 원격 그룹이라는 두 개의 엔티티를 포함하는 사용자 그룹을 설정한다고 가정해 보겠습니다.
인증과 관련해 다음과 같은 행동이 예상됩니다.
그룹의 로컬 구성원이 FortiGate에 인증하면, 인증정보는 FortiGate의 로컬 사용자 데이터베이스를 사용해 확인됩니다.
원격 그룹의 구성원이 FortiGate에 인증하면, 인증정보는 원격 그룹 LDAP 서버를 사용해 확인됩니다.
그러나 실제로는 그렇지 않습니다. 사용자 그룹에 원격 그룹을 추가한 후, 사용자 그룹의 모든 구성원이 인증할 때마다 FortiGate는 로컬 사용자 데이터베이스 와 원격 인증 서버를 모두 사용해 인증정보의 유효성을 검사하려고 시도합니다. 또한, 사용자 그룹에 둘 이상의 원격 서버를 추가하는 경우, FortiGate는 사용자 인증 시도에 설정된 모든 인증 서버를 사용합니다.
기본적으로 FortiGate는 특정 사용자를 적절한 인증 방법과 일치시키지 않고 단순히 모든 인증 방법을 시도합니다. 모두 성공하면 사용자가 인증된 것입니다.
Ivanti 인증 영역
Ivanti는 인증 영역이라는 사용자 그룹과 유사한 기능을 구현합니다. FortiGate의 사용자 그룹과 달리 각 Ivanti 인증 영역은 단일 인증 서버로 제한됩니다. 여러 서버의 사용자를 관리하려면 별도의 영역을 사용해야 합니다.
이러한 제한에도 불구하고 (그리고 편리하게도) Ivanti를 사용하면 ‘추가 인증 서버’를 설정할 수 있습니다(그림 9). 이 옵션은 특정 SSO 설정을 활성화하기 위한 것입니다.
그림 9: Ivanti 사용자 영역에 대한 추가 인증 서버 설정
추가 인증 서버를 설정하면 Ivanti는 두 서버를 모두 사용해 인증정보의 유효성 검사를 시도합니다. 두 서버가 모두 승인하는 경우에만 인증이 성공합니다.
인증정보를 유출하기 위한 악성 인증 서버 생성
공격자는 이러한 행동을 악용해 아무 원격 인증 서버를 사용함으로써 FortiGate 또는 Ivanti에 인증하는 모든 사용자의 인증정보를 유출할 수 있습니다. 사용자 그룹 또는 영역에 악성 인증 서버를 추가하면 VPN 서버가 공격자가 제어하는 서버로 인증정보를 유출하게 할 수 있습니다(그림 10).
그림 10: 클라이언트 인증정보를 감염시키기 위해 악성 인증 서버 추가
이러한 인증정보는 VPN에 연결하는 클라이언트의 인증정보이거나 관리 인터페이스에 연결하는 관리자의 인증정보일 수 있습니다. 사용자 그룹 또는 영역을 사용해 관리되는 모든 인증은 이 방법을 사용해 탈취될 수 있습니다.
이를 FortiGate에서 구현하기 위해 악성 서버를 사용하는 원격 그룹을 만든 다음 표적 사용자 그룹에 추가했습니다. Ivanti를 사용해 표적 영역에 대한 추가 인증 서버로 악성 서버를 간단히 추가했습니다.
이제 표적 사용자 그룹/영역의 구성원이 인증할 때마다 VPN은 Akamai 서버를 사용해 인증정보의 유효성 검사를 시도할 것입니다(그림 11).
그림 11: 사용자 그룹에 악성 RADIUS 인증 서버 추가
인증정보를 캡처하기 위해서는 RADIUS 인증 서버를 사용할 것입니다. 이 시나리오에서는 다음 두 가지 이유로 RADIUS 인증이 편리합니다.
사용자가 서버에 존재하는지를 먼저 확인하지 않고 초기 요청 중에 인증정보가 서버로 전송됩니다.
공격자가 결정한 키로 암호화된 인증정보가 서버로 전송되어 공격자가 일반 텍스트 인증정보를 복구할 수 있습니다(그림 12).
그림 12: RADIUS 인증 메시지의 암호화된 비밀번호
다음 스크립트(RFC 2865 기반)는 RADIUS 비밀번호를 해독할 수 있습니다.
import hashlib
# Authenticator value can be obtained from the PCAP
authenticator = bytearray.fromhex("98f245b6e3724f5873fa74e576323c67")
enc = bytearray.fromhex("15644ca055b817ce683083fecebc2902016f2890660d0dfcaee214a0dbaa1046")
# Pre-shared key configured by the attacker when setting up the rogue server
secret = bytes("verygoodpsk", "utf-8")
chunk_len = 16
enc_chunks = []
dec = ""
for i in range(0, len(enc), chunk_len):
enc_chunks.append(enc[i:i+chunk_len])
for chunk in enc_chunks:
dec_chunk = b""
chunk_key = hashlib.md5(secret + authenticator ).digest()
i = 0
for enc_byte in chunk:
dec_chunk += (enc_byte ^ chunk_key[i]).to_bytes(1,"big")
dec += chr(enc_byte ^ chunk_key[i])
i+=1
authenticator = chunk
print(dec)
마지막으로 참고할 점은 앞서 언급했듯이 Ivanti가 추가 인증 서버를 사용하는 경우 인증이 성공하려면 두 서버 모두 사용자를 승인해야 한다는 것입니다. 서버가 제공된 인증정보를 승인하지 않으면 사용자는 Ivanti에 인증할 수 없습니다. 이를 방지하려면 RADIUS 서버가 제공된 모든 인증정보를 승인하게 해야 하며, 이는 쉽게 설정할 수 있습니다.
설정 파일 비밀 추출
가장 우려되는 발견 사항은 VPN 설정 파일과 관련이 있습니다.
설정 파일에서 찾을 수 있는 여러 흥미로운 설정 중 가장 눈에 띄는 것은 비밀입니다. VPN은 로컬 사용자 비밀번호, SSH 키, 인증서 그리고 가장 흥미로운 써드파티 서비스 계정의 인증정보 등 많은 비밀을 설정에 저장합니다.
공격자는 크게 다음 두 가지 방법으로 이러한 민감한 파일을 얻을 수 있습니다.
공격자는 VPN에 대한 제어권을 얻은 후 관리 인터페이스를 통해 디바이스 설정을 내보낼 수 있습니다.
공격자는 공유 폴더와 같은 공개 위치에 저장된 이전에 내보낸 설정 파일을 찾을 수 있습니다.
이를 보호하기 위해 설정 파일에 암호화된 형태로 비밀이 저장됩니다. 그림 13은 FortiGate 설정 파일에 암호화된 비밀의 예시를 보여줍니다.
그림 13: FortiGate 설정 파일 내의 암호화된 비밀번호
이제 몇 가지 비밀을 해독해 보겠습니다!
FortiGate 설정 파일의 비밀 해독
비밀이 해시되어 있기 때문에 복구할 수 없다고 생각할 수 있지만 실제로는 그렇지 않습니다. 예를 들어, 통합 비밀번호는 써드파티에 연결하기 위해 일반 텍스트 비밀번호가 필요하므로 가역적 암호화를 사용해 저장해야 합니다.
이는 FortiGate 비밀번호 암호화 프로세스를 파헤친 바트 도페이드(Bart Dopheide)의 블로그 게시물에서 입증되었습니다. FortiGate는 AES를 사용해 설정의 모든 비밀을 암호화합니다. 이 암호화를 수행하는 데 어떤 키가 사용될까요? 도페이드는 모든 FortiGate 어플라이언스에서 싱글 하드코딩 키 가 사용된다는 사실을 발견했습니다. 이 키는 변경할 수 없습니다. 원 블로그 게시물에는 이 키가 공유되어 있지 않지만, Google에 검색하면 바로 찾을 수 있습니다.
Fortinet은 이 문제에 CVE 2019–6693 을 할당하고 수정을 구현해 사용자가 하드 코딩된 키를 사용자 지정 키로 변경할 수 있게 했습니다.
이 수정 이후에도 이 문제는 오늘날 여전히 매우 중요합니다. 키가 변경되지 않았기 때문에 기본적으로 FortiGate 어플라이언스는 여전히 동일한 키를 사용합니다. 즉, 공격자가 기본 설정으로 FortiGate 어플라이언스의 설정 파일을 입수하면 디바이스에 저장된 모든 비밀을 해독할 수 있습니다. 이 코드는 해독 프로세스를 구현합니다.
하지만 FortiGate 관리자가 모범 사례에 따라 기본 키 대신 사용자 지정 키를 사용했다면 어떨까요? Akamai는 VPN을 제어하면 여전히 쉽게 비밀을 얻을 수 있다는 사실을 발견했습니다.
개인 데이터 암호화 설정은 사용자 지정 암호화 키를 제어하는 데 사용됩니다. 놀라운 점은 관리자가 이 기능을 간단히 비활성화할 수 있다는 것입니다. 이 작업에는 현재 설정된 키에 대한 지식이 필요하지 않으며 모든 비밀의 암호화가 원래 하드 코딩된 키로 되돌려집니다.
암호화 되돌리기
암호화를 되돌리려면 다음 FortiGate 명령줄 인터페이스 명령을 사용할 수 있습니다.
FGT # config system global
FGT (global) # set private-data-encryption disable
FGT (global) # end
이 시점에서 설정 파일을 다운로드하고 알려진 기본 키를 사용해 (앞에서 설명한 것과 동일하게) 비밀을 해독할 수 있습니다.
이 방법을 사용하면 많은 흥미로운 비밀이 감염될 수 있습니다. FortiGate는 ‘외부 커넥터’ 기능을 통해 다양한 애플리케이션과의 통합을 지원합니다. 이러한 커넥터는 다양한 용도로 사용되지만 대부분 애플리케이션에 대한 인증정보가 필요하다는 중요한 측면을 공유합니다(그림 14).
그림 14: FortiGate 외부 커넥터 옵션
즉, FortiGate에는 클라우드 공급업체, SAP, 쿠버네티스, ESXi 등과 같은 중요한 서비스에 대한 인증정보가 포함되어 있을 수 있습니다.
어떤 경우에는 인증정보를 얻는 데 해당 애플리케이션에 대한 높은 권한이 필요합니다. 예를 들어, ‘Active Directory 서버 폴링’ 통합 작업에는 도메인 컨트롤러에 대한 관리 접속 권한이 있는 계정의 인증정보가 필요하므로 FortiGate 유출이 즉시 전체 도메인 유출로 전환될 가능성이 있습니다.
Ivanti 설정 파일에서 비밀 해독
Ivanti의 상황도 매우 유사합니다. 사실 더 심각할 수도 있습니다.
Ivanti는 또한 가역 암호화를 사용해 비밀을 저장합니다. 디바이스에서 코드를 추출해 자세히 살펴보면 암호화 키로 사용되는 비밀 값을 빠르게 찾을 수 있는데, 이는 (역시) 정적 문자열입니다(그림 15).
그림 15: Ivanti 정적 암호화 키
Akamai는 전체 키를 삭제했지만, 키의 시작 부분을 살펴보면 적어도 Juniper가 마지막으로 Connect Secure를 소유했던 2015년 이후로는 변경되지 않았을 가능성이 높다고 추정할 수 있습니다.
Ivanti는 저장된 비밀을 보호하는 데 더 큰 노력을 기울여 FortiGate보다 더 복잡한 암호화 알고리즘을 구축한 것으로 보입니다. 그럼에도 불구하고 이 프로세스는 분명히 여전히 가역적입니다. 즉, 모든 Ivanti 인스턴스 전반의 비밀은 변경할 수 없는 하나의 정적 키를 사용해 암호화됩니다. 공격자는 이 지식을 사용해 모든 Ivanti 설정 파일을 해독할 수 있습니다.
Ivanti가 비밀번호를 해독하도록 허용
초기 접근 방식은 암호화 프로세스를 리버스 엔지니어링해 비밀 해독기를 만드는 것이었습니다. 물론 가능하지만, 디컴파일된 코드를 몇 시간 동안 살펴본 후 개념 증명(PoC)을 위해 다른 접근 방식을 사용하기로 결정했습니다. Akamai는 Ivanti에게 힘든 작업을 맡겼습니다.
주요 아이디어는 공격자 소유의 전용 Ivanti 인스턴스를 사용해 암호화된 비밀번호를 ‘공급’한 다음 비밀을 해독하게 하는 것입니다(그림 16).
그림 16: 공격자 실험실 환경에서의 Ivanti 비밀번호 해독 프로세스
해독은 다음 단계를 통해 수행할 수 있습니다.
Ivanti 설정 파일에서 암호화된 비밀번호 획득
실험실 환경에서 Ivanti 인스턴스와 LDAP 서버(예: Active Directory를 실행하는 Windows 서버) 설정
실험실 Ivanti 인스턴스에서 간편 인증을 사용하는 인증 서버로 LDAP 서버 설정
실험실 Ivanti 설정을 파일로 내보내기
설정 파일의 기존 암호화된 LDAP 비밀번호를 해독하려는 암호화된 비밀번호로 바꾸기
수정된 설정 파일을 Ivanti 인스턴스로 다시 가져오기
이제 LDAP 서버에 대한 인증 시도를 트리거하면 Ivanti가 설정에서 비밀번호를 해독해 일반 텍스트로 LDAP 서버로 전송합니다. 패킷을 캡처하면 해독된 비밀번호를 얻을 수 있습니다(그림 17).
그림 17: 제공된 비밀번호를 해독하고 그 결과를 LDAP로 유출하는 Ivanti
Akamai는 해독 프로세스의 ‘인터페이스’로 LDAP 서버 인증을 사용하지만, LDAP 비밀번호에만 국한되지 않는다는 점에 유의해야 합니다. 테스트 결과 이 기법은 AD 비밀번호, RADIUS 사전 공유 키 및 API 키를 포함하되 이에 국한되지 않는 설정 파일에 저장된 모든 비밀에 대해 작동 하는 것으로 나타났습니다.
일반 텍스트 MDM 서버 비밀번호
Ivanti는 인증 방법으로 몇 가지 인기 있는 모바일 디바이스 관리(MDM) 서버를 지원합니다(그림 18).
그림 18: Ivanti MDM 서버 설정
다른 인증 서버와 마찬가지로 이 통합 작업에는 MDM 서버에 대한 인증정보가 필요합니다. MDM 서버의 설정을 살펴보면 두 가지 흥미로운 필드를 발견할 수 있는데, 바로 ‘비밀번호 암호화’ 및 ‘비밀번호 일반 텍스트’입니다. 이름에서 알 수 있듯이 두 필드 모두 일반 텍스트로 저장됩니다(그림 19). ♂️
그림 19: 일반 텍스트 비밀번호가 포함된 Ivanti MDM 설정
인터넷에서 사용되는 VPN 악용 이후 기법
이 게시물에서 강조한 기법 중 일부는 이미 인터넷에서 사용되고 있을 가능성이 있습니다. Ivanti 어플라이언스에 대한 일련의 악용 캠페인을 다룬 Cutting Edge 보고서에서 Mandiant 연구원들은 공격자가 Ivanti 디바이스에 설정된 LDAP 서비스 계정을 유출할 수 있다고 밝혔습니다(그림 20).
그림 20: 감염된 LDAP 계정을 언급한 Mandiant의 보고서
Mandiant 보고서는 공격자가 이 작업을 수행한 방법을 자세히 설명하지 않지만 Akamai는 이 블로그에서 강조한 방법 중 하나를 사용해 인증정보를 획득했을 가능성이 높다 고 생각합니다. 그 방법은 바로 설정 파일에서 인증정보를 추출하거나 네트워크 트래픽을 스니핑하는 것입니다.
이러한 종류의 기술은 구축하기가 아주 쉽기 때문에 모든 수준의 정교함을 갖춘 공격자가 이를 사용할 수 있을 것으로 간주됩니다.
VPN 서버 사용 시 권장 사항
Akamai는 방금 강조한 기법으로 인한 리스크를 최소화하기 위해 VPN 서버를 사용할 때 따라야 할 네 가지 원칙을 권장합니다.
제로 트러스트 네트워크 접속(ZTNA) 사용
서비스 계정 권한 제한
VPN 인증에 전용 ID 사용
설정 변경 모니터링
1. 제로 트러스트 네트워크 접속(ZTNA) 사용
기존 VPN의 주요 문제 중 하나는 네트워크에 대한 접속 권한을 부여하는 ‘전부 아니면 전무’ 접근 방식입니다. 이때 사용자는 ‘In’(네트워크에 완전히 접속할 수 있음)이거나 ‘Out’(아무것도 접속할 수 없음)인 상태입니다.
이 두 가지 옵션 모두 문제가 있습니다. 한편으로는 사용자에게 내부 애플리케이션에 대한 원격 접속 권한을 제공해야 합니다. 다른 한편으로는 공격자가 VPN 서버를 감염시킬 경우 네트워크에 대한 전체 접속 권한을 얻지 못하게 해야 합니다.
제로 트러스트 네트워크 접속(ZTNA) 이 해결책을 제시합니다. 엔티티별로 네트워크 접속 정책을 정의함으로써 사용자가 승인된 원격 작업을 수행하도록 허용하는 동시에 잠재적인 유출로 인한 영향을 줄일 수 있습니다.
Akamai Enterprise Application Access 는 ID와 맥락을 기반으로 프라이빗 애플리케이션에 대한 정밀한 접속을 제공하는 ZTNA 솔루션입니다. ID 기반 정책과 사용자 위치, 시간, 디바이스 보안 등의 실시간 데이터를 사용해 사용자가 필요한 애플리케이션에만 접속하게 하고 네트워크 수준의 접속을 차단합니다. Akamai MFA와 원활하게 연동되어 강력한 사용자 인증을 지원합니다.
2. 서비스 계정 권한 제한
이 게시물에서 설명한 바와 같이 VPN 서버에 저장된 서비스 계정의 일반 텍스트 비밀번호를 복구하는 것은 간단합니다. VPN은 어떤 경우에는 일반 텍스트 비밀번호를 사용해야 하기 때문에 이를 피할 수 있는 실질적인 방법은 없습니다.
잠재적인 VPN 감염의 영향을 줄이려면 권한이 제한된 서비스 계정(가급적 읽기 전용)을 사용하는 것이 좋습니다. 보안팀 직원은 공격자가 VPN에 저장된 인증정보를 활용하는 방법이 있는지 파악하고 VPN 유출이 다른 중요한 자산의 유출로 이어지지 않게 해야 합니다.
일부 통합 작업에는 강력한 권한이 있는 서비스 계정이 필요합니다. 가능하면 이러한 통합 작업은 피해야 합니다.
3. VPN 인증에 전용 ID 사용
이제 우리는 VPN을 제어할 수 있는 공격자가 VPN 사용자를 인증하는 인증정보를 감염시키는 것은 아주 쉬운 일이라는 것을 압니다. AD와 같은 기존 인증 서비스를 사용해 VPN 사용자를 인증하고 싶을 수 있지만, 이는 피하는 것이 좋습니다. VPN을 제어할 수 있는 공격자는 인증정보를 획득하고 이를 사용해 내부 자산으로 피벗해 VPN을 단일 장애 지점으로 만들 수 있습니다.
대신 별도의 전용 방법을 사용해 VPN에 사용자를 인증하는 것이 좋습니다. 예를 들어, 이 용도로 특별히 발급된 인증서를 사용해 인증서 기반 인증을 수행하세요.
4. 설정 변경 모니터링
위에서 강조한 기법은 모두 어떤 식으로든 디바이스 설정에 반영됩니다. 네트워크 디바이스 설정은 자주 변경되지 않는 경향이 있으므로 이러한 변경 사항은 중요한 탐지 기회를 제공할 수 있습니다.
설정 변경 사항을 파악하려면 주기적으로 디바이스 설정을 가져와서 ‘골든 이미지’와 비교하는 것이 좋습니다. 디바이스 대부분에는 시스템 및 보안 이벤트에 대한 내부 로깅 기능도 포함되어 있습니다. 사용 가능한 모든 로그를 수집하고 분석해 디바이스 설정의 의심스러운 변경 사항을 식별하는 데 사용하는 것이 좋습니다.
이 네 가지 원칙은 한 마디로 요약할 수 있습니다. ‘VPN을 맹목적으로 신뢰하지 마세요.’
요약
공격자는 사용자의 VPN을 노립니다. 사실입니다. 보안팀 직원은 공격자가 VPN에 접속하는 것은 시간문제라고 생각하고 지금부터 그에 따라 행동해야 합니다. 보안팀 직원은 감염된 VPN이 완전히 감염된 네트워크로 이어지지 않게 해야 합니다.
공개 타임라인
Ivanti
2024.03.26 - 벤더사에 최초 보고
2024.04.05 - Ivanti는 신고 내용을 인정하고 수정 작업을 진행 중이라고 알림
2024.06.03 - Akamai가 8월 7일에 리서치 내용을 게시할 계획임을 Ivanti에 최초 통지
2024.06.27 - Ivanti는 수정 작업을 진행 중이지만 게시일 이전에 문제가 해결될지 확인할 수 없다고 밝힘
2024.07.08 - Ivanti는 하드 코딩된 키 문제와 MDM 일반 텍스트 비밀번호에 CVE-2024-37374와 CVE-2024-37375를 할당했지만 아직 패치를 릴리스하지는 않음
2024.07.15 - 예정된 릴리스 일정에 대해 Ivanti에 추가 통지
2024.08.07 - 리서치 게시
Fortinet
2024.03.22 - 벤더사에 최초 보고
2024.04.17 - Fortinet 초기 대응, 설명된 문제 중 어느 것도 수정이 필요하지 않다는 결론
2024.04.21 - Akamai가 8월 7일에 리서치 내용을 게시할 계획임을 Fortinet에 최초 통지
2024.04.30 - Fortinet은 설명한 사용자 지정 암호화 키 우회 문제를 수정할 계획이라고 알림
2024.07.15 - 예정된 릴리스 일정에 대해 Fortinet에 추가 통지
2024.07.23 - Fortinet은 게시일 이전에 패치를 릴리스하지 못할 가능성이 높다고 밝힘
2024.08.02 - Fortinet은 추가 고려 끝에 사용자 지정 암호화 키 우회가 ‘보안 경계를 넘지 않기 때문에’ 수정하지 않기로 결정했다고 알림
2024.08.07 - 리서치 게시