▲

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

 (wts.dev)
1P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • 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 권한 팝업을 맹신하지 않아야 함을 시사함
▲
GN⁺ 19시간전  [-]
Hacker News 의견

  • 누군가 Apple에서 이 글을 볼 거라는 아주 작은 가능성에 걸어, 내가 항상 부탁하고 싶은 말을 반복함—Apple이 '지금 (로컬 관리자) 비밀번호를 입력하라'는 대화상자를 아무 때나 무작위로 띄우는 작업을 멈춰줬으면 하는 바람임, 왜냐하면 컴퓨터가 업데이트나 뭔가를 설치하고 싶다는 충동이 들었기 때문임. 기초적인 기술만 있어도 웹에서 거의 똑같이 보이는 가짜 팝업을 쉽게 만들 수 있음, 그리고 기술적으로 상위 20% 정도를 제외한 대부분의 사용자는 이게 진짜인지 혹은 브라우저 안에서 만들어진 가짜인지 알아차릴 생각도 못 함. 이런 문제를 원천적으로 막으려면 정상적인 소프트웨어가 갑자기 아무런 예고 없이 작업 중간에 비밀번호 대화상자를 띄우지 않는다는 습관을 사용자에게 심어줘야 함, 그런데 현재의 macOS 보안 UI는 그와 정반대임. 메뉴바에 컬러풀하고 눈에 띄는 아이콘을 표시하거나, Windows처럼 보안 화면을 잠깐 띄워주는 등의 방식으로 바꿔야 함. 지금의 UI 설계는 정말 문제가 많음

    • 이런 팝업에서 내가 제일 싫은 점은 왜 이걸 요구하는지, 거절하면 무슨 일이 생기는지, 혹시라도 나중에 이 설정을 바꾸려면 뭘 해야 하는지도 전혀 모르겠다는 점임. 앱에서 '설정 패널을 열고 XXX 권한을 주세요' 라고 안내하는 방식은 원하는 앱, 권한, 토글을 명확히 볼 수 있는데, 비밀번호 팝업은 이런 UX를 제공하지 않음. 그래서 'capabilities'라는 개념을 별로 좋아하지 않게 되었음, UX가 너무 불편하고 거의 어쩔 수 없는 점임. '앱을 완벽히 사용하려면 <root my computer>를 허용하세요' 같은 식으로 나올 텐데, 공급사가 메시지를 정하면 무조건 이런 식임. 도움이 전혀 안 되는 UX임

    • macOS가 여전히 모달 창을 윈도우에 붙여서 표시했다면 이런 현상이 좀 덜했을 것 같음. 완전히 해결되는 건 아니지만 좀 나았으리라 생각함. 지금처럼 툴바 위에 모달이 덮여버리면 딱 봐도 '앱 내부'라는 느낌이 들게 만듦. Steve Jobs가 Aqua 데모할 때도 이런 따로 떠다니는 모달 때문에 사용성이 떨어진다고 강조했었는데, 지금은 Apple이 모든 화면에서 모바일 UI를 쓰고 싶어 하는 이상한 집착 때문에 이렇게 됐다고 생각함

    • 기술이 없는 내 가족들은 로컬 기기 비밀번호랑 iCloud/Apple ID 비밀번호의 차이도 못 알아봄, 결국 아무거나 입력해볼 때까지 다 쳐 넣음(이건 UI가 불분명하고 일관성이 없어서 그런 것임). Apple이 옛날엔 Vista의 UAC를 놀렸지만, 지금은 본인들도 갑작스러운 알림과 엉성한 UI를 잔뜩 만들어둠

    • 리눅스에서 Mac으로 최근에 옮겨왔는데, 무작위로 뜨는 root 비밀번호 팝업 때문에 진짜 혼란스러웠음. 어느 앱이나 명령어가 root 권한을 요청하는 건지, 왜 필요한 건지 아무 설명이 없어서 몇 번 허용해주다가 그냥 거절로 바꿈. 그 이후로는 더는 팝업이 안 뜸. 근데 여전히 뭘 위해 팝업이 떴는지, 왜 안 뜨는지 전혀 모르는 상황임

    • 다시 한 번 이 고전 글을 추천하고 싶음: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/

    • 패스키(Passkey) 팝업은 자바스크립트 팝업과 구분이 전혀 안 돼서 보안상 특히 심각한 실수임

    • 이런 상황에선 내장된 지문 인식기가 정말 고마움. 원래 노트북 화면은 닫고 외부 모니터로만 쓰지만, 시스템 인증이 필요할 땐 일부러 열어서 지문으로 인증함

    • 반전: 사실 그런 대화상자는 애초에 없었음! 이미 속은 것임

    • 현 시점에서 가장 인기 있는 댓글에 끼워서 알려드리고 싶은 정보가 있음—이 기사에 중요한 업데이트가 있음: https://news.ycombinator.com/item?id=43969087

    • 가짜 팝업을 클릭할 때의 위협 모델이 뭔지 궁금함. 실제로 시스템이 아니라면 이게 아무 의미 없는 조작 아닌지 궁금함

    • iCloud에 로그인할 때 컴퓨터의 로컬 비밀번호를 요구하는 팝업이 뜨는데, 그걸 입력하면 그 비밀번호가 iCloud 서버로 업로드됨

  • 최근에 mac 앱을 시스템 Applications가 아닌 내 홈 디렉토리 Applications(~/Applications)에 설치해야 한다는 사실을 알게 됨, 물론 이건 한 명만 쓰는 컴퓨터일 때나 의미 있음. 나 자신을 비관리자(non-admin) 사용자로 내려놓고, 앱들을 홈디렉토리 Applications에 설치하면 업데이트 권한 요청이 귀찮게 안 뜸. 대부분의 앱들이 관리자가 아니어도 알아서 업데이트함. 예외적으로 Tailscale 등 OS 통합이 필요한 앱만 별도 권한이 필요함. 참고로 Pareto Security라는 앱에서 추천한 방식임

    • 아쉽게도 거의 대부분의 앱 개발자도 이 방식을 모름, 또 많은 앱들은 아예 /Applications 경로에만 설치하길 요구해서 그 외 위치에서는 작동하지도 않음

    • ~/Applications에 앱을 설치하면 root 없이 자동 업데이트가 가능하지만, 그만큼 의심스러운 코드도 root 권한 없이 쉽게 덮어쓸 수 있음

    • macOS 15.4.1을 쓰고 있는데 ~/Applications 폴더 자체가 없음

    • 신기하다고 느껴짐! 나는 평상시에 admin 계정이 꼭 필요하기 때문에 이 방법을 쓰기는 어렵지만, 해당되는 사람에겐 정말 쓸 만한 방법임

  • 이 글 내용에 중요한 정정이 필요함. 이전에는 CVE가 macOS Sequoia 15.5에서 패치됐다고 했는데, 사실은 같은 날 공개된 macOS Ventura 13.7.6과 macOS Sonoma 14.7.6에는 패치가 적용되지 않았음. Apple이 당연히 모든 버전에 패치를 넣었을 거라 생각하고 그렇게 적었는데, 보안 릴리즈 노트에서 내 이름이 다른 두 버전에 없는 걸 확인하고 Apple에 직접 문의함. 아직 답은 못 받음. 직접 테스트를 위해 가상머신을 띄워서 macOS Sonoma 14.7.6에 패치를 적용하고 내 PoC를 돌렸더니, 여전히 취약점이 작동함. 아마 Ventura 13.7.6도 마찬가지일 거라고 생각함. Apple이 왜 패치를 안 넣었는지 이해가 안 됨. 추가 정보가 생기면 다시 글을 업데이트할 예정임

  • macOS의 TCC 시스템은 견고한 프라이버시 장치로 평판이 높지만, 실제로는 데이터베이스 입력 하나로 쉽게 우회될 수 있다는 사실을 떠올려보면 씁쓸한 느낌임. 사용자의 동의 팝업이 실제 데이터베이스 조작 앞에서는 큰 의미가 없음, 특히 SIP가 꺼진 개발 환경에서는 더함. 이건 결국 신뢰 문제임. 과연 UX 차원의 동의가 여전히 실질적인 보안 경계선인지 의문임. 이제 점점 OS 레벨의 권한 팝업에 의존하는데, 그 경계가 실제로는 허상(혹은 그냥 연출)에 불과하다면, 권한 신뢰를 ‘보여주는 것’이 아니라 ‘실제로 어떻게 유지할지’ 다시 생각해야 할 필요가 있음

    • 실제 ‘capabilities’ 시스템이 구현된다면 훨씬 좋을 거라는 데 동의함. 근데 결국 데이터베이스라면 사용자 영역이나 커널 둘 중 어디에 저장해야 한다는 딜레마가 있음. 근데 어느 쪽도 딱히 마음에 들지는 않는 생각임

  • 예전에 'I'm a Mac and I'm a PC' 광고에서 Vista의 이런 요소들을 조롱했던 게 기억남. 그런데 지금은 내 Mac이 Vista보다도 더 별로임. 정말 짜증남

    • 보안이랑 확장성 간의 절충은 피할 수 없는 숙명 같음. 그래도 기준선이 예전보다는 옮겨졌다는 점도 있음. 적어도 macOS는 예전 Windows처럼 악성 프로세스가 넘쳐흐르지는 않음. 아니면 내가 운 좋고 조심해서 그런 걸지도 모름

    • 그냥 궁금해서 묻는데, 어떤 점이 특히 그렇게 짜증났는지 알고 싶음

  • TCC 시스템은 처음부터 허술하기 짝이 없는 구조였음. 합법적인 개발자들만 괴롭히고, 사용자는 권한 요청 팝업에 시달리게 만들 뿐, 악성 앱은 연구자들이 계속 밝혀내듯 다양한 경로로 이 '보안(쇼)'를 우회함. 보안 연구자는 아니지만 Mac 개발자로서 나도 우회 방법을 여러 개 찾았음. Apple 엔지니어들도 정말 자신들이 쓰는 기술을 이해하는지조차 의심스러움. 전통 맥 개발자들 중에서 과연 몇 명이나 남아 있을지 궁금함

    • 기본 시스템 기능들이 계속 TCC에 추가되면서 Mac에서 기업용 관리 소프트웨어를 배포하는 데 엄청난 마찰이 생겼음(특히 교육 분야에서). 이제는 그 가치 자체에 의문을 가질 정도임. 2003년부터 macOS (Cocoa) 개발자로 일하면서 느끼는 점임

  • 회사 Mac을 쓰는데 주기적으로 ‘Slack이 새로운 헬퍼 툴 설치를 시도합니다’라는 알림이 뜸. 이게 뭔지, 왜 뜨는지 전혀 모르겠음. IT팀에 물어봤더니 확인 방법을 몰랐음. 이게 악용될 수 있겠다고 자주 생각하고 있음, 비밀번호를 계속 요구하기 때문이고, 매번 취소를 눌러도 계속 뜸

    • 이 대화상자는 System Management 프레임워크에서 보내는 것임. Slack이 어디에 설치되어 있든, 어떤 사용자가 깔았든 상관없이 스스로 업데이트할 수 있게 권한이 높은 헬퍼 툴을 설치하는 과정임

    • 이런 팝업이 나올 때마다 무슨 정보를 보고 허용이나 거절을 결정해야 할지 알 방법이 없어서 항상 취소만 누르게 됨

    • Slack을 웹 앱(하지만 브라우저 내에서가 아니라 별도 창으로)으로 쓰고 있음 https://support.apple.com/en-us/104996 Discord도 같은 방식으로 사용 가능함. 체감상 Electron 앱보다 훨씬 쾌적하게 쓸 수 있음. 대부분의 Electron 앱이 이 방식이 더 나음

    • 나는 ‘헬퍼 툴’ 팝업을 직접 본 적은 없지만, Slack 같은 단순 메시징 앱이 왜 그런 권한이 필요한지 이유를 모르겠음. Slack 지원팀에 문의해보는 게 좋겠음(그리고 진짜 제대로 된 답변을 받을 수 있길 바람)

    • 비밀번호를 필요로 하는 앱(예: 리눅스에서 루트로만 실행되는 바이너리)과 마찬가지로 악용 가능성은 분명 있음. 결국 개발자와 해당 앱이 진짜인지 신뢰할 수 있느냐의 문제임. 애플이 외부 앱에 아예 root 권한을 못 주게 막는 날에는 Mac이 완전히 폐쇄형(walled garden)이 되는 날이고, 이곳(HN)에 불만 댓글이 넘쳐날 것임. 결론적으로 Slack처럼 명확하게 필요하지 않은 앱에는 root 권한을 주지 않는 ‘좋은 불신’을 갖는 게 중요함

    • 입력 포커스를 강제로 빼앗아서, 메시지 입력 중이던 텍스트가 갑자기 비밀번호 입력 창에 입력되기 시작함. 아주 짜증나는 경험임

    • 팝업이 시간차로 쌓임. 주말 지나서 컴퓨터 켜면 계속 반복해서 팝업이 떠서 결국 Slack을 그냥 종료함. 1년째 이러는 중임. 이 권한을 Slack에서 어떻게 거두는지 모르겠음, 좀 악의적인 느낌이 듦

    • 이런 식의 ‘보안’ 차단 도구들이 진짜 바보 같음. 오히려 사람을 더 멍청하게 만드는 훈련임. 오늘은 진짜여도 내일은 아닐 수도 있음. 은행에서 ‘신원 보호’ 명목으로 내 개인정보를 요구하는 전화를 계속 받는데, 이런 장치들이 다 사람을 훈련시켜서 낯선 사람에게 개인정보를 넘기게 만듦

    • macOS 개발자는 아니지만, 아무 (악의적인) 앱이라도 시스템의 팝업 창 스타일을 흉내내서 사용자 비밀번호를 훔칠 수 있는지 궁금했음

    • VSCode도 회사에서 지급한 Mac에서 똑같이 팝업을 띄움. 몇 년째 그냥 무시하고 있음

    • 모든 Electron 기반 앱에서 OS 사용자 계정을 여러 개 쓰면 이런 팝업이 나옴

    • nordVPN도 동일한 현상임

  • Apple이 패치 내놓는 데에 꼬박 1년이 걸림. 상당히 긴 느낌임. <i>2024-05-04 여러 업데이트 메시지를 남김, PoC를 계속 테스트 중임</i> <i>2025-05-12 패치가 릴리스됨</i>

    • 나도 1년이 엄청 오래 걸린 것에 동의함. 실제로는 내가 찾은 동작에 대해 뭔가 합법적인(내부용?) 이유가 있었고, 악의적 케이스와의 균형점을 찾느라 오래 걸린 것이거나, 아니면 우선순위가 낮았던 것이라 생각함. 어쨌든 패치에 1년이 걸린 건 충격적으로 느껴짐

  • Adobe Creative Cloud는 운영체제 설정에서 명시적으로 백그라운드 실행을 꺼도 계속 여러 프로세스를 백그라운드에서 실행함

  • 이 사람의 연구를 정말 좋아함, 발표도 너무 잘하는 느낌임

    • 고마운 마음임! 참고로 나는 남자가 아님, 그냥 한 사람이란 사실을 알려드림
답변달기