Mastodon
Connect with us

Hacking

Η έρευνα «Attack the Glass» αποκαλύπτει κρίσιμη ευπάθεια στην αλυσίδα λογισμικού

Η έρευνα Attack the Glass δείχνει πως κώδικας από προμηθευτές μπορεί να αλλάξει τι βλέπουν οι χρήστες στην οθόνη, ακόμα κι αφού περάσουν όλοι οι προεγκατασταμένοι έλεγχοι ασφαλείας. Για οργανισμούς και πολίτες αυτό σημαίνει ανάγκη για καλύτερη επαλήθευση runtime, διαχείριση προμηθευτών και συνεχές monitoring.

Published

on

Η έρευνα «Attack the Glass» αποκαλύπτει κρίσιμη ευπάθεια στην αλυσίδα λογισμικού

Μια τετραετής έρευνα της nDiligence φέρνει στο φως μια δομική αδυναμία που επηρεάζει τον τρόπο με τον οποίο εφαρμογές και συσκευές «χτίζουν» ό,τι βλέπουμε στην οθόνη μας κατά τη διάρκεια της χρήσης. Το εύρημα, που ονομάστηκε Attack the Glass (ATG), δείχνει πως ακόμη και όταν όλες οι παραδοσιακές ασφάλειες έχουν περάσει, ένας επιτιθέμενος μπορεί να τροποποιήσει το περιεχόμενο, να υποκλέψει πληκτρολογήσεις και να ενεργήσει με την εξουσία του χρήστη — χωρίς να ανιχνεύεται εύκολα.

Το συμπέρασμα της ομάδας, που μελέτησε 50 τύπους πλατφορμών κατά τη διάρκεια τεσσάρων χρόνων, είναι ανησυχητικό: 46 από αυτές αξιολογήθηκαν ως κρίσιμου ή υψηλού κινδύνου. Η έρευνα δημοσιεύεται υπό καθεστώς TLP CLEAR, με λευκή βίβλο 16 κεφαλαίων, 20 διαδικτυακές επιδείξεις και playbooks αποκατάστασης.

Τι ακριβώς ανακάλυψε η έρευνα

Η καρδιά του προβλήματος είναι η πρακτική του «runtime client-side rendering» — δηλαδή η δημιουργία του user interface, η φόρτωση δεδομένων και η εκτέλεση κώδικα πάνω στη συσκευή του τελικού χρήστη, ενώ η εφαρμογή τρέχει. Πολύ λογισμικό που θεωρούμε «τοπικό» στην εμπειρία χρήσης βασίζεται σε πόρους που προέρχονται από δεκάδες ή ακόμα και εκατοντάδες προμηθευτές: εσωτερικά συστήματα, εξωτερικοί vendors, CDN και υποπρομηθευτές τους.

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

Πώς παρακάμπτονται οι τρέχουσες άμυνες

Στην πράξη, μέτρα όπως σύνδεση χρηστών (sign-in), κρυπτογράφηση, η φιλοσοφία Zero Trust, firewalls και η ανασκόπηση κώδικα λειτουργούν πριν ο κώδικας φτάσει και εκτελεστεί στη συσκευή του χρήστη. Μόλις όμως ο κώδικας φορτωθεί τοπικά, θεωρείται «έμπιστος» και δεν υπάρχουν επαρκείς μηχανισμοί που να παρακολουθούν ή να επαληθεύουν διαρκώς τη συμπεριφορά του στο runtime.

Το αποτέλεσμα είναι ότι κακόβουλες τροποποιήσεις μπορούν να παραμείνουν ενεργές και μη ανιχνεύσιμες από αυτοματοποιημένα εργαλεία που ελέγχουν κυρίως την αλυσίδα πριν τη διανομή του λογισμικού. Το παράδειγμα της υπόθεσης Polyfill.io τον Φεβρουάριο του 2024 — όπου το domain που έτρεχε μια βιβλιοθήκη που χρησιμοποιούν πάνω από 100.000 ιστοσελίδες πουλήθηκε σε εταιρεία με κυρώσεις — δείχνει πόσο εύκολα μπορεί να συμβεί αυτό και για πόσο καιρό να παραμείνει απαρατήρητο.

Ρεαλιστικές συνέπειες σε κρίσιμα πεδία

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

Η ομάδα της nDiligence ταξινόμησε πέντε είδη επιθέσεων που προκύπτουν από ATG: deceive (παραπλάνηση), disrupt (διατάραξη), degrade (υποβάθμιση), deny (άρνηση πρόσβασης) και destroy (καταστροφή). Αυτές οι ενέργειες μπορούν να στοχοποιηθούν με μεγάλη ακρίβεια, επηρεάζοντας συγκεκριμένους χρήστες ή ομάδες χωρίς να ενεργοποιούν ευρέως ανιχνεύσιμα μοτίβα.

Παραδείγματα που επιβεβαιώνουν τον κίνδυνο

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

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

Τι μπορούν να κάνουν οργανισμοί και προγραμματιστές

Η αντιμετώπιση χρειάζεται πολλαπλά επίπεδα πρακτικών: μείωση της ανάσχεσης στην πλευρά του client όπου αυτό είναι εφικτό, καθιέρωση μηχανισμών υπογραφής και επαλήθευσης πόρων στο runtime, και χρήση τεχνολογιών όπως Subresource Integrity (SRI) και Content Security Policy (CSP). Επιπλέον, σημαντικά εργαλεία είναι η δημιουργία και διανομή του SBOM (Software Bill of Materials) και η επαλήθευση υπογραφών πακέτων κατά την εκτέλεση.

Άλλες πρακτικές περιλαμβάνουν την αυστηρή διαχείριση προμηθευτών, το continuous monitoring των προμηθευτικών αλυσίδων, την υλοποίηση runtime integrity monitoring και, όπου είναι δυνατό, την απόδοση κρίσιμων διεπαφών στο server-side rendering για να μειωθεί η εμπιστοσύνη σε τρίτους πόρους στην πλευρά του client. Κάθε επιλογή έχει κόστος: απόδοση, εμπειρία χρήστη, και χρόνο ανάπτυξης, και γι’ αυτό απαιτείται ισορροπία.

Τι χρειάζεται από την ευρύτερη κοινότητα και τις αρχές

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

Χρειάζονται πρότυπα και ρυθμίσεις που να απαιτούν διαρκή επαλήθευση της ακεραιότητας του λογισμικού κατά το runtime, καθώς και δοκιμές που προσομοιώνουν επιθέσεις αλυσίδας εφοδιασμού σε περιβάλλοντα παραγωγής. Η υιοθέτηση πρωτοκόλλων όπως το TLP CLEAR για την κοινοποίηση ευπαθειών και η χρήση κοινών playbooks αποκατάστασης θα βοηθήσουν στη συντονισμένη αντίδραση σε μελλοντικά συμβάντα.

Τι σημαίνει αυτό για τους χρήστες

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

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

Advertisement