이집트에서 상업 감시 업체가 악용한 0-day 취약점

 (blog.google)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Google TAG와 The Citizen Lab은 iPhone 대상 0-day 익스플로잇 체인을 실제 공격에서 발견했으며, Intellexa가 이를 이용해 Predator 스파이웨어를 몰래 설치함
  • Apple은 iOS 16.7과 iOS 17.0.1에서 CVE-2023-41991·41992·41993을 패치했으며, Google은 iOS 사용자에게 즉시 업데이트를 권장함
  • 공격은 대상이 HTTP 사이트에 접속할 때 MITM 주입으로 트래픽을 가로채 c.betly[.]me와 sec-flare[.]com으로 리다이렉트하는 방식이라, 별도 클릭이나 전화 응답이 필요 없었음
  • iOS 체인은 Safari 원격 코드 실행, 인증서 검증 문제, XNU Kernel 로컬 권한 상승으로 이어졌고, 이후 작은 바이너리가 Predator 전체 임플란트 설치 여부를 결정함
  • Android 대상 공격도 이집트에서 관찰됐으며, Chrome의 CVE-2023-4762를 이용한 초기 렌더러 원격 코드 실행 취약점은 9월 5일 패치됨

Intellexa의 Predator 설치용 익스플로잇 체인

  • Google Threat Analysis Group(TAG)은 The Citizen Lab과 함께 실제 공격에 쓰이던 iPhone용 0-day 익스플로잇 체인을 발견함
  • 상업 감시 업체 Intellexa가 개발한 이 체인은 기기에 Predator 스파이웨어를 은밀히 설치하는 데 사용됨
  • Apple은 iOS 16.7과 iOS 17.0.1에서 다음 취약점을 패치함
    • CVE-2023-41991
    • CVE-2023-41992
    • CVE-2023-41993
  • 빠른 패치로 사용자 보호가 강화됐으며, 모든 iOS 사용자는 가능한 한 빨리 설치하는 것이 권장됨

MITM을 통한 전달 방식

  • Intellexa 익스플로잇 체인은 man-in-the-middle(MITM) 공격으로 전달됨
  • MITM 공격에서는 공격자가 대상과 대상이 접속하려는 웹사이트 사이에 끼어들어 트래픽을 가로챔
  • 대상이 http 사이트에 접속하면 공격자는 가짜 데이터를 돌려보내 다른 웹사이트로 이동시킬 수 있음
  • https 사이트는 트래픽이 암호화되고 인증서로 수신 데이터가 의도한 웹사이트에서 왔는지 검증할 수 있음
  • 이번 캠페인에서는 대상이 어떤 http 사이트에 접속하더라도 트래픽 주입으로 c.betly[.]me Intellexa 사이트로 조용히 리다이렉트됨
    • 사용자가 예상된 표적이면 다시 sec-flare[.]com 익스플로잇 서버로 이동함
    • 문서 열기, 특정 링크 클릭, 전화 응답 같은 사용자 행동이 필요 없었음

iOS 익스플로잇 체인 구성

  • 대상이 익스플로잇 서버로 리다이렉트되면 iOS 익스플로잇 체인이 실행됨
  • 체인은 세 가지 취약점으로 구성됨
    • CVE-2023-41993: Safari의 초기 원격 코드 실행(RCE)
    • CVE-2023-41991: 인증서 검증 문제
    • CVE-2023-41992: XNU Kernel의 로컬 권한 상승(LPE)
  • 이후 작은 바이너리가 실행되어 Predator 전체 임플란트를 설치할지 결정함
  • TAG는 전체 Predator 임플란트를 확보하지 못함
  • Google은 Google vulnerability disclosure policy에 맞춰 이 익스플로잇의 기술 심층 분석을 공개할 계획임

Android 대상 공격과 Chrome 취약점

  • 공격자는 이집트의 Android 기기에 Predator를 설치하기 위한 익스플로잇 체인도 보유하고 있었음
  • TAG는 Android 익스플로잇이 전달된 두 가지 방식을 관찰함
    • MITM 주입
    • 표적에게 직접 보낸 일회용 링크
  • TAG가 확보한 것은 Chrome의 초기 렌더러 원격 코드 실행 취약점뿐이며, 이 취약점은 CVE-2023-4762를 악용함
  • 해당 버그는 별도 보안 연구자가 Chrome Vulnerability Rewards Program에 이미 보고했으며, 9월 5일 패치됨
  • Google은 Intellexa가 이 취약점을 이전에 0-day로 사용했다고 평가함

Chrome의 MITM 방어와 Google의 대응

  • Chrome은 수년간 웹 전반의 HTTPS 보편화를 추진해옴
  • Chrome의 “HTTPS-First Mode”는 MITM 네트워크 주입을 통한 익스플로잇 전달 가능성을 줄일 수 있음
    • 모든 페이지를 HTTPS로 먼저 로드하려고 시도함
    • HTTP 요청으로 되돌아가기 전에 큰 경고를 표시함
  • 이 설정은 Advanced Protection Program에 등록되어 있고 Chrome에 로그인한 사용자에게 기본 활성화되어 있음
  • Google은 모든 사용자에게 MITM 공격 방어를 위해 “HTTPS-First Mode” 활성화를 권장함
  • 이번 캠페인은 상업 감시 업체 확산이 온라인 사용자 안전에 심각한 위험을 만들 수 있음을 보여줌
  • TAG는 상업 스파이웨어 산업에 대한 조치와 연구 공개를 계속하고, 공공·민간 부문과 협력해 관련 대응을 이어갈 예정임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 추가 정보가 나온 건 좋지만, Chrome 패치만 언급하는 점이 좀 불안함. Android에서 샌드박스 탈출은 무엇이었는지 궁금함
    Android의 Chrome 프로세스 안에서 코드 실행이 가능해졌더라도 지속성 확보까지 가능하면 안 되므로, 분명 다른 취약점이 더 있음
    이번 공격 벡터는 표적 캠페인에서 HTTP 중간자 공격과 일회성 링크였지만, 누군가 이를 광고 캠페인이나 SMS/Discord/Matrix 같은 스팸에 넣어 대량 살포해 봇넷을 만들거나 사용자 자격 증명을 훔치는 걸 막을 이유도 없어 보임

    • 이게 정말 핵심임. 블로그 글에 그 정보가 빠져 있어서 행간을 읽어야 하는데, Android 쪽에 현재 미패치 이슈가 있는 것처럼 들림
    • 후속 Android 체인의 단계를 캡처하지 못했고, 초기 실행 구성요소만 확보했다고 되어 있음
      즉 샌드박스 탈출과 권한 상승 버그가 빠져 있다는 뜻임
      또한 여기서는 합법 감청 기능을 이용한 ISP 수준 중간자 공격으로 전달된 듯하지만, 피싱 링크를 통한 원클릭 방식으로도 이 익스플로잇을 전달하지 못할 이유는 없음
    • 제조사가 버린 Android 기기가 수백만 대라서, 아직 패치되지 않았고 아마 영원히 패치되지 않을 결함이라 일부 세부 정보를 빼고 있을 수도 있음
    • 글의 중심은 iPhone 익스플로잇 체인임: Safari 익스플로잇 → PAC 우회 → 커널 익스플로잇
      Android 버전도 꽤 비슷했지만, Linux 커널 완화 기법을 우회하려면 익스플로잇이 두 개 더 필요했던 것 같음
      PZ에 좋은 기술 분석 글이 있음
    • 모바일 환경을 잘 알지는 못하지만, Chrome 샌드박스를 벗어나면 기본 운영체제 안으로 들어가는 것 아닌가 싶음. 거기서 추가 취약점을 악용하지 않고는 지속성을 만들 수 없는 건가?

  • HTTPS가 없는 것보다는 낫고, 이 공격은 초기 페이로드 주입에 HTTP를 이용하지만, 일부 국가의 국가 지원 공격자는 CA나 CDN 인프라를 그냥 우회·장악할 수도 있을 것 같음

    • 그런 식으로 인증서를 위조하면 모든 브라우저가 알아차리고 해당 CA를 제거할 가능성이 커서, 보호 장치가 있음
    • 아니면 우리 모두가 사랑하는 LetsEncrypt가 인증한 스푸핑 도메인을 클릭하게 만들 수도 있음
      필요한 건 클라이언트를 c.betly[.]me로 보내는 HTTP 302/307 리다이렉트 응답뿐인 듯함. HTML 리다이렉트 페이로드나 어쩌면 DNS도 가능할 수 있음
    • 기기를 장악하는 데는 HTTP 사이트 아무 곳이나 한 번 방문하는 것만으로 충분했거나 충분하다는 점이 중요함

  • Predator 스파이웨어를 다룬 Darknet Diaries의 최근 관련 에피소드가 있음: https://darknetdiaries.com/episode/137/

  • 이런 0-day가 가르쳐 주는 건, 강력한 적대자의 표적이 된 사람이라면 극도로 편집증적으로 행동하고 공격 표면을 최대한 줄여야 한다는 점임
    James Bond가 M과 안전하게 통신하려면, 그 기능 하나만 하는 맞춤형 장비형 모바일 기기를 쓰는 편이 나음. 익명 제3자 선불 기기로 무작위 게시판에 미리 합의한 순환식 지리 잠금 코드북 순서로 암호화된 메시지를 남겨야 함. 그보다 운영 보안이 조금이라도 약하면 끝장임
    평범한 사람이 연결된 디지털 기기를 평범하게 쓴다면, 그 기기에 넣은 건 이미 도난당했다고 가정해야 함. 정말 사적으로 유지하고 싶다면 디지털에 올리지 말고 종이나 구식 아날로그 테이프 같은 곳에 둬야 함. 그러면 적어도 물리적으로 훔쳐야 하는데, 상황에 따라 훨씬 어려울 수는 있지만 반드시 더 안전하다는 뜻은 아님. 결국 어느 쪽이든 잃게 됨
    유일한 실제 탈출구는 투명성과 견제·균형이 강하게 작동하는 민주 정부, 강력하게 집행되는 개인정보 보호법, 그리고 Citizen Lab 같은 활동에 대한 강한 지원을 갖추는 것임

  • 이 취약점은 현 대통령 Abdel Fatah El Sisi와 대선에서 경쟁하는 Ahmed El Tantawy 후보의 휴대폰을 해킹하는 데 이집트 당국이 사용했을 가능성이 큼
    https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...

  • 글에는 나오지 않지만 iOS의 Lockdown Mode가 이 익스플로잇 체인을 막았음

  • 이해가 안 되는 점이 있음: 스파이웨어 업체와 0-day 판매 업체 모두 0-day를 찾는 전담 인력을 두고 있음. 왜 Google과 Apple은 그냥 이 인력들을 스카우트하지 않는 걸까?
    Google과 Apple이라면 매우 경쟁력 있는 급여를 제시할 수 있을 텐데, 왜 그렇게 하지 않는지 궁금함. 숙련된 0-day 사냥꾼을 사실상 전부 빼오는 비용이 그냥 패치를 내는 비용보다 크다고 판단해서일까?

    • 바로 그런 일을 하는 사람임. 0-day 연구자로 일하고 있음
      직원 관점에서는 임금은 비슷함. Big Tech의 일은 덜 흥미롭다. 많은 버그를 찾는 대형 버그 탐지 기계를 만들고, 찾은 버그를 버그 추적기에 올려 두면 3개월 뒤에나 고쳐질 수도 있음. 공격 보안 쪽 일은 더 흥미롭다. 얕은 취약점은 Big Tech가 찾으므로, 필요한 건 몇 개뿐이고 연구 대상 시스템을 깊이 알아야 함. 취약점에서 코드 실행까지 이어가는 지식도 필요함. 익스플로잇 작성은 쉬운 일이 아님. 내가 비도덕적이라고 보는 회사에서 왜 엔지니어들이 일하는지는 설명하기 어렵지만, 아마 그들은 나와 같은 방식으로 느끼지 않기 때문일 것임
      고용주 관점에서는 “연간 X개의 취약점을 찾는 비율에 얼마를 쓸 것인가”의 문제임. 코드에 버그가 있어도 시장에서 가장 안전한 코드로 여겨진다면, 보안 예산을 늘리는 게 회사에 이익이 아닐 수 있음. 보안 예산을 늘리면 어느 부서 예산을 줄일지, 회사 건강성에 대한 순효과가 무엇인지 따져야 함
      취약점을 고치고 싶다면, 취약점을 찾고 익스플로잇하는 가격을 구매자들이 감당할 수 없을 만큼 높여야 함. 그리고 공격 보안의 발전이 발견·익스플로잇 비용을 낮추는 만큼 계속 그 가격을 더 높게 유지해야 함. 방어 기업은 주로 버그 예방으로 돈을 벌지 않고, 공격 기업은 주로 버그를 찾아 돈을 벌기 때문에 불일치가 생김. 회사든 어떤 조직이든 궁극적인 취약점은 유한한 자원임
    • Google에는 돈과 명성으로 살 수 있는 최고 수준의 팀 중 하나가 있음: https://en.m.wikipedia.org/wiki/Project_Zero
      전 세계 독립 연구자들과의 협업도 훌륭함. 하지만 매일 작성되는 소프트웨어의 양을 생각하면 여전히 일부 이슈를 놓칠 수 있음
    • 이건 미국 정부 예산을 보고 “왜 잠재적 범죄자들을 모두 매수해서 미국 범죄 대부분을 줄이지 않느냐”고 묻는 것과 비슷해 보임
    • 그중 일부는 급여와 상관없이 애초에 Google이나 Apple에서 일하고 싶어 하지 않을 것임
      오늘 그들을 스카우트하더라도 내일은 그런 회사들에서 일하는 새로운 사람들이 잔뜩 생길 테니, 끝없는 순환이 될 것임
    • 좋은 생각이지만, 어느 면에서는 “왜 세계에서 가장 부유한 나라가 세계 최고의 군 장성들을 모두 고용해서 다른 나라에 한 명도 남기지 않느냐”는 질문과 비슷한 난제임
      불가능한 이유는 많지만, 결국 세계와 인류가 너무 크고 복잡해서 한 주체가 전부, 아니 대부분조차 가질 수 없다는 데로 귀결됨. 모든 것에 너무 다양한 이질성이 내장되어 있음. 돈을 넘어서는 세계관과 충성심도 많음

  • Firefox에도 Https First가 있지만 dom.security.https_first 설정을 켜야 하는 듯함
    가능하다면 “HTTPS-Only Mode”가 확실히 가장 좋음

    • 그래도 “어쨌든 허용”을 누르고 싶은 충동을 이겨야 함. 솔직히 위험을 알아도 나조차 누를 것 같음. 그냥 그 사이트를 방문하고 싶으니까
      프롬프트가 극도로 수상해 보이지 않는 한, 예를 들어 HTTPS를 지원하는 걸 아는 Google.com 같은 사이트에서 뜨는 경우가 아니라면, 이건 아무것도 해결하지 못함

  • 이 글에서 링크한 Citizen Lab 게시물에 중간자 공격 세부 정보가 있음. 거의 공격이라고 부르기도 애매할 정도로, 네트워크가 필요할 때 콘텐츠 주입을 하도록 설계되어 있음

답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.