Ο hacker του Google Project, ο James Forshaw, ανακάλυψε μια νέα κατηγορία αδυναμιών που βρίσκονται σε μερικούς από τους kernel mode drivers στα Windows που θα μπορούσαν να επιτρέψουν στους εισβολείς να κλιμακώσουν τα προνόμια. Τα ελαττώματα οφείλονται στην έλλειψη απαραίτητων ελέγχων κατά τη διεκπεραίωση συγκεκριμένων αιτημάτων.
Τα Windows χρησιμοποιούν τα πεδία PreviousMode για τη ρύθμιση του UserMode ή του KernelMode και, συνεπώς, καθορίζουν εάν τα επιχειρήματα της κλήσης προέρχονται από μια αξιόπιστη ή μη αξιόπιστη πηγή.
Ο μηχανισμός χρησιμοποιείται επίσης για τη δημιουργία και το άνοιγμα αρχείων, όπου ο κώδικας kernel mode μπορεί να επιλέξει από διάφορες λειτουργίες του API, συμπεριλαμβανομένων ορισμένων που οδηγούν στην εσωτερική λειτουργία του I / O Manager IopCreateFile.
Σε αυτήν την περίπτωση, το PreviousMode εκχωρείται σε μια συγκεκριμένη μεταβλητή για να καθορίσει εάν θα ελέγξει για έγκυρες παραμέτρους και buffer.
Το λειτουργικό σύστημα χρησιμοποιεί τη μεταβλητή επίσης για έλεγχο προνομίων στο αντικείμενο της συσκευής αν είναι UserMode. Η παράμετρος Options στο IopCreateFile εκτίθεται σε λειτουργίες API που θα μπορούσαν να χρησιμοποιηθούν μόνο από τη λειτουργία kernel για να ορίσετε ένα flag για να παρακάμψετε την AccessMode και να την ορίσετε στο KernelMode.
“Το IoCreateFile μπορεί να καλείται μόνο από τον κώδικα λειτουργίας του kernel και δεν υπάρχει μεταβατική περίοδος syscall, επομένως όλες οι κλήσεις θα χρησιμοποιήσουν όποια προηγούμενη λειτουργία έχει οριστεί στο thread. Αν το IoCreateFile κληθεί από ένα thread με προηγούμενη κατάσταση που έχει οριστεί στο UserMode, αυτό σημαίνει ότι θα γίνει SecAC και MemAC. ” διαβάζοντας την ανάλυση του white hat hacker.
“Η εφαρμογή του MemAC είναι ιδιαίτερα προβληματική, καθώς σημαίνει ότι το kernel mode δεν μπορεί να περάσει τους δείκτες του πυρήνα σε IoCreateFilewhich κάνοντας το API πολύ δύσκολο να το χρησιμοποιήσει. Ωστόσο, ο καλών του IoCreateFile δεν μπορεί απλώς να αλλάξει την προηγούμενη κατάσταση του thread σε KernelMode, καθώς τότε θα απενεργοποιηθεί το SecAC.”
Υπό συγκεκριμένες συνθήκες, αυτό σημαίνει ότι οι έλεγχοι πρόσβασης είναι αναγκασμένοι να συμβούν, επιτρέποντας στους drivers kernel mode να ανοίγουν ένα όνομα αντικειμένου που καθορίζεται από μια εφαρμογή λειτουργίας χρήστη.
Το Forshaw εξήγησε ότι ορισμένοι drivers που έχουν αποσταλεί με Windows που λειτουργούν σε kernel mode δεν πραγματοποίησαν όλους τους ελέγχους πρόσβασης κατά το χειρισμό συγκεκριμένων αιτημάτων (IRP_MJ_CREATE). Ο κώδικας λειτουργίας kernel mode θα μπορούσε να αναγκάσει τους ελέγχους πρόσβασης, ανοίγοντας την πόρτα σε κακόβουλη δραστηριότητα.
“Ο τύπος λειτουργίας που εκτελείται και οι συγκεκριμένες παράμετροι της λειτουργίας διαβιβάζονται στη δομή τοποθεσίας στοίβας IO που βρίσκεται αμέσως μετά τη δομή IRP”, συνεχίζει ο εμπειρογνώμονας. “Σε περίπτωση ανοίγματος ενός αρχείου, ο κύριος τύπος λειτουργίας είναι IRP_MJ_CREATE και χρησιμοποιεί το πεδίο Create union της δομής IO_STACK_LOCATION.”
Ένας εισβολέας που ελέγχει τα arguments ενός αρχείου δημιουργίας / ανοιχτής κλήσης θα μπορούσε να χρησιμοποιήσει αιτήματα που προέρχονται από τη λειτουργία χρήστη για να καταστραφεί το ζήτημα και να στείλει ένα αίτημα IRP_MJ_CREATE με έναν έλεγχο που έχει οριστεί στο KernelMode, με αυτόν τον τρόπο θα μπορούσε να αυξήσει τα προνόμια.
Προκειμένου να οριστεί η κλάση του σφάλματος που οδηγεί στην κλιμάκωση τοπικών προνομίων, υπάρχει ανάγκη για τα ακόλουθα χωριστά στοιχεία.
- Ένας αρχικός μηχανισμός λειτουργίας πυρήνα (ο οποίος καλεί το IoCreateFile ή το IoCreateFileEx) ο οποίος θέτει τα flag INPC και IFAC αλλά δεν ορίζει OFAC. Αυτό θα μπορούσε να είναι σε ένα πρόγραμμα οδήγησης ή στον ίδιο τον πυρήνα.
- Ένας ευάλωτος δέκτης ο οποίος χρησιμοποιεί το RequestorMode κατά τη διεκπεραίωση του IRP_MJ_CREATE για μια απόφαση ασφάλειας, αλλά δεν ελέγχει επίσης τα Flag για το SFAC.
“Ένας εισβολέας θα πρέπει να είναι σε θέση να κατευθύνει τον μυητή για να ανοίξει ένα αντικείμενο της συσκευής που χειρίζεται ο δέκτης. Ο έλεγχος ασφαλείας στον δέκτη παρακάμπτεται, επειδή το Irp-> RequestorMode θα είναι KernelMode, αλλά το flag SL_FORCE_ACCESS_CHECK δεν εξετάζεται. “Διαβάστε την ανάλυση που δημοσιεύεται από τη Microsoft.”
“Στις έρευνες του, ο James βρήκε στιγμές τόσο των πρωτοκόλλων όσο και των δεκτών, αλλά κανένας που όταν συνδεθεί θα οδηγούσε άμεσα σε κλιμάκωση προνομίων. Επιλέξαμε να συνεργαστούμε μαζί του για περαιτέρω έρευνα και να δούμε τι μπορούμε να βρούμε μαζί “.
Η Microsoft θα λύσει το σφάλμα στις μελλοντικές εκδόσεις του λειτουργικού συστήματος Windows και εν τω μεταξύ σχεδιάζει να εφαρμόσει τις περισσότερες από τις ενημερώσεις κώδικα στα Windows 10 19H1.
“Για να συνοψίσουμε τις συνδυασμένες έρευνες του James και του MSRC, δεν φαινόταν να υπάρχει συνδυασμός μυητή και δέκτη που να υπάρχει στις τρέχουσες υποστηριζόμενες εκδόσεις των Windows που θα μπορούσαν να χρησιμοποιηθούν για την κλιμάκωση τοπικών προνομίων “out of the box”.
Παρ ‘όλα αυτά, επιλέξαμε να τις αντιμετωπίσουμε σε μελλοντικές εκδόσεις των Windows ως μέτρο άμυνας σε βάθος. Οι περισσότερες από αυτές τις ενημερώσεις κώδικα βρίσκονται σε εξέλιξη για κυκλοφορία στα Windows 10 19H1, με λίγους να κρατήθηκαν πίσω για περαιτέρω δοκιμές συμβατότητας και / ή επειδή το στοιχείο που υπάρχει και είναι απενεργοποιημένο από προεπιλογή ” καταλήγει η Microsoft.
“Υπάρχει κάποιος κίνδυνος οι drivers τρίτων μερών να είναι ευάλωτοι σε αυτήν την κατηγορία ευπάθειας και παροτρύνουμε όλους τους προγραμματιστές του kernel driver να αναθεωρήσουν τον κώδικα τους για να διασφαλίσουν τη σωστή επεξεργασία των αιτημάτων IRP και την αμυντική χρήση των API ανοιχτών αρχείων”
