macOS xpc_connection_get_audit_token Attack

Μάθετε το χάκινγκ στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

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

Βασικές Πληροφορίες Μηνυμάτων Mach

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

pagemacOS IPC - Inter Process Communication

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

XPC Σύνδεση

Αν δεν ξέρετε πώς δημιουργείται μια XPC σύνδεση ελέγξτε:

pagemacOS XPC

Σύνοψη Ευπάθειας

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

  • Τα mach ports έχουν έναν μόνο παραλήπτη, πολλούς αποστολείς.

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

  • Η λήψη του audit token μιας XPC σύνδεσης είναι κρίσιμη για πολλούς έλεγχους ασφαλείας.

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

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

  • Οι χειριστές γεγονότων XPC χειρίζονται συγχρονισμένα. Αυτό σημαίνει ότι ο χειριστής γεγονότων για ένα μήνυμα πρέπει να ολοκληρωθεί πριν κληθεί για το επόμενο, ακόμη και σε συγχρονισμένες ουρές αποστολής. Έτσι, μέσα σε έναν χειριστή γεγονότων XPC το audit token δεν μπορεί να αντικατασταθεί από άλλα κανονικά (μη απάντηση!) μηνύματα.

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

  1. Παραλλαγή 1:

  • Η εκμετάλλευση συνδέεται με την υπηρεσία A και την υπηρεσία B

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

  • Η υπηρεσία A καλεί το xpc_connection_get_audit_token ενώ δεν βρίσκεται μέσα στον χειριστή γεγονότων για μια σύνδεση σε ένα dispatch_async.

  • Έτσι ένα διαφορετικό μήνυμα θα μπορούσε να αντικαταστήσει το Audit Token επειδή αποστέλλεται ασύγχρονα έξω από τον χειριστή γεγονότων.

  • Η εκμετάλλευση περνά στην υπηρεσία B το SEND right στην υπηρεσία A.

  • Έτσι η υπηρεσία B θα στέλνει πραγματικά τα μηνύματα στην υπηρεσία A.

  • Η εκμετάλλευση προσπαθεί να καλέσει την προνομιούχα ενέργεια. Σε μια RC η υπηρεσία A ελέγχει την εξουσιοδότηση αυτής της ενέργειας ενώ η υπηρεσία B αντικατέστησε το Audit token (δίνοντας στην εκμετάλλευση πρόσβαση για να καλέσει την προνομιούχα ενέργεια).

  1. Παραλλαγή 2:

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

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

  • Η εκμετάλλευση στέλνει στην υπηρεσία B ένα μήνυμα περνώντας αυτό το replay port.

  • Όταν η υπηρεσία B απαντά, στέλνει το μήνυμα στην υπηρεσία A, ενώ η εκμετάλλευση στέλνει ένα διαφορετικό μήνυμα στην υπηρεσία A προσπαθ

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

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

Last updated