Bảo mật macOS MDM: Lỗ hổng enrollment dựa trên serial number

• Giảng viên: Marcell Molnár
• Thời gian phát biểu (ước tính): ~34:48
• Mục tiêu chính: Trình bày về lỗ hổng bảo mật nghiêm trọng trong quy trình MDM enrollment của macOS, cho phép tấn công dựa trên serial number của thiết bị
• Kiến thức tiên quyết: Hiểu biết cơ bản về MDM (Mobile Device Management), macOS, reverse engineering

Tóm tắt các ý trọng tâm

• Lỗ hổng cho phép attacker giả mạo thiết bị Apple chỉ bằng cách sử dụng serial number (10-12 ký tự)
• Apple Business Manager và MDM enrollment chỉ xác thực dựa trên serial number, không có cơ chế bảo mật bổ sung
• Khoảng 60% trường hợp không có SSO, cho phép enrollment trực tiếp
• Có thể thu thập thông tin nhạy cảm: Wi-Fi passwords, credentials, API keys, và thậm chí root access trên hàng chục nghìn thiết bị
• Apple đã biết về vấn đề này ít nhất 8 năm (từ bài báo của Duo Security)
• Các biện pháp phòng ngừa chính: bật SSO, kiểm soát scope của credentials, không embed API keys trong shell scripts

Mục lục theo thời gian

1. [00:03-02:52] Giới thiệu và động lực nghiên cứu
2. [02:52-06:04] Phát hiện ban đầu: Phantom device từ Brazil
3. [06:04-09:32] Tái tạo lỗ hổng với hackintosh VM
4. [09:32-13:32] Reverse engineering quy trình MDM
5. [13:32-17:10] Weaponization và bypass techniques
6. [17:10-23:28] Phân loại “prizes” (thông tin thu được)
7. [23:28-25:48] Jackpot: Root access thông qua MDM API keys
8. [25:48-30:01] Biện pháp phòng ngừa và khuyến nghị
9. [30:01-34:48] Q&A session

Chi tiết bài giảng (theo thời gian)

[00:03-02:52] Giới thiệu và bối cảnh

• Ý tưởng chính:
  • So sánh lỗ hổng như một “slot machine” - spin và có thể win các thông tin có giá trị
  • Giảng viên từ Hungary, làm việc tại Form 3 (công ty fintech UK)
  • Jackpot lớn nhất: root access trên 45,000 thiết bị cùng lúc
• Cấu trúc bài thuyết trình:
  1. Journey và động lực nghiên cứu
  2. Hardcore reverse engineering
  3. Prizes và exploitation

[02:52-06:04] Phát hiện ban đầu: Phantom device alert

• Ý tưởng chính:
  • Alert từ SOCK: một thiết bị đăng nhập từ Brazil
  • Thiết bị gốc vẫn online ở Germany
  • Xuất hiện “phantom device” - bản duplicate trong MDM
  • Điểm chung duy nhất: serial number
• Khái niệm quan trọng:
  • Apple Business Manager (ABM): Registry tự động cho các thiết bị Apple mua từ Apple hoặc authorized reseller
  • Zero-touch enrollment: Thiết bị tự động enroll vào MDM khi unbox lần đầu, không cần cài đặt thủ công
• Phát hiện then chốt:
  • MDM enrollment chỉ phụ thuộc vào serial number
  • Serial number không phải thông tin bí mật (in trên hộp, có trong manifests, GitHub)

[06:04-09:32] Tái tạo lỗ hổng

• Công cụ sử dụng:
  • OSX-KVM project (Kolia trên GitHub) - tạo macOS VM trên Ubuntu
  • OpenCore - boot disc compiler
• Quy trình thử nghiệm:
  1. Tạo VM macOS
  2. Edit config với serial number của thiết bị bị compromise
  3. Recompile OpenCore
  4. Boot VM → tự động enroll vào MDM
• Kết quả:
  • Thành công tạo thêm phantom device
  • Xác nhận: chỉ cần serial number để enroll
  • May mắn: MDM chỉ có Adobe Acrobat free version trong self-service
• Insight:
  • Nhiều công ty có thể deploy thông tin nhạy cảm hơn qua MDM
  • Cần nghiên cứu sâu hơn về mức độ rủi ro

[09:32-13:32] Reverse engineering quy trình MDM

• Cấu trúc serial number (format cũ, đến 2021):
  • 10-12 ký tự alphanumeric
  • Format cố định: [Location][Year][Week][Sequential Number][Model]
  • Manufacturing location: chỉ 2 variants
  • Rất dễ generate serial numbers hợp lệ
• Ba thành phần chính trong MDM process:
  1. Apple device (mới unbox)
  2. iprofiles.apple.com (Apple Business Manager API)
  3. Company’s MDM server

• Message flow:

  Bước 1: Device → Apple Business Manager

  • Gửi JSON nhỏ chỉ chứa serial number
  • Response:
    • Empty nếu device không enroll
    • Dictionary lớn với thông tin công ty nếu enrolled (support phone, email, MDM server address)

  Bước 2: Device → MDM Server

  • Hai endpoints khả dụng:
    • Web-based mới (B64 encoded payload)
    • XML-based cũ (same payload, XML format)
  • Payload chứa: hardware info, serial number, UID
  • Chỉ serial number được sử dụng thực sự

  Bước 3: MDM Response

  • Nếu có SSO: bị block (~40% trường hợp)
  • Không SSO: enrollment thành công (~60% trường hợp)
• Tài liệu tham khảo quan trọng:
  • “MDM Me Maybe” article của Duo Security (8 năm trước)
  • Là nguồn thông tin duy nhất về process này trên internet

[13:32-17:10] Weaponization và bypass kỹ thuật

• Chiến lược weaponization:
  1. Generate hoặc scrape serial numbers từ GitHub
  2. Poll Apple API
  3. Thu thập MDM server addresses
  4. Thử enroll
• Kỹ thuật instrumentation:
  • Sử dụng LLDB để instrument profiles command
  • Swap serial number trong memory
  • Capture messages và MDM addresses
• Roadblock 1: Client-side rate limiting
  • Vấn đề: Script dừng sau 10 serial numbers
  • Nguyên nhân: Profile enrollment dates được lưu trong file, giới hạn 10 dòng
  • Bypass: rm /var/db/ConfigurationProfiles/Settings/.profilesAreInstalled (client-side validation!)
  • Edge case: nhớ tăng year khi chuyển năm mới
• Roadblock 2: SSO protection
  • Bypass technique: Exploit endpoint discrepancy
  • XML response có thể chứa 2 URLs khác nhau (new & legacy)
  • Edit enrollment profile on disk, swap URL mới → URL cũ
  • Legacy endpoint có thể không có SSO (~60% success rate)
• Lưu ý kỹ thuật:
  • Configuration có thể hidden trong MDM settings
  • Admins có thể quên secure legacy endpoint khi migrate

[17:10-23:28] Phân loại “prizes” - Tier system

Tier 1: Basic information (luôn có)

• Company information (không cần bypass SSO):
  • Support phone number
  • Email addresses
  • Person phụ trách MDM
  • Office locations
  • MDM server address
• Configuration profiles (nếu bypass SSO hoặc không SSO):
  • Password policies
  • EDR agent info
  • VPN certificates
  • Network passwords
  • Xảy ra với mọi enrollment
• Self-service applications:
  • Free software (thấp giá trị)
  • Licensed software (Microsoft Office, etc.)
  • Internal tools - mở attack surface mới
  • Custom company-developed tools
• Local administrator password:
  • Khi MDM agent install → tạo local account
  • Nếu admin sloppy: same password cho tất cả devices
  • DSCL transfers password in clear text → check Burp logs
  • Có thể reuse across all machines

Tier 2: Cooler prizes (cần kỹ thuật nâng cao)

• Wi-Fi passwords:
  • Vấn đề: VM không có wireless card → Apple từ chối install wireless profiles
  • Giải pháp: Reverse engineer profile installation process
  • Profiles được encrypted & signed với per-device certificate
  • Bypass: Hook NS dictionary function với LLDB
  • Dump password from memory trước khi rejection
  • Bug bounty: $50 cho network password từ California :)
• Credentials trong shell scripts:
  • Admins giải quyết problems ngoài MDM bằng custom shell scripts
  • Tìm thấy: Slack tokens, GitHub credentials, SharePoint API keys, AD/LDAP passwords
  • Root cause: Misconception về “closed ecosystem”
  • Reality: Rogue enrollment → unsafe environment → credentials exposed
• Ví dụ về shell script abuse:
  • MDM agent runs as root
  • Small mistakes → race conditions
  • Download to /tmp or risky copy operations
  • Users có thể trigger từ self-service
  • Reliable local privilege escalation

[23:28-25:48] JACKPOT: Root access via MDM API keys

• Kịch bản điển hình:
  • Admin hit brick wall với MDM capabilities
  • Can’t solve với shell scripts alone
  • Vendor FAQ suggests: “Put API key in shell script for MDM API access”
• Vulnerability chain:
  1. API key embedded trong shell script
  2. Shell script pushed qua MDM
  3. Rogue enrollment retrieves script
  4. Attacker obtains API key
• MDM API abuse:
  • Shout-out to co-author Magdalina
  • Mỗi MDM API có “reverse shell function” ẩn
  • Cho phép push one-liner shell scripts đến bất kỳ enrolled device nào
  • Result: Root access trên tất cả devices
• Vấn đề về scope:
  • Admins đôi khi restrict token scope
  • Nhưng: Black box nature → không nhận ra risk
  • Ngay cả read-only access cũng leak sensitive info (PII)
• Impact thực tế:
  • Giảng viên đạt: root access trên 45,000 devices simultaneously

[25:48-30:01] Biện pháp phòng ngừa và khuyến nghị

• Defense #0: Bật SSO (must-have)
  • Luôn enable SSO cho MDM enrollment
  • Kiểm tra documentation cho legacy endpoints
  • Ensure SSO extends to cả hai endpoints (new & legacy)
  • Legacy endpoint có thể dùng LDAP-based SSO thay vì “true SSO”
  • Rule: Turn on ALL checkboxes
• Defense #1: Credential management trong shell scripts
  • Mindset: Luôn assume credentials sẽ落vào tay users hoặc attackers
  • Think twice trước khi push
  • Reduce scope tối đa
  • Apply least privilege principle
  • Security review bởi in-house team
• Defense #2: Admin password policies
  • Sử dụng per-machine passwords thay vì single shared password
  • Tránh lateral movement từ red team
  • Remote attacker risk thấp hơn nhưng internal threat cao
• Defense #3: SSO cho self-service (separately)
  • Last line of defense
  • Nhiều abusable tools không phải trong profiles mà trong self-service
  • Highly recommended
• Defense #4: Local privilege escalation prevention
  • Shell scripts running as root → high risk
  • Common mistakes:
    • Download to /tmp
    • Risky copy operations
  • Race conditions → reliable local root exploit
  • Users trigger từ self-service
  • Red team có thể easily abuse
• Defense #5: MDM API key protection
  • NEVER put MDM’s own API key trong shell scripts
  • Nếu absolutely necessary:
    • Double-check scope restrictions
    • Verify không có abusable functions
    • Download vendor’s Postman collection
    • Test key capabilities yourself
  • Ngay cả read-only access exposes PII

[30:01-34:48] Q&A Session

• Q1: Legacy vs new endpoint differences?
  • A: Exact same end result và enrollment
  • Legacy primarily cho mobile/iPhone, new cho MacBooks
  • Vendor independent (per Apple MDM developer documentation)
• Q2: Chỉ cần serial number để enroll?
  • A: Đúng, không authentication khác
  • Duo Security reported 8 năm trước
  • Apple’s response: không provide thêm security, shift responsibility to vendor
  • “Phone book approach” - lookup MDM by serial number
  • Apple obfuscates process (different TCP protocol) nhưng server-side vẫn simple
• Q3: MDM protocol vulnerabilities?
  • A: Next research step
  • Plan: tạo scanner cho administrators
  • Đã report vulnerabilities cho MDM vendors (chưa disclose)
  • Gap: Apple assumes MDM vendor provides security, vendors assume Apple vets requests
  • Falls through the cracks

Phương pháp / Hệ thống được giải thích

Apple Business Manager + MDM Enrollment Flow

• Mục đích: Zero-touch device management cho organizations
• Components:
  1. Apple Business Manager (device registry)
  2. Company MDM server (on-prem hoặc SaaS)
  3. iprofiles.apple.com (Apple API)
  4. Device serial number (authentication token)
• Workflow:
  1. Company đăng ký ABM
  2. Devices tự động register khi mua
  3. Configure MDM server address trong ABM
  4. Device unbox → tự động connect → enroll
  5. Company logo hiện ngay khi boot
• Ưu điểm: User-friendly, automatic, không cần manual setup
• Nhược điểm: Security phụ thuộc hoàn toàn vào serial number secrecy
• Assumptions: Serial number là protected information (sai!)
• Constraints: Apple coi đây là phone book service, không thêm security layer

Serial Number Format (Pre-2021)

• Structure: [Loc][YY][WW][XXXX][Model]
  • Loc: Manufacturing location (2 variants)
  • YY: Year
  • WW: Week
  • XXXX: Sequential number
  • Model: 4 chars model identifier
• Weaknesses:
  • Rất predictable
  • Small key space
  • Dễ generate valid numbers
  • Public information (boxes, GitHub, manifests)

So sánh / Ưu nhược điểm

MDM Endpoint Comparison

Aspect	New (Web-based)	Legacy (XML-based)
Format	B64 encoded	XML
Primary use	MacBooks	Mobile/iPhone
SSO	Thường có	Có thể bypass
Security	LDAP hoặc modern SSO	Often LDAP-only
Risk	Medium	Higher (forgotten)

Scope Restriction Effectiveness

Pros của restricted scope:

• Giảm blast radius
• Limit damage potential

Cons/Limitations:

• Admins không realize ease of extraction
• Black box nature → false sense of security
• Read-only vẫn leak PII
• Attackers có thể chain với other vulns

Q&A / Hiểu lầm đã được làm rõ

• Q: Có cần Apple account để enroll không?
  • A: Không, chỉ cần serial number. Apple không provide additional security, shift responsibility to vendors [32:13-33:26]
• Q: Legacy và new endpoint có giống nhau không?
  • A: Exactly the same enrollment result. Chỉ khác format (XML vs B64). Vendor independent [31:09-32:06]
• Q: Apple có biết issue này không?
  • A: Có, ít nhất 8 năm. Duo Security reported, Apple declined to fix, coi như feature not bug [32:33-33:19]
• Hiểu lầm phổ biến: MDM là “closed ecosystem” an toàn
  • Reality: Rogue enrollment dễ dàng expose mọi thứ kể cả credentials trong scripts

Assignments / Hành động tiếp theo

Dành cho MDM Administrators:

1. Immediate actions:
   • Audit SSO configuration (both endpoints)
   • Review shell scripts cho embedded credentials
   • Check API key scopes trong scripts
   • Enable SSO cho self-service
2. Short-term:
   • Implement per-device admin passwords
   • Security review all custom scripts
   • Download vendor Postman collection, test API keys
   • Document endpoint configurations
3. Long-term:
   • Establish script review process
   • Regular security audits
   • Monitor MDM vendor security advisories
   • Consider scanner tools (upcoming from researcher)

Dành cho Security Researchers:

• Investigate MDM protocol vulnerabilities
• Test vendor implementations
• Develop automated scanning tools