▲

iPhone을 벽돌로 만들 수 있었던 1줄짜리 코드 이야기

 (rambo.codes)
2P by GN⁺ 21시간전 | ★ favorite | 댓글 1개
  • Darwin Notification 시스템의 특성과 취약점을 이용해 iPhone을 벽돌화할 수 있었던 사례 소개
  • 이 취약점은 CVE-2025-24091로 등록되었으며, 제보자는 $17,500(2500만원) 의 버그 바운티를 수령했음
  • 특별한 권한 없이 시스템 수준 알림을 전송할 수 있다는 점을 악용해 iOS 장치 전체를 마비시킬 수 있었음
  • 간단한 한 줄 코드로 "Restore in Progress" 모드를 강제 유발하여 재부팅 반복을 유도하는 서비스 거부(DoS) 공격 가능성이 확인됨
  • iOS 18.3 업데이트를 통해 중요한 Darwin Notification 전송에 제한 권한(entitlement) 을 요구하도록 수정되어 취약점이 해결됨

Darwin Notifications

  • Darwin Notifications는 iOS와 macOS에서 프로세스 간 간단한 메시지를 주고받기 위한 CoreOS 레벨의 메커니즘임
  • notify_post 로 이벤트를 알리고, notify_register_dispatch 로 이벤트를 수신하며, 상태값(state) 을 읽거나 쓸 수 있는 구조임
  • 특별한 권한 없이 수신 및 송신이 가능하고, 보안 검증 절차가 없음
  • 시스템의 다양한 컴포넌트들이 이 레거시 API에 의존하고 있었음

취약점 개요

  • Apple 운영 체제의 모든 프로세스는 Darwin Notifications를 수신할 수 있으며, 특별한 권한이 필요하지 않음
  • 샌드박스된 앱에서도 Darwin Notification을 전송할 수 있는 구조적 허점이 존재했음
  • 데이터 전송량이 제한적이기 때문에 민감한 데이터 유출 위험은 크지 않음
  • 특정 중요한 시스템 알림(ex: 복원 시작 알림)을 송신하면 전체 시스템에 영향을 줄 수 있음
  • 이로 인해 서비스 거부(DoS) 공격 가능성을 찾아냄

EvilNotify와 VeryEvilNotify

  • EvilNotify 앱을 통해 다양한 시스템 반응을 강제로 발생시킬 수 있었음
    • 액체 감지 아이콘 표시
    • Wi-Fi 차단 및 셀룰러 강제 사용
    • 잠금 화면 및 제어 센터 제스처 차단
    • Find My Lost Mode 진입 등
  • 특히, notify_post("com.apple.MobileSync.BackupAgent.RestoreStarted") 한 줄로 Restore in Progress 상태에 빠뜨릴 수 있었음
  • 이 모드는 장치가 실제로 복원되지 않기 때문에 실패하며, 유일한 해결책은 "재시작" 버튼을 누르는 것임
  • VeryEvilNotify 앱은 위젯 확장을 이용해 재부팅 후에도 자동으로 공격 재시작이 가능하도록 구현함
  • 위젯 확장은 시스템이 백그라운드에서 주기적으로 실행되며, notify_post 함수를 호출하여 "복원 진행 중" 모드를 반복적으로 트리거함
  • 결과적으로 장치를 완전히 벽돌화시키는 효과를 일으킬 수 있었음

타임라인 및 CVE 등록

  • 2024년 6월 26일: Apple에 초기사건 보고서 제출
  • 2024년 9월 27일: Apple로부터 완화 조치가 진행 중이라는 메시지 수신
  • 2025년 1월 28일: 문제 해결 완료 및 버그 바운티 자격 확정
  • 2025년 3월 11일: CVE-2025-24091로 공식 등록되고 iOS/iPadOS 18.3에서 해결됨
  • 버그 바운티 금액은 미화 17,500달러 지급

대응 및 완화 조치

  • 민감한 Darwin Notification 송신에는 제한된 권한(entitlement) 이 필요하도록 변경됨
  • 예를 들어, 기존 com.apple.MobileBackup.BackupAgent.RestoreStarted 알림은 com.apple.private.restrict-post.MobileBackup.BackupAgent.RestoreStarted로 변경됨
  • 알림을 수신하는 프로세스도 새로운 이름을 사용해 비인가 앱의 무단 송신을 차단함
  • 이 제한 권한 체계는 iOS 18.2 베타 2부터 적용되기 시작했고, iOS 18.3에서 완전히 마무리됨
▲
GN⁺ 21시간전  [-]
Hacker News 의견

  • 이 API를 통해 설정 및 알림 게시에 대한 모든 사용에 권한을 요구하지 않는 점이 흥미로움

    • 기기에서 프로세스 간에 64비트 정보를 공유할 수 있는 방법이 있음
    • 앱 간 사용자 추적에 적합한 기능임
    • 시스템이 값을 저장하고, 어느 앱에서 왔는지 추적하지 않는다면, 앱 삭제 및 재설치 후에도 지속적인 저장소가 가능함
    • IDFA 또는 IDFV 재설정을 우회하는 데 사용할 수 있음

  • 설명된 취약점은 기기를 "벽돌"로 만들지 않음

    • 복구를 위해서는 테더드 복원이 필요함

  • $17,500는 꽤 괜찮음

    • 블로그 게시물이 보통 적은 금액이거나, 회사가 취약점을 수정하고 보상을 하지 않는 경우가 많음
    • Apple은 2019년 이후로 이 부분에서 개선됨

  • 훌륭한 작업임

    • 간단하고 효과적이며 강력한 취약점임
    • 20년 전 대학 친구와 함께 이론화했던 완벽한 서버 취약점을 떠올리게 함
    • 2년 전 CVE-2022-23093로 발견됨

  • iOS 핵심 팀이 이를 검토했을 때 사무실에서 얼마나 힘든 날이었을지 상상할 수 있음

  • 코드 한 줄로 기기가 "복구 진행 중" 모드에 들어가게 할 수 있었음

    • 어떤 프로세스든 알림을 보내 시스템을 그 모드로 속일 수 있었음

  • 옛날 IRC 시절이 그리움

    • 작은 변화가 기술에 얼마나 위험할 수 있는지를 상기시킴
    • 보안이 앞서 나가는 것인지 아니면 계속해서 누수를 막는 것인지 궁금함

  • 타사 앱이 자체 알림 체계를 가지고 있다면 유사하게 사칭될 수 있음을 암시함

    • 기기를 벽돌로 만들 수는 없겠지만 다른 동작을 유발할 가능성이 있음

  • 악성 앱을 사용자가 적극적으로 설치해야 하므로 우선순위가 낮을 수 있음

    • 그러나 그 시간표가 자신감을 주지 않음

  • 이 글은 대단한 읽을거리였음

    • 매우 오래된 API가 얼마나 강력했는지 보여줌
    • iOS의 저수준 상태를 모두 트리거하는 멋진 데모였음
    • notify_post가 지금은 어떻게 되었는지 궁금함
답변달기