Hacking
STAR Fuzzer: agentic fuzzing που γράφει τα δικά του harnesses
Το STAR Fuzzer αυτοματοποιεί επιλογή στόχων, δημιουργία harness και τριάριση, βρίσκοντας σφάλματα που συχνά ξεφεύγουν σε κριτική κώδικα ή LLM audits. Τα ευρήματα συνοδεύονται από επαληθεύσιμα payloads, μειώνοντας τον χρόνο μέχρι τη διόρθωση.
Η Bright Security παρουσίασε το STAR Fuzzer, μια νέα προσέγγιση agentic fuzzing που αυτοματοποιεί τα πιο απαιτητικά βήματα του fuzzing: επιλέγει στόχους, γράφει και επαληθεύει harnesses, τριάρει ευρήματα και παραδίδει byte‑ακριβή payloads που αναπαράγουν τα σφάλματα. Το εργαλείο ενσωματώνει έναν εξελικτικό μηχανισμό που δοκιμάζει εκατομμύρια εισροές χωρίς να χρειάζεται να τρέξει ολόκληρη η εφαρμογή, με πρώτα αποτελέσματα που δείχνουν ριζική αύξηση στην κάλυψη και στην ανεύρεση κρίσιμων ευπαθειών.
Στην πρώτη ανοικτή δοκιμή έδειξε ότι το 45% των έργων που ελέγχθηκαν περιείχαν ευπάθειες σε επίπεδο High ή Critical, ενώ μέσα στον πρώτο μήνα δημοσιοποίησε δέκα ευρήματα σε οκτώ έργα ανοιχτού κώδικα, ανάμεσά τους το standard library του Crystal, το htop και το RIOT OS. Το αποτέλεσμα δεν είναι απλώς ένας κατάλογος πιθανών προβλημάτων, αλλά πλήρως αναπαραγόμενα αποδεικτικά στοιχεία που μπορούν να τεθούν άμεσα σε διόρθωση.
Τι είναι το agentic fuzzing και γιατί αλλάζει τα δεδομένα
Ο όρος agentic fuzzing περιγράφει τη χρήση AI agents για τα βήματα του fuzzing που παραδοσιακά απαιτούσαν ανθρώπινη κρίση: ποια συναρτήσεις να ελεγχθούν, πώς να κατασκευαστεί το harness που θα τροφοδοτήσει την υπό δοκιμή λειτουργία, και ποια κρασαρίσματα αξίζουν προτεραιότητα. Το STAR Fuzzer αναλαμβάνει αυτά τα καθήκοντα, ενώ για την ίδια τη γενετική αναζήτηση των εισροών χρησιμοποιεί έναν εξελικτικό, structure‑aware engine που παραμένει γρήγορος και επαναλαμβανόμενος.
Αυτό αλλάζει δύο πράγματα: πρώτον, το fuzzing παύει να περιορίζεται σε ομάδες ειδικών που γράφουν και συντηρούν harnesses για κάθε στόχο. Δεύτερον, η αυτοματοποίηση της τριάρισης μειώνει τον χρόνο που περνάει ένας developer για να καταλάβει αν ένα crash είναι πραγματικό και διορθώσιμο ή ένα θόρυβο χωρίς συνέπειες.
Πού παραδοσιακά αποτυγχάνει το fuzzing και τι αφήνει έξω το DAST
Coverage‑guided fuzzers όπως το AFL++ και το libFuzzer έχουν αποδείξει ότι βρίσκουν σοβαρές ευπάθειες, αλλά εξαρτώνται από hand‑written harnesses και ανθρώπινη τριάριση. Αυτό τα κάνει κυρίως εργαλείο εξειδικευμένων ομάδων και κρίσιμων έργων. Αντίθετα, DAST εργαλεία επικεντρώνονται σε ό,τι είναι προσβάσιμο μέσω HTTP και συχνά δεν φτάνουν στην εσωτερική λογική parsing και επεξεργασίας που παράγει τις σοβαρότερες αστοχίες.
Επιπλέον, οι προσπάθειες που βασίζονται σε LLMs στην pentesting φέρνουν καλά αποτελέσματα σε γνωστές κατηγορίες σφαλμάτων αλλά τείνουν να “βλέπουν” αυτά που έχουν ήδη δει. Τα zero‑days που επιβιώνουν σε ώριμο κώδικα συνήθως δεν ταιριάζουν σε γνωστά patterns — και εκεί ακριβώς υπερέχει το fuzzing που παρατηρεί συμπεριφορά, όχι που προβλέπει.
Πώς λειτουργεί τεχνικά το STAR Fuzzer
Η καρδιά του STAR Fuzzer είναι ένας εξελικτικός μηχανισμός που δουλεύει πάνω σε μικρά, αυτόνομα harnesses τα οποία εκτελούν το target μέσω IPC. Το αποτέλεσμα είναι ότι ο κώδικας υπό δοκιμή μπορεί να γραφτεί σε C, C++, Rust, Go, Java/Kotlin, Crystal, Node, Python ή άλλες γλώσσες, αρκεί να διαβάζει είσοδο και να αναφέρει πίσω το αποτέλεσμα.
Μια κρίσιμη ιδέα είναι η format‑agnostic, structure‑aware parsing: κάθε seed μετασχηματίζεται σε ένα δένδρο πεδίων με τύπους και αυτό το δένδρο μπορεί να σειριακοποιηθεί ξανά στα ακριβή bytes που παρείχε ο αρχικός seed. Έτσι δεν χρειάζεται να γράψει κάποιος grammar ή dictionary για κάθε στόχο. Οι μεταλλάξεις γίνονται σε επίπεδο πεδίου, όχι μόνο byte‑level, ώστε να ξεπερνούν τους πρώτους ελέγχους sanity και να δοκιμάζουν την εσωτερική λογική που πραγματικά προκαλεί κατάρρευση ή υπερβολική κατανάλωση μνήμης.
Evolutionary search, reproducibility και ταχύτητα
Το σύστημα κρατά έναν πληθυσμό οργανισμών, καθένας με ένα genome που είναι λίστα μεταλλάξεων. Σε κάθε εποχή (epoch) οι οργανισμοί μεταλλάσσονται, τρέχουν και βαθμολογούνται με βάση signals όπως coverage και impact. Οι βελτιώσεις αποθηκεύονται, οι μη παραγωγικές αλλαγές αναιρούνται και οργανισμοί “αναπαράγονται”. Κάθε genome μπορεί να επαναληφθεί byte‑ακριβώς από ένα logged random seed, πράγμα που σημαίνει ότι κάθε εύρημα συνοδεύεται από πιστοποιημένο αναπαραγώγιμο payload.
Σε persist mode, το κόστος εκτέλεσης ενός harness γίνεται πολύ μικρότερο από το να ξεκινάς μια νέα διεργασία για κάθε input — το Bright αναφέρει περίπου 51x ταχύτερη εκτέλεση σε αυτή τη ρύθμιση, κάτι κρίσιμο όταν μιλάμε για εκατομμύρια προσπάθειες.
Πρώτα αποτελέσματα σε έργα ανοιχτού κώδικα
Προτού κυκλοφορήσει ευρέως, το STAR Fuzzer δοκιμάστηκε αυτοματοποιημένα πάνω σε πληθώρα έργων ανοιχτού κώδικα και μέσα σε λίγες ημέρες κατέγραψε ότι στο 45% των έργων υπήρχαν High ή Critical ευπάθειες. Στον πρώτο μήνα που έγινε διαθέσιμο δημοσιεύτηκαν δέκα ευρήματα σε οκτώ έργα. Κάποια ενδεικτικά παραδείγματα:
Στο TwelveMonkeys, ένα πεδίο header (mipMapCount) χρησιμοποιούσε το μέγεθος για uncapped array και ένα 38‑byte αρχείο ανέγερσε πολυ‑gigabyte allocation (CWE‑789). Στο Fider, ο έλεγχος βασιζόταν στο compressed size ενός image αλλά μετά γινόταν πλήρης decode, με συνέπεια ένα 436 KB PNG να εκτοξεύεται σε ~562 MB στη μνήμη (CWE‑409). Στο standard library του Crystal βρέθηκαν δύο διαφορετικές καταστάσεις: type confusion στο XML και stack overflow για self‑referencing YAML anchors.
Άλλες εύστοχες ανακαλύψεις περιλαμβάνουν out‑of‑bounds read στο parsing του htop, null‑pointer access στο universal‑ctags, unbounded allocation σε εικόνες στο scrimage και off‑by‑one στο RIOT OS. Κάποιες από αυτές ήταν αόρατες σε απλή κριτική κώδικα, επειδή οι συνθήκες που τις ενεργοποιούν είναι πολύ συγκεκριμένες ή παίζουν με compressed/decoded μεγέθη.
Γιατί τα LLMs δεν αρκούν για zero‑day discovery
Τα LLMs είναι ισχυρά στο να εντοπίζουν patterns που ήδη υπάρχουν στα δεδομένα εκπαίδευσης — unchecked memcpy, SQL injection patterns, κ.λπ. Όμως όταν μιλάμε για zero‑day που δεν μοιάζει με κάτι που έχει δει το μοντέλο, η προσέγγιση προβλέπει, δεν παρατηρεί. Το fuzzing εκτελεί το compiled πρόγραμμα εκατομμύρια φορές και βλέπει πραγματικά outputs, sanitizer reports και συμπεριφορές allocator/struture που ένα LLM δεν μπορεί να μαντέψει χωρίς να τρέξει κώδικα.
Για να γίνει μια στατιστική παραλληλία: μια fuzzing καμπάνια 1–10 εκατομμυρίων εκτελέσεων απαιτεί πολύ λιγότερο χρόνο και παράγει πραγματικό ground truth σε σχέση με το να επιχειρούσαμε να “μοιράσουμε” το ίδιο φορτίο σε ένα LLM, όπου κάθε υπόθεση κοστίζει tokens και παραμένει υποθετική μέχρι να επαληθευτεί.
Πού ταιριάζει καλύτερα το STAR Fuzzer στην πράξη
Το εργαλείο ξεχωρίζει σε περιβάλλοντα όπου η είσοδος που πρέπει να ελεγχθεί είναι κάτω από το HTTP layer: επεξεργασία αρχείων, εικόνων, document parsers, serialization libraries, raw binary protocols, embedded/IoT firmware και backend services που δέχονται πολύπλοκα binary inputs. Επίσης, είναι ιδανικό για οργανισμούς που έχουν μεγάλο μέρος κώδικα παραγόμενο από AI και χρειάζονται testing που δεν περιορίζεται σε μοτίβα.
Συμπληρώνει — δεν αντικαθιστά — εργαλεία όπως DAST και SAST. Το DAST εξακολουθεί να ελέγχει την επιφάνεια του δικτύου και τις καταστάσεις σε τρέχουσες εφαρμογές, ενώ το STAR Fuzzer εμβαθύνει στις συναρτήσεις που διαχειρίζονται untrusted input και προσφέρει αναπαραγώγιμα payloads ώστε προγραμματιστές να μπορούν να διορθώσουν γρήγορα.
Τι σημαίνει για τις ομάδες ασφαλείας και τους developers
Σε πρακτικό επίπεδο, η αυτοματοποίηση της δημιουργίας harness και της τριάρισης μειώνει το κόστος υιοθέτησης fuzzing σε ομάδες που δεν διαθέτουν εξειδικευμένους fuzzing engineers. Τα reproducer payloads και οι pull request‑τύπου αναφορές κάνουν το εύρημα άμεσα αξιοποιήσιμο από προγραμματιστές, μειώνοντας τον χρόνο από την ανακάλυψη έως τη διόρθωση.
Υπάρχουν όμως και ζητήματα προς προσοχή: το fuzzing απαιτεί σωστή ρύθμιση του build environment και ασφαλή χειρισμό των ευρημάτων, ειδικά όταν περιλαμβάνουν ενεργοποίηση σε firmware ή σε κρίσιμες βιβλιοθήκες. Επιπλέον, το εργαλείο δουλεύει καλύτερα όταν συνδυάζεται με πολιτικές διόρθωσης και CI pipelines που μπορούν να αποδεκτούν και να επαληθεύσουν fixes γρήγορα.
