iLeakage: 애플 기기에 대한 브라우저 기반 타이머리스 추측 실행 공격

 (ileakage.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Spectre 완화가 약 6년간 이어졌지만, iLeakage는 Mac·iPad·iPhone의 Safari에서 추측 실행 사이드채널이 여전히 악용될 수 있음을 보여줌
  • 공격자는 사용자가 악성 웹페이지를 방문해 클릭하도록 유도한 뒤, JavaScript와 WebAssembly로 Safari가 임의 웹페이지를 렌더링하게 만들어 민감 정보를 복구할 수 있음
  • 시연에는 Gmail 최근 메시지 제목, Instagram 자동완성 자격 증명, YouTube 시청 기록, Apple M3 기반 MacBook Pro의 Facebook 비밀번호와 SMS 2FA 토큰 복구가 포함됨
  • 영향 범위는 Apple A-series·M-series CPU를 쓰는 macOS·iOS 기기이며, Safari 17.2가 포함된 iOS 17.2와 macOS 14.2에서 완화됨
  • Lockdown Mode나 JavaScript 비활성화로도 막을 수 있지만 기능 제약이 있고, Safari 안에서 실행되며 시스템 로그에 흔적을 남기지 않아 탐지가 매우 어려움

Apple 기기에서 다시 드러난 Spectre 위험

  • iLeakage는 Safari 웹브라우저를 대상으로 하는 추측 실행 사이드채널 공격임
  • 대상은 Apple의 A-series 또는 M-series CPU를 사용하는 macOS·iOS 기기임
    • 최근 iPhone과 iPad가 포함됨
    • 2020년 이후 Apple 노트북과 데스크톱도 포함됨
  • 원래 한 브라우저 탭의 코드는 다른 탭의 내용을 추론하지 못해야 하지만, iLeakage는 공격자 페이지를 방문하고 클릭한 사용자의 대상 웹페이지 내용을 읽을 수 있음
  • 복구 가능한 정보에는 개인 정보, 비밀번호, 신용카드 정보가 포함될 수 있음
  • 연구진은 2022년 9월 12일 Apple에 결과를 공개했으며, 이는 공개 릴리스 408일 전이었음

실제로 복구된 민감 데이터

  • 연구진은 대중적인 서비스에서 고가치 정보를 복구하는 사례를 시연함

  • Instagram 자격 증명

    • macOS Safari에서 사용자가 LastPass 자동완성 자격 증명 관리자로 Instagram에 로그인하는 상황을 사용함

  • Gmail 받은편지함

    • iOS Safari에서 사용자가 Google에 로그인된 상태라고 가정하고, iPad에서 Gmail 계정의 최근 메시지 제목을 복구함

  • YouTube 시청 기록

    • iOS용 Chrome에서 YouTube 시청 기록을 복구함
    • iOS용 Chrome은 Apple App Store 정책 때문에 Safari 브라우징 엔진 위의 셸로 동작함

  • Facebook 비밀번호와 2FA 토큰

    • Apple M3 칩이 탑재된 MacBook Pro, macOS 14.1.1, Safari 17.1 환경에서 Facebook 비밀번호를 먼저 복구함
    • 이후 Android 휴대전화로 전송된 SMS 2FA 토큰을 Google Messages를 통해 복구함

Spectre와 사이드채널의 동작 방식

  • 대부분의 현대 CPU는 분기 결과가 즉시 나오지 않을 때 실행 경로를 예측하고, 해당 경로의 명령을 먼저 처리하는 추측 실행을 사용함
  • 예측이 틀리면 CPU는 상태 변경을 되돌리지만, 캐시 같은 마이크로아키텍처 상태에는 흔적이 남을 수 있음
  • Spectre는 이 흔적을 이용해 원래 프로그램 의미상 접근할 수 없는 데이터를 읽는 하드웨어 취약점임
  • 사이드채널은 프로그램이 안전한 알고리듬을 실행하더라도 시스템 구현 특성을 악용할 수 있음
    • 예시로 소리, 전자기 방사, 열 스로틀링, CPU 마이크로아키텍처 자원 공유가 있음
  • 공격자와 대상이 같은 CPU에서 실행되면 코어, 캐시, 내부 버퍼 같은 자원을 공유하며, 이 경합은 타이밍이나 전력 소비 같은 변수로 간접 측정될 수 있음

Safari 방어를 우회한 타이머리스 공격 구성

  • 브라우저 벤더들은 Spectre 이후 추측 실행·일시적 실행 공격에 대한 방어를 강화해 왔음
  • Safari 방어에는 35-bit addressing, value poisoning, 탭당 프로세스 격리 정책, 저해상도 타이머가 포함됨
  • iLeakage는 Apple Silicon CPU와 Safari를 상대로 한 첫 추측 실행 공격 시연임
  • 공격은 Apple CPU의 공개되지 않은 캐시 구성을 실증적으로 복구하는 데서 시작함
    • 이후 낮은 해상도 타이머만으로 캐시 히트와 미스를 구분하는 speculation 기반 가젯을 만듦
    • 타이머 없이 race condition을 활용하는 변형도 시연함
  • 이 가젯은 eviction set 생성 테스트와 covert channel 양쪽에 사용됨
  • Safari로 기법을 옮긴 뒤에는 CPU가 추측 실행 중일 때 Safari가 특정 데이터 타입용 코드를 공격자가 만든 잘못된 타입 객체에 실행하게 만듦
  • 최종적으로 Safari 렌더링 프로세스 주소 공간 어디서든 out-of-bounds read가 가능해짐
  • 서로 다른 도메인의 웹사이트를 같은 주소 공간으로 통합하는 새 방법과 결합해, 민감 정보를 유출하는 speculative type confusion 공격을 수행함

완화책, 탐지 난이도, 브라우저별 영향

  • iLeakage는 Safari 17.2에서 완화됐으며, Safari 17.2는 iOS 17.2와 macOS 14.2에 포함됨
    • 대응책은 Apple 기기를 최신 OS 버전으로 업데이트하는 것임
  • Lockdown Mode는 Safari의 JIT 컴파일을 비활성화해 iLeakage를 완화함
    • JIT 컴파일은 iLeakage가 공격 프리미티브를 만드는 데 사용하는 성능 기능임
    • Lockdown Mode는 일부 메시지 첨부파일과 알 수 없는 FaceTime 통화를 차단하는 등 기기 동작을 바꿀 수 있음
    • 전체 목록은 Apple의 Lockdown Mode 문서에 있음
  • JavaScript 비활성화도 iLeakage를 막지만, Safari가 일부 웹사이트를 잘못 또는 불완전하게 렌더링할 수 있고 온라인 결제 같은 고급 웹 기능이 동작하지 않을 수 있음
  • iLeakage는 Safari 안에서 실행되고 시스템 로그 파일에 흔적을 남기지 않아 탐지가 매우 어려움
    • 다만 공격자 웹페이지를 방문한 흔적은 최근 방문 페이지에 대한 브라우저 캐시에 남을 수 있음
  • 실제 악용 증거는 없음
    • 종단 간 공격 구성은 매우 어렵고, 브라우저 기반 사이드채널 공격과 Safari 구현에 대한 고급 지식이 필요함
  • 자격 증명 관리자는 계속 사용하는 편이 권장됨
    • iLeakage는 웹페이지에 자동완성된 자격 증명을 복구할 수 있음
    • 많은 플랫폼은 자동완성이 일어나기 위해 사용자 상호작용을 요구함
  • macOS의 Chrome, Firefox, Microsoft Edge는 다른 JavaScript 엔진을 사용하므로 Safari JavaScript 엔진의 특수성을 악용하는 iLeakage가 동작하지 않음
  • iOS에서는 Apple App Store와 샌드박싱 정책 때문에 다른 브라우저 앱도 Safari JavaScript 엔진을 사용함
    • iOS용 Chrome, Firefox, Edge는 북마크와 설정 동기화 같은 보조 기능을 제공하는 Safari 위 래퍼임
    • App Store의 거의 모든 브라우저 애플리케이션이 iLeakage에 취약함
  • 학술 논문은 iLeakage paper로 제공되며, 2023 ACM Conference on Computer and Communications Security에 게재됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 FAQ에서 빠진 게 있어 보임: 이게 WebKit 취약점인지 Safari 취약점인지, 모바일 Safari에는 해당 개발자 설정이 없는데 Lockdown Mode를 켜면 완화되는지, Apple에 언제 공개했는지 궁금함
    이후 페이지가 업데이트되어 마지막 질문에는 답이 생겼고, 연구진은 2022년 9월 12일 Apple에 결과를 공개했으며 공개 릴리스 408일 전이었다고 함

    • 기술적으로는 Hacker News Favorite Processor, 즉 M1/M2 취약점이라고 볼 수 있지만, 현재 시장의 관련 CPU들이 모두 같은 취약성을 가져서 소프트웨어가 이를 완화하도록 설계해야 하는 기능처럼 되어버렸음
      WebKit에서 가능한 모든 Spectre 가젯을 제거하는 건 비현실적이므로, 브라우저는 서로 다른 웹사이트를 서로 다른 프로세스에 격리하는 식으로 운영체제의 Spectre 완화책을 활용해야 함
      FAQ에 “결국 Safari 렌더링 프로세스의 주소 공간 어디서든 범위 밖 읽기를 달성한다”고 되어 있으니, 개인적으로는 Safari의 사이트 격리를 잘못 구현한 취약점으로 봄
    • 마지막 질문은 FAQ에 답이 있음: 연구진은 2022년 9월 12일 Apple에 결과를 공개했고, 공개 릴리스 408일 전이었다고 함
    • 이건 Safari나 다른 브라우저 안에서 Spectre와 유사한 추측 실행 부채널을 활용할 수 있는 아키텍처 취약점처럼 보임
      어떤 환경에서 악용 가능한지는 이 부채널을 유발하고 측정하는 JavaScript 기반 가젯의 세부 구현에 달려 있으며, 아직 읽지 않은 논문에 들어 있을 수 있음
    • 이제 FAQ에 답이 올라옴: 이건 Safari 취약점이고, “iLeakage는 Safari의 JavaScript 엔진 특성을 악용한다”고 되어 있음
      Lockdown Mode는 Safari에서 JIT 컴파일을 비활성화하므로 완화가 되며, iLeakage가 공격 프리미티브를 만드는 데 쓰는 성능 기능을 막는다고 함

  • “자격 증명 관리자를 쓰면 위험한가?”에 대해 대부분은 아니라고 답하지만, 메모리에서 뭔가 새어 나오는 거라면 Safari 프로세스 공간 안의 모든 메모리에 영향을 줘야 하는 것 아닌가 싶음
    이 분야에 익숙하지 않아서 왜 자격 증명 관리자 사용 여부가 예외 조건이 되는지 이해가 잘 안 됨

    • 기본적으로는 이렇게 말하는 듯함: 이 특정 공격에 추가 보안을 주지는 않지만 비밀번호 관리자를 쓰는 편이 일반적으로 더 안전하고, 이 공격에 더 취약해지는 것도 아님
      사람들이 “newpassword2” 같은 방식으로 돌아가게 만드는 걸 피하려는 것 같고, 자동 입력을 끄고 단축키나 다른 사용자 상호작용으로 채우면 더 안전함
    • 데모 중 하나는 비밀번호 관리자가 필드를 자동 입력해서 메모리에 올라간 덕분에, Instagram 같은 제3자 사이트의 아이디/비밀번호 조합을 복구하는 내용이었음
      비밀번호 관리자를 쓰지 않고 브라우저에도 저장하지 않으며 매번 직접 입력하면 면역이라는 식으로 읽을 수도 있지만, 그건 여러 이유로 좋지 않은 반론임
      비밀번호 관리자는 다른 많은 이유로 유익하고, 비밀번호가 탈취돼도 최소한 한 웹사이트만 손상됨
      이 기법은 아마 세션 토큰도 훔칠 수 있는데, 비밀번호 탈취만큼은 아니어도 여전히 나쁨
      비밀번호 관리자를 클릭해야 채우도록 설정하면 이 공격도 막을 수 있음
    • 비밀번호 관리자를 쓴다고 더 취약해지는 건 아니라는 뜻으로 보임
      페이지에 자동 입력된 비밀번호는 직접 입력한 비밀번호처럼 복구할 수 있지만, 비밀번호 관리자 안에 저장된 모든 비밀번호를 직접 읽어낼 수는 없다는 의미임
    • 이 취약점은 관련된 Safari/WebKit 프로세스의 메모리, 구체적으로 window.open 호출로 열린 사이트들에만 접근을 허용하는 것으로 이해함
      별도 비밀번호 관리자 앱에 저장된 비밀번호는 그 앱이 손상된 Safari 창이나 프로세스에 자동 입력하지 않는 한 접근 불가능함
    • Safari는 일반적으로 서로 다른 출처와 확장을 서로 다른 주소 공간에 두므로 추측 실행 공격에 취약하지 않다고 이해함
      이번 공격은 서로 다른 두 출처가 같은 주소 공간을 공유하게 만드는 방법을 찾은 것이고, 확장에는 적용되지 않는다고 봄
      논문에는 “Safari의 사이트 격리 정책을 악용해, 공격자 페이지가 JavaScript window.open API로 임의의 피해자 페이지를 열기만 해도 주소 공간을 공유하게 하는 새 기법을 보인다”고 되어 있음

  • WebKit 전용이라는 프레이밍이 정말 맞는지 헷갈림. 캐시 악용 자체는 일반적인 것으로 보이고, 인용문에도 Safari, Firefox, Tor 전반에서 거의 완벽한 정확도를 보였다고 되어 있음
    또한 window.open()을 통한 공격이 정말 WebKit 전용인지, 아니면 이번 연구에서 WebKit만 깊게 본 것인지 궁금함
    window.open()은 호출한 창이 새 창 참조를 받고, 새 창은 window.opener로 역참조를 갖는 공유 맥락을 암시하는데, 다른 브라우저 엔진들은 완전한 격리를 달성하는지도 의문임

    • Chromium과 Firefox는 데스크톱 브라우저에 사이트 격리를 구현해서, 같은 사이트가 아닌 페이지는 같은 프로세스에 로드되지 않아야 함
      모바일 브라우저에서는 Chromium의 사이트 격리가 제한적이고, Firefox는 아직 구현을 끝내지 못했음
      https://www.chromium.org/Home/chromium-security/site-isolati...

  • 혼란스러움. 이건 심각도 높은 이슈처럼 보이는데 수정이 디버그 메뉴 뒤에 있음. 왜 제대로 모든 곳에 배포되기 전에 공개됐는지 모르겠음
    또한 부채널 완화책이 사실상 쓸모없고 이런 공격이 고쳐졌다고 가장하면 안 된다는 점도 보여줌
    현대 CPU에서 여러 애플리케이션을 돌리는 호스트라면, 아무리 샌드박스해도 신뢰할 수 없는 코드를 실행하는 건 안전하지 않음

    • Apple은 이걸 고칠 시간이 400일 넘게 있었던 듯하고, 내가 줬을 시간보다도 이미 길었음
      Apple 사용자들이 위험을 모른 채 또 1년 넘게 방치되는 것보다, 위험을 알려주는 편이 훨씬 낫다고 봄
      기업에 버그를 고칠 시간을 주는 데는 찬성하지만, 어느 시점부터는 영향을 받는 사람들에게 알리지 않는 쪽이 더 무책임해짐
    • 완화 상태는 나도 헷갈리지만, 웹사이트보다 논문이 더 명확함
      논문은 추측 JavaScript 샌드박스 탈출은 여전히 가능하지만 공격자가 자기 주소 공간과 자기 데이터 읽기로 제한된다고 설명함
      작성 시점에 Apple 패치가 공개되어 있고 Safari Technology Preview 173 이상에 구현되어 있다고 하며, [57]은 https://github.com/WebKit/WebKit/pull/10169임
      그 아래에서 엔지니어가 window.open()과 프로세스 격리에 대한 추가 강화 패치를 계속 링크하고 있음
    • 표준 Safari 17.0 on Ventura에서는 Swap Processes on Cross-Site Window Open이 이미 켜져 있고 Stable로 표시된 줄 알았음
      내가 직접 켠 건 아니어서 Apple이 이미 활성화했고 설명이 오래된 것일 수도 있다고 생각했지만, 나중에 보니 비슷한 이름의 Swap Processes on Cross-Site Navigation을 보고 있었고 현재 기본 활성화는 아닌 듯함
    • “프라이버시와 보안의 마지막 보루”라는 Apple이 이걸 400일 이상 붙잡고도 고치지 않았기 때문임
      수정 배포 전에 공개한 연구진보다, 이렇게 오래 손 놓고 있던 Apple을 탓해야 함
    • 이 수정은 WebKit의 프로세스 모델을 바꿔야 했기 때문에 전체 배포 전에 아직 테스트 중이라 디버그 메뉴 뒤에 있을 가능성이 큼
      모든 부채널 공격이 고쳐진 건 아니지만, 부채널 완화책이 쓸모없다고 하는 건 부적절함
      안전벨트를 해도 자동차 사고로 사람이 죽지만 안전벨트가 쓸모없는 건 아닌 것처럼, 완화책은 악용 난도를 크게 높여줌

  • “연구진은 2022년 9월 12일 Apple에 결과를 공개했다”는데, Apple이 왜 1년 넘게 거의 방치했는지 정말 궁금함

    • 그럴 수 있기 때문임
      Apple은 CVE 권력자 중 하나라 자기 제품에 대한 CVE 발급을 거부할 수 있고, 그런 힘이 있으면 원하는 만큼 느리게 움직일 수 있음

  • iLeakage 웹사이트에서 수정 관련 문구를 본 것 같았는데 사라졌음. 착각한 줄 알았지만 실제로 지난 한 시간 사이에 웹사이트가 바뀌고 있었음
    “Apple이 iOS 17.1, iPadOS 17.1, macOS Sonoma 14.1을 방금 릴리스했으니 기기를 업데이트하라”는 문구가 있었고, 지금은 되돌려졌음
    https://github.com/ileakage-authors/ileakage-authors.github....

    • 논문 저자 중 한 명이 이 스레드를 읽고 있는 것 같음
      내가 사이트에 공개 일정이 없다고 지적하자 FAQ에 짧은 섹션이 추가됐고, 여기서 수정 배포 여부가 헷갈리는 상황이라 연구진도 같이 혼란스러워진 듯함
    • 이상함. iOS 17.1로 업데이트했더니 Settings -> Safari -> Advanced -> Feature Flags 아래에 Swap Processes on Cross-Site Navigation이 있고 기본으로 켜져 있음
      macOS의 Swap Processes on Cross-Site Window Open과 다른 것인지 궁금함

  • “iLeakage는 끝까지 실행하기 상당히 어려운 공격이며, 브라우저 기반 부채널 공격과 Safari 구현에 대한 고급 지식이 필요하다”는 문구가 Apple이 크게 신경 쓰지 않는 이유일 수도 있음

    • 실행하기 너무 어려워서 현실적으로 불가능하고, 사실상 위험은 0%에 가깝다는 뜻으로 보임
      또 하나의 무서운 별명과 도메인 이름까지 붙인 건 전문적이지도 신뢰할 만하지도 않아 보임

  • Apple A 시리즈나 M 시리즈 CPU가 들어간 macOS 또는 iOS 기기, 즉 최근 iPhone/iPad와 2020년 이후 Apple 노트북·데스크톱이 해당된다면, 드문 Intel Mac 사용자로서 나는 영향받지 않는 것 같음

    • 아마 영향받을 가능성이 큼
      캐시 계층 구조만 조금 다를 뿐이고, 개념 증명에 약간의 변경이 필요할 것임
    • macOS라면 Safari를 안 쓰면 됨
      iOS라면 Lockdown Mode를 써야 하고, 그게 iPhone을 안전하게 쓰는 유일한 방법임
      Lockdown Mode 없이 한 벤치마크는 mitigations=off로 CPU 벤치마크를 돌린 것만큼 쓸모없다고 봐야 함

  • iOS 기기에서 다른 브라우저 엔진을 허용해야 할 또 하나의 좋은 이유임

    • EU 규제가 결국 Apple을 강제할 수도 있음

  • 아래 명령을 실행할 때 오류가 난다면 터미널에 Full Disk Access를 부여하고 다시 시도하면 됨
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1

답변달기