macOS xpc_connection_get_audit_token Attack

Reading time: 10 minutes

Για περισσότερες πληροφορίες ελέγξτε την αρχική ανάρτηση: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Αυτή είναι μια περίληψη:

Mach Messages Basic Info

Αν δεν ξέρετε τι είναι τα Mach Messages, αρχίστε να ελέγχετε αυτή τη σελίδα:

macOS IPC - Inter Process Communication

Π προς το παρόν θυμηθείτε ότι (ορισμός από εδώ):
Τα mach messages αποστέλλονται μέσω ενός mach port, το οποίο είναι ένα κανάλι επικοινωνίας με έναν δέκτη και πολλούς αποστολείς που είναι ενσωματωμένο στον πυρήνα mach. Πολλές διαδικασίες μπορούν να στείλουν μηνύματα σε ένα mach port, αλλά σε οποιαδήποτε στιγμή μόνο μία διαδικασία μπορεί να διαβάσει από αυτό. Όπως και οι περιγραφείς αρχείων και οι υποδοχές, τα mach ports κατανέμονται και διαχειρίζονται από τον πυρήνα και οι διαδικασίες βλέπουν μόνο έναν ακέραιο αριθμό, τον οποίο μπορούν να χρησιμοποιήσουν για να υποδείξουν στον πυρήνα ποια από τα mach ports τους θέλουν να χρησιμοποιήσουν.

XPC Connection

Αν δεν ξέρετε πώς να καθιερώσετε μια XPC σύνδεση, ελέγξτε:

macOS XPC

Vuln Summary

Αυτό που είναι ενδιαφέρον να γνωρίζετε είναι ότι η αφαίρεση του XPC είναι μια σύνδεση ένα προς ένα, αλλά βασίζεται σε μια τεχνολογία που μπορεί να έχει πολλούς αποστολείς, οπότε:

• Τα mach ports είναι ένας δέκτης, πολλοί αποστολείς.
• Το audit token μιας XPC σύνδεσης είναι το audit token που αντιγράφεται από το πιο πρόσφατα ληφθέν μήνυμα.
• Η απόκτηση του audit token μιας XPC σύνδεσης είναι κρίσιμη για πολλές ελέγχους ασφαλείας.

Αν και η προηγούμενη κατάσταση ακούγεται υποσχόμενη, υπάρχουν ορισμένα σενάρια όπου αυτό δεν θα προκαλέσει προβλήματα (από εδώ):

• Τα audit tokens χρησιμοποιούνται συχνά για έναν έλεγχο εξουσιοδότησης για να αποφασιστεί αν θα γίνει αποδεκτή μια σύνδεση. Καθώς αυτό συμβαίνει χρησιμοποιώντας ένα μήνυμα προς την υπηρεσία, δεν έχει καθιερωθεί ακόμη καμία σύνδεση. Περισσότερα μηνύματα σε αυτό το port θα αντιμετωπιστούν απλώς ως επιπλέον αιτήματα σύνδεσης. Έτσι, οποιοσδήποτε έλεγχος πριν από την αποδοχή μιας σύνδεσης δεν είναι ευάλωτος (αυτό σημαίνει επίσης ότι μέσα στο -listener:shouldAcceptNewConnection: το audit token είναι ασφαλές). Επομένως, αναζητούμε XPC συνδέσεις που επαληθεύουν συγκεκριμένες ενέργειες.
• Οι χειριστές γεγονότων XPC διαχειρίζονται συγχρονισμένα. Αυτό σημαίνει ότι ο χειριστής γεγονότος για ένα μήνυμα πρέπει να ολοκληρωθεί πριν κληθεί για το επόμενο, ακόμη και σε ταυτόχρονες ουρές εκτέλεσης. Έτσι, μέσα σε έναν χειριστή γεγονότος XPC, το audit token δεν μπορεί να αντικατασταθεί από άλλα κανονικά (μη απαντητικά!) μηνύματα.

Δύο διαφορετικές μέθοδοι που μπορεί να είναι εκμεταλλεύσιμες:

1. Variant1:

• Εκμετάλλευση συνδέεται με την υπηρεσία A και την υπηρεσία B
• Η υπηρεσία B μπορεί να καλέσει μια προνομιακή λειτουργία στην υπηρεσία A που ο χρήστης δεν μπορεί
• Η υπηρεσία A καλεί xpc_connection_get_audit_token ενώ δεν είναι μέσα στον χειριστή γεγονότων για μια σύνδεση σε μια dispatch_async.
• Έτσι, ένα διαφορετικό μήνυμα θα μπορούσε να αντικαταστήσει το Audit Token επειδή αποστέλλεται ασύγχρονα έξω από τον χειριστή γεγονότων.
• Η εκμετάλλευση περνά στην υπηρεσία B το δικαίωμα ΑΠΟΣΤΟΛΗΣ στην υπηρεσία A.
• Έτσι, η svc B θα είναι στην πραγματικότητα αποστέλλοντας τα μηνύματα στην υπηρεσία A.
• Η εκμετάλλευση προσπαθεί να καλέσει την προνομιακή ενέργεια. Σε μια RC η svc A ελέγχει την εξουσιοδότηση αυτής της ενέργειας ενώ η svc B αντικαθιστά το Audit token (δίνοντας στην εκμετάλλευση πρόσβαση για να καλέσει την προνομιακή ενέργεια).

2. Variant 2:

• Η υπηρεσία B μπορεί να καλέσει μια προνομιακή λειτουργία στην υπηρεσία A που ο χρήστης δεν μπορεί
• Η εκμετάλλευση συνδέεται με την υπηρεσία A που στέλνει στην εκμετάλλευση ένα μήνυμα που αναμένει απάντηση σε μια συγκεκριμένη θύρα απάντησης.
• Η εκμετάλλευση στέλνει στην υπηρεσία B ένα μήνυμα περνώντας αυτή τη θύρα απάντησης.
• Όταν η υπηρεσία B απαντά, στέλνει το μήνυμα στην υπηρεσία A, ενώ η εκμετάλλευση στέλνει ένα διαφορετικό μήνυμα στην υπηρεσία A προσπαθώντας να φτάσει σε μια προνομιακή λειτουργία και αναμένοντας ότι η απάντηση από την υπηρεσία B θα αντικαταστήσει το Audit token τη σωστή στιγμή (Race Condition).

Variant 1: calling xpc_connection_get_audit_token outside of an event handler

Σενάριο:

• Δύο mach υπηρεσίες A και B στις οποίες μπορούμε και οι δύο να συνδεθούμε (βάσει του προφίλ sandbox και των ελέγχων εξουσιοδότησης πριν από την αποδοχή της σύνδεσης).
• A πρέπει να έχει έναν έλεγχο εξουσιοδότησης για μια συγκεκριμένη ενέργεια που μπορεί να περάσει η B (αλλά η εφαρμογή μας δεν μπορεί).
• Για παράδειγμα, αν η B έχει κάποιες δικαιοδοσίες ή εκτελείται ως root, μπορεί να της επιτραπεί να ζητήσει από την A να εκτελέσει μια προνομιακή ενέργεια.
• Για αυτόν τον έλεγχο εξουσιοδότησης, η A αποκτά το audit token ασύγχρονα, για παράδειγμα καλώντας xpc_connection_get_audit_token από dispatch_async.

Αυτό συνέβη με A ως smd και B ως diagnosticd. Η λειτουργία SMJobBless από το smb μπορεί να χρησιμοποιηθεί για να εγκαταστήσει ένα νέο προνομιακό βοηθητικό εργαλείο (ως root). Αν μια διαδικασία που εκτελείται ως root επικοινωνήσει με smd, δεν θα εκτελούνται άλλοι έλεγχοι.

Επομένως, η υπηρεσία B είναι diagnosticd επειδή εκτελείται ως root και μπορεί να χρησιμοποιηθεί για να παρακολουθήσει μια διαδικασία, οπότε μόλις ξεκινήσει η παρακολούθηση, θα στέλνει πολλαπλά μηνύματα ανά δευτερόλεπτο.

Για να εκτελέσετε την επίθεση:

1. Ξεκινήστε μια σύνδεση με την υπηρεσία που ονομάζεται smd χρησιμοποιώντας το πρότυπο XPC.
2. Δημιουργήστε μια δευτερεύουσα σύνδεση με diagnosticd. Αντίθετα με τη φυσιολογική διαδικασία, αντί να δημιουργήσετε και να στείλετε δύο νέες mach ports, το δικαίωμα αποστολής του πελάτη αντικαθίσταται με ένα αντίγραφο του δικαιώματος αποστολής που σχετίζεται με τη σύνδεση smd.
3. Ως αποτέλεσμα, τα μηνύματα XPC μπορούν να αποστέλλονται στο diagnosticd, αλλά οι απαντήσεις από το diagnosticd ανακατευθύνονται στο smd. Για το smd, φαίνεται ότι τα μηνύματα και από τον χρήστη και από το diagnosticd προέρχονται από την ίδια σύνδεση.

4. Το επόμενο βήμα περιλαμβάνει την εντολή στο diagnosticd να ξεκινήσει την παρακολούθηση μιας επιλεγμένης διαδικασίας (πιθανώς της δικής του του χρήστη). Ταυτόχρονα, μια πλημμύρα κανονικών 1004 μηνυμάτων αποστέλλεται στο smd. Ο σκοπός εδώ είναι να εγκαταστήσει ένα εργαλείο με αυξημένα προνόμια.
5. Αυτή η ενέργεια προκαλεί μια race condition μέσα στη λειτουργία handle_bless. Ο χρόνος είναι κρίσιμος: η κλήση της συνάρτησης xpc_connection_get_pid πρέπει να επιστρέψει το PID της διαδικασίας του χρήστη (καθώς το προνομιακό εργαλείο βρίσκεται στο πακέτο εφαρμογής του χρήστη). Ωστόσο, η συνάρτηση xpc_connection_get_audit_token, συγκεκριμένα μέσα στη υπορουτίνα connection_is_authorized, πρέπει να αναφέρεται στο audit token που ανήκει στο diagnosticd.

Variant 2: reply forwarding

Σε ένα περιβάλλον XPC (Διαδικασία-Διαδικασία Επικοινωνίας), αν και οι χειριστές γεγονότων δεν εκτελούνται ταυτόχρονα, η διαχείριση των μηνυμάτων απάντησης έχει μια μοναδική συμπεριφορά. Συγκεκριμένα, υπάρχουν δύο διακριτές μέθοδοι για την αποστολή μηνυμάτων που αναμένουν απάντηση:

1. xpc_connection_send_message_with_reply: Εδώ, το μήνυμα XPC λαμβάνεται και επεξεργάζεται σε μια καθορισμένη ουρά.
2. xpc_connection_send_message_with_reply_sync: Αντίθετα, σε αυτή τη μέθοδο, το μήνυμα XPC λαμβάνεται και επεξεργάζεται στην τρέχουσα ουρά εκτέλεσης.

Αυτή η διάκριση είναι κρίσιμη επειδή επιτρέπει την πιθανότητα τα πακέτα απάντησης να αναλύονται ταυτόχρονα με την εκτέλεση ενός χειριστή γεγονότων XPC. Σημειωτέον, ενώ το _xpc_connection_set_creds εφαρμόζει κλείδωμα για να προστατεύσει από την μερική αντικατάσταση του audit token, δεν επεκτείνει αυτή την προστασία σε ολόκληρο το αντικείμενο σύνδεσης. Ως εκ τούτου, αυτό δημιουργεί μια ευπάθεια όπου το audit token μπορεί να αντικατασταθεί κατά τη διάρκεια της περιόδου μεταξύ της ανάλυσης ενός πακέτου και της εκτέλεσης του χειριστή γεγονότων του.

Για να εκμεταλλευτείτε αυτή την ευπάθεια, απαιτείται η εξής ρύθμιση:

• Δύο mach υπηρεσίες, αναφερόμενες ως A και B, και οι δύο μπορούν να καθιερώσουν μια σύνδεση.
• Η υπηρεσία A θα πρέπει να περιλαμβάνει έναν έλεγχο εξουσιοδότησης για μια συγκεκριμένη ενέργεια που μόνο η B μπορεί να εκτελέσει (η εφαρμογή του χρήστη δεν μπορεί).
• Η υπηρεσία A θα πρέπει να στείλει ένα μήνυμα που αναμένει απάντηση.
• Ο χρήστης μπορεί να στείλει ένα μήνυμα στην B στο οποίο θα απαντήσει.

Η διαδικασία εκμετάλλευσης περιλαμβάνει τα εξής βήματα:

1. Περιμένετε να στείλει η υπηρεσία A ένα μήνυμα που αναμένει απάντηση.
2. Αντί να απαντήσετε απευθείας στην A, η θύρα απάντησης καταλαμβάνεται και χρησιμοποιείται για να στείλει ένα μήνυμα στην υπηρεσία B.
3. Στη συνέχεια, αποστέλλεται ένα μήνυμα που περιλαμβάνει την απαγορευμένη ενέργεια, με την προσδοκία ότι θα επεξεργαστεί ταυτόχρονα με την απάντηση από την B.

Παρακάτω είναι μια οπτική αναπαράσταση του περιγραφέντος σεναρίου επίθεσης:

 (1) (1) (1) (1) (1) (1).png)

Discovery Problems

• Δυσκολίες στην Εύρεση Περιπτώσεων: Η αναζήτηση για περιπτώσεις χρήσης του xpc_connection_get_audit_token ήταν δύσκολη, τόσο στατικά όσο και δυναμικά.
• Μεθοδολογία: Χρησιμοποιήθηκε το Frida για να συνδεθεί η συνάρτηση xpc_connection_get_audit_token, φιλτράροντας κλήσεις που δεν προέρχονται από χειριστές γεγονότων. Ωστόσο, αυτή η μέθοδος περιορίστηκε στη συνδεδεμένη διαδικασία και απαιτούσε ενεργή χρήση.
• Εργαλεία Ανάλυσης: Χρησιμοποιήθηκαν εργαλεία όπως IDA/Ghidra για την εξέταση προσβάσιμων mach υπηρεσιών, αλλά η διαδικασία ήταν χρονοβόρα, περιπλέκεται από κλήσεις που περιλαμβάνουν την κοινή μνήμη dyld.
• Περιορισμοί Σενάριων: Οι προσπάθειες να αυτοματοποιηθούν οι αναλύσεις για κλήσεις προς xpc_connection_get_audit_token από μπλοκ dispatch_async εμποδίστηκαν από τις πολυπλοκότητες στην ανάλυση μπλοκ και τις αλληλεπιδράσεις με την κοινή μνήμη dyld.

The fix

• Αναφερόμενα Ζητήματα: Υποβλήθηκε αναφορά στην Apple που περιγράφει τα γενικά και συγκεκριμένα ζητήματα που βρέθηκαν στο smd.
• Απάντηση της Apple: Η Apple αντιμετώπισε το ζήτημα στο smd αντικαθιστώντας το xpc_connection_get_audit_token με το xpc_dictionary_get_audit_token.
• Φύση της Διόρθωσης: Η συνάρτηση xpc_dictionary_get_audit_token θεωρείται ασφαλής καθώς ανακτά το audit token απευθείας από το mach μήνυμα που σχετίζεται με το ληφθέν μήνυμα XPC. Ωστόσο, δεν είναι μέρος του δημόσιου API, παρόμοια με το xpc_connection_get_audit_token.
• Απουσία Ευρύτερης Διόρθωσης: Παραμένει ασαφές γιατί η Apple δεν υλοποίησε μια πιο εκτενή διόρθωση, όπως η απόρριψη μηνυμάτων που δεν ευθυγραμμίζονται με το αποθηκευμένο audit token της σύνδεσης. Η πιθανότητα νόμιμων αλλαγών audit token σε ορισμένα σενάρια (π.χ. χρήση setuid) μπορεί να είναι παράγοντας.
• Τρέχουσα Κατάσταση: Το ζήτημα παραμένει στο iOS 17 και macOS 14, αποτελώντας πρόκληση για όσους επιδιώκουν να το εντοπίσουν και να το κατανοήσουν.