macOS의 권한 팝업, 믿어도 될까?

• macOS의 TCC 권한 시스템이 허점으로 인해 사용자에게 오인 표시된 권한 요청 팝업을 띄울 수 있었음
• 이 취약점은 CVE-2025-31250으로 등록되었으며, 사용자의 동의가 다른 앱에 적용되는 문제임
• 악성 앱이 권한 요청 창을 신뢰받는 앱의 이름으로 표시해 사용자 동의를 유도하는 스푸핑 공격 가능성이 존재함
• Apple의 macOS Sequoia 15.5에서 패치되었으나, 다른 버전에서는 여전히 미패치된 상태임
• 권한 부여 이력 확인 및 취소의 어려움과 더불어, 향후에도 유사한 취약점이 발생할 가능성 존재함

중요 정정

• 이 취약점이 macOS Sequoia 15.5에서 패치되었으나, macOS Ventura 13.7.6 및 macOS Sonoma 14.7.6에서는 아직 패치되지 않음
• Apple의 보안 릴리즈 노트에 보고자가 언급되지 않았음을 확인함
• 직접 가상머신에서 macOS Sonoma 14.7.6을 테스트해 취약점이 여전히 악용 가능함을 검증함
• Ventura 13.7.6도 동일한 상태일 것으로 추정됨
• Apple 측의 공식 답변을 기다리는 중임

소개

• CVE-2025-31250 취약점은 애플리케이션이 macOS에 허위 권한 요청 팝업을 표시할 수 있게 해주는 현상임
• "Application A"가 팝업을 띄우면, 팝업에는 "Application B"로 표시되고, 결과적으로 사용자의 권한 동의는 "Application C"에 적용됨
• 보통은 세 애플리케이션이 동일하지만, 이 허점으로 인해 서로 다른 앱을 지정할 수 있었음
• 이로 인해 권한 요청 창의 신뢰성에 큰 문제가 발생함
• 이전에도 비슷한 "스푸핑" 방법이 HackTricks 등에서 소개되었으나, 본 취약점은 더 단순한 방식임

TCC

• TCC는 Apple OS에 내장된 핵심 권한 관리 시스템임
• "tccd" 데몬에 메시지를 보냄으로써 권한이 관리되며, 퍼블릭 API가 프라이빗 TCC 프레임워크 함수를 호출함
• 데몬은 Apple의 XPC API를 사용하여 메시지 통신을 함
• 본 취약점이 패치되기 전, 임의 메시지를 보내면 권한 요청 팝업 표시 앱과 실제 권한 부여 앱을 다르게 지정할 수 있었음
• 이런 허점이 왜 생겼는지 이해하기 위해 Apple Events에 대해 알아볼 필요가 있음

Apple Events

Apple Events란 무엇인가

• Apple Events는 macOS 앱 간의 프로세스 통신 방식임
• 1993년 발간된 고전적인 도서 시절부터 이어져 온 프로토콜임
• macOS X 도입 후에도 구조에 맞게 재설계되어 사용되고 있음
• 현대에는 주로 자동화(Automation) 목적으로 사용되며, AppleScript 및 JavaScript로 스크립팅함
• Windows의 Script Host와 비슷하며, 악성코드의 벡터로 악용된 적도 있음

Apple Events와 TCC

• macOS Mojave 10.14부터는 Apple Events 전송에 사용자 동의가 필수임
• TCC의 권한 저장 데이터베이스(TCC.db)에는 요청 앱, 서비스, 그리고 동의 응답 정보가 기록됨
• Apple Events는 개별 수신 앱마다 권한을 나누어 관리해야 하므로, TCC.db의 indirect object 컬럼이 사용됨
• TCC 데몬의 TCCAccessRequestIndirect 함수가 이 컬럼을 활용한 메시지를 처리함
• 해당 함수에 논리적 버그가 존재해, 사용자에게 보여주는 앱과 실제로 권한을 받는 앱이 다르게 지정될 수 있었음

개념 증명(Proof-of-Concept)

• Swift 코드 예시는 다음과 같이 권한 요청 메시지를 조작함
  • "spoofedBundle" 경로의 앱 이름을 사용자 동의 팝업에 노출시킴
  • "actualBundle"의 번들 ID를 실제 권한 부여 대상으로 지정함
• 결과적으로 사용자는 신뢰할 만한 앱이 권한을 요청하는 것처럼 보지만, 실제 권한은 악성 앱에 돌아감
• "indirect_object" 값을 비워도 여러 TCC 서비스를 공략할 수 있었음
• 이로 인해 사용자 권한 동의의 신뢰성 붕괴가 발생함
• 공격자는 사용자를 속여 임의 앱이 권한을 획득하도록 유도할 수 있음

취약점 악용

한계점 및 특이사항

• 특정 TCC 서비스만 공격에 취약하지만, Microphone, Camera 등 주요 서비스는 공격 대상임
• 파일/폴더 권한 같은 경우 추가 보호장치로 인해 큰 효과는 없음
• 악성 앱이 실제로 권한이 필요한 타 앱 대신 사용자가 동의하도록 사회공학적 기법과 함께 사용 가능함

타이밍의 중요성

• 팝업을 띄울 시점이 중요함
• 악성 앱은 실행 중인 앱과 현재 전면에 있는 앱을 감지해, 적절한 타이밍에 팝업을 표시하여 사용자가 헷갈리게 할 수 있음
• 예시로 FaceTime 실행 시, Camera 권한 팝업을 띄우면 사용자는 정상 권한 요청으로 오인할 수 있음
• Voice Memos 실행 시 Microphone 권한 요청을 스푸핑하는 시나리오도 가능함
• 컨텍스트에 맞는 시점을 노려 악용하면 성공률이 높아짐

과거 취약점 재조명

• TCC.db의 경로가 사용자 홈 폴더에 따라 결정됨을 악용한 취약점들이 존재함
• 2020년까지 HOME 환경 변수만 바꾸면 페이크 TCC.db를 사용할 수 있었음($HOMERun)
• 패치 이후에도 루트 권한과 사용자 동의가 필요하지만, 사회공학적 스푸핑과 결합시 권한 우회가 가능함
• 악성 앱이 사용자로부터 동의 유도 후, 홈 폴더 변경 및 등록 데이터베이스 추가를 통해 가짜 TCC.db로 우회 가능함
• 실제로 이런 방식으로 테스트해 TCC 동작에 영향을 줄 수 있었음을 확인함

타임라인

1.

• 2024-05-02 : Apple Product Security에 초기 보고 및 추가 메시지 전송함

2.

• 2024-05-03 : Apple Product Security에서 추가 설명 요청 및 답변
• 같은 날, 전체 TCC 우회 가능성을 발견해 Apple에 재보고함

3.

• 2024-05-04 : PoC 테스트 지속 및 추가 업데이트 메시지 남김

4.

• 2024-05-06 : Apple Product Security에서 정보 제공에 감사 인사

5.

• 이후에도 수시로 패치 현황 질의 및 상태 확인, 2024-06~2025-02까지 지속적으로 Apple에 소통했으나 오랜 기간 수정되지 않음

6.

• 2025-05-12 : 해당 버그 패치 릴리즈됨

결론

기타 사항

• TCC는 System Settings 앱의 Privacy & Security(기존 Security & Privacy) 항목 및 해당 자동화 섹션에서 표시됨
• 하지만 Apple Events 관련 동의 내역은 GUI에서 보이지 않아 사용자가 직접 취소하기 어려움
• CLI 도구인 tccutil로는 취소 가능하나, 거의 알려지지 않음
• 최근 Apple Endpoint Security 프레임워크에 TCC 데이터베이스 변경 감시 기능이 추가됨
• 만약 정상적으로 동작한다면, 실제로 권한을 받은 앱이 무엇인지 사용자에게 알려 악용 방지에 보탬이 될 수 있음

Apple의 패치

• 실제 패치 내용은 복잡하며, 외부에서 임의로 indirect object가 지정된 메시지들은 tccd에서 조용히 무시하도록 변경됨
• 동작 확인 결과, 더이상 스푸핑이 불가능해졌음을 확인함
• 만약 패치가 불완전하다면 이후 업데이트에서 추가 조치가 필요할 수 있음

마지막 생각

• 본 취약점에 "TCC, Who?"라는 이름을 붙임
• 보안 연구자의 시각에서 권한 시스템의 신뢰성이 갖는 중요성을 다시 강조함
• 앞으로도 유사한 허점이 발견될 가능성이 있음을 암시함
• 사용자는 macOS 권한 팝업을 맹신하지 않아야 함을 시사함