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

 (wts.dev)
2P by GN⁺ | ★ favorite | 댓글 1개
  • CVE-2025-31250은 macOS의 TCC 권한 동의 팝업을 신뢰하기 어렵게 만든 취약점으로, 화면에 보이는 앱과 실제 권한을 받는 앱을 다르게 만들 수 있었음
  • 문제는 tccd의 TCCAccessRequestIndirect 처리에 있었고, target_path는 팝업에 표시될 앱 이름에, target_identifier는 실제 권한을 받을 앱 식별자에 쓰였음
  • 기존 우회처럼 가짜 앱·Dock 바로가기·사용자 클릭 유도가 필요하지 않았고, 사용자가 스푸핑된 팝업에서 Allow를 누르면 공격이 성립할 수 있었음
  • Apple은 macOS Sequoia 15.5에서 패치했지만, 같은 날 나온 Ventura 13.7.6과 Sonoma 14.7.6은 패치하지 않으며 이전 버전 패치 계획도 없다고 확인함
  • 공격자는 FaceTime, Voice Memos, System Settings 같은 앱이 열리는 순간을 노려 권한 팝업 스푸핑을 시도할 수 있어, 사용자가 실제 권한 부여 대상을 오인할 위험이 있음

CVE-2025-31250의 핵심 동작

  • CVE-2025-31250은 macOS TCC 권한 팝업에서 표시되는 앱과 실제 권한을 받는 앱을 다르게 만들 수 있었던 취약점임
  • 패치 전에는 다음과 같은 구성이 가능했음
    • Application A가 macOS에 권한 동의 팝업 표시를 요청함
    • 팝업은 Application B에서 온 것처럼 보임
    • 사용자의 동의 결과는 Application C에 적용됨
  • 세 앱은 서로 달라도 됐고, 정상적인 사용에서는 보통 같은 앱일 가능성이 높음
  • 핵심 문제는 팝업에 표시되는 앱과 실제 권한 수신 앱이 달라도 검증이 충분하지 않았다는 점임

패치 적용 범위와 정정 사항

  • 초기 설명과 달리 패치는 macOS Sequoia 15.5에만 적용됨
  • 같은 날 릴리스된 macOS Ventura 13.7.6과 macOS Sonoma 14.7.6은 패치되지 않았음
  • Sonoma 14.7.6 가상 머신에서 PoC를 컴파일해 실행했을 때 취약점이 여전히 동작함
  • Apple Product Security는 보고 상태를 “We’ve addressed the issue in all planned releases.”로 바꿨고, 이후 Ventura와 Sonoma에는 이 취약점 패치 계획이 없다고 확인함
  • 결과적으로 Ventura와 Sonoma는 이 취약점에 취약한 상태로 남아 있음

TCC와 Apple Events가 만나는 지점

  • TCC는 Apple 운영체제의 핵심 권한 시스템이며, 내부적으로 tccd 데몬과 private TCC 프레임워크를 통해 동작함
  • 개발자는 private API를 직접 호출하지 않지만, public API가 필요한 시점에 내부적으로 TCC 기능을 호출함
  • tccd는 Apple의 XPC API를 사용해 메시지를 받음
  • 패치 전에는 XPC 메시지를 tccd로 보낼 수 있는 앱이 조작된 메시지를 보내, 권한 팝업 표시 앱과 실제 권한 수신 앱을 분리할 수 있었음

Apple Events와 TCC 데이터 모델

  • Apple Events는 macOS의 프로세스 간 통신 방식이며, 현재는 주로 자동화 용도로 쓰임
  • Apple Events 자동화는 Apple의 Open Scripting Architecture를 통해 스크립트화할 수 있음
    • 대표 언어는 AppleScript
    • JavaScript도 사용할 수 있음
  • macOS Mojave 10.14부터 앱이 Apple Events를 보내려면 TCC를 통한 사용자 동의가 필요함
  • TCC의 사용자 동의 결과는 사용자 홈 폴더 아래 Application Support/com.apple.TCC/TCC.db SQLite 데이터베이스에 저장됨
  • 일반적인 TCC 행에는 요청 앱, 요청 서비스, 사용자 동의 결과가 들어감
  • Apple Events는 수신 앱마다 권한을 제한해야 하므로 indirect object 컬럼을 사용함
    • 이 컬럼에는 Apple Events를 받을 앱의 식별자가 들어감
    • Apple Events 외에 FileProviderDomain 서비스도 이 컬럼을 사용함

취약한 XPC 메시지 구조

  • 문제는 TCCAccessRequestIndirect 함수의 로직 버그에 있었음
  • 이 함수는 TCC.db의 indirect object 컬럼을 써야 하는 접근 요청을 처리함
  • PoC의 핵심은 target_prompt가 2일 때 두 필드를 분리해 넣는 방식임
    • target_path: GUI 권한 팝업에 표시할 앱 이름을 얻는 데 사용됨
    • target_identifier: 실제로 데이터베이스에 기록되어 권한을 받는 앱의 번들 ID로 사용됨
  • TCCAccessRequestIndirect는 indirect object용 함수인데도, 빈 문자열을 indirect object로 넣어 해당 컬럼을 쓰지 않는 여러 TCC 서비스에도 사용할 수 있었음
  • 이 버그는 다른 접근 요청 함수에는 존재하지 않았음

악용 조건과 제한

  • 취약점 악용은 사용자가 권한 팝업에서 Allow를 눌러야 성공함
  • 사용할 수 있는 TCC 서비스는 제한적이었지만, Microphone과 Camera 같은 주요 서비스가 포함됨
  • 특정 디렉터리 접근 권한 팝업도 스푸핑할 수 있었지만, 파일 주변의 추가 보안 계층 때문에 유용성은 낮았음
  • 악성 앱이 권한을 자기 자신이 아니라 다른 앱에 적용하게 만드는 것도 가능했음
    • 공격자가 다른 앱을 제어할 수 있지만 그 앱에 TCC 권한이 필요한 경우에 활용할 수 있는 경로임

팝업 타이밍을 이용한 속임수

  • 무작위로 권한 팝업이 뜨면 사용자가 의심하고 Don’t Allow를 누를 가능성이 있음
  • macOS 앱은 실행 중인 애플리케이션 목록과 현재 최상위 앱을 확인할 수 있음
  • 악성 앱은 특정 앱이 실행되거나 최상위 앱이 되는 시점까지 기다린 뒤, 그 앱 이름으로 스푸핑된 권한 팝업을 띄울 수 있음
  • 예를 들어 FaceTime 실행 시 Camera 권한 팝업을, Voice Memos 실행 시 Microphone 권한 팝업을 스푸핑할 수 있음
  • 사용자는 앱을 열거나 전환한 직후 나타난 팝업을 해당 앱의 정상 권한 요청으로 오인할 수 있음

기존 TCC 우회 경로와의 연결

  • 이전에는 tccd가 사용자 홈 폴더를 HOME 환경 변수로 판단해, 가짜 홈 폴더와 가짜 TCC.db를 심는 방식의 TCC 우회가 가능했음
  • 이 문제는 2020년 7월 중순 업데이트에서 패치됐고, 이후 tccd는 운영체제의 사용자 정보 디렉터리에서 홈 폴더를 조회함
  • 이후에도 사용자 홈 폴더 변경을 악용한 우회 사례가 있었음
    • Wojciech Reguła는 macOS의 GUI 사용자 정보 디렉터리 편집기 플러그인 시스템을 악용한 CVE-2020-27937을 공개함
    • Microsoft Threat Intelligence 팀은 import/export 명령을 이용한 powerdir 우회를 공개함
  • 사용자 홈 폴더를 바꾸려면 일반적으로 두 가지가 필요함
    • root 권한
    • 특정 TCC 서비스에 대한 사용자 동의
  • CVE-2025-31250은 root 권한 요구사항을 우회하지 못하지만, 필요한 TCC 동의를 스푸핑된 팝업으로 유도할 수 있음
  • 악성 앱이 사용자를 속여 동의를 얻고 root 권한 상승까지 확보하면, 사용자 정보 디렉터리를 바꾸고 가짜 TCC.db를 심는 경로가 가능함
  • REG.db는 유효한 TCC.db를 추적하지만, TCC에는 앱이 REG.db에 항목을 추가할 수 있는 함수가 있어 심어둔 TCC.db 경로를 추가할 수 있음

사용자에게 보이는 권한 관리의 한계

  • TCC는 System Settings의 Privacy & Security 패널 뒤에서 동작하는 시스템임
  • Apple Events 관련 동의 결과는 Automation 섹션에 표시됨
  • Privacy & Security 패널에서는 사용자가 부여한 동의를 확인하고, 많은 경우 특정 동의를 철회할 수 있음
  • 그러나 공격자가 사용자를 속여 Apple Events 권한을 허용하게 만든 경우, 해당 동의 결과가 System Settings에 나타나지 않았음
  • 사용자는 tccutil CLI 도구로 동의를 철회할 수 있지만, 이 도구는 문서화가 제한적이고 대부분의 사용자가 알기 어려움

Endpoint Security와 탐지 가능성

  • Apple의 Endpoint Security 프레임워크는 최근 TCC 데이터베이스 수정 감시를 지원하기 시작함
  • Objective-See의 글은 이 변경을 다룬 자료임: Endpoint Security TCC database monitoring
  • 이 기능이 기대대로 동작하면, 프레임워크를 쓰는 앱은 사용자에게 실제로 어느 앱에 권한을 부여했는지 사후 알림을 줄 수 있음
  • 다만 이 탐지 가능성은 Apple이 Endpoint Security 이벤트를 추가한 시점과 취약점 패치 사이의 짧은 기간에만 직접적인 의미가 있었음

Apple의 수정 방식

  • macOS Sequoia 15.5의 tccd 바이너리 분석 결과, 최종 패치는 초기 추정보다 더 복잡했음
  • 패치 후에는 같은 방식으로 TCC 팝업을 스푸핑할 수 없음
  • indirect object에 빈 문자열을 넣어 다른 TCC 서비스에 TCCAccessRequestIndirect를 사용하는 동작도 제한된 것으로 보임
  • 취약한 형태의 메시지는 이제 tccd에서 조용히 버려지고 아무 동작도 하지 않는 것으로 관찰됨
  • 간단한 검증에서는 좋은 패치로 보였지만, 전체 동작을 완전히 이해하려면 추가 분석이 필요함

보고와 패치까지의 흐름

  • 이 취약점은 Apple에 보고된 두 번째 버그였고, Apple이 패치한 보고 건 중 패치까지 가장 오래 걸린 사례였음
  • 보고 과정에는 초기 제보, Apple Product Security의 추가 설명 요청, 잠재적 전체 TCC 우회 경로 공유, PoC 테스트 업데이트, 재현 상태 확인, 여러 차례의 진행 상황 문의가 포함됨
  • 제안된 단순 패치는 두 필드가 같은 앱을 가리키는지 검증하는 방식이었음
  • Apple은 조사 중이라는 답변을 여러 차례 보냈고, 이후 크레딧 표기 이름을 요청한 뒤 패치를 릴리스함
  • 취약점 이름은 “TCC, Who?”로 붙여짐

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Apple 누군가가 본다면, 하루 중 뜬금없이 로컬 관리자 암호를 요구하는 팝업을 그만 띄우라고 계속 부탁하고 싶음
    기본적인 기술만 있어도 웹에서 그럴듯한 복제 팝업을 만들 수 있고, 기술 이해도가 낮은 대다수 사용자는 브라우저 화면 밖으로 끌어보거나 탭을 바꿔 진짜인지 확인할 생각을 못 함
    이런 공격을 막는 유일한 방법은 정식 소프트웨어가 작업 도중 아무 맥락 없이 “암호 입력” 대화상자를 띄운다는 학습을 시키지 않는 것임. 메뉴 막대에 색 있는 깜빡이는 아이콘을 띄우든, Windows처럼 보안 전환 화면을 쓰든 해야지, 현대 macOS의 보안 UI는 심하게 나쁨

    • 이런 요청이 왜 뜨는지, “아니오”를 누르면 무슨 일이 생기는지, 나중에 설정을 어떻게 관리해야 하는지 전혀 알 수 없어서 싫음
      앱이 “환경설정을 열고 XXX 권한을 주세요”라고 안내하면 앱과 기능 토글을 보고 켜거나 다시 끌 수 있는데, 이 경험은 전혀 다름
      그래서 기능 권한(capabilities) 이라는 개념 자체를 별로 좋아하지 않게 됐고, 그 주변 사용자 경험은 거의 필연적으로 나쁠 수밖에 없어 보임. 판매사가 문구를 정하면 “새 앱을 온전히 즐기려면 활성화하세요” 같은 식이 될 테니 도움도 안 됨
    • 기술에 익숙하지 않은 친척들은 로컬 기기 암호와 iCloud/Apple ID 암호를 구분하지 못해서, 될 때까지 전부 입력함
      탓할 수 없는 게, 이 UI들이 불명확하고 일관성이 없음. Apple은 예전에 Vista의 UAC를 조롱했지만, 결국 갑작스러운 프롬프트 조각모음과 더 약한 UI로 비슷한 상태가 됨
    • 최근 Linux에서 Mac으로 옮겼는데, 무작위 root 암호 팝업 때문에 정말 혼란스러웠음
      어떤 앱이나 명령이 root 접근을 요청하는지, 왜 필요한지 설명이 없어서 몇 번 허용한 뒤부터는 거부하기 시작함. 이제 그 팝업은 안 뜨지만, 무엇이 원인이었고 왜 멈췄는지는 여전히 모름
    • macOS가 아직 창에 붙는 모달을 썼다면 문제가 덜했을 것 같음. 완전히 해결되진 않아도 지금보다는 나았을 듯함
      예전 스크린샷에서는 모달이 도구 막대 위에 붙어 있어서 “애플리케이션의 일부”처럼 읽혔음. Steve Jobs도 Aqua 시연 때 분리된 모달의 고통을 짚었는데, 결국 Apple의 모든 것에 모바일 UI를 씌우려는 집착 때문에 분리된 모달로 돌아옴
      [0] https://kagi.com/proxy/latest?c=LsHiRSPxhD29sXqLhdI0j1EsQ98n...
      [1] https://youtu.be/6-fkYFV7rOY?t=242
    • 오래된 명글 The Line of Death를 다시 볼 때가 된 것 같음: https://textslashplain.com/2017/01/14/the-line-of-death/

  • 최근에야 Mac 앱은 시스템 /Applications가 아니라 홈 디렉터리의 Applications에 설치해야 한다는 걸 알게 됨. 물론 단일 사용자 기기에서만 말이 됨
    계정을 비관리자 사용자로 낮추고 앱을 홈 Applications에 설치하면, 앱이 스스로 업데이트하려고 할 때 권한 요청에 시달리지 않음. 거의 대부분은 비관리자 권한으로 알아서 업데이트할 수 있고, 예외는 Tailscale처럼 더 깊은 OS 통합이 필요한 것들뿐임
    비관리자 사용은 Pareto Security 앱이 권장했음: https://paretosecurity.com/mac/checks/not-using-admin
    전체 점검 목록: https://paretosecurity.com/mac/checks
    앱: https://paretosecurity.com/mac 및 https://github.com/paretoSecurity/pareto-mac

    • 안타깝게도 많은, 어쩌면 대부분의 애플리케이션 개발자도 이걸 모름. 심지어 앱을 반드시 /Applications 에 설치하도록 요구하고, 아니면 아예 동작하지 않게 만드는 경우도 많음
    • ~/Applications에 설치하면 root 없이 자동 업데이트할 수 있지만, 수상한 코드도 root 권한 없이 그 앱을 덮어쓸 수 있음
    • 모든 설치 프로그램이 그런 건 아니고, 무능한 개발자가 만든 설치 프로그램만 그럼
      제대로 아는 개발자가 만든 설치 프로그램은 “모든 사용자용” 또는 “나만 사용” 같은 선택지를 제공함
    • ~/Applications가 있다는 건 알고 있었지만, 새 직장에서 기본적으로 관리자 권한이 없어진 뒤에야 실제로 쓰기 시작함
      이제 Homebrew가 cask를 ~/Applications에 설치하도록 설정했고, 거의 모든 애플리케이션에서 잘 동작함
    • macOS 15.4.1에는 아예 ~/Applications가 없음

  • 중요한 정정임. 이 CVE가 macOS Sequoia 15.5 등에서 패치됐다고 썼지만, 그 부분은 착각이었음
    같은 날 배포됐어도 macOS Ventura 13.7.6과 macOS Sonoma 14.7.6은 이 취약점에 대해 패치되지 않은 것으로 보임
    Apple이 모든 릴리스에 패치를 포함했을 거라고 가정하고 문장을 썼는데, 보안 릴리스 노트를 확인해보니 다른 두 릴리스에는 내 크레딧이 없었음. Apple에 확인을 요청했지만 아직 답을 받지 못함
    직접 가상 머신을 띄워 macOS Sonoma 14.7.6으로 업데이트한 뒤 개념 증명 코드를 컴파일하고 실행해봤고, 여전히 동작했음. macOS Ventura 13.7.6도 같을 것으로 봄. Apple이 왜 두 릴리스에 패치를 넣지 않았는지는 모르겠음

    • 수정됨: Ventura와 Sonoma는 계속 취약한 상태로 남음. Apple은 이 문제를 Sequoia에만 패치하기로 결정함

  • Vista를 조롱하던 “I’m a Mac and I’m a PC” 광고가 떠오름. 그런데 이제 내 Mac이 Vista보다 더 나빠져서 짜증남

    • Linux도 권한 상승이 필요할 때는 더 짜증남. 예/아니오 대화상자가 아니라 암호 프롬프트가 뜸
      내가 컴퓨터 잠금을 풀어둔 채 자리를 비운 공격 시나리오까지 방어하고 싶지는 않으니 암호 요구는 무의미함. 필요한 건 내가 무언가를 권한 상승한다는 표시뿐이고, 추가 보안은 Windows처럼 애플리케이션이 “예” 클릭을 자동화할 수 없게 하는 정도면 됨
      마지막으로 확인했을 때 Linux에는 이걸 해결할 방법이 없었고, 생체 인증으로 바꾸는 방법조차 찾지 못했음
    • Windows는 UAC 경험을 개선할 시간이 꽤 많았음. 물론 불평할 다른 부분도 여전히 많음
    • 보안과 확장성 사이의 절충은 피하기 어려워 보임
      그래도 기준점은 조금 옮겨졌음. 적어도 macOS는 예전 Windows에서 흔했던 악성 프로세스에 시달리지는 않음. 아니면 내가 조심해서 그런 걸 수도 있음

  • 처음부터 TCC는 모래성 같았음
    합법적인 개발자만 방해하고, 예전에 Apple이 조롱하던 권한 프롬프트로 사용자를 괴롭히는 반면, 악성 앱은 연구자들이 계속 찾아내고 보고하는 수많은 방식으로 이 “보안 연극”을 쉽게 우회함
    전문 보안 연구자가 아니라 Mac 개발자일 뿐인데도 우회 방법을 여러 개 발견했음. Apple 엔지니어들이 자신들이 쓰는 기술을 이해하지 못하는 것처럼 보일 정도고, 실제로 그럴 수도 있음. iPhone 이전 시대부터 남아 있는 사람이 얼마나 될까 싶음

    • 기본 시스템 기능을 계속 TCC에 편입하면서 Mac용 기업 관리 소프트웨어 배포, 특히 교육 분야 배포의 마찰이 크게 늘었고, 전체 가치 제안이 의심스러울 정도가 됨
      2003년부터 macOS(Cocoa) 개발을 해온 입장에서 하는 말임

  • 업무용 Mac에서 Slack이 “새 helper tool을 설치하려고 한다”는 알림을 자주 띄움. 왜 필요한지, 무슨 뜻인지 전혀 모름
    IT에 이게 진짜인지 어떻게 확인하냐고 물었지만, 그들도 몰랐음. 암호를 요구하고 취소를 눌러도 계속 다시 뜨기 때문에 악용될 수 있지 않을까 자주 생각함

    • 이 대화상자는 System Management 프레임워크에서 나옴
      Slack은 아마 설치 위치나 최초 설치 사용자가 누구인지와 관계없이 스스로 업데이트하기 위해, 개념적으로 setuid root 바이너리와 비슷한 권한 있는 helper tool을 설치하려는 것 같음
      [1]: https://developer.apple.com/documentation/servicemanagement/...
    • 이 팝업을 항상 봄
      허용할지 말지 합리적으로 판단하는 데 쓸 정보가 전혀 없어서 항상 취소를 누름
    • Slack은 브라우저가 아닌 웹 앱으로 사용함: https://support.apple.com/en-us/104996
      Discord도 이 방식으로 설치할 수 있고, 개인적으로 Electron 앱보다 사용 경험이 더 좋음. 거의 모든 Electron 앱은 이렇게 쓰는 편이 낫다고 봄
    • “helper tool” 팝업은 잘 모르지만, 확실히 의심할 것 같음
      설령 Slack이 맞더라도 Slack은 메시징 애플리케이션일 뿐이라 helper tool이 합법적으로 왜 필요한지 모르겠음. Slack 지원팀에 물어보는 게 좋겠고, 실제 답과 설명을 받을 수 있으면 좋겠음
    • 악용될 수 있어 보이지만, 암호를 요구하는 임의 앱이 가진 만큼의 악용 가능성에 가깝다고 봄. 예를 들면 root로 실행하지 않으면 실행을 거부하는 Linux 바이너리 같은 것임
      결국 앱 개발자를 신뢰하는지, 그리고 이 앱이 정말 그 개발자에게서 온 것인지 판단하는 문제임. Apple이 사용자가 서드파티 앱에 root 접근을 주지 못하게 막는 날, Mac은 완전히 벽으로 둘러싼 정원이 될 것이고 HN에는 불평이 쏟아질 것임
      전반적으로 Slack처럼 명확히 필요해 보이지 않는 앱에는 root 권한을 주지 않는 편이 좋은 편집증이라고 봄

  • Apple이 수정판을 내는 데 꼬박 1년이 걸렸음. 매우 긴 시간임
    2024-05-04: 개념 증명 테스트를 계속하면서 추가 업데이트 메시지를 여러 개 남김
    2025-05-12: 패치가 배포됨

    • 내가 발견한 동작에 합법적인, 어쩌면 내부용 사용 사례가 있어서 그 예외는 허용하면서 악성 사용은 막는 데 시간을 썼을 것 같음
      아니면 사용자 상호작용 수준이 더 높아서, 즉 사용자가 “허용”을 눌러야 해서 우선순위가 높지 않았을 수도 있음. 그래도 1년은 충격적으로 긴 시간이라고 봄

  • 2009년쯤 Steve Jobs에게 이메일을 보낸 적이 있음
    MacOS 권한 대화상자는 쉽게 위조될 수 있으니, 사용자가 고른 비밀 문구나 아이콘을 이 대화상자 안에 표시하고, 당시 DRM 기능처럼 화면 캡처도 막아야 한다고 말했음
    답장은 없었고 구현도 되지 않음. 어떤 프로그램이든 여전히 이를 위조해서 시스템 암호를 가져갈 수 있음

    • 그 정도라면 앱이 그냥 UI 프레임워크로 가짜 프롬프트를 띄울 수도 있음
      사용자는 버튼만 누르는 것보다 전체 암호를 입력하는 데 더 주저할 것 같음. 다만 공격자가 OS 자체 코드를 역이용해 오해를 부르는 내용의 프롬프트를 띄우는, 내 버그와 비슷한 문제라면 Apple Product Security에 보고해서 보상금을 받을 수도 있을 것임

  • 오늘 Mac OS가 Chrome이 Bluetooth 접근을 원한다고 알려줬고, 당연히 거부했음
    그러니 가끔은 권한 시스템이 작동하는 셈임

  • Adobe Creative Cloud는 OS 설정에서 명시적으로 그러지 말라고 해도, 여러 프로세스를 백그라운드에서 계속 실행함

    • Creative Cloud는 개인적으로 악성코드라고 봄
답변달기