Πώς να χακάρετε έναν μη επιδιορθωμένο διακομιστή Exchange με αδίστακτο κώδικα PowerShell

Μόλις πριν από δύο μήνες, ανακοινώθηκαν κάποια ανησυχητικά νέα για σφάλματα: ένα ζευγάρι τρωτών σημείων zero-day ανακοινώθηκε στο Microsoft Exchange.

Όπως έχουμε συμβουλεύτηκε εκείνη τη στιγμή, αυτά τα τρωτά σημεία, ορίζονται επίσημα CVE-2022-41040 και CVE-2022-41082:

[ήταν] δύο μηδενικές ημέρες που [θα μπορούσαν] να συνδεθούν μεταξύ τους, με το πρώτο σφάλμα να χρησιμοποιείται εξ αποστάσεως για να ανοίξει αρκετή τρύπα ώστε να ενεργοποιηθεί το δεύτερο σφάλμα, το οποίο δυνητικά επιτρέπει την απομακρυσμένη εκτέλεση κώδικα (RCE) στον ίδιο τον διακομιστή Exchange.

Η πρώτη ευπάθεια θύμιζε την ενοχλητική και ευρέως κακοποιημένη Τρύπα ασφαλείας ProxyShell από τον Αύγουστο του 2021, επειδή βασιζόταν σε επικίνδυνη συμπεριφορά στη λειτουργία Autodiscover του Exchange, περιγράφεται από τη Microsoft ως πρωτόκολλο δηλαδή "χρησιμοποιείται από πελάτες του Outlook και EAS [Exchange ActiveSync] για εύρεση και σύνδεση σε γραμματοκιβώτια στο Exchange".

Ευτυχώς, η εσφαλμένη λειτουργία Autodiscover που θα μπορούσε να εκμεταλλευτεί στην επίθεση ProxyShell από οποιονδήποτε απομακρυσμένο χρήστη, είτε ήταν συνδεδεμένος είτε όχι, ήταν διορθώθηκε πριν από περισσότερο από ένα χρόνο.

Δυστυχώς, οι ενημερώσεις κώδικα ProxyShell δεν έκαναν αρκετά για να κλείσουν το exploit σε επαληθευμένους χρήστες, οδηγώντας στο νέο CVE-2022-40140 zero-day, το οποίο σύντομα ήταν λακωνικά, αν και παραπλανητικά, μεταγλωττισμένο ProxyNotShell.

Όχι τόσο επικίνδυνο, αλλά επικίνδυνο πάντως

Σαφώς, το ProxyNotShell δεν ήταν τόσο επικίνδυνο όσο το αρχικό ProxyShell, δεδομένου ότι απαιτούσε αυτό που είναι γνωστό ως πιστοποιημένη πρόσβαση, επομένως δεν ήταν ανοιχτό σε κατάχρηση από κανέναν από οπουδήποτε.

Αλλά γρήγορα αποδείχθηκε ότι σε πολλούς διακομιστές Exchange, η γνώση του ονόματος σύνδεσης και του κωδικού πρόσβασης οποιουδήποτε χρήστη θα ήταν αρκετή για να περάσει ως έλεγχος ταυτότητας και να τοποθετηθεί αυτή η επίθεση, ακόμα κι αν αυτός ο χρήστης θα χρειαζόταν ο ίδιος να χρησιμοποιήσει έλεγχο ταυτότητας δύο παραγόντων (2FA) για να συνδεθεί σωστά για πρόσβαση το email τους.

Ως ειδικός του Sophos Chester Wisniewski βάλε το τότε:

Είναι μια «ευπάθεια μεσαίου ελέγχου ταυτότητας», αν θέλετε να την ονομάσετε έτσι. Αυτό είναι μια μικτή ευλογία. Αυτό σημαίνει ότι ένα αυτοματοποιημένο σενάριο Python δεν μπορεί απλώς να σαρώσει ολόκληρο το Διαδίκτυο και να εκμεταλλευτεί ενδεχομένως κάθε διακομιστή Exchange στον κόσμο μέσα σε λίγα λεπτά ή ώρες, όπως είδαμε να συνέβη με το ProxyLogon και το ProxyShell το 2021. […]

Χρειάζεστε έναν κωδικό πρόσβασης, αλλά η εύρεση ενός συνδυασμού διεύθυνσης email και κωδικού πρόσβασης έγκυρα σε οποιονδήποτε διακομιστή Exchange πιθανότατα δεν είναι πολύ δύσκολη, δυστυχώς. Και μπορεί να μην έχετε υποστεί εκμετάλλευση μέχρι σήμερα, επειδή για να συνδεθείτε με επιτυχία στο Outlook Web Access [OWA] απαιτεί το διακριτικό FIDO ή τον έλεγχο ταυτότητας ή οποιονδήποτε δεύτερο παράγοντα που μπορεί να χρησιμοποιείτε.

Αλλά αυτή η επίθεση δεν απαιτεί αυτόν τον δεύτερο παράγοντα. [...] Η απόκτηση απλώς συνδυασμού ονόματος χρήστη και κωδικού πρόσβασης είναι ένα αρκετά χαμηλό εμπόδιο.

Όπως ίσως θυμάστε, πολλοί από εμάς υποθέσαμε (ή τουλάχιστον ελπίζαμε) ότι η Microsoft θα βιαζόταν να διορθώσει τις τρύπες του ProxyNotShell, δεδομένου ότι απομένουν ακόμη δύο εβδομάδες μέχρι την Τρίτη ενημέρωσης κώδικα του Οκτωβρίου.

Αλλά απογοητευτήκαμε όταν διαπιστώσαμε ότι προφανώς ήταν μια αξιόπιστη επιδιόρθωση πιο περίπλοκο από το αναμενόμενο, και ο Οκτώβριος ήρθε και έφυγε με το ProxyNotShell που αντιμετωπιζόταν μόνο με λύσεις, όχι με κατάλληλες ενημερώσεις κώδικα.

Ακόμη και το Patch Tuesday του Νοεμβρίου δεν παρείχε άμεσα τις απαραίτητες διορθώσεις, αν και οι ενημερώσεις κώδικα παρόλα αυτά βγήκε την ίδια ημέρα ως μέρος μιας ενημέρωσης ασφαλείας για το Exchange που θα μπορούσε να ληφθεί και να εγκατασταθεί ξεχωριστά:

Αποκαλύφθηκε η απόδειξη της ιδέας

Τώρα που η σκόνη έχει καταλαγιάσει και όλοι είχαν χρόνο να επιδιορθώσουν τους διακομιστές Exchange τους (τουλάχιστον αυτούς που δεν έχουν ξεχάσει), οι ερευνητές του Zero Day Initiative (ZDI), στον οποίο αρχικά αποκαλύφθηκαν αυτά τα τρωτά σημεία για υποβολή σε Microsoft, έχουν εξηγήσει πώς μπορούν να εκμεταλλευτούν τα σφάλματα.

Τα κακά νέα, ανάλογα με τη γνώμη σας για τις αποκαλύψεις φανερών εκμεταλλεύσεων, είναι ότι η ομάδα ZDI έχει πλέον ουσιαστικά παράσχει ένα proof-of-concept (PoC) που εξηγεί πώς να επιτεθείτε σε διακομιστές Exchange.

Τα καλά νέα, φυσικά, είναι ότι:

• Μπορούμε πλέον μόνοι μας να μελετήσουμε και να κατανοήσουμε τα σφάλματα. Αυτό όχι μόνο μας βοηθά όλους να διασφαλίσουμε ότι οι συνολικές προφυλάξεις που έχουμε λάβει (δεν περιορίζονται μόνο στην επιδιόρθωση) είναι πιθανό να παρέχουν την προστασία που περιμένουμε, αλλά επίσης μας ενημερώνει για πρακτικές προγραμματισμού που θα θέλουμε να αποφύγουμε στο μέλλον, επομένως δεν Δεν παγιδευόμαστε στο να ανοίγουμε σφάλματα αυτού του είδους στον δικό μας κώδικα από την πλευρά του διακομιστή.
• Τώρα δεν έχουμε καμία δικαιολογία για να μην εφαρμόσουμε τα patches. Αν έχουμε καθυστερήσει να ενημερώσουμε, η εξήγηση του ZDI για το γιατί λειτουργεί η επίθεση καθιστά σαφές ότι η θεραπεία είναι σίγουρα προτιμότερη από την ασθένεια.

Πώς λειτουργεί

ZDI's εξήγηση Αυτή η ευπάθεια δημιουργεί μια συναρπαστική ιστορία για το πόσο περίπλοκο μπορεί να είναι να συνδέσεις μαζί όλα τα μέρη που χρειάζεσαι για να μετατρέψεις μια ευπάθεια σε βιώσιμη εκμετάλλευση.

Αξίζει επίσης να το διαβάσετε για να σας βοηθήσει να καταλάβετε γιατί η διερεύνηση ενός υπάρχοντος exploit μπορεί να βοηθήσει στην αποκάλυψη άλλων τρόπων με τους οποίους θα μπορούσε να γίνει κακή χρήση μιας ευπάθειας, προκαλώντας ενδεχομένως πρόσθετες ενημερώσεις κώδικα, προτρέποντας αλλαγές διαμόρφωσης και προωθώντας νέες πρακτικές προγραμματισμού που μπορεί να μην ήταν προφανείς μόνο από την επιδιόρθωση την αρχική τρύπα.

Η εξήγηση είναι, αναγκαστικά, περίπλοκη και αρκετά τεχνική, και σας οδηγεί σε μια μακροσκελή σειρά βημάτων για να επιτύχετε την απομακρυσμένη εκτέλεση κώδικα (RCE) στο τέλος.

Με την ελπίδα να σας βοηθήσουμε να ακολουθήσετε τις λεπτομέρειες υψηλού επιπέδου πιο εύκολα, εάν αποφασίσετε να διαβάσετε την αναφορά ZDI, εδώ είναι μια ελπίδα-όχι-πολύ-απλοποιημένη περίληψη με τα βήματα που αναφέρονται αντίστροφα…

…έτσι θα ξέρετε εκ των προτέρων γιατί η ιστορία παίρνει τις κατευθύνσεις που κάνει:

• ΒΗΜΑ 4. Ξεγελάστε εξ αποστάσεως το Exchange για να δημιουργήσει ένα αντικείμενο .NET της επιλογής σας, με μια παράμετρο αρχικοποίησης της επιλογής σας.

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

Τα αντικείμενα μπορούν να διαχειρίζονται και να ελέγχονται από το ίδιο το λειτουργικό σύστημα, για να αποφευχθεί το είδος των σφαλμάτων κακής διαχείρισης της μνήμης που είναι κοινά σε μια γλώσσα όπως η C, όπου συνήθως χρειάζεται να εκχωρήσετε μόνοι σας μνήμη, να συμπληρώσετε τα σχετικά πεδία δεδομένων με το χέρι και να θυμάστε να απελευθερώστε τη μνήμη και τους πόρους που χρησιμοποιείτε, όπως υποδοχές δικτύου ή αρχεία δίσκου, όταν τελειώσετε.

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

Συνήθως, πρέπει να μεταβιβάσετε μία ή περισσότερες παραμέτρους ως ορίσματα στον κατασκευαστή, για να δηλώσετε πώς θέλετε να διαμορφωθεί το αντικείμενο όταν ξεκινά.

Με απλά λόγια, αν κάνετε στιγμιότυπο, ας πούμε, α TextString αντικείμενο (φτιάχνουμε αυτά τα ονόματα, αλλά καταλαβαίνετε) χρησιμοποιώντας μια παράμετρο που είναι η ίδια μια συμβολοσειρά κειμένου όπως π.χ. example.com:8888...

…θα καταλήξετε πιθανώς με ένα buffer μνήμης που έχει εκχωρηθεί για να κρατήσει το κείμενό σας, αρχικοποιημένο έτσι ώστε να διατηρεί την ίδια τιμή που μεταβιβάσατε, δηλαδή το ακατέργαστο κείμενο example.com:8888.

Σε αυτό το πλαίσιο, η συμβολοσειρά κειμένου που μεταβιβάζεται ως δεδομένα στον κατασκευαστή αντικειμένου δεν αποτελεί αμέσως προφανή απειλή για την ασφάλεια στον κυβερνοχώρο όταν ενεργοποιείτε τον κατασκευαστή εξ αποστάσεως, εκτός από μια πιθανή άρνηση υπηρεσίας (DoS) ζητώντας επανειλημμένα όλο και μεγαλύτερες συμβολοσειρές προσπαθήστε να εξαντλήσετε τη μνήμη.

Αλλά αν επρόκειτο να στιγματίσετε, ας πούμε, α ConnectedTCPClient αντικείμενο χρησιμοποιώντας την ίδια παράμετρο συμβολοσειράς κειμένου του example.com:8888, μπορεί να καταλήξετε με ένα buffer μνήμης έτοιμο να κρατήσει προσωρινά δεδομένα, μαζί με μια υποδοχή δικτύου που εκχωρείται από το λειτουργικό σύστημα που είναι έτοιμη να ανταλλάξει δεδομένα με τον διακομιστή example.com μέσω θύρας TCP 8888.

Μπορείτε να δείτε τον κίνδυνο απομακρυσμένης εκτέλεσης κώδικα εκεί, ακόμα κι αν δεν μπορέσετε ποτέ να στείλετε δεδομένα στην ανοιχτή υποδοχή, δεδομένου ότι έχετε εξαπατήσει τον διακομιστή να καλέσει το σπίτι σε μια τοποθεσία που ελέγχετε.

Μπορεί ακόμη και να βρείτε ένα αντικείμενο που ονομάζεται, ας πούμε, RunCmdAndReadOutput, όπου η συμβολοσειρά κειμένου που στέλνετε ως παράμετρος είναι, κυριολεκτικά, μια εντολή που θέλετε να εκτελεστεί αυτόματα μόλις δημιουργηθεί το αντικείμενο, ώστε να μπορείτε να συλλέξετε την έξοδο του αργότερα.

Ακόμα κι αν δεν καταφέρετε ποτέ να ανακτήσετε την έξοδο της εντολής, απλώς η δημιουργία ενός τέτοιου αντικειμένου θα σας επέτρεπε να επιλέξετε μια εντολή για εκτέλεση, δίνοντάς σας έτσι μια γενική απομακρυσμένη εκτέλεση κώδικα και παρουσιάζοντας έναν κίνδυνο που περιορίζεται μόνο από τα δικαιώματα πρόσβασης της ίδιας της διαδικασίας διακομιστή .

Φυσικά, η επίθεση είναι τόσο εύκολη μόλις φτάσετε στο τελευταίο στάδιο, το οποίο υποτίθεται ότι δεν μπορείτε να κάνετε, επειδή το Exchange έχει μια αυστηρή λίστα επιτρεπόμενων που σας εμποδίζει να επιλέξετε οποιοδήποτε παλιό αντικείμενο για δημιουργία στιγμιότυπου.

Θεωρητικά, μόνο ασφαλή αντικείμενα ή αντικείμενα χαμηλού κινδύνου μπορούν να δημιουργηθούν εξ αποστάσεως μέσω του PowerShell, έτσι ώστε να δημιουργηθεί το φανταστικό μας TextString παραπάνω, ή α SimpleIntegerValue, μπορεί να θεωρηθεί αποδεκτό, ενώ α ConnectedTCPClient ή ένα RunCmdAndReadOutput σίγουρα δεν θα ήταν.

Αλλά οι ερευνητές του ZDI παρατηρούν ότι πριν ενεργοποιήσουν το τελευταίο βήμα, θα μπορούσαν να κάνουν το εξής:

• ΒΗΜΑ 3. Ξεγελάστε εξ αποστάσεως τον Exchange ώστε να πιστεύει ότι ένα αντικείμενο χαμηλού κινδύνου που έχει περάσει τη δοκιμή ασφαλείας είναι, στην πραγματικότητα, κάποιο άλλο αντικείμενο της επιλογής σας.

Ακόμα κι έτσι, μπορείτε να περιμένετε από το Exchange να αποτρέψει την απομακρυσμένη δημιουργία ακόμη και αντικειμένων χαμηλού κινδύνου, για να ελαχιστοποιήσει ακόμη περισσότερο την απειλή.

Όμως οι ερευνητές διαπίστωσαν ότι μπορούσαν:

• ΒΗΜΑ 2. Ξεγελάστε εξ αποστάσεως το Exchange για να το χρησιμοποιήσει PowerShell Remoting χαρακτηριστικό για τη δημιουργία ενός αντικειμένου με βάση τις παραμέτρους αρχικοποίησης που ελέγχονται εξωτερικά.

Και αυτό ήταν δυνατό λόγω της τρύπας που μοιάζει με ProxyShell που ήταν μόνο ημι-μπαλωμένη:

• ΒΗΜΑ 1. Εξαπατήστε εξ αποστάσεως το Exchange ώστε να αποδεχτεί και να επεξεργαστεί ένα αίτημα ιστού με κωδικό εισαγόμενο συσκευάζοντας ένα έγκυρο username:password πεδίο στο αίτημα επίσης.

Ακόμα κι αν ο χρήστης που ονομάστηκε στο αίτημα δεν ήταν πραγματικά συνδεδεμένος και θα έπρεπε να περάσει από κάποιο είδος διαδικασίας 2FA για να αποκτήσει πρόσβαση στο δικό του γραμματοκιβώτιο, ένας εισβολέας που γνώριζε username:password Ο συνδυασμός θα είχε αρκετές πληροφορίες ελέγχου ταυτότητας για να ξεγελάσει το Exchange ώστε να αποδεχτεί μια σύνδεση ιστού που θα μπορούσε να χρησιμοποιηθεί για την έναρξη της αλυσίδας επίθεσης που περιγράφεται στα βήματα 2 έως 4 παραπάνω.

Χαλαρά μιλώντας, κάθε έγκυρο username:password ο συνδυασμός θα έκανε, δεδομένου ότι ο "έλεγχος ταυτότητας" χρειαζόταν απλώς για να αποτρέψει το Exchange από το να απορρίψει το αίτημα HTTP εκ των προτέρων.

Τι να κάνω;

Σημειώστε ότι αυτή η επίθεση λειτουργεί μόνο:

• Εάν έχετε διακομιστές Exchange εσωτερικού χώρου. Η Microsoft ισχυρίζεται ότι έχει κλειδώσει γρήγορα τις δικές της υπηρεσίες cloud, επομένως το Exchange Online δεν επηρεάζεται. Βεβαιωθείτε ότι γνωρίζετε πού βρίσκονται οι διακομιστές Exchange. Ακόμα κι αν χρησιμοποιείτε τώρα το Exchange Online, μπορεί να έχετε ακόμα διακομιστές εσωτερικού χώρου σε λειτουργία, που ίσως έχουν απομείνει κατά λάθος από τη διαδικασία μετεγκατάστασης.
• Εάν οι διακομιστές σας δεν έχουν επιδιορθωθεί. Βεβαιωθείτε ότι έχετε εφάρμοσε την ενημερωμένη έκδοση λογισμικού Exchange της 2022-11-08 προς την κλείστε τα τρωτά σημεία που απαιτεί η εκμετάλλευση.
• Εάν οι διακομιστές σας εξακολουθούν να δέχονται τον Βασικό έλεγχο ταυτότητας, γνωστό και ως έλεγχος ταυτότητας παλαιού τύπου. Βεβαιωθείτε ότι έχετε απέκλεισε όλες τις πτυχές του ελέγχου ταυτότητας παλαιού τύπου έτσι οι διακομιστές σας δεν θα το δεχτούν username:password κεφαλίδες που αναφέρονται παραπάνω και δεν θα δεχτούν εξαρχής επικίνδυνα αιτήματα πρωτοκόλλου Autodiscover. Αυτό σταματά τους επιτιθέμενους εξαπάτηση ενός διακομιστή ώστε να αποδεχτεί τα κόλπα δημιουργίας αντικειμένων που έχουν παγιδευτεί με εκρήξεις, ακόμα κι αν αυτός ο διακομιστής δεν έχει διορθωθεί.

Μπορείς να παρακολουθείτε των επίσημων συμβουλών πρόληψης, αποκατάστασης και απόκρισης, και οι πελάτες της Sophos μπορούν να παρακολουθούν τα ονόματα ανίχνευσης απειλών που χρησιμοποιούνται από τα προϊόντα μας, μέσω της ροής του Sophos X-Ops στο Twitter (@SophosXOps).

Έχουν δημοσιευθεί νέες πληροφορίες σχετικά με τα CVE-2022-41040 και CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) Νοέμβριος 21, 2022

---

ΜΑΘΕΤΕ ΠΕΡΙΣΣΟΤΕΡΑ ΣΧΕΤΙΚΑ ΜΕ ΤΗΝ ΕΞΕΛΙΞΗ ΑΝΤΑΛΛΑΓΗΣ ΚΑΙ ΤΟ OAUTH2

Με τον Paul Ducklin και τον Chester Wisniewski
Intro και outro μουσική από Edith Mudge.

---