Κρίση ασφάλειας στο Vertex AI: άνοδος προνομίων μέσω Service Agents

Τι ανακαλύφθηκε και γιατί προκαλεί ανησυχία

Η πρόσφατη αποκάλυψη ευπαθειών στο Vertex AI της Google φέρνει ένα σημαντικό ζήτημα στον προσκήνιο: επιτιθέμενοι με πολύ περιορισμένα αρχικά δικαιώματα μπορούν να αποκτήσουν τον έλεγχο λογαριασμών υπηρεσίας υψηλού επιπέδου (Service Agents) και έτσι να επεκτείνουν τα προνόμια τους σε ολόκληρο το project. Η ουσία της απειλής δεν είναι απλώς μία μεμονωμένη «τρύπα» σε ένα προϊόν, αλλά η συνδυαστική αδυναμία προεπιλεγμένων ρυθμίσεων ταυτοτήτων και η δυνατότητα απομακρυσμένης εκτέλεσης κώδικα σε managed υποδομές. Για οργανισμούς που αναπτύσσουν γρήγορα υποδομές Generative AI, το ρίσκο είναι πρακτικά άμεσο: διαρροή LLM memories, πρόσβαση σε chat logs, και ευρεία ανάγνωση/εγγραφή σε BigQuery και GCS.

Πώς λειτουργούν οι Service Agents και τι τους κάνει επικίνδυνους

Στο Google Cloud, οι «Service Agents» είναι managed λογαριασμοί υπηρεσίας που διαχειρίζεται η ίδια η Google για να εκτελεί εσωτερικές διεργασίες μιας υπηρεσίας. Επειδή πρέπει να κάνουν πολλά πράγματα για λογαριασμό των χρηστών, συχνά αποκτούν εκτεταμένα δικαιώματα αυτόματα. Το πρόβλημα δεν είναι η ύπαρξή τους—είναι αναγκαίοι—αλλά οι προεπιλεγμένες πολιτικές και οι επιτρεπτές ροές εργασίας που επιτρέπουν σε ελαττωματικές εισροές (όπως κακόβουλα εργαλεία ή ανοιχτά staging buckets) να χρησιμοποιηθούν ως μοχλός κλιμάκωσης.

Αντίθετα με έναν παραδοσιακό χρήστη, που αποκτά δικαιώματα μέσω IAM roles, οι Service Agents μπορούν να έχουν πρόσβαση σε ευαίσθητα δεδομένα και λειτουργίες χωρίς καν να εμφανίζονται ως «χρήστες» στις καθημερινές καταγραφές, καθιστώντας την ανίχνευση και τον περιορισμό δυσκολότερα.

Δύο κύριες επιθέσεις: Agent Engine και Ray-cluster

Οι ερευνητές ασφάλειας περιγράφουν δύο διακριτά σενάρια εκμετάλλευσης. Το πρώτο αφορά το Vertex AI Agent Engine, όπου το να έχεις δικαίωμα να ενημερώσεις έναν reasoning engine (aiplatform.reasoningEngines.update) αρκεί για να εισαγάγεις «εργαλεία» που περιέχουν κακόβουλο Python κώδικα. Η τεχνική είναι απλή αλλά αποτελεσματική: ένας επιτιθέμενος φορτώνει ένα εργαλείο που μοιάζει νόμιμο αλλά ενσωματώνει ένα reverse shell ή άλλο payload. Όταν ο reasoning engine το καλέσει, ο κώδικας εκτελείται στο compute instance, και ο επιτιθέμενος παίρνει πρόσβαση στο metadata service ώστε να εξάγει το access token του Reasoning Engine Service Agent. Αυτός ο λογαριασμός συχνά έχει δικαιώματα που περιλαμβάνουν πρόσβαση σε LLM memories, πρόσβαση σε GCS buckets, και πρόσβαση σε logs—δηλαδή, πρόσβαση σε δεδομένα που στην πράξη είναι πολύ πιο ευαίσθητα από απλά «compute».

Το δεύτερο σενάριο εντοπίζεται σε clusters του Ray που τρέχουν πάνω σε Vertex AI. Εκεί, ο «Custom Code Service Agent» επισυνάπτεται αυτόματα σε κόμβους και head nodes. Οι ερευνητές έδειξαν ότι χρήστες με πολύ περιορισμένα δικαιώματα—συμπεριλαμβανομένων όσων καλύπτει ο ρόλος «Vertex AI Viewer»—μπορούν μέσω του GCP Console να ανοίξουν το «Head node interactive shell» και να αποκτήσουν root shell στον head node. Από εκεί, παρόμοια τακτική: πρόσβαση στο metadata service για το token του Custom Code Service Agent και στη συνέχεια χρήση του token για ευρεία πρόσβαση σε storage, BigQuery, Pub/Sub και άλλες υπηρεσίες.

Τεχνική εξήγηση: metadata service και tokens

Κέντρο κάθε επίθεσης είναι το metadata service των compute instances. Σε υποδομές Google Compute Engine και managed υπηρεσίες, υπάρχει ένας HTTP endpoint (metadata) από το οποίο οι διεργασίες στο instance μπορούν να ανακτήσουν tokens για τον λογαριασμό υπηρεσίας που χρησιμοποιείται από το instance. Αν μια διεργασία (ή ένα εργαλείο) εκτελεστεί στο instance, μπορεί να καλέσει τον endpoint και να πάρει ένα προσωρινό access token, που στη συνέχεια δίνει πρόσβαση στο Google Cloud με τα δικαιώματα του λογαριασμού υπηρεσίας. Σε αυτά τα σενάρια, το λάθος είναι ότι οι Service Agents έχουν υπερβολικά ευρεία permissions, και ότι μη-ελεγχόμενος κώδικας μπορεί να τρέξει σε ένα περιβάλλον που έχει πρόσβαση στο metadata.

Αυτός ο συνδυασμός—εκτέλεση κώδικα + metadata tokens με εκτεταμένα δικαιώματα—είναι η κλασική συνταγή για privilege escalation: ελάχιστα αρχικά δικαιώματα αρκούν για να φτάσει κάποιος πολύ ψηλότερα.

Πρακτικά παραδείγματα κινδύνων για επιχειρήσεις

Σκεφτείτε ένα startup που τρέχει LLM-based agents για υποστήριξη πελατών. Οι συνομιλίες, οι LLM memories και τα logs αποθηκεύονται σε buckets και BigQuery tables. Ένας εσωτερικός χρήστης με viewer access σε Vertex AI—κάτι που μπορεί να έχει δοθεί για λόγους troubleshooting—μπορεί, με τις παραπάνω ευπάθειες, να διαβάσει όλες τις συνομιλίες των πελατών, να εξάγει ευαίσθητα δεδομένα και να δημιουργήσει νέες εγγραφές σε πίνακες που επηρεάζουν reporting. Σε εταιρείες με προσωπικά δεδομένα, αυτό γίνεται θέμα συμμόρφωσης και νομικής ευθύνης. Σε άλλα σενάρια, με write access στον storage, ένας επιτιθέμενος μπορεί να αντικαταστήσει μοντέλα ή δεδομένα, προκαλώντας supply-chain compromise.

Ακόμη και αν το συγκεκριμένο token έχει περιορισμένο scope για IAM operations, οι δυνατότητες πρόσβασης σε δεδομένα είναι συχνά πιο κρίσιμες και άμεσες από την ικανότητα να αλλάξει κάποιος IAM policies.

Γιατί η αντίδραση της Google έχει σημασία

Στην αποκάλυψη των ευπαθειών, η απάντηση της Google ότι αυτές οι συμπεριφορές είναι «working as intended» δείχνει ότι οι προεπιλεγμένες ρυθμίσεις παραμένουν. Αυτό απελευθερώνει την ευθύνη στον χρήστη για να σκληρύνει την πλατφόρμα, αλλά δημιουργεί σημαντικό κενό ασφαλείας: πολλές ομάδες υιοθετούν υπηρεσίες όπως το Vertex AI με default configs για να επιταχύνουν τα projects παραγωγής. Όταν ένας πάροχος θεωρεί ορισμένες συμπεριφορές «θέλω-να-λειτουργούν-έτσι», οι πελάτες πρέπει να λάβουν επιπλέον μέτρα—κάτι που αυξάνει το κόστος και την πολυπλοκότητα της διαχείρισης ασφάλειας.

Επιπλέον, επειδή οι Service Agents διαχειρίζονται από τον πάροχο, η δυνατότητα των οργανισμών να προσαρμόσουν τις default άδειες είναι περιορισμένη· άρα η λύση απαιτεί συνεργασία μεταξύ cloud provider και πελάτη για σφαιρικές βελτιώσεις.

Άμεσα μέτρα για προστασία των περιβαλλόντων

Υπάρχουν πρακτικά βήματα που οι πλατφόρμες και οι ομάδες ασφαλείας μπορούν να εφαρμόσουν αμέσως. Πρώτον, αξιολογήστε και αποδώστε μείωση δικαιωμάτων στους Service Agents: δημιουργήστε custom roles με το ελάχιστο απαραίτητο scope αντί να αφήνετε default wide-ranging permissions. Δεύτερον, απενεργοποιήστε τις ρουτίνες που επιτρέπουν άμεση πρόσβαση σε interactive shells για head nodes ή περιορίστε τη με IAM conditions και organization policies. Τρίτον, πριν οποιαδήποτε ενημέρωση reasoning engines ή πριν φορτώσετε νέα εργαλεία, εφαρμόστε strict validation και sandboxing του κώδικα—μην εμπιστεύεστε staging buckets που είναι δημόσια.

Παρακολούθηση και logging πρέπει να ενισχυθούν: χρησιμοποιήστε Cloud Audit Logs, ενεργοποιήστε Security Command Center policies για να ειδοποιείστε άμεσα για προσβάσεις στο metadata service ή περίεργες εξαγωγές δεδομένων. Αν είναι εφικτό, περιορίστε την ικανότητα των instances να προσεγγίζουν το metadata service χωρίς πρόσθετο επίπεδο ελέγχου (π.χ., IAM conditions ή πρόσθετα firewall/sidecar).

Συστάσεις αρχιτεκτονικής και πολιτικές ασφαλείας

Σε αρχιτεκτονικό επίπεδο, σκεφτείτε private endpoints και VPC Service Controls για να περιορίσετε το εύρος στο οποίο μπορούν να λειτουργήσουν αυτά τα tokens. Χρησιμοποιήστε Workload Identity ή άλλες μηχανικές ταυτοποίησης ώστε να μην βασίζεστε σε shared service account keys και να μπορείτε να εφαρμόζετε fine-grained IAM. Εξετάστε επίσης τη δυνατότητα να περιορίσετε ποιοι χρήστες μπορούν να ανεβάζουν/ενημερώνουν εργαλεία σε reasoning engines, και να επιβάλλετε code review, signing και static analysis πριν οποιαδήποτε ανάπτυξη.

Επιπλέον, ενσωματώστε μηχανισμούς detection για suspicious metadata access patterns. Το metadata service είναι σχεδιασμένο για να είναι γρήγορο και εύχρηστο, αλλά αυτό σημαίνει ότι μικρές ανεπιθύμητες κλήσεις πρέπει να θεωρούνται ύποπτες όταν προέρχονται από μη αναμενόμενες διεργασίες.

Γιατί έχει σημασία

Η ευρεία υιοθέτηση του Generative AI σε επιχειρήσεις σημαίνει ότι οι πλατφόρμες που φιλοξενούν agents και LLMs κρατούν πολύ ευαίσθητες πληροφορίες: συνομιλίες πελατών, εσωτερικά προφίλ, και μοντέλα που αντιπροσωπεύουν πνευματική ιδιοκτησία. Μια ευπάθεια που επιτρέπει την κλιμάκωση προνομίων δεν είναι απλά τεχνικό ζήτημα· είναι ζήτημα επιχειρησιακού ρίσκου, συμμόρφωσης, και εμπιστοσύνης. Επιπλέον, τέτοιες αδυναμίες υπογραμμίζουν την ανάγκη για κοινές πρακτικές ασφαλείας στον κόσμο του cloud: least privilege, defense in depth, και συνεχής παρακολούθηση.

Αν οι πάροχοι διατηρούν επικίνδυνα defaults, το αποτέλεσμα θα είναι μεγαλύτερο κόστος για τους πελάτες και συχνότερα περιστατικά διαρροών που οδηγούν σε ρυθμιστικά πρόστιμα και απώλεια πελατών.

Τι μπορούν να κάνουν οι ομάδες ασφάλειας τώρα

Ξεκινήστε με audit των permissions των Service Agents στα έργα σας. Εφαρμόστε custom roles και περιορίστε δικαιώματα όσο περισσότερο γίνεται. Απενεργοποιήστε λειτουργίες που επιτρέπουν interactive shell πρόσβαση σε head nodes ή τουλάχιστον περιορίστε τις μέσω IAM και οργανωτικών πολιτικών. Ενισχύστε το pipeline για αλλαγές σε reasoning engines: code signing, static analysis, και review από ειδικούς ασφαλείας πριν οτιδήποτε προωθηθεί στο production. Τέλος, ενεργοποιήστε ειδοποιήσεις για απρόσμενες κλήσεις στο metadata service και αυξήστε την ορατότητα στα audit logs για να εντοπίζετε γρήγορα ύποπτες κινήσεις.

Ευρωπαϊκό και ελληνικό πλαίσιο

Σε ευρωπαϊκό επίπεδο, οι απαιτήσεις για προστασία προσωπικών δεδομένων (GDPR) και οι αυξανόμενες κανονιστικές πιέσεις καθιστούν τέτοιες ευπάθειες ιδιαίτερα κρίσιμες. Οι εταιρείες στην Ελλάδα που υιοθετούν Vertex AI ή παρόμοιες λύσεις θα πρέπει να αξιολογούν όχι μόνο τη λειτουργικότητα αλλά και τη συμμόρφωση των cloud defaults με το νομικό τους πλαίσιο. Η επιλογή ιδιωτικών buckets, οριοθέτηση πρόσβασης και η τεκμηριωμένη πολιτική για retention δεδομένων είναι κρίσιμες προσαρμογές που πρέπει να γίνουν νωρίς.

Επιπλέον, οι ελληνικές ομάδες IT μπορούν να πιέσουν για βελτιώσεις στις προεπιλεγμένες ρυθμίσεις του παρόχου και να απαιτήσουν δυνατότητες εκτενούς logging και ελέγχων πρόσβασης ειδικά για managed Service Agents. Η συνεργασία με legal και compliance ομάδες είναι απαραίτητη ώστε τα τεχνικά μέτρα να συνάδουν με επιχειρησιακές και ρυθμιστικές υποχρεώσεις.

Συμπέρασμα

Οι ευπάθειες στο Vertex AI υπενθυμίζουν ότι η ασφάλεια στο cloud δεν είναι αυτοματοποιημένη: οι default επιλογές και οι managed λογαριασμοί υπηρεσίας μπορούν να κρύβουν κινδύνους που απαιτούν ενεργή διαχείριση. Ο συνδυασμός εκτέλεσης μη-ελεγχόμενου κώδικα και access tokens από το metadata service είναι η βασική αδυναμία που πρέπει να αντιμετωπιστεί. Οφείλουν οι ομάδες ασφάλειας και οι cloud engineers να εφαρμόσουν least privilege, να ενισχύσουν pipelines και να ενεργοποιήσουν κανόνες παρακολούθησης, προτού μια τέτοια εκμετάλλευση γίνει πραγματική καταστροφή για την επιχείρηση.