Επιθέσεις σε υποδομές AI μέσω MCP και prompt injection

Οι επιτιθέμενοι έχουν μετατοπίσει την προσοχή τους: δεν στοχεύουν πια μόνο παραδοσιακούς web servers αλλά αναζητούν ευάλωτα σημεία μέσα στην ίδια την υποδομή τεχνητής νοημοσύνης. Η δημοφιλής πρακτική της αυτο-φιλοξενίας μοντέλων και των proxies/agents που μεσολαβούν ανάμεσα σε χρήστες, APIs και εσωτερικές υπηρεσίες έχει ανοίξει νέες, πολύτιμες διαδρομές επίθεσης. Η πρόσφατη ανάλυση περιστατικών δείχνει στοχευμένα RCE (remote code execution) σε MCP endpoints, blind prompt injection σε agent πλατφόρμες και την ανησυχητική πρακτική εξόρυξης credentials απευθείας από τη μνήμη διεργασιών.

Η ταχύτητα υιοθέτησης self-hosted και managed AI λύσεων επιτείνει τον κίνδυνο. Η αναφορά cloud-AI του Wiz για το 2026 δείχνει ότι περίπου 90% των cloud περιβαλλόντων τρέχει κάποιο self-hosted AI λογισμικό, 81% χρησιμοποιεί managed AI υπηρεσίες και 63% φιλοξενεί δικά του models. Όταν ένα μόνο εκτεθειμένο συστατικό λειτουργεί ως πύλη σε API κλειδιά, tokens και cloud ρόλους, ο αντίκτυπος γίνεται γρήγορα επιπέδου παραβίασης ταυτότητας και πλαγίων κινήσεων.

Τι είναι το MCP και γιατί αποτελεί προνομιακό στόχο

Το MCP (Model Context Protocol) είναι σχεδιασμένο για να επιτρέπει επικοινωνία μεταξύ clients και μοντέλων, να δοκιμάζει συνδέσεις και να μεταφέρει περιβάλλον εκτέλεσης. Σε πρακτικό επίπεδο, MCP endpoints συχνά εκτίθενται για προεπισκόπηση, δοκιμές ή για να διασυνδέσουν agent frameworks με μοντέλα. Αυτό που κάνει το πρωτόκολλο δελεαστικό για επιθέσεις είναι ότι συνήθως έχει άμεση πρόσβαση σε εργαλεία που μπορούν να τρέξουν κώδικα, να ανοίξουν shells ή να μεταφέρουν δεδομένα σε back-end συστήματα.

Σε πολλά deployments, proxies και agents (π.χ. LangChain, Flowise, Langflow) βρίσκονται ανάμεσα σε χρήστες, model APIs και εσωτερικές υπηρεσίες. Ένα εκτεθειμένο MCP route ή ένα preview endpoint μπορεί να γίνει γρήγορα γέφυρα για να αποσπαστούν κλειδιά, να χρησιμοποιηθούν quotas inference, ή να γίνει lateral movement εντός του cloud περιβάλλοντος. Η φύση της επικοινωνίας —συχνά με πολλαπλά formats και προσωρινά εργαλεία— επιτρέπει την απόκρυψη κακόβουλων ενεργειών πίσω από φαινομενικά έγκυρα handshakes.

Πώς εκμεταλλεύτηκαν το LiteLLM: authentication bypass και command injection

Ένα από τα πιο εμφανή περιστατικά αφορά το LiteLLM, όπου ερευνητές κατέγραψαν συνδυασμό authentication bypass και command-injection ευπαθειών. Η ευπάθεια που επιτρέπει bypass έχει καταχωρηθεί ως CVE-2026-59822 και αφορά μια παραποιημένη Authorization header που στρέφει μηχανισμούς fallback του OAuth2, αφήνοντας το MCP tooling να δεχτεί αιτήματα χωρίς έγκυρο κλειδί.

Παράλληλα, το preview endpoint του MCP υπέφερε από command injection, επισημασμένο ως CVE-2026-42271. Τα endpoints αυτά δέχονταν μια MCP configuration με πεδίο command και, κατά τη δοκιμή σύνδεσης, μπορούσαν να εκτελέσουν την εντολή. Οι εκδόσεις 1.74.2 έως 1.83.6 του LiteLLM ήταν ευπαθείς και η διόρθωση κυκλοφόρησε στη 1.83.7.labs.

Στα honeypots, οι επιτιθέμενοι έστελναν μια stdio-based MCP configuration που κατέβαζε και εκκινούσε έναν cryptominer, ενώ ταυτόχρονα επέστρεφε ένα συντακτικά ορθό MCP handshake ώστε η σύνδεση να μοιάζει νόμιμη. Το payload χρησιμοποιούσε προσωριούς, κρυφούς φακέλους, εκκινούσε τον miner σαν αποσπασμένη διεργασία και έσβηνε τον staging φάκελο για να μειώσει τα ψηφιακά ίχνη.

Συνδέσεις με άλλες ευπάθειες και οι συνέπειες

Η σοβαρότητα ενισχύθηκε από προηγούμενες ευπάθειες: οι ερευνητές έδειξαν ότι η CVE-2026-42271 μπορεί να συνδυαστεί με bypass στην host-header validation της Starlette, την CVE-2026-48710, και να μετατρέψει ένα αρχικά authenticated bug σε πλήρη unauthenticated διαδρομή συμβιβασμού. Ο συνδυασμός τέτοιων σφαλμάτων δείχνει πόσο επικίνδυνο γίνεται το μικρο-σφάλμα όταν λειτουργεί μέσα σε ένα οικοσύστημα με πολλούς ενδιάμεσους.

Επιπλέον, το γεγονός ότι η CVE-2026-42271 προστέθηκε στο κατάλογο Known Exploited Vulnerabilities της CISA δείχνει την πραγματική χρήση αυτής της ευπάθειας από κακόβουλους παράγοντες σε παραγωγικά περιβάλλοντα.

Blind prompt injection: η επιθετική χρήση DNS callbacks

Μια δεύτερη, πιο λεπτή στρατηγική ήταν η χρήση blind prompt injection εναντίον agent πλατφορμών όπως LangChain, Flowise, OpenWebUI και Node-RED. Αντί να περιμένουν ορατή έξοδο από την εφαρμογή, οι επιτιθέμενοι προσπάθησαν να αναγκάσουν τον agent να κάνει DNS αιτήματα προς domains που ελέγχονταν από αυτούς — τεχνική γνωστή ως OAST (out-of-band application security testing).

Το DNS callback λειτουργεί σαν «αποδεικτικό» ότι μια εντολή έφτασε σε εκτελεστικό εργαλείο, χωρίς να χρειάζεται η εφαρμογή να εμφανίζει το αποτέλεσμα. Στη συνέχεια οι επιτιθέμενοι χρησιμοποίησαν εξωτερικές υπηρεσίες για να ανακτήσουν follow-on εντολές, συχνά Encoded με Base64 ώστε να αποφύγουν απλές φίλτρα και καταγραφές. Το αποτέλεσμα είναι μια επίθεση δύο σταδίων: αρχική διείσδυση μέσω του prompt και εκτέλεση κακόβουλου φορτίου που έρχεται «από έξω» μετά το callback.

AI-native post-exploitation και κλοπή κλειδιών από μνήμη

Η τρίτη, και ίσως πιο ανησυχητική, τεχνική αφορά αυτό που οι ερευνητές ονομάζουν AI-native post-exploitation. Οι επιτιθέμενοι δεν περιορίζονται πια σε συλλογή SSH κλειδιών ή cloud metadata. Αντίθετα, «σκανάρουν» την κατάσταση των φορτωμένων Python modules σε υπηρεσίες όπως το LiteLLM για να αντλήσουν master keys, tokens και proxy credentials απευθείας από τη μνήμη διεργασιών.

Αυτό είναι ιδιαίτερα επικίνδυνο επειδή πολλά AI gateways συγκεντρώνουν τα API κλειδιά για OpenAI, Anthropic, Azure και Google Gemini, μαζί με δικαιώματα IAM και πρόσβαση σε MCP-connected εσωτερικές υπηρεσίες. Κάποιος που αποκτά αυτά τα κλειδιά μπορεί να καταναλώσει inference quotas (LLMjacking), να κλωνοποιήσει εργασίες ή να κινηθεί πλευρικά μέσα στο εταιρικό περιβάλλον.

Παραδείγματα camouflage δείχνουν πόσο προσεκτικοί γίνονται οι επιτιθέμενοι: σε ένα Langflow στόχο, ο miner φυτεύτηκε under /app/data/.claude/ και μετονομάστηκε σε «unicorn» — επιλογές που μιμούνται αρχεία σχετιζόμενα με το Claude Code και μειώνουν την πιθανότητα άμεσης ανίχνευσης από διαχειριστές.

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

Η απάντηση πρέπει να είναι πρακτική, άμεση και συνδυαστική. Πρώτον, οι οργανισμοί πρέπει να χαρτογραφήσουν κάθε internet-accessible AI component και να ορίσουν σαφή ownership, monitoring και patching ευθύνες. Η ασφάλεια όχι μόνο κατά την ανάπτυξη αλλά και στη συνέχεια ως συνεχή λειτουργία είναι ζωτικής σημασίας για credential-dense υποδομές.

Ειδικές ενέργειες περιλαμβάνουν: αναγκαστική authentication για εκτεθειμένα AI services, απενεργοποίηση ή περιορισμό των MCP routes και preview endpoints όταν δεν είναι απολύτως απαραίτητα, άμεση αναβάθμιση του LiteLLM πέρα από τις ευπαθείς εκδόσεις και περιστροφή (rotation) πιθανώς εκτεθειμένων provider/proxy credentials. Τοποθέτηση MCP υπηρεσιών πίσω από authenticated, network-restricted reverse proxies και firewall κανόνες μειώνει σημαντικά την επιφάνεια επίθεσης.

Επίσης, runtime detection είναι κρίσιμη: κανόνες που ειδοποιούν για spawn διεργασιών shell, Python one-liners, εκτελέσεις download utilities, Base64 decoders, ανεξήγητες εξαγωγές αρχείων ή ασυνήθιστη εξερχόμενη DNS δραστηριότητα μπορούν να αποκαλύψουν τόσο MCP exploitation όσο και agent-driven prompt injection. Η παρακολούθηση συστημάτων, οι συγκεντρώσεις logs και η χρήση EDR/NDR με κανόνες ειδικούς για AI υποδομές γίνονται προτεραιότητα.

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

Για τις ομάδες ανάπτυξης και τα security teams, το μήνυμα είναι ξεκάθαρο: το AI infrastructure πρέπει να αντιμετωπίζεται ως παραγωγική, credential-dense υποδομή — όχι ως sandbox για πειραματισμό. Οι αποφάσεις για self-hosting προσφέρουν έλεγχο και ιδιωτικότητα, αλλά συνοδεύονται από την ανάγκη για επαγρύπνηση, αυστηρή διαχείριση των κλειδιών και συνεχή patching. Για τις επιχειρήσεις, η επένδυση σε σωστή ορατότητα, αυθεντικοποίηση και περιορισμούς δικτύου είναι πλέον το ίδιο κρίσιμη με τον ίδιο τον μηχανισμό inference.

Σε πρακτικό επίπεδο, οι τελικοί χρήστες δεν χρειάζεται να κατανοούν τεχνικές λεπτομέρειες, αλλά πρέπει να απαιτούν από τους παρόχους και τις ομάδες IT σαφή πολιτική για την εξασφάλιση των API keys και τον περιορισμό πρόσβασης. Οι οργανισμοί που υιοθετούν AI οφείλουν να ενσωματώνουν security-by-design στις αρχιτεκτονικές τους αποφάσεις και να προσαρμόζουν τα SOC playbooks ώστε να περιλαμβάνουν απειλές ειδικές για AI stacks.