Greek - Ht
HackTricks Training Twitter Linkedin Sponsor

macOS xpc_connection_get_audit_token Attack

Support HackTricks

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

Βασικές Πληροφορίες για τα Mach Messages

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

macOS IPC - Inter Process Communication

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

Σύνδεση XPC

Αν δεν ξέρετε πώς να δημιουργηθεί μια σύνδεση 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 δεν μπορεί να αντικατασταθεί από άλλα κανονικά (μη απαντητικά!) μηνύματα.

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

  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 (δίνοντας στην εκμετάλλευση πρόσβαση για να καλέσει την προνομιακή ενέργεια).

  1. Variant 2:

  • Η υπηρεσία B μπορεί να καλέσει μια προνομιακή λειτουργία στην υπηρεσία A που ο χρήστης δεν μπορεί

  • Η εκμετάλλευση συνδέεται με την υπηρεσία A, η οποία στέλνει στην εκμετάλλευση ένα μήνυμα που αναμένει απάντηση σε μια συγκεκριμένη θύρα απάντησης.

  • Η εκμετάλλευση στέλνει στην υπηρεσία B ένα μήνυμα που περνά αυτή τη θύρα απάντησης.

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

Variant 1: καλώντας xpc_connection_get_audit_token εκτός ενός χειριστή γεγονότων

Σενάριο:

  • Δύο 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 και μπορεί να χρησιμοποιηθεί για να παρακολουθήσει μια διαδικασία, οπότε μόλις ξεκινήσει η παρακολούθηση, θα στέλνει πολλαπλά μηνύματα ανά δευτερόλεπτο.

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

  1. Ξεκινήστε μια σύνδεση στην υπηρεσία που ονομάζεται smd χρησιμοποιώντας το πρότυπο XPC.

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

  3. Ως αποτέλεσμα, τα μηνύματα XPC μπορούν να αποστέλλονται στο diagnosticd, αλλά οι απαντήσεις από το diagnosticd ανακατευθύνονται στο smd. Για το smd, φαίνεται ότι τα μηνύματα από τον χρήστη και το diagnosticd προέρχονται από την ίδια σύνδεση.

  1. Το επόμενο βήμα περιλαμβάνει την εντολή στο diagnosticd να ξεκινήσει την παρακολούθηση μιας επιλεγμένης διαδικασίας (πιθανώς της δικής του του χρήστη). Ταυτόχρονα, αποστέλλεται μια πλημμύρα κανονικών μηνυμάτων 1004 στο smd. Ο σκοπός εδώ είναι να εγκαταστήσει ένα εργαλείο με αυξημένα δικαιώματα.

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

Variant 2: προώθηση απαντήσεων

Σε ένα περιβάλλον 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.

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

![https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/variant2.png](../../../../../../.gitbook/assets/image (1) (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, προκαλώντας προκλήσεις για όσους επιδιώκουν να το εντοπίσουν και να το κατανοήσουν.

Support HackTricks
PreviousmacOS PID ReuseNextmacOS Thread Injection via Task port

Last updated