악성 PowerShell 코드로 패치되지 않은 Exchange 서버를 해킹하는 방법

불과 XNUMX달 전만 해도 걱정스러운 버그 소식이 전해졌습니다. Microsoft Exchange에서 한 쌍의 제로데이 취약점이 발표되었습니다.

마찬가지로 우리 당시 조언, 이러한 취약점은 공식적으로 지정 CVE-2022-41040 과 CVE-2022-41082:

서로 연결할 수 있는 두 개의 제로 데이가 있었습니다. 첫 번째 버그는 Exchange 서버 자체에서 잠재적으로 원격 코드 실행(RCE)을 허용하는 두 번째 버그를 트리거할 수 있는 구멍을 원격으로 여는 데 사용되었습니다.

첫 번째 취약점은 번거롭고 널리 악용되는 ProxyShell 보안 허점 Exchange 자동 검색 기능의 위험한 동작에 의존했기 때문에 2021년 XNUMX월부터 마이크로소프트가 설명하는 프로토콜로 "Outlook 및 EAS [Exchange ActiveSync] 클라이언트에서 Exchange의 사서함을 찾고 연결하는 데 사용".

다행스럽게도 로그인 여부에 관계없이 모든 원격 사용자가 ProxyShell 공격에서 악용할 수 있는 Autodiscover 잘못된 기능은 XNUMX년 이상 전에 패치됨.

안타깝게도 ProxyShell 패치는 인증된 사용자에 대한 익스플로잇을 차단하기에 충분하지 않아 새로운 CVE-2022-40140 제로데이로 이어졌습니다. 더빙 된 ProxyNotShell.

위험하지는 않지만 그럼에도 불구하고 위험합니다

분명히 ProxyNotShell은 인증된 액세스라고 알려진 것을 필요로 했기 때문에 원래 ProxyShell만큼 위험하지 않았습니다.

그러나 많은 Exchange 서버에서 사용자의 로그온 이름과 암호를 알면 인증된 것으로 통과하고 이 공격을 수행하기에 충분하다는 사실이 빠르게 드러났습니다. 사용자가 액세스하기 위해 올바르게 로그온하기 위해 이중 인증(2FA)을 사용해야 하는 경우에도 마찬가지입니다. 그들의 이메일.

Sophos 전문가 Chester Wisniewski 넣어 당시 :

당신이 그것을 부르고 싶다면 "중간 인증 취약점"입니다. 그것은 복합적인 축복입니다. 자동화된 Python 스크립트가 2021년 ProxyLogon 및 ProxyShell에서 발생한 것처럼 전체 인터넷을 스캔하고 전 세계의 모든 Exchange 서버를 몇 분 또는 몇 시간 만에 잠재적으로 악용할 수 없음을 의미합니다. […

암호가 필요하지만 주어진 Exchange 서버에서 유효한 하나의 이메일 주소와 암호 조합을 찾는 것은 불행히도 그리 어렵지 않을 것입니다. 그리고 OWA(Outlook Web Access)에 성공적으로 로그인하려면 FIDO 토큰, 인증자 또는 사용 중인 두 번째 요소가 필요하기 때문에 지금까지 악용되지 않았을 수 있습니다.

그러나이 공격에는 두 번째 요소가 필요하지 않습니다. [...] 사용자 이름과 암호 조합을 얻는 것만으로도 장벽이 매우 낮습니다.

아마 기억하시겠지만, 우리 중 많은 사람들은 XNUMX월 패치 화요일까지 아직 XNUMX주가 남았다는 점을 감안할 때 Microsoft가 ProxyNotShell 구멍에 대한 수정을 서두르겠다고 가정했습니다(또는 적어도 희망했습니다).

그러나 우리는 신뢰할 수 있는 해결책이 분명히 있다는 사실에 실망했습니다. 생각보다 복잡하다, 그리고 XNUMX월은 적절한 패치가 아닌 해결 방법으로만 해결되는 ProxyNotShell과 함께 왔습니다.

XNUMX월 패치 화요일도 필요한 수정 사항을 직접 제공하지 않았습니다. 그럼에도 불구하고 나왔다 별도로 가져와서 설치할 수 있는 Exchange 특정 보안 업데이트의 일부로 같은 날:

개념 증명 공개

문제가 해결되고 모든 사람이 Exchange 서버(최소한 잊어버리지 않은 서버)를 패치할 시간을 가졌으므로 ZDI(Zero Day Initiative)의 연구원은 원래 이 취약점을 제출하기 위해 책임 있게 공개했습니다. 마이크로소프트, 설명했다 버그를 악용하는 방법.

명백한 악용 공개에 대한 귀하의 의견에 따라 나쁜 소식은 ZDI 팀이 이제 Exchange 서버를 공격하는 방법을 설명하는 개념 증명(PoC)을 효과적으로 제공했다는 것입니다.

물론 좋은 소식은 다음과 같습니다.

• 이제 버그를 직접 연구하고 이해할 수 있습니다. 이렇게 하면 우리가 취한 전반적인 예방 조치(패치에 국한되지 않음)가 우리가 기대하는 보호를 제공할 가능성이 있음을 확인하는 데 도움이 될 뿐만 아니라 향후 피하고 싶은 프로그래밍 관행을 알려줍니다. 우리 자신의 서버 측 코드에서 이런 종류의 버그를 여는 데 갇히지 마십시오.
• 이제 패치를 적용하지 않은 것에 대해 더 이상 변명의 여지가 없습니다. 업데이트에 대해 시간을 끌었다면 공격이 작동하는 이유에 대한 ZDI의 설명은 확실히 질병보다 치료법이 더 낫다는 것을 분명히 합니다.

전달 방법

ZDI의 설명 이 취약점에 대한 설명은 취약점을 실행 가능한 악용으로 전환하는 데 필요한 모든 부분을 함께 연결하는 것이 얼마나 복잡한지에 대한 흥미로운 이야기를 만듭니다.

또한 기존 익스플로잇을 파고들어 취약점이 오용될 수 있는 다른 방법을 밝히고, 잠재적으로 추가 패치를 요구하고, 구성 변경을 촉구하고, 수정만으로는 분명하지 않을 수 있는 새로운 프로그래밍 관행을 촉진하는 데 도움이 되는 이유를 이해하는 데 도움이 되는 내용도 읽어볼 가치가 있습니다. 원래 구멍.

설명은 필연적으로 복잡하고 매우 기술적이며 마지막에 RCE(원격 코드 실행)를 달성하기 위한 일련의 긴 단계를 안내합니다.

ZDI 보고서를 읽기로 결정한 경우 높은 수준의 세부 정보를 보다 쉽게 ​​따를 수 있도록 하기 위해 역순으로 나열된 단계가 포함된 요약이 여기에 있습니다.

...그래서 스토리가 진행되는 방향을 취하는 이유를 미리 알 수 있습니다.

• 4단계. 선택한 초기화 매개변수를 사용하여 원격으로 Exchange를 속여 선택한 .NET 개체를 인스턴스화합니다.

현대 코딩에서는 인스턴스화된 객체 할당된 메모리 청크에 대한 전문 용어로, 사용 중인 동안 필요한 데이터와 리소스로 자동으로 초기화되고 작동할 수 있는 특정 기능 집합에 연결됩니다. (인스턴스화 에 대한 멋진 단어입니다 만들.)

개체는 일반적으로 메모리를 직접 할당하고 관련 데이터 필드를 수동으로 채우고 완료되면 네트워크 소켓이나 디스크 파일과 같이 사용 중인 메모리와 리소스를 해제합니다.

객체에는 일반적으로 건설자, 적절한 양의 메모리와 올바른 시스템 리소스 세트를 할당하기 위해 새 개체가 생성될 때 자동으로 실행됩니다.

일반적으로 하나 이상의 매개 변수를 생성자에 인수로 전달하여 개체가 시작될 때 구성할 방법을 지정해야 합니다.

간단히 말해서 인스턴스화하면 TextString 다음과 같은 텍스트 문자열 자체인 매개변수를 사용하여 개체(이 이름을 지어내고 있지만 아이디어를 얻음) example.com:8888...

... 아마도 텍스트를 저장하기 위해 할당된 메모리 버퍼로 끝날 것입니다. 초기화되어 전달한 것과 동일한 값, 즉 원시 텍스트를 저장합니다. example.com:8888.

그런 맥락에서 개체 생성자에 데이터로 전달된 텍스트 문자열은 생성자를 원격으로 트리거할 때 더 큰 문자열을 반복적으로 요청하여 가능한 서비스 거부(DoS)를 제외하고 즉시 명백한 사이버 보안 위협을 제기하지 않습니다. 메모리를 소진하십시오.

하지만 예를 들어 ConnectedTCPClient 의 매우 동일한 텍스트 문자열 매개변수를 사용하는 객체 example.com:8888, 서버와 데이터를 교환할 준비가 된 운영 체제에 의해 할당된 네트워크 소켓과 함께 임시 데이터를 보유할 준비가 된 메모리 버퍼가 생길 수 있습니다. example.com TCP 포트를 통해 8888.

서버를 속여 제어하는 ​​위치로 홈을 호출하도록 속인 경우 열린 소켓에 데이터를 보내지 않더라도 원격 코드 실행 위험을 볼 수 있습니다.

예를 들어 다음과 같은 개체를 찾을 수도 있습니다. RunCmdAndReadOutput여기서 매개 변수로 보내는 텍스트 문자열은 말 그대로 개체가 생성되는 즉시 자동으로 실행하여 나중에 해당 출력을 수집할 수 있도록 하는 명령입니다.

명령의 출력을 복구할 수 없더라도 그러한 개체를 인스턴스화하면 실행할 명령을 선택할 수 있으므로 일반적인 원격 코드 실행이 가능하고 서버 프로세스 자체의 액세스 권한에 의해서만 제한되는 위험이 있습니다. .

물론 Exchange에는 인스턴스화할 이전 개체를 선택하지 못하도록 하는 엄격한 허용 목록이 있기 때문에 공격은 마지막 단계에 도달한 후에만 가능합니다.

이론적으로 안전하거나 위험도가 낮은 객체만 PowerShell을 통해 원격으로 생성할 수 있습니다. TextString 위, 또는 SimpleIntegerValue, 허용 가능한 것으로 간주될 수 있지만 ConnectedTCPClient 또는 RunCmdAndReadOutput 확실히 그렇지 않을 것입니다.

그러나 ZDI 연구원은 마지막 단계를 트리거하기 전에 다음과 같이 할 수 있음을 확인했습니다.

• 3단계. 원격으로 Exchange를 속여 안전 테스트를 통과한 위험도가 낮은 개체를 실제로는 사용자가 선택한 다른 개체로 생각하도록 합니다.

그렇더라도 Exchange가 위험도가 낮은 개체의 원격 생성을 방지하여 위협을 더욱 최소화할 것으로 예상할 수 있습니다.

그러나 연구원들은 다음과 같은 작업을 수행할 수 있음을 발견했습니다.

• 2단계. 원격으로 Exchange를 속여 PowerShell Remoting 외부에서 제어되는 초기화 매개변수를 기반으로 개체를 생성하는 기능입니다.

그리고 그것은 단지 세미 패치된 ProxyShell과 같은 구멍 때문에 가능했습니다.

• 1단계. 유효한 코드를 압축하여 코드가 포함된 웹 요청을 수락하고 처리하도록 Exchange를 원격으로 속입니다. username:password 필드도 요청에 포함합니다.

요청에 이름이 지정된 사용자가 실제로 로그인하지 않았고 자신의 사서함에 액세스하기 위해 일종의 2FA 프로세스를 거쳐야 하는 경우에도 username:password 조합은 위의 2~4단계에서 설명한 공격 체인을 시작하는 데 사용할 수 있는 웹 연결을 수락하도록 Exchange를 속일 수 있는 충분한 인증 정보를 가지고 있습니다.

느슨하게 말하면 모든 유효한 username:password Exchange가 HTTP 요청을 미리 거부하는 것을 방지하기 위해 "인증"이 필요하다는 점을 고려하면 조합이 가능합니다.

무엇을해야 하는가?

이 공격은 다음에서만 작동합니다.

• 온프레미스 Exchange 서버가 있는 경우. Microsoft는 자체 클라우드 서비스를 신속하게 잠갔다고 주장하므로 Exchange Online은 영향을 받지 않습니다. 당신을 확인 Exchange 서버의 위치 파악. 지금 Exchange Online을 사용하는 경우에도 마이그레이션 프로세스에서 실수로 남아 있는 온-프레미스 서버가 여전히 실행 중일 수 있습니다.
• 서버가 패치되지 않은 경우. 당신이되어 있는지 확인 2022-11-08 Exchange 소프트웨어 업데이트 적용 에 취약점을 닫습니다 익스플로잇이 요구하는 것.
• 서버가 레거시 인증이라고도 하는 기본 인증을 여전히 수락하는 경우. 당신이되어 있는지 확인 레거시 인증의 모든 측면 차단 따라서 귀하의 서버는 username:password 위에서 언급한 헤더이며 애초에 위험한 자동 검색 프로토콜 요청을 수락하지 않습니다. 이것 공격자 중지 해당 서버가 패치되지 않은 경우에도 부비 트랩 개체 인스턴스화 트릭을 수락하도록 서버를 속입니다.

여러분의 시간과 재능으로 추적하다 우리의 공식적인 예방, 치료 및 대응 조언, 그리고 Sophos 고객은 Sophos X-Ops Twitter 피드(@SophosXOps).

CVE-2022-41040 및 CVE-2022-41082에 대한 새로운 정보가 게시되었습니다. https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops(@SophosXOps) 2022 년 11 월 21 일

---

Exchange 인증 및 OAUTH2에 대해 자세히 알아보기

Paul Ducklin과 Chester Wisniewski와 함께
인트로 및 아웃트로 음악 에디스 머지.

---