macOS xpc_connection_get_audit_token Attack
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)
Για περισσότερες πληροφορίες, ελέγξτε την αρχική ανάρτηση: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Αυτή είναι μια περίληψη:
Αν δεν ξέρετε τι είναι τα Mach Messages, αρχίστε να ελέγχετε αυτή τη σελίδα:
macOS IPC - Inter Process CommunicationΠ προς το παρόν θυμηθείτε ότι (ορισμός από εδώ): Τα Mach messages αποστέλλονται μέσω ενός mach port, το οποίο είναι ένα κανάλι επικοινωνίας με έναν μόνο δέκτη και πολλούς αποστολείς που έχει ενσωματωθεί στον πυρήνα mach. Πολλές διεργασίες μπορούν να στείλουν μηνύματα σε ένα mach port, αλλά σε οποιαδήποτε στιγμή μόνο μία διεργασία μπορεί να διαβάσει από αυτό. Όπως και οι περιγραφείς αρχείων και οι υποδοχές, τα mach ports κατανέμονται και διαχειρίζονται από τον πυρήνα και οι διεργασίες βλέπουν μόνο έναν ακέραιο αριθμό, τον οποίο μπορούν να χρησιμοποιήσουν για να υποδείξουν στον πυρήνα ποια από τα mach ports τους θέλουν να χρησιμοποιήσουν.
Αν δεν ξέρετε πώς να δημιουργηθεί μια XPC σύνδεση, ελέγξτε:
macOS XPCΑυτό που είναι ενδιαφέρον να γνωρίζετε είναι ότι η αφαίρεση του XPC είναι μια σύνδεση ένα προς ένα, αλλά βασίζεται σε μια τεχνολογία που μπορεί να έχει πολλούς αποστολείς, οπότε:
Τα mach ports είναι ένας μόνο δέκτης, πολλοί αποστολείς.
Το audit token μιας XPC σύνδεσης είναι το audit token του αντιγραμμένου από το πιο πρόσφατα ληφθέν μήνυμα.
Η απόκτηση του audit token μιας XPC σύνδεσης είναι κρίσιμη για πολλές ελέγχους ασφαλείας.
Αν και η προηγούμενη κατάσταση ακούγεται υποσχόμενη, υπάρχουν ορισμένα σενάρια όπου αυτό δεν θα προκαλέσει προβλήματα (από εδώ):
Τα audit tokens χρησιμοποιούνται συχνά για έναν έλεγχο εξουσιοδότησης για να αποφασιστεί αν θα γίνει αποδεκτή μια σύνδεση. Καθώς αυτό συμβαίνει χρησιμοποιώντας ένα μήνυμα προς την υπηρεσία port, δεν έχει δημιουργηθεί ακόμη σύνδεση. Περισσότερα μηνύματα σε αυτό το port θα αντιμετωπιστούν απλώς ως επιπλέον αιτήματα σύνδεσης. Έτσι, οποιοσδήποτε έλεγχος πριν από την αποδοχή μιας σύνδεσης δεν είναι ευάλωτος (αυτό σημαίνει επίσης ότι μέσα στο -listener:shouldAcceptNewConnection: το audit token είναι ασφαλές). Επομένως, αναζητούμε XPC συνδέσεις που επαληθεύουν συγκεκριμένες ενέργειες.
Οι χειριστές γεγονότων XPC διαχειρίζονται συγχρονισμένα. Αυτό σημαίνει ότι ο χειριστής γεγονότος για ένα μήνυμα πρέπει να ολοκληρωθεί πριν κληθεί για το επόμενο, ακόμη και σε ταυτόχρονες ουρές εκτέλεσης. Έτσι, μέσα σε έναν χειριστή γεγονότος XPC, το audit token δεν μπορεί να αντικατασταθεί από άλλα κανονικά (μη απαντητικά!) μηνύματα.
Δύο διαφορετικές μέθοδοι που μπορεί να είναι εκμεταλλεύσιμες:
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 (δίνοντας στην εκμετάλλευση πρόσβαση για να καλέσει την προνομιακή ενέργεια).
Variant 2:
Η υπηρεσία B μπορεί να καλέσει μια προνομιακή λειτουργία στην υπηρεσία A που ο χρήστης δεν μπορεί
Η εκμετάλλευση συνδέεται με την υπηρεσία A, η οποία στέλνει στην εκμετάλλευση ένα μήνυμα που αναμένει απάντηση σε μια συγκεκριμένη θύρα απάντησης.
Η εκμετάλλευση στέλνει στην υπηρεσία B ένα μήνυμα που περνά αυτή τη θύρα απάντησης.
Όταν η υπηρεσία B απαντά, στέλνει το μήνυμα στην υπηρεσία A, ενώ η εκμετάλλευση στέλνει ένα διαφορετικό μήνυμα στην υπηρεσία A προσπαθώντας να φτάσει σε μια προνομιακή λειτουργία και αναμένοντας ότι η απάντηση από την υπηρεσία B θα αντικαταστήσει το Audit token τη σωστή στιγμή (Race Condition).
Σενάριο:
Δύο mach υπηρεσίες A και B στις οποίες μπορούμε και οι δύο να συνδεθούμε (βάσει του προφίλ sandbox και των ελέγχων εξουσιοδότησης πριν από την αποδοχή της σύνδεσης).
A πρέπει να έχει έναν έλεγχο εξουσιοδότησης για μια συγκεκριμένη ενέργεια που μπορεί να περάσει η B (αλλά η εφαρμογή μας δεν μπορεί).
Για παράδειγμα, αν η B έχει κάποιες δικαιοδοσίες ή εκτελείται ως root, μπορεί να της επιτραπεί να ζητήσει από την A να εκτελέσει μια προνομιακή ενέργεια.
Για αυτόν τον έλεγχο εξουσιοδότησης, η A αποκτά το audit token ασύγχρονα, για παράδειγμα καλώντας xpc_connection_get_audit_token από dispatch_async.
Σε αυτή την περίπτωση, ένας επιτιθέμενος θα μπορούσε να προκαλέσει μια Race Condition κάνοντας μια εκμετάλλευση που ζητά από την A να εκτελέσει μια ενέργεια πολλές φορές ενώ κάνει B να στέλνει μηνύματα στην A. Όταν η RC είναι επιτυχής, το audit token της B θα αντιγραφεί στη μνήμη ενώ το αίτημα της εκμετάλλευσης μας θα διαχειρίζεται από την A, δίνοντάς της πρόσβαση στην προνομιακή ενέργεια που μόνο η B μπορούσε να ζητήσει.
Αυτό συνέβη με A ως smd και B ως diagnosticd. Η λειτουργία SMJobBless από το smb μπορεί να χρησιμοποιηθεί για να εγκαταστήσει ένα νέο προνομιακό βοηθητικό εργαλείο (ως root). Αν μια διεργασία που εκτελείται ως root επικοινωνήσει με smd, δεν θα εκτελούνται άλλοι έλεγχοι.
Επομένως, η υπηρεσία B είναι diagnosticd επειδή εκτελείται ως root και μπορεί να χρησιμοποιηθεί για να παρακολουθήσει μια διεργασία, οπότε μόλις ξεκινήσει η παρακολούθηση, θα στέλνει πολλαπλά μηνύματα ανά δευτερόλεπτο.
Για να εκτελέσετε την επίθεση:
Ξεκινήστε μια σύνδεση στην υπηρεσία που ονομάζεται smd χρησιμοποιώντας το πρότυπο XPC.
Δημιουργήστε μια δευτερεύουσα σύνδεση με το diagnosticd. Αντίθετα με τη φυσιολογική διαδικασία, αντί να δημιουργήσετε και να στείλετε δύο νέες mach ports, το δικαίωμα αποστολής του πελάτη αντικαθίσταται με ένα αντίγραφο του δικαιώματος αποστολής που σχετίζεται με τη σύνδεση smd.
Ως αποτέλεσμα, τα XPC μηνύματα μπορούν να αποσταλούν στο diagnosticd, αλλά οι απαντήσεις από το diagnosticd ανακατευθύνονται στο smd. Για το smd, φαίνεται ότι τα μηνύματα από τον χρήστη και το diagnosticd προέρχονται από την ίδια σύνδεση.
Το επόμενο βήμα περιλαμβάνει την εντολή στο diagnosticd να ξεκινήσει την παρακολούθηση μιας επιλεγμένης διεργασίας (πιθανώς της δικής του του χρήστη). Ταυτόχρονα, αποστέλλεται μια πλημμύρα κανονικών 1004 μηνυμάτων στο smd. Ο σκοπός εδώ είναι να εγκατασταθεί ένα εργαλείο με ανυψωμένα δικαιώματα.
Αυτή η ενέργεια προκαλεί μια race condition μέσα στη λειτουργία handle_bless. Ο χρόνος είναι κρίσιμος: η κλήση της συνάρτησης xpc_connection_get_pid πρέπει να επιστρέψει το PID της διεργασίας του χρήστη (καθώς το προνομιακό εργαλείο βρίσκεται στο πακέτο της εφαρμογής του χρήστη). Ωστόσο, η συνάρτηση xpc_connection_get_audit_token, συγκεκριμένα μέσα στη υπορουτίνα connection_is_authorized, πρέπει να αναφέρεται στο audit token που ανήκει στο diagnosticd.
Σε ένα περιβάλλον XPC (Διαδικασία-Διαδικασία Επικοινωνία), αν και οι χειριστές γεγονότων δεν εκτελούνται ταυτόχρονα, η διαχείριση των απαντητικών μηνυμάτων έχει μια μοναδική συμπεριφορά. Συγκεκριμένα, υπάρχουν δύο διακριτές μέθοδοι για την αποστολή μηνυμάτων που αναμένουν απάντηση:
xpc_connection_send_message_with_reply: Εδώ, το XPC μήνυμα λαμβάνεται και επεξεργάζεται σε μια καθορισμένη ουρά.
xpc_connection_send_message_with_reply_sync: Αντίθετα, σε αυτή τη μέθοδο, το XPC μήνυμα λαμβάνεται και επεξεργάζεται στην τρέχουσα ουρά εκτέλεσης.
Αυτή η διάκριση είναι κρίσιμη επειδή επιτρέπει την πιθανότητα τα πακέτα απάντησης να αναλύονται ταυτόχρονα με την εκτέλεση ενός χειριστή γεγονότων XPC. Σημειωτέον, ενώ το _xpc_connection_set_creds εφαρμόζει κλείδωμα για να προστατεύσει από την μερική αντικατάσταση του audit token, δεν επεκτείνει αυτή την προστασία σε ολόκληρο το αντικείμενο σύνδεσης. Ως εκ τούτου, αυτό δημιουργεί μια ευπάθεια όπου το audit token μπορεί να αντικατασταθεί κατά τη διάρκεια της περιόδου μεταξύ της ανάλυσης ενός πακέτου και της εκτέλεσης του χειριστή γεγονότων του.
Για να εκμεταλλευτείτε αυτή την ευπάθεια, απαιτείται η εξής ρύθμιση:
Δύο mach υπηρεσίες, αναφερόμενες ως A και B, και οι δύο μπορούν να δημιουργήσουν μια σύνδεση.
Η υπηρεσία A θα πρέπει να περιλαμβάνει έναν έλεγχο εξουσιοδότησης για μια συγκεκριμένη ενέργεια που μόνο η B μπορεί να εκτελέσει (η εφαρμογή του χρήστη δεν μπορεί).
Η υπηρεσία A θα πρέπει να στείλει ένα μήνυμα που αναμένει απάντηση.
Ο χρήστης μπορεί να στείλει ένα μήνυμα στην B στο οποίο θα απαντήσει.
Η διαδικασία εκμετάλλευσης περιλαμβάνει τα εξής βήματα:
Περιμένετε να στείλει η υπηρεσία A ένα μήνυμα που αναμένει απάντηση.
Αντί να απαντήσετε απευθείας στην A, η θύρα απάντησης καταλαμβάνεται και χρησιμοποιείται για να στείλει ένα μήνυμα στην υπηρεσία B.
Στη συνέχεια, αποστέλλεται ένα μήνυμα που περιλαμβάνει την απαγορευμένη ενέργεια, με την προσδοκία ότι θα επεξεργαστεί ταυτόχρονα με την απάντηση από την B.
Παρακάτω είναι μια οπτική αναπαράσταση του περιγραφέντος σεναρίου επίθεσης:
 (1) (1) (1) (1) (1) (1).png)
Δυσκολίες στην Εύρεση Περιστατικών: Η αναζήτηση για περιστατικά χρήσης του xpc_connection_get_audit_token ήταν δύσκολη, τόσο στατικά όσο και δυναμικά.
Μεθοδολογία: Χρησιμοποιήθηκε το Frida για να συνδεθεί η συνάρτηση xpc_connection_get_audit_token, φιλτράροντας κλήσεις που δεν προέρχονται από χειριστές γεγονότων. Ωστόσο, αυτή η μέθοδος περιορίστηκε στη συνδεδεμένη διεργασία και απαιτούσε ενεργή χρήση.
Εργαλεία Ανάλυσης: Χρησιμοποιήθηκαν εργαλεία όπως IDA/Ghidra για την εξέταση προσβάσιμων mach υπηρεσιών, αλλά η διαδικασία ήταν χρονοβόρα, περιπλεγμένη από κλήσεις που περιλάμβαναν την κοινή μνήμη dyld.
Περιορισμοί Σενάριων: Οι προσπάθειες να αυτοματοποιηθούν οι αναλύσεις για κλήσεις προς xpc_connection_get_audit_token από μπλοκ dispatch_async εμποδίστηκαν από τις πολυπλοκότητες στην ανάλυση μπλοκ και τις αλληλεπιδράσεις με την κοινή μνήμη dyld.
Αναφερόμενα Ζητήματα: Υποβλήθηκε αναφορά στην 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, προκαλώντας προκλήσεις για όσους επιθυμούν να το εντοπίσουν και να το κατανοήσουν.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
