English · Ελληνικά
access.log, και κάποιος (το box, ή ένας προηγούμενος επιτιθέμενος σε αυτό το κοινόχρηστο instance) έχει ήδη αφήσει έναν stale exit marker σε εκείνο το log που μπλοκάρει το gadget από το να ξαναπυροδοτηθεί. Το να αλλάξω σε μια παραλλαγή session-file poisoning του ίδιου CVE παρακάμπτει εντελώς το log και προσγειώνει RCE σαν www-data. Από εκεί ένα αρχείο .env παραδίδει τα credentials βάσης δεδομένων του Craft σε plaintext, ένα SELECT ενάντια στον πίνακα users τραβάει ένα bcrypt hash, και το rockyou το σπάει σε δευτερόλεπτα. Αυτό είναι SSH σαν adam και το user flag — αλλά το root είναι το πραγματικό γρίφος: ένα GNU Inetutils telnetd ακούει μόνο στο loopback, και ο αρχαίος χειρισμός του της μεταβλητής environment telnet USER (CVE-2026-24061) επιτρέπει σε έναν client να του δώσει -f root και να μπει κατευθείαν σαν root, χωρίς να ζητηθεί password.
Μόνο SSH και ένα web front end — τίποτα δεν κρύβεται πίσω από ένα vhost αυτή τη φορά.
Το site στη θύρα 80 είναι μια εγκατάσταση Craft CMS. Το /admin/login διαρρέει το ακριβές build στα paths footer/asset του:
Το Craft ≤5.6.16 είναι ευάλωτο στο CVE-2025-32432, ένα unauthenticated RCE στο feature δημιουργίας asset-transform. Η ρίζα του προβλήματος είναι μια αλυσίδα gadget Yii2: ο handler session του Craft υποστηρίζεται από file storage τύπου yii\web\PhpManager, και η δημιουργία asset-transform μπορεί να εξαναγκαστεί σε unserializing δεδομένων ελεγχόμενων από τον επιτιθέμενο από εκείνο το storage, που — μέσω του σωστού gadget — καταλήγει σε αυθαίρετη εκτέλεση PHP.
Το φυσικό PoC (cd-ratel/CVE-2025-32432) δουλεύει γράφοντας ένα payload PHP μέσα στο /var/log/nginx/access.log μέσω ενός φτιαγμένου User-Agent, μετά πυροδοτώντας το gadget asset-transform ώστε να κάνει include() το αρχείο log και να τρέξει τον injected κώδικα ανάμεσα σε markers output. Απέτυχε σε κάθε ID asset:
Το ίδιο το log ήταν το πρόβλημα: το access.log κουβαλούσε ήδη ένα stale statement exit; από μια προηγούμενη προσπάθεια εκμετάλλευσης (αυτό είναι ένα κοινόχρηστο instance HTB, οπότε κάποιος το χτύπησε πριν από μένα), που κάνει short-circuit την εκτέλεση PHP πριν το δικό του marker-wrapped payload του gadget τρέξει ποτέ. Τα PoCs log-poisoning είναι εύθραυστα ακριβώς επειδή εξαρτώνται από ένα αρχείο του οποίου δεν ελέγχουν το πλήρες περιεχόμενο.
Το να αλλάξω στο c0gnit00/CVE-2025-32432 ("CraftCMS2Shell") παρακάμπτει εντελώς το path log — κάνει αντ' αυτού poison το δικό του PHP session file του Craft (/var/lib/php/sessions/sess_<id>), στο οποίο τίποτα άλλο στο box δεν γράφει, και κάνει auto-brute-force το ID asset που χρειάζεται:
RCE σαν www-data, και το δικό του .env του Craft στο web root παραδίδει τα credentials βάσης δεδομένων εντελώς ξεκάθαρα:
Credentials MySQL root. Κατευθείαν στον πίνακα users για ένα hash να σπάσω:
Το bcrypt cost 13 είναι αργό, αλλά ο admin CMS πίσω από ένα "απλό" box συνήθως επαναχρησιμοποιεί μια πρώιμη καταχώρηση rockyou. Και το κάνει:
adam : darkangel — και το email του λογαριασμού admin του ίδιου του Craft λειτούργησε διπλά σαν system username, οπότε ούτε εκεί χρειάστηκε μάντεμα.Ο www-data δεν μπορούσε να διαβάσει το /home/adam απευθείας (mode 750, ανήκε στον adam:adam), οπότε αυτό το credential είναι ο μόνος τρόπος εισόδου. Το SSH το επιβεβαιώνει και ρίχνει το user flag:
Το sudo -l είναι αδιέξοδο — ο adam δεν έχει κανόνα, ούτε καν NOPASSWD — και το /root/root.txt είναι ένα καθαρό permission denied. Καμία παραξενιά SUID επίσης· το box θέλει μια υπηρεσία, όχι ένα τοπικό binary. Ο έλεγχος listeners αναδεικνύει κάτι στο loopback:
Ένας daemon telnet προσβάσιμος μόνο από το ίδιο το box είναι μια ισχυρή ένδειξη. Έλεγχος τι πραγματικά ακούει:
Το telnetd GNU Inetutils 1.9.3–2.7 είναι ευάλωτο στο CVE-2026-24061 (CVSS 9.8): τιμά τη διαπραγμάτευση ENVIRON του client telnet και περνά ό,τι διεκδικεί ο client σαν μεταβλητή USER κατευθείαν στο login σαν argument, unsanitized. Ένας client που διαπραγματεύεται USER=-f root κάνει το telnetd να τρέξει:
Το login -f προορίζεται για trusted callers όπως το getty, όχι για ένα argument που ένας απομακρυσμένος client telnet μπορεί να διαλέξει. Ο daemon δεν το ελέγχει ποτέ για λογική, οπότε είναι ένα authentication bypass μεταμφιεσμένο σαν bug argument-injection.
Η σημαία -l του client netkit telnet προορίζεται να κάνει ακριβώς αυτό (telnet -l '-froot' 127.0.0.1 23), αλλά το να κάνεις pipe εντολές μέσα του non-interactively μέσω ενός καναλιού SSH exec_command δεν δουλεύει — ο client δεν κατανέμει ποτέ ένα πραγματικό TTY, η διαπραγμάτευση telnet IAC/ENVIRON καταπίνεται πριν μπορέσει να συμβεί το login, και η σύνδεση απλά κλείνει. Το να κάνεις script το ωμό πρωτόκολλο socket με το χέρι από ένα heredoc SSH χτύπησε τον ίδιο τοίχο για τον ίδιο λόγο: χωρίς PTY, η διαπραγμάτευση μισοολοκληρώνεται, τίποτα δεν επιστρέφει.
Η αναζήτηση στο GitHub για ένα έτοιμο PoC ανέδειξε ένα που φαινόταν υποσχόμενο και αποδείχτηκε νάρκη: το jacubes/CVE-2026-24061 δεν είναι καθόλου exploit telnet — το rce.py του καλεί το _fetch_bytes(url, api_key) → _load_module_memory(...) → bootstrap(...), δηλαδή κατεβάζει και εκτελεί κώδικα ελεγχόμενο από επιτιθέμενο από έναν απομακρυσμένο server τη στιγμή που το τρέχεις. Απορρίφθηκε — αυτό είναι μια backdoor που φοράει αριθμό CVE, όχι ένα PoC.
exec/eval/dynamic import δεν αναπαράγει την ευπάθεια — σου ζητά να εμπιστευτείς έναν άγνωστο τρίτο με εκτέλεση κώδικα στο box (και πιθανώς στο δικό σου μηχάνημα, ανάλογα με το πού τρέχει).Η πραγματική λύση ήταν ένα PoC που υλοποιεί σωστά τη διαπραγμάτευση πρωτοκόλλου telnet αντί να βασίζεται στον interactive client — το Ish3ng0m4/CVE-2026-24061-Telnetd μιλάει ωμό IAC/DO/WILL/SB ENVIRON πάνω από ένα απλό socket, κάνει inject USER=-f root στο subnegotiation, και διαβάζει το shell κατευθείαν από το καλώδιο — χωρίς να χρειάζεται TTY:
adam επρόκειτο πάντα να φτάσει εκεί μόλις είχε shell καθόλου. Η μόνη πραγματική λύση είναι να μην τρέχεις telnetd — το SSH το έχει κάνει ξεπερασμένο ακριβώς για αυτή την κλάση bug.Χωρίς Metasploit στον host επίθεσης, οπότε και τα δύο CVEs έτρεξαν μέσω standalone PoCs Python αντί για module. Το pattern που είχε τη μεγαλύτερη σημασία ήταν να κάνω τα πάντα scriptable και non-interactive:
-c CMD του PoC session-poisoning επιστρέφει το output εντολής απευθείας στην απάντηση HTTP — δεν χρειάζεται reverse shell μόνο για να διαβάσεις ένα αρχείο .env ή να κάνεις query MySQL. Κράτησα ολόκληρη τη φάση καταμέτρησης σε κλήσεις τύπου-curl μιας-βολής.ssh. Μόλις τα credentials για τον adam ήταν στο χέρι, ένα λεπτό wrapper ssh_run.py (paramiko, ένα exec_command ανά κλήση) έκανε κάθε επόμενη εντολή μία μόνο scriptable κλήση αντί για ένα session interactive τύπου-pexpect.telnet του macOS (brew, netkit-derived) που τρέχει μέσω ενός καναλιού SSH χωρίς PTY δεν ολοκληρώνει ποτέ τη διαπραγμάτευση πρωτοκόλλου — το handshake ENVIRON της σημαίας -l χάνεται. Ένα PoC που κάνει το ίδιο τη διαπραγμάτευση IAC/ENVIRON πάνω από ένα ωμό socket παρακάμπτει όλο το πρόβλημα TTY, γι' αυτό το exploit που δουλεύει είναι ένας client πρωτοκόλλου from-scratch αντί για μια scripted κλήση του binary telnet του συστήματος.| → www-data | Craft CMS 5.6.16 pre-auth deserialization RCE μέσω μιας αλυσίδας gadget Yii2 PhpManager στο pipeline asset-transform (CVE-2025-32432 / CWE-502)· ένα plaintext .env κάθονταν μέσα στο web root με ζωντανά credentials βάσης δεδομένων |
| → adam | Credentials DB από το .env επαναχρησιμοποιημένα για να διαβαστεί ο πίνακας users· το password bcrypt του admin ήταν μια λέξη λεξικού σπάσιμη από rockyou σε δευτερόλεπτα (CWE-521) |
| → root | Το GNU Inetutils telnetd (1.9.3–2.7) εμπιστεύεται την τιμή USER διαπραγματευμένη μέσω ENVIRON του client telnet και την περνά unsanitized στο login, οπότε το USER=-f root γίνεται login -f root — ένα χωρίς-password session root (CVE-2026-24061 / CWE-287, CWE-88) |