Το παρακάτω άρθρο αφορά την προσωπική εμπειρία του Orange Tsai οπότε παρατίθενται αυτολεξεί τα λόγια του σχετικά με το πως κατάφερε να χακάρει το Facebook για ακόμη μια φορά.
Γεια, έχει περάσει πολύς καιρός από το τελευταίο μου άρθρο. Αυτή η νέα ανάρτηση αφορά την έρευνά μου αυτόν τον Μάρτιο, η οποία αφορά το πώς εντόπισα ευπάθειες σε ένα κορυφαίο προϊόν Mobile Device Management, τις οποίες και παράκαμψα για να επιτύχω απομακρυσμένη εκτέλεση κώδικα.
Όλες οι ευπάθειες έχουν αναφερθεί στον προμηθευτή και διορθώθηκαν τον Ιούνιο. Μετά από αυτό, συνεχίσαμε να παρακολουθούμε μεγάλες εταιρείες για να παρακολουθούμε τη συνολική πρόοδο της διόρθωσης και στη συνέχεια διαπιστώσαμε ότι το Facebook δεν συμβάδιζε με την ενημέρωση κώδικα για περισσότερες από 2 εβδομάδες, οπότε προσπαθήσαμε να αρπάξουμε την ευκαιρία!
Ως Red Team, ψάχνουμε πάντα νέους δρόμους για να διεισδύσουμε σε εταιρικά δίκτυα. Αυτή τη φορά ερευνούμε τις επιθέσεις που αφορούν την ασφάλεια των επιχειρήσεων και ενδιαφερόμαστε για το MDM, οπότε το άρθρο που ακολουθεί είναι σχετικά με αυτό!
Τι είναι το MDM;
Το Mobile Device Management, γνωστό και ως MDM, είναι ένα σύστημα αξιολόγησης στοιχείων που καθιστά το BYOD (Bring your own device) των εργαζομένων πιο διαχειρίσιμο για τις επιχειρήσεις. Το MDM μπορεί να εγγυηθεί ότι οι συσκευές λειτουργούν σύμφωνα με την εταιρική πολιτική και σε ένα αξιόπιστο περιβάλλον.
Ο στόχος μας
Το MDM, ως κεντρικό σύστημα, μπορεί να διαχειρίζεται και να ελέγχει όλες τις συσκευές των εργαζομένων. Είναι αναμφίβολα ένας ιδανικός στόχος για τους χάκερ. Επομένως, έχουμε δει hacker και ομάδες APT να κάνουν κατάχρηση του MDM όλα αυτά τα χρόνια!
Από προηγούμενες περιπτώσεις, γνωρίζουμε ότι το MDM είναι ένας σταθερός στόχος για τους hacker και θέλαμε να κάνουμε μια σχετική έρευνα. Υπάρχουν πολλές λύσεις MDM, ακόμη και από διάσημες εταιρείες όπως η Microsoft, η IBM και η Apple.
Έχουμε καταγράψει γνωστές λύσεις MDM και σαρώσαμε αντίστοιχα μοτίβα σε όλο το διαδίκτυο. Διαπιστώσαμε ότι τα πιο διαδεδομένα MDM είναι τα VMware AirWatch και MobileIron!
Γιατί λοιπόν επιλέξαμε το MobileIron ως στόχο μας; Σύμφωνα με τον επίσημο ιστότοπό τους, περισσότερες από 20.000 επιχειρήσεις επέλεξαν το MobileIron ως λύση MDM. Γνωρίζουμε επίσης ότι το Facebook έχει εκθέσει τον MobileIron server από το 2016. Αναλύσαμε επίσης το Fortune Global 500 και βρήκαμε ότι πάνω από το 15% χρησιμοποιεί και εκθέτει τον MobileIron server στο κοινό! Για τους παραπάνω λόγους, έγινε ο κύριος στόχος μας!
Το αρχείο που θα ερευνήσουμε κυκλοφόρησε στις αρχές του 2018. Φαίνεται λίγο παλιό αλλά είναι καλύτερο από το τίποτα!
Εύρεση ευπαθειών
Αφού ολοκληρώσαμε τελικά το πακέτο δοκιμών είδαμε ότι το component βασίζεται σε Java και έχει εκτεθεί σε τρεις θύρες:
- 443 – η διεπαφή εγγραφής χρήστη
- 8443 – η διεπαφή διαχείρισης συσκευών
- 9997 – το πρωτόκολλο συγχρονισμού συσκευών MobileIron (πρωτόκολλο MI)
Όλες οι ανοιχτές θύρες είναι κρυπτογραφημένες με TLS. Το Apache βρίσκεται στο μπροστινό μέρος του διαδικτυακού τμήματος και παρέχει όλες τις συνδέσεις στο backend, ένα Tomcat με Spring MVC.
Λόγω του Spring MVC, είναι δύσκολο να βρείτε παραδοσιακές ευπάθειες όπως SQL Injection ή XSS.
Μιλώντας για την ευπάθεια, η βασική αιτία είναι απλή. Η Tomcat εξέθεσε μια υπηρεσία Web που κάνει deserialize στο user input με το format Hessian. Ωστόσο, αυτό δεν σημαίνει ότι μπορούμε να κάνουμε τα πάντα! Η κύρια προσπάθεια αυτού του άρθρου είναι να επιλυθεί αυτό, οπότε δείτε την εκμετάλλευση παρακάτω:
Παρόλο που γνωρίζουμε ότι το Web Service κάνει deserialize στο user input, δεν μπορούμε να τo ενεργοποιήσουμε. Το endpoint βρίσκεται και στα δύο:
- Διεπαφή εγγραφής χρήστη – https://mobileiron/mifs/services/
- Διεπαφή διαχείρισης – https://mobileiron:8443/mics/services/
Μπορούμε να «αγγίξουμε» το deserialization (είναι η διαδικασία μετατροπής κάποιου αντικειμένου σε μορφή δεδομένων που μπορεί να γίνει restore αργότερα) μόνο μέσω της διεπαφής διαχείρισης, επειδή το περιβάλλον εργασίας του χρήστη αποκλείει την πρόσβαση στο Web Service.
Το MobileIron βασίστηκε στα Apache Rewrite Rules για να αποκλείσει την πρόσβαση στην υπηρεσία Web. Βρίσκεται μπροστά από μια αρχιτεκτονική reverse-proxy και το backend είναι ένας διακομιστής ιστού που βασίζεται σε Java.
Εκμετάλλευση ευπαθειών
Ο Moritz Bechler έχει κάνει μια φοβερή έρευνα, η οποία συνοψίζει την ευπάθεια “Hessian deserialization” στο whitepaper του που ονομάζεται Java Unmarshaller Security. Από τον πηγαίο κώδικα του marshalsec, μαθαίνουμε ότι το Hessian deserialization ενεργοποιεί το equals() και το hashcode() ενώ ανακατασκευάζει ένα HashMap. Θα μπορούσε επίσης να ενεργοποιήσει το toString () μέσω του XString και τα γνωστά gadget για exploit μέχρι στιγμής είναι:
- Apache XBean
- Caucho Resin
- Spring AOP
- ROME EqualsBean/ToStringBean
Στο περιβάλλον μας, μπορούσαμε να ενεργοποιήσουμε μόνο το gadget chain του Spring AOP και να πραγματοποιήσουμε ένα JNDI Injection. Μόλις πραγματοποιηθεί το JNDI Injection, τα υπόλοιπα μέρη των ευπαθειών είναι εύκολα!
Επίθεση στο Facebook
Τώρα έχουμε ένα τέλειο RCE (απομακρυσμένη εκτέλεση κώδικα) συνδυάζοντας τα JNDI Injection, Tomcat BeanFactory και GroovyShell. Ήρθε η ώρα να γίνει το hack στο Facebook!
Ωστόσο, γνωρίζαμε ότι το Facebook χρησιμοποιεί το MobileIron από το 2016. Παρόλο που η απόκριση του server είναι 403 Forbidden now, το Web Service εξακολουθεί να είναι προσβάσιμο!
Μια κρίσιμη ευπάθεια (CVE-2015-3253) στο Groovy 2.4 μας επέτρεψε να επιτύχουμε το RCE με εκμεταλλευση ενός σφάλματος Java deserialization.
Η MobileIron χρησιμοποιεί την έκδοση 1.5.6 του Groovy, η οποία ήταν ευάλωτη στην επίθεση. Ως εκ τούτου, μπορέσαμε να χρησιμοποιήσουμε αυτήν την επίθεση για να χακάρουμε το Facebook.
Πηγή: blog.orange.tw
