macOS Gatekeeper / Quarantine / XProtect
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Gatekeeper는 Mac 운영 체제를 위해 개발된 보안 기능으로, 사용자가 신뢰할 수 있는 소프트웨어만 시스템에서 실행하도록 보장합니다. 이는 사용자가 App Store 외부의 소스에서 다운로드하고 열려고 시도하는 소프트웨어(앱, 플러그인 또는 설치 패키지 등)를 검증함으로써 작동합니다.
Gatekeeper의 핵심 메커니즘은 검증 프로세스에 있습니다. 다운로드한 소프트웨어가 인정된 개발자에 의해 서명되었는지 확인하여 소프트웨어의 진위를 보장합니다. 또한, 소프트웨어가 Apple에 의해 노타리제이션되었는지 확인하여 알려진 악성 콘텐츠가 없고 노타리제이션 이후에 변조되지 않았음을 확인합니다.
또한, Gatekeeper는 사용자가 다운로드한 소프트웨어를 처음 열 때 승인을 요청하여 사용자 제어 및 보안을 강화합니다. 이 보호 장치는 사용자가 무심코 해로운 실행 코드를 실행하는 것을 방지하는 데 도움을 줍니다.
애플리케이션 서명, 즉 코드 서명은 Apple의 보안 인프라의 중요한 구성 요소입니다. 이는 소프트웨어 저자(개발자)의 신원을 검증하고 코드가 마지막으로 서명된 이후에 변조되지 않았음을 보장하는 데 사용됩니다.
작동 방식은 다음과 같습니다:
애플리케이션 서명: 개발자가 애플리케이션을 배포할 준비가 되면, 개인 키를 사용하여 애플리케이션에 서명합니다. 이 개인 키는 Apple Developer Program에 등록할 때 Apple이 개발자에게 발급하는 인증서와 연결되어 있습니다. 서명 프로세스는 앱의 모든 부분에 대한 암호화 해시를 생성하고 이 해시를 개발자의 개인 키로 암호화하는 과정을 포함합니다.
애플리케이션 배포: 서명된 애플리케이션은 개발자의 인증서와 함께 사용자에게 배포되며, 이 인증서에는 해당 공개 키가 포함되어 있습니다.
애플리케이션 검증: 사용자가 애플리케이션을 다운로드하고 실행하려고 시도할 때, Mac 운영 체제는 개발자의 인증서에서 공개 키를 사용하여 해시를 복호화합니다. 그런 다음 현재 애플리케이션 상태를 기반으로 해시를 재계산하고 이를 복호화된 해시와 비교합니다. 일치하면 애플리케이션이 개발자가 서명한 이후로 수정되지 않았음을 의미하며, 시스템은 애플리케이션 실행을 허용합니다.
애플리케이션 서명은 Apple의 Gatekeeper 기술의 필수적인 부분입니다. 사용자가 인터넷에서 다운로드한 애플리케이션을 열려고 시도할 때, Gatekeeper는 애플리케이션 서명을 검증합니다. Apple이 알려진 개발자에게 발급한 인증서로 서명되었고 코드가 변조되지 않았다면, Gatekeeper는 애플리케이션 실행을 허용합니다. 그렇지 않으면 애플리케이션을 차단하고 사용자에게 경고합니다.
macOS Catalina부터는 Gatekeeper가 애플리케이션이 Apple에 의해 노타리제이션되었는지도 확인하여 추가 보안 계층을 추가합니다. 노타리제이션 프로세스는 애플리케이션에서 알려진 보안 문제와 악성 코드를 검사하며, 이러한 검사가 통과하면 Apple은 Gatekeeper가 검증할 수 있는 티켓을 애플리케이션에 추가합니다.
일부 악성 샘플을 확인할 때는 항상 서명을 확인해야 하며, 서명한 개발자가 이미 악성 코드와 관련이 있을 수 있습니다.
Apple의 노타리제이션 프로세스는 사용자들을 잠재적으로 해로운 소프트웨어로부터 보호하기 위한 추가적인 안전장치 역할을 합니다. 이는 개발자가 자신의 애플리케이션을 Apple의 노타리 서비스에 제출하여 검토를 받는 과정을 포함합니다. 이 서비스는 App Review와 혼동해서는 안 됩니다. 이 서비스는 제출된 소프트웨어에 악성 콘텐츠와 코드 서명과 관련된 잠재적인 문제를 검사하는 자동화된 시스템입니다.
소프트웨어가 우려 사항 없이 이 검사를 통과하면, 노타리 서비스는 노타리제이션 티켓을 생성합니다. 개발자는 이 티켓을 자신의 소프트웨어에 첨부해야 하며, 이를 '스테이플링'이라고 합니다. 또한, 노타리제이션 티켓은 온라인에 게시되어 Gatekeeper, Apple의 보안 기술이 이를 접근할 수 있습니다.
사용자가 소프트웨어를 처음 설치하거나 실행할 때, 노타리제이션 티켓의 존재 - 실행 파일에 스테이플링되었거나 온라인에서 발견된 경우 - Gatekeeper에 소프트웨어가 Apple에 의해 노타리제이션되었음을 알립니다. 결과적으로, Gatekeeper는 초기 실행 대화 상자에 설명 메시지를 표시하여 소프트웨어가 Apple에 의해 악성 콘텐츠 검사를 받았음을 나타냅니다. 이 과정은 사용자가 자신의 시스템에 설치하거나 실행하는 소프트웨어의 보안에 대한 신뢰를 높입니다.
Sequoia 버전부터, **spctl**은 더 이상 Gatekeeper 구성을 수정할 수 없습니다.
**spctl**은 Gatekeeper와 상호작용하고 열거하는 CLI 도구입니다 (XPC 메시지를 통해 syspolicyd 데몬과 함께). 예를 들어, 다음과 같이 Gatekeeper의 상태를 확인할 수 있습니다:
GateKeeper 서명 검사는 격리 속성이 있는 파일에 대해서만 수행되며, 모든 파일에 대해 수행되지 않습니다.
GateKeeper는 환경 설정 및 서명에 따라 이진 파일이 실행될 수 있는지 확인합니다:
**syspolicyd**는 Gatekeeper를 시행하는 주요 데몬입니다. 이 데몬은 /var/db/SystemPolicy에 위치한 데이터베이스를 유지 관리하며, 여기에서 데이터베이스를 지원하는 코드와 여기에서 SQL 템플릿을 찾을 수 있습니다. 데이터베이스는 SIP에 의해 제한되지 않으며 root에 의해 쓰기가 가능하고, 데이터베이스 /var/db/.SystemPolicy-default는 다른 데이터베이스가 손상될 경우를 대비한 원본 백업으로 사용됩니다.
또한, 번들 /var/db/gke.bundle 및 **/var/db/gkopaque.bundle**는 데이터베이스에 삽입되는 규칙이 포함된 파일을 포함합니다. root로 이 데이터베이스를 확인할 수 있습니다:
**syspolicyd**는 assess, update, record 및 cancel과 같은 다양한 작업을 수행하는 XPC 서버를 노출하며, 이는 Security.framework의 SecAssessment* API를 사용하여 접근할 수 있고 **xpctl**은 실제로 XPC를 통해 **syspolicyd**와 통신합니다.
첫 번째 규칙이 "App Store"로 끝나고 두 번째 규칙이 "Developer ID"로 끝나는 점에 주목하십시오. 이전 이미지에서는 App Store 및 식별된 개발자의 앱을 실행할 수 있도록 활성화되어 있었습니다. 해당 설정을 App Store로 수정하면 "Notarized Developer ID" 규칙이 사라질 것입니다.
또한 type GKE의 수천 개의 규칙이 있습니다:
이 해시는 다음에서 가져온 것입니다:
/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth
/var/db/gke.bundle/Contents/Resources/gk.db
/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db
또는 이전 정보를 다음과 같이 나열할 수 있습니다:
The options --master-disable and --global-disable of spctl will completely 비활성화 these signature checks:
완전히 활성화되면 새로운 옵션이 나타납니다:
앱이 GateKeeper에 의해 허용될지 확인할 수 있습니다:
GateKeeper에 특정 앱의 실행을 허용하는 새로운 규칙을 추가하는 것이 가능합니다:
Regarding kernel extensions, the folder /var/db/SystemPolicyConfiguration contains files with lists of kexts allowed to be loaded. Moreover, spctl has the entitlement com.apple.private.iokit.nvram-csr because it's capable of adding new pre-approved kernel extensions which need to be saved also in NVRAM in a kext-allowed-teams key.
Upon downloading an application or file, specific macOS applications such as web browsers or email clients attach an extended file attribute, commonly known as the "quarantine flag," to the downloaded file. This attribute acts as a security measure to mark the file as coming from an untrusted source (the internet), and potentially carrying risks. However, not all applications attach this attribute, for instance, common BitTorrent client software usually bypasses this process.
The presence of a quarantine flag signals macOS's Gatekeeper security feature when a user attempts to execute the file.
In the case where the quarantine flag is not present (as with files downloaded via some BitTorrent clients), Gatekeeper's checks may not be performed. Thus, users should exercise caution when opening files downloaded from less secure or unknown sources.
코드 서명의 유효성을 확인하는 것은 리소스 집약적인 프로세스로, 코드와 모든 번들 리소스의 암호화된 해시를 생성하는 것을 포함합니다. 또한, 인증서 유효성 확인은 발급 후 취소되었는지 확인하기 위해 Apple의 서버에 온라인 확인을 수행하는 것을 포함합니다. 이러한 이유로, 앱이 실행될 때마다 전체 코드 서명 및 인증 확인을 실행하는 것은 비현실적입니다.
따라서 이러한 확인은 격리된 속성을 가진 앱을 실행할 때만 수행됩니다.
이 속성은 파일을 생성/다운로드하는 애플리케이션에 의해 설정되어야 합니다.
그러나 샌드박스된 파일은 생성하는 모든 파일에 이 속성이 설정됩니다. 비샌드박스 앱은 스스로 설정할 수 있거나, 시스템이 생성된 파일에 com.apple.quarantine 확장 속성을 설정하도록 Info.plist에서 LSFileQuarantineEnabled 키를 지정할 수 있습니다.
Moreover, all files created by a process calling qtn_proc_apply_to_self are quarantined. Or the API qtn_file_apply_to_path adds the quarantine attribute to a specified file path.
It's possible to check its status and enable/disable (root required) with:
You can also find if a file has the quarantine extended attribute with: 당신은 또한 파일에 격리 확장 속성이 있는지 확인할 수 있습니다:
확인하십시오 값 확장된 속성 및 다음과 같이 격리 속성을 작성한 앱을 찾으십시오:
실제로 프로세스는 "생성한 파일에 격리 플래그를 설정할 수 있습니다" (저는 이미 생성된 파일에 USER_APPROVED 플래그를 적용해 보았지만 적용되지 않았습니다):
```c #include #include
enum qtn_flags { QTN_FLAG_DOWNLOAD = 0x0001, QTN_FLAG_SANDBOX = 0x0002, QTN_FLAG_HARD = 0x0004, QTN_FLAG_USER_APPROVED = 0x0040, };
#define qtn_proc_alloc _qtn_proc_alloc #define qtn_proc_apply_to_self _qtn_proc_apply_to_self #define qtn_proc_free _qtn_proc_free #define qtn_proc_init _qtn_proc_init #define qtn_proc_init_with_self _qtn_proc_init_with_self #define qtn_proc_set_flags _qtn_proc_set_flags #define qtn_file_alloc _qtn_file_alloc #define qtn_file_init_with_path _qtn_file_init_with_path #define qtn_file_free _qtn_file_free #define qtn_file_apply_to_path _qtn_file_apply_to_path #define qtn_file_set_flags _qtn_file_set_flags #define qtn_file_get_flags _qtn_file_get_flags #define qtn_proc_set_identifier _qtn_proc_set_identifier
typedef struct _qtn_proc *qtn_proc_t; typedef struct _qtn_file *qtn_file_t;
int qtn_proc_apply_to_self(qtn_proc_t); void qtn_proc_init(qtn_proc_t); int qtn_proc_init_with_self(qtn_proc_t); int qtn_proc_set_flags(qtn_proc_t, uint32_t flags); qtn_proc_t qtn_proc_alloc(); void qtn_proc_free(qtn_proc_t); qtn_file_t qtn_file_alloc(void); void qtn_file_free(qtn_file_t qf); int qtn_file_set_flags(qtn_file_t qf, uint32_t flags); uint32_t qtn_file_get_flags(qtn_file_t qf); int qtn_file_apply_to_path(qtn_file_t qf, const char *path); int qtn_file_init_with_path(qtn_file_t qf, const char path); int qtn_proc_set_identifier(qtn_proc_t qp, const char bundleid);
int main() {
qtn_proc_t qp = qtn_proc_alloc(); qtn_proc_set_identifier(qp, "xyz.hacktricks.qa"); qtn_proc_set_flags(qp, QTN_FLAG_DOWNLOAD | QTN_FLAG_USER_APPROVED); qtn_proc_apply_to_self(qp); qtn_proc_free(qp);
FILE *fp; fp = fopen("thisisquarantined.txt", "w+"); fprintf(fp, "Hello Quarantine\n"); fclose(fp);
return 0;
}
모든 격리된 파일을 찾으려면:
격리 정보는 **~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2**에 의해 LaunchServices에서 관리되는 중앙 데이터베이스에 저장되어 GUI가 파일 출처에 대한 데이터를 얻을 수 있도록 합니다. 또한, 이는 출처를 숨기려는 애플리케이션에 의해 덮어쓸 수 있습니다. 또한, 이는 LaunchServices API를 통해 수행될 수 있습니다.
libquarantine.dylb
이 라이브러리는 확장 속성 필드를 조작할 수 있는 여러 기능을 내보냅니다.
qtn_file_* API는 파일 격리 정책을 다루고, qtn_proc_* API는 프로세스(프로세스에 의해 생성된 파일)에 적용됩니다. 내보내지 않은 __qtn_syscall_quarantine* 함수는 정책을 적용하는 함수로, "Quarantine"을 첫 번째 인수로 하여 mac_syscall을 호출하여 요청을 Quarantine.kext로 보냅니다.
Quarantine.kext
커널 확장은 시스템의 커널 캐시를 통해서만 사용할 수 있습니다. 그러나 Kernel Debug Kit를 https://developer.apple.com/에서 다운로드할 수 있으며, 이 키트에는 확장의 기호화된 버전이 포함되어 있습니다.
이 Kext는 MACF를 통해 여러 호출을 후킹하여 모든 파일 생애 주기 이벤트를 가로채기 위해 사용됩니다: 생성, 열기, 이름 바꾸기, 하드 링크... 심지어 setxattr를 사용하여 com.apple.quarantine 확장 속성을 설정하지 못하도록 합니다.
또한 몇 가지 MIB를 사용합니다:
security.mac.qtn.sandbox_enforce: Sandbox와 함께 격리 강제 적용
security.mac.qtn.user_approved_exec: 격리된 프로세스는 승인된 파일만 실행할 수 있습니다
XProtect는 macOS에 내장된 안티멀웨어 기능입니다. XProtect는 애플리케이션이 처음 실행되거나 수정될 때 알려진 멀웨어 및 안전하지 않은 파일 유형의 데이터베이스와 비교하여 확인합니다. Safari, Mail 또는 Messages와 같은 특정 앱을 통해 파일을 다운로드하면 XProtect가 자동으로 파일을 스캔합니다. 데이터베이스에 있는 알려진 멀웨어와 일치하면 XProtect는 파일 실행을 차단하고 위협에 대해 경고합니다.
XProtect 데이터베이스는 Apple에 의해 정기적으로 업데이트되며, 이러한 업데이트는 자동으로 다운로드되어 Mac에 설치됩니다. 이를 통해 XProtect는 항상 최신 알려진 위협에 대해 최신 상태를 유지합니다.
그러나 XProtect는 완전한 기능을 갖춘 안티바이러스 솔루션이 아닙니다. 특정 알려진 위협 목록만 확인하며, 대부분의 안티바이러스 소프트웨어처럼 접근 시 스캔을 수행하지 않습니다.
최신 XProtect 업데이트에 대한 정보를 얻으려면 다음을 실행하십시오:
XProtect는 /Library/Apple/System/Library/CoreServices/XProtect.bundle에 위치하며, 이 번들 안에는 XProtect가 사용하는 정보가 있습니다:
XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist: 해당 cdhashes를 가진 코드가 레거시 권한을 사용할 수 있도록 허용합니다.
XProtect.bundle/Contents/Resources/XProtect.meta.plist: BundleID 및 TeamID를 통해 로드가 금지된 플러그인 및 확장 목록 또는 최소 버전을 나타냅니다.
XProtect.bundle/Contents/Resources/XProtect.yara: 악성 소프트웨어를 탐지하기 위한 Yara 규칙입니다.
XProtect.bundle/Contents/Resources/gk.db: 차단된 애플리케이션과 TeamID의 해시가 포함된 SQLite3 데이터베이스입니다.
**/Library/Apple/System/Library/CoreServices/XProtect.app**에 XProtect와 관련된 또 다른 앱이 있지만, 이는 Gatekeeper 프로세스와 관련이 없습니다.
Gatekeeper는 애플리케이션을 실행할 때마다 실행되지 않습니다. 오직 AppleMobileFileIntegrity (AMFI)만이 Gatekeeper에 의해 이미 실행되고 검증된 앱을 실행할 때 실행 가능한 코드 서명을 확인합니다.
따라서 이전에는 앱을 실행하여 Gatekeeper로 캐시한 후, 애플리케이션의 실행 불가능한 파일(예: Electron asar 또는 NIB 파일)을 수정하고, 다른 보호 장치가 없다면 애플리케이션이 악성 추가 사항과 함께 실행되었습니다.
하지만 이제는 macOS가 애플리케이션 번들 내의 파일 수정**을 방지하기 때문에 이는 불가능합니다. 따라서 Dirty NIB 공격을 시도하면, 앱을 실행하여 Gatekeeper로 캐시한 후 번들을 수정할 수 없기 때문에 더 이상 악용할 수 없음을 알게 될 것입니다. 예를 들어 Contents 디렉토리의 이름을 NotCon으로 변경하고(악용에서 지시된 대로) 앱의 주요 바이너리를 실행하여 Gatekeeper로 캐시하면 오류가 발생하고 실행되지 않습니다.
Gatekeeper를 우회하는 방법(사용자가 무언가를 다운로드하고 Gatekeeper가 이를 허용하지 않아야 할 때 실행하도록 만드는 것)은 macOS의 취약점으로 간주됩니다. 과거에 Gatekeeper를 우회할 수 있게 해준 기술에 할당된 CVE는 다음과 같습니다:
Archive Utility를 사용하여 추출할 경우, 경로가 886자를 초과하는 파일은 com.apple.quarantine 확장 속성을 받지 않는 것이 관찰되었습니다. 이 상황은 의도치 않게 해당 파일이 Gatekeeper의 보안 검사를 우회할 수 있게 합니다.
자세한 내용은 원본 보고서를 확인하세요.
Automator로 생성된 애플리케이션의 경우, 실행에 필요한 정보는 application.app/Contents/document.wflow에 있으며 실행 파일에는 없습니다. 실행 파일은 Automator Application Stub이라는 일반적인 Automator 바이너리입니다.
따라서 application.app/Contents/MacOS/Automator\ Application\ Stub가 시스템 내의 다른 Automator Application Stub을 가리키는 심볼릭 링크로 설정할 수 있으며, 그러면 document.wflow(당신의 스크립트) 안의 내용을 Gatekeeper를 트리거하지 않고 실행합니다.
예상 위치: /System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub
자세한 내용은 원본 보고서를 확인하세요.
이 우회에서는 application.app/Contents에서 압축을 시작하는 애플리케이션으로 zip 파일이 생성되었습니다. 따라서 quarantine attr는 application.app/Contents의 모든 파일에 적용되었지만, application.app에는 적용되지 않았습니다. Gatekeeper가 확인하는 것은 application.app이었기 때문에, application.app이 트리거될 때 quarantine 속성이 없었기 때문에 Gatekeeper가 우회되었습니다.
Check the original report for more information.
구성 요소가 다르더라도 이 취약점의 악용은 이전 것과 매우 유사합니다. 이 경우 **application.app/Contents**에서 Apple Archive를 생성하므로 **application.app**은 Archive Utility에 의해 압축 해제될 때 격리 속성을 받지 않습니다.
Check the original report for more information.
ACL **writeextattr**는 파일에 속성을 쓰는 것을 방지하는 데 사용할 수 있습니다:
Moreover, AppleDouble 파일 형식은 ACE를 포함하여 파일을 복사합니다.
소스 코드에서 **com.apple.acl.text**라는 xattr에 저장된 ACL 텍스트 표현이 압축 해제된 파일의 ACL로 설정될 것임을 확인할 수 있습니다. 따라서, ACL이 다른 xattr의 기록을 방지하는 애플리케이션을 AppleDouble 파일 형식으로 zip 파일로 압축했다면... 격리 xattr는 애플리케이션에 설정되지 않았습니다:
자세한 정보는 원본 보고서를 확인하세요.
이것은 AppleArchives로도 악용될 수 있습니다:
구글 크롬이 다운로드된 파일에 격리 속성을 설정하지 않는 것으로 발견되었습니다. 이는 일부 macOS 내부 문제 때문입니다.
AppleDouble 파일 형식은 ._로 시작하는 별도의 파일에 파일의 속성을 저장하며, 이는 macOS 기계 간에 파일 속성을 복사하는 데 도움을 줍니다. 그러나 AppleDouble 파일을 압축 해제한 후 ._로 시작하는 파일이 격리 속성을 부여받지 않는 것으로 나타났습니다.
파일을 생성할 수 있는 것은 Gatekeeper를 우회할 수 있었습니다. 이 요령은 AppleDouble 이름 규칙을 사용하여 DMG 파일 애플리케이션을 생성하고, 이 숨겨진 파일에 대한 심볼릭 링크로 보이는 파일을 생성하는 것이었습니다. dmg 파일이 실행될 때, 쿼런틴 속성이 없기 때문에 Gatekeeper를 우회하게 됩니다.
앱이 포함된 디렉토리를 생성합니다.
앱에 uchg를 추가합니다.
앱을 tar.gz 파일로 압축합니다.
tar.gz 파일을 피해자에게 보냅니다.
피해자가 tar.gz 파일을 열고 앱을 실행합니다.
Gatekeeper는 앱을 확인하지 않습니다.
".app" 번들에 격리 xattr가 추가되지 않으면, 실행할 때 Gatekeeper가 트리거되지 않습니다.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
