S3 Ep102.5: "ProxyNotShell" 교환 버그 – 전문가의 말 [오디오 + 텍스트]

플라톤에 의해 재발행

팔로워 : 0

당황하지 말고 행동할 준비가 되어 있어야 합니다.

Paul Ducklin과 Chester Wisniewski와 함께

인트로 및 아웃트로 음악 에디스 머지.

원하는 지점으로 건너뛰려면 아래의 음파를 클릭하고 끕니다. 당신은 또한 수 직접 들어 사운드클라우드에서.

당신은 우리를들을 수 있습니다 사운드 클라우드, Apple Podcasts, Google 포드 캐스트, 스포티 파이, 스티 그리고 좋은 팟캐스트가 있는 곳이면 어디든지. 아니면 그냥 버리세요 RSS 피드의 URL 좋아하는 팟캐쳐에.

대본 읽기

[뮤지컬 모뎀]

오리. 모두 안녕.

Naked Security 팟캐스트의 또 다른 특별 미니 에피소드에 오신 것을 환영합니다.

저는 친구이자 동료인 Chester Wisniewski와 함께 다시 합류한 Paul Ducklin입니다.

안녕하세요, 쳇.

쳇. [FAKE AUSSIE ACCENT] 안녕, 오리.

오리. 음, Chet, 모두가 듣고 있다고 확신합니다. 그들이 팟캐스트가 나온 직후 듣고 있다면 우리가 무엇에 대해 이야기할지 알고 있습니다!

그리고 이것은 이중 배럴이어야합니다 마이크로소프트 익스체인지 제로데이 2022년 XNUMX월 마지막 날에 세탁물에서 나온 것입니다.

우리의 세일즈 친구들은 "아, 월말이야, 분기말이야, 정신없는 시간이야...하지만 내일은 모두가 0달러로 리셋된다."라고 말합니다.

이번 주말에는 시스템 관리자와 IT 관리자에게 그런 일이 없을 것입니다!

쳇. 오리, 내 생각에, 그리운 더글러스 애덤스의 불멸의 말에서, "당황하지 말 것" 순서가 될 수 있습니다.

많은 조직이 더 이상 Exchange 서버에서 자체 이메일을 호스팅하지 않으므로 많은 사람들이 이번 주말에 스트레스를 받지 않고 심호흡을 하고 잠시 시간을 보낼 수 있습니다.

그러나 Exchange를 온프레미스로 실행하는 경우…

...저라면 몇 가지 완화 조치를 취하기 위해 약간의 초과 근무를 할 수 있습니다. 아마도 월요일이나 화요일에 이 일이 더 큰 일로 발전할 불쾌한 놀라움을 겪지 않도록 하기 위함입니다. 극적인.

오리. 그래서, 그것은 CVE-2022-41040 및 CVE-2022-41042... 꽤 많은 양입니다.

트위터에서 이렇게 언급되는 걸 본 적이 있다. ProxyNotShell, 와 약간의 유사점이 있기 때문에 프록시쉘 불과 XNUMX년 전만 해도 큰 화제가 되었던 취약점,

그러나 이러한 유사점이 있기는 하지만 서로 연결되어 잠재적으로 원격 코드 실행을 제공하는 완전히 새로운 익스플로잇 쌍입니다. 맞습니까?

쳇. 그게 무슨 소리야.

이러한 취약점은 피해자에 대한 적극적인 공격 중에 발견되었으며 GTSC라고 하는 베트남 조직은 이 두 가지 새로운 취약점을 밝혀내어 적이 일부 클라이언트에 액세스할 수 있도록 했습니다.

책임감있게 공개한듯 그 취약점 제로데이 취약점을 책임감 있게 보고하기 위해 Trend Micro에서 운영하는 ZDI(Zero Day Initiative)에 참여합니다.

그리고 물론 ZDI는 XNUMX주 조금 전에 Microsoft와 모든 인텔리전스를 차례로 공유했습니다.

그리고 오늘 나오는 이유는 베트남 그룹이...

...그들은 XNUMX주가 지났지만 이러한 민족 국가 행위자들로부터 사람들을 보호하는 데 도움이 되는 경보나 조언이 나오지 않았다는 사실에 약간 조바심을 내고 걱정하는 것처럼 들립니다.

그래서 그들은 경종을 울리고 자신을 보호하기 위해 무엇인가 해야 한다는 것을 모두에게 알리기로 결정했습니다.

오리. 그리고 공평하게, 그들은 조심스럽게 말했습니다. "이러한 취약점을 악용하는 방법을 정확히 밝히지는 않겠지만 효과적인 것으로 확인된 완화 방법을 제공할 것입니다."

익스플로잇 자체가 특별히 위험하지 않은 것처럼 들립니다...

...하지만 함께 연결하면 서버에서 이메일을 읽을 수 있는 조직 외부의 누군가가 실제로 첫 번째 버그를 사용하여 문을 열고 두 번째 버그를 사용하여 본질적으로 Exchange 서버에 맬웨어를 삽입할 수 있음을 의미합니다.

쳇. 그리고 그것은 당신이 말했던 정말 중요한 요점입니다. "당신의 서버에서 이메일을 읽을 수 있는 사람."

이것은 *인증되지 않은* 공격이 아니므로 공격자가 이러한 공격을 성공적으로 실행하려면 조직에 대한 정보가 필요합니다.

오리. 이제 우리는 그들이 어떤 종류의 자격 증명을 필요로 하는지 정확히 알지 못합니다. 왜냐하면 우리가 이것을 녹음할 때 [2022-09-30T23:00:00Z], 모든 것이 여전히 대부분 비밀이기 때문입니다.

그러나 내가 읽은 것(믿는 경향이 있는 사람들에게서)에 따르면 세션 쿠키나 인증 토큰이 충분하지 않고 실제로 사용자의 암호가 필요한 것처럼 보입니다.

그러나 암호를 제공한 후 이중 인증[2FA]이 있는 경우 첫 번째 버그(문을 여는 버그)가 *비밀번호가 제공되는 지점과 2FA 코드가 입력되는 지점 사이에 트리거됩니다 요청*.

따라서 비밀번호는 필요하지만 2FA 코드는 필요하지 않습니다 ...

쳇. 그렇게 부르고 싶다면 "중간 인증 취약점"처럼 들립니다.

그것은 혼합된 축복입니다.

이는 자동화된 Python 스크립트가 2021년에 ProxyLogon 및 ProxyShell에서 발생한 것과 같이 전체 인터넷을 스캔하고 전 세계의 모든 Exchange 서버를 몇 분 또는 몇 시간 만에 잠재적으로 악용할 수 없음을 의미합니다.

우리는 지난 18개월 동안 많은 조직에 피해를 입힌 웜웨어가 다시 발생하는 것을 보았습니다.

오리. "워마지"?

쳇. 워마지, 네! [웃음]

오리. 그 말인가?

글쎄, 그렇지 않다면 지금이다!

그게 마음에 들어요... 빌릴 수 있어요, 체스터. [웃음]

쳇. 나는 이것이 약간 벌레가 될 수 있다고 생각합니다. 맞습니까?

암호가 필요하지만 주어진 Exchange 서버에서 유효한 하나의 이메일 주소와 암호 조합을 찾는 것은 불행히도 그리 어렵지 않을 것입니다.

수백 또는 수천 명의 사용자에 대해 이야기할 때… 많은 조직에서 그 중 한두 명은 잘못된 암호를 가지고 있을 가능성이 높습니다.

Outlook Web Access[OWA]에 성공적으로 로그인하려면 FIDO 토큰이나 인증자 또는 사용 중인 두 번째 요소가 필요하기 때문에 지금까지 악용되지 않았을 수도 있습니다.

그러나 이 공격에는 두 번째 요소가 필요하지 않습니다.

따라서 사용자 이름과 비밀번호 조합을 얻는 것은 매우 낮은 장벽입니다…

오리. 이제 여기에 또 다른 복잡성이 있습니다. 그렇지 않습니까?

즉, 비록 마이크로소프트의 지침 공식적으로 Microsoft Exchange Online 고객이 Blue Alert를 중단할 수 있다고 공식적으로 밝혔습니다. 온프레미스 Exchange가 있는 경우에만 위험합니다…

… 아마도 몇 년 전에 클라우드로 전환한 사람들 중에 전환하는 동안 온프레미스와 클라우드 서비스를 동시에 실행했지만 온프레미스를 끄지 못한 사람들이 의외로 많습니다. 교환 서버.

쳇. 정확하게!

우리는 이것이 ProxyLogin 및 ProxyShell로 돌아가는 것을 보았습니다.

많은 경우 범죄자들은 자신에게 없다고 생각했던 Exchange 서버를 통해 네트워크에 침입했습니다.

예를 들어, 누군가는 VMware 서버에서 실행 중인 VM 목록을 확인하지 않고 온프레미스 네트워크와 클라우드 네트워크 간에 데이터를 포크리프팅하는 동안 마이그레이션하는 Exchange 서버가 지원했다는 사실을 알아차리지 못했습니다.

… 사실 여전히 켜져 있고 활성화되어 있고 인터넷에 노출되어 있었습니다.

그리고 더 나쁜 것은 그들이 거기에 있는지 알려지지 않았을 때 패치를 받을 가능성이 훨씬 더 적다는 것입니다.

내 말은, 최소한 Exchange가 있는 조직은 정기적으로 유지 관리 일정을 잡기 위해 최선을 다할 것입니다.

그러나 네트워크에 무언가가 있다는 사실을 모를 때 VM에서는 정말 쉬운 일인 "잊었기 때문에" Windows 업데이트나 Exchange 업데이트를 적용하지 않았을 가능성이 높기 때문에 상황은 더욱 악화됩니다.

오리. 그리고 머피의 법칙에 따르면 해당 서버에 정말로 의존하고 있으며 제대로 관리하지 않으면 정말로 필요한 바로 전날에 충돌이 발생합니다.

그러나 그것이 있는지 모르고 나쁜 용도로 사용될 수 있다면 몇 년, 몇 년, 몇 년 동안 아무 문제 없이 작동할 가능성이 상당히 높을 것입니다. [웃음]

쳇. 예, 불행히도 그것은 확실히 제 경험이었습니다!

어리석게 들릴지 모르지만 자신이 가지고 있는 것을 찾기 위해 자신의 네트워크를 스캔하는 것은 어쨌든 정기적으로 수행하는 것이 좋습니다.

그러나 확실히, 이와 같은 게시판에 대해 들었을 때 Microsoft Exchange와 같이 과거에 사용했다는 것을 알고 있는 제품이라면 내부 엔맵 스캔...

… 그리고 아마도 로그인할 수도 있습니다. shodan.io 외부 서비스를 확인하여 모든 항목이 꺼져 있는지 확인하십시오.

오리. 우리는 이제 Microsoft의 자체 응답에서 그들이 패치를 출시하기 위해 미친 듯이 몸을 떨고 있다는 것을 알고 있습니다.

그 패치가 나타나면 꽤 빨리 적용하는 것이 낫지 않습니까?

어떤 패치가 익스플로잇을 파악하기 위해 리버스 엔지니어링의 대상이 된다면 이런 종류의 것이 될 것이기 때문입니다.

쳇. 예, 절대적으로, 오리!

패치를 해도 시간의 창이 생기겠죠?

내 말은, 일반적으로 Microsoft는 화요일 패치를 위해 태평양 표준시로 오전 10.00시에 패치를 릴리스합니다.

지금 우리는 일광 절약 시간에 있으므로 UTC-7입니다... 따라서 일반적으로 UTC 17:00 경은 Microsoft에서 패치를 릴리스하므로 대부분의 직원이 하루 종일 시애틀에서 들어오는 쿼리에 응답할 수 있습니다. [Microsoft 본사는 워싱턴주 시애틀 벨뷰에 있습니다.]

여기서 핵심은 이것이 발생하기 전에 이것이 얼마나 쉽게 악용되는지에 따라 몇 시간 또는 몇 분의 일종의 "경주"가 있다는 것입니다.

그리고 다시 ProxyShell 및 ProxyLogon을 사용한 이전 Exchange 익스플로잇으로 돌아가서 XNUMX, XNUMX, XNUMX일 이내에 패치를 적용한 고객조차도…

...솔직히 Exchange 서버의 경우 다소 빠르며 패치하기가 매우 어렵습니다. 이메일 서버를 중단하기 전에 신뢰할 수 있는지 확인하기 위해 많은 테스트가 필요합니다.

그 서버가 얻을 수 있는 충분한 시간이었습니다. 웹쉘, 암호 해독기, 모든 종류의 백도어 그들에 설치.

그래서 공식 패치가 나왔을 때 빨리 대처해야 할 뿐만 아니라…

…*조치를 취한 후*, 패치를 사용할 수 있게 된 시점과 적용할 수 있었던 시점 사이에 시스템이 공격을 받았다는 증거를 찾기 위해 해당 시스템을 철저히 검사하는 것이 좋습니다.

Naked Security에 대한 많은 대화가 있을 것이라고 확신합니다. 트위터 및 기타 장소에서 우리가 보고 있는 공격 유형에 대해 이야기하여 무엇을 찾아야 하는지 알 수 있습니다.

오리. 제한된 수의 공격으로 이미 배포된 알려진 맬웨어의 해시를 찾아볼 수는 있지만…

...사실, 결론은 모든 종류의 맬웨어가 가능성이 있다는 것입니다.

그리고 제 생각에 당신이 말한 것처럼 마지막 미니 에피소드 우리가 한 것처럼, 대시보드에 갑자기 발생한 나쁜 일에 대한 경고를 기다리는 것만으로는 더 이상 충분하지 않습니다.

사기꾼이 이미 당신의 네트워크에 있고 당신이 아직 눈치채지 못한 무언가(오랜 세월 동안 거기에 있었을 수도 있습니다!)를 남겼을 경우를 대비하여 사전에 나가서 살펴봐야 합니다.

쳇. 그래서 저는 그것이 우리를 다음으로 인도한다고 생각합니다. "패치를 기다리는 동안 우리는 지금 무엇을합니까?"

MSRC(Microsoft Security Research Center) 블로그 출시 일부 완화 조언 그리고 세부 사항... Microsoft가 현재 공개할 수 있는 만큼.

당신이 순수하다면 나는 말할 것입니다. 마이크로소프트 익스체인지 온라인 고객, 당신은 거의 명확하고 상황이 변경되는 경우에만주의를 기울여야합니다.

그러나 하이브리드 상황에 있거나 여전히 Microsoft Exchange를 온프레미스에서 실행하고 있다면 오늘 오후나 내일 아침에 할만한 가치가 있는 작업이 있을 것입니다.

물론 녹음 당시는 금요일 오후... 그래서, 정말, 이 말을 듣게 되면 “아직 안 했으면 듣자마자 바로.”

여기에서 모범 사례는 무엇입니까, 덕?

분명히 할 수 있는 한 가지는 패치를 사용할 수 있을 때까지 외부 웹 액세스를 끄는 것입니다.

IIS 서버를 종료하면 끝입니다!

오리. 나는 많은 회사가 그 위치에 있지 않을 것이라고 생각합니다.

그리고 Microsoft는 그들이 말하는 두 가지를 나열합니다. 글쎄, 그들은 말하지 않습니다. "이것은 확실히 효과가 있을 것입니다."

그들은 그것이 당신의 위험을 크게 제한할 것이라고 제안합니다.

하나는 IIS 서버에 적용할 수 있는 URL 재작성 규칙이 있다는 것입니다. (내 이해는 Exchange 웹 서비스[EWS]에 대한 액세스로 바뀌는 들어오는 연결을 수락하는 것이 IIS라는 것입니다.)

따라서 첫 번째 구멍의 악용 가능성을 찾는 IIS 설정이 있습니다. 그러면 PowerShell 트리거가 시작되지 않습니다.

그리고 Exchange Server에서 차단할 수 있는 몇 가지 TCP 포트가 있습니다.

나는 그것이 포트 5985 및 5986이라고 믿습니다. PowerShell Remoting... Exchange 서버에 삽입되는 이러한 불량 PowerShell 원격 실행 명령을 중지합니다.

그러나 Microsoft는 이것이 모든 것을 해결한다는 것을 약속하기보다는 이것이 귀하의 노출을 "제한"할 것이라고 말합니다.

그리고 그것은 그들이 이것이 촉발될 수 있는 다른 방법이 있다고 의심하기 때문일 수 있지만, 그들은 아직 그들이 무엇인지 정확히 파악하지 못했습니다. [웃음]

두 설정 모두 Exchange 자체에서 수행하는 작업이 아닙니다.

그 중 하나는 IIS에 있고 다른 하나는 일종의 네트워크 필터링 규칙입니다.

쳇. Microsoft가 영구적인 수정 사항을 제공하는 동안 앞으로 며칠을 버틸 수 있도록 하는 데 도움이 됩니다.

좋은 소식은 방화벽에 통합될 수 있는 IPS이든 Microsoft Windows Server 인프라를 보호하는 엔드포인트 보안 제품이든 간에 많은 보안 소프트웨어가 있다고 생각합니다.

...이에 대한 공격은 많은 경우(최소한 초기 보고서)에서 ProxyLogon과 매우 유사해 보이며 결과적으로 기존 규칙이 이러한 공격으로부터 보호할 수 있는지 여부가 불분명합니다.

그들은 그럴 수 있지만 그 외에도 대부분의 공급업체는 현재 공개적으로 공유된 모든 지표를 기반으로 가능한 한 준비가 되었는지 확인하기 위해 약간 강화하려고 하는 것으로 보입니다. Exchange 서버에서 이러한 일이 발생하면 경고를 보냅니다.

오리. 맞습니다, 체스터.

Sophos 고객에게 좋은 소식은 로그를 살펴보고 싶은 경우 Sophos 관련 탐지를 추적할 수 있다는 것입니다.

방화벽의 IPS든 엔드포인트든 IPS뿐만 아니라 우리는 많은 행동 규칙도 가지고 있습니다.

검색하려면 해당 탐지 이름을 추적할 수 있습니다. @SophosXops 트위터 피드.

위협 사냥에 사용할 수 있는 새로운 탐지 이름을 얻으면 쉽게 찾을 수 있도록 여기에 게시하고 있습니다.

Sophos X-Ops는 다음 탐지 기능을 추가했습니다.

Troj/WebShel-EC 및 Troj/WebShel-ED는 공격에서 논의된 웹쉘을 탐지합니다.

IPS 서명 sid:2307757은 Microsoft에서 Sophos XG 방화벽과 Sophos Endpoint IPS에 대해 게시한 정보를 기반으로 합니다.

— Sophos X-Ops(@SophosXOps) 2022 년 9 월 30 일