Vulnerability scanning triage βήμα-βήμα: nmap, nuclei, nikto και χειροκίνητη επαλήθευση — από τα σήματα στο επαληθευμένο εύρημα

Ένα ολοκληρωμένο, εργαστηριακό walkthrough vulnerability scanning και triage — από τη χαρτογράφηση υπηρεσιών με nmap, στο template-based scanning με nuclei, στον έλεγχο web misconfigurations με nikto και, τέλος, στη χειροκίνητη επαλήθευση με curl. Ο στόχος δεν είναι «να τρέξουμε σαρωτές» αλλά να δείξουμε τη διαφορά που κρίνει την αξία ενός assessment: οι σαρωτές παράγουν σήματα, όχι αποδείξεις. Μέσα σε ένα απομονωμένο lab που κατέχουμε εξ ολοκλήρου, μετατρέπουμε περίπου 25 γραμμές θορυβώδους output σε ένα επαληθευμένο, προτεραιοποιημένο εύρημα (έκθεση ενός .git/ directory) — και ταυτόχρονα «σκοτώνουμε» με το χέρι ένα εντυπωσιακό αλλά ψευδώς θετικό εύρημα (δήθεν κρίσιμο CVE βασισμένο σε banner).

TL;DR (EN): A vulnerability-scanning triage chain — nmap, nuclei, nikto and manual verification — turning raw scanner signals into one validated finding while killing a false positive. The core lesson: scanners produce signals, humans and CTEM produce proof.

Νομική σημείωση / Authorization — διαβάστε πρώτα. Ολόκληρη η άσκηση εκτελέστηκε αποκλειστικά μέσα σε ένα απομονωμένο εργαστήριο που κατασκευάσαμε και κατέχουμε εξ ολοκλήρου. Ο μοναδικός στόχος (127.0.0.100:8080) είναι ένας δικός μας lab web server που τρέχει τοπικά, χωρίς καμία δημοσιευμένη θύρα προς το διαδίκτυο ή σε δίκτυα τρίτων. Οι διευθύνσεις, τα ονόματα (Meltemi Logistics AE), τα «μυστικά» (deploy-bot, git.meltemi.lab) και το ίδιο το repository είναι εικονικά και υπάρχουν μόνο μέσα στο lab. Το vulnerability scanning, ακόμη και το «αθώο», εναντίον συστημάτων που δεν σας ανήκουν ή για τα οποία δεν έχετε ρητή γραπτή εξουσιοδότηση, είναι παράνομο και μπορεί να θεωρηθεί επίθεση. Σαρώστε μόνο ό,τι σας ανήκει ή ό,τι έχετε εντολή να ελέγξετε, μέσα σε συμφωνημένο scope. Ο σκοπός του άρθρου είναι αμιγώς εκπαιδευτικός και αμυντικός.

Εισαγωγή: γιατί το vulnerability scanning είναι η αρχή, όχι το τέλος

Υπάρχει μια βαθιά παρανόηση που στοιχίζει ακριβά σε πολλούς οργανισμούς: ότι ένας vulnerability scanner «βρίσκει τις ευπάθειες». Δεν τις βρίσκει. Ένας σαρωτής παράγει ενδείξεις — σήματα ότι κάτι ίσως είναι πρόβλημα. Το αν το σήμα αντιστοιχεί σε πραγματική, εκμεταλλεύσιμη έκθεση, ποια είναι η πραγματική του σοβαρότητα, και τι πρέπει να διορθωθεί πρώτο, είναι δουλειά που κανένα εργαλείο δεν κάνει μόνο του. Είναι δουλειά ανθρώπου.

Η απόσταση ανάμεσα στο «ο σαρωτής έβγαλε 200 findings» και στο «να ποια τρία πρέπει να διορθώσετε αυτή την εβδομάδα και γιατί» είναι, ουσιαστικά, η απόσταση ανάμεσα σε ένα αυτοματοποιημένο report που κανείς δεν διαβάζει και σε ένα assessment που αλλάζει την ασφάλεια ενός οργανισμού. Αυτή η απόσταση λέγεται triage: η διαδικασία με την οποία διαχωρίζεις τον θόρυβο από το σήμα, το σήμα από το εύρημα, και το εύρημα από την απόδειξη.

Σε αυτό το άρθρο θα δείτε μια αλυσίδα τεσσάρων εργαλείων να κάνει ακριβώς αυτό, βήμα-βήμα, με πραγματικές εντολές, πραγματικό output και πραγματικά screenshots από την εκτέλεση σε δικό μας απομονωμένο lab. Θα ξεκινήσουμε με τρεις σαρωτές που, ο καθένας με τον τρόπο του, μας πλημμυρίζουν με σήματα. Και θα τελειώσουμε με το πιο υποτιμημένο εργαλείο ολόκληρης της αλυσίδας — το curl στα χέρια ενός αναλυτή — που μετατρέπει τα σήματα σε μία απόφαση: αυτό είναι αληθινό και σοβαρό, εκείνο είναι ψευδώς θετικό και το πετάμε.

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

Το σενάριο είναι οικείο σε κάθε ομάδα ασφάλειας. Μια φανταστική εταιρεία, η «Meltemi Logistics AE», έχει ένα εσωτερικό web portal. Κάποιος το έβαλε online βιαστικά. Η δουλειά μας είναι να το «σαρώσουμε» όπως θα έκανε ένας επιτιθέμενος στη φάση της αναγνώρισης — αλλά με τη σκέψη ενός αμυντικού που θέλει να ξέρει τι πραγματικά κινδυνεύει.

Το portal εκθέτει, σκόπιμα, μερικά πράγματα που οι σαρωτές θα σημάνουν:

• Ελλείποντα security headers (δεν στέλνει Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security κ.λπ.) — αληθινό αλλά χαμηλής σοβαρότητας σήμα.
• Ένα robots.txt που «διαρρέει» διαδρομές (/admin/, /backup/, /.git/, /config/) — information leak.
• Ένα εκτεθειμένο .git/ directory (/.git/config, /.git/HEAD) — αυτό είναι το αληθινό, σοβαρό εύρημα.
• Ένα «παλιό» banner Server: Apache/2.4.49 (Unix) — που θα γίνει η παγίδα μας.

Και εδώ είναι το κρίσιμο κόλπο του lab: το banner Apache/2.4.49 είναι πλαστό. Η έκδοση 2.4.49 του Apache είναι διαβόητη για το CVE-2021-41773 (path traversal / RCE). Κάθε banner-based σαρωτής θα «ουρλιάξει» ότι ο server είναι ευάλωτος. Στην πραγματικότητα ο στόχος μας δεν είναι καν πραγματικός Apache — είναι ένας ελεγχόμενος server που απλώς δηλώνει αυτό το banner. Το exploit δεν δουλεύει. Αυτό είναι το κλασικότερο false positive που υπάρχει, και θα δείξουμε ακριβώς πώς το ξεσκεπάζουμε.

Απομόνωση και τι εκτελέστηκε πραγματικά — με πλήρη ειλικρίνεια. Ο ιδανικός τρόπος να στηθεί αυτό το lab είναι ένα container σε ένα ιδιωτικό Docker bridge χωρίς published ports, ώστε ο στόχος να είναι προσβάσιμος μόνο μέσω της bridge IP του από τον host. Για τη συγκεκριμένη εκτέλεση, ο Docker daemon δεν ήταν διαθέσιμος στο περιβάλλον αξιολόγησης (χωρίς δικαιώματα εκκίνησης της υπηρεσίας), και αυτό δεν το κρύβουμε. Αντ’ αυτού, στήσαμε τον ίδιο ακριβώς στόχο ως πραγματική διεργασία σε μια αποκλειστική loopback διεύθυνση (127.0.0.100:8080). Στο Linux, ολόκληρο το 127.0.0.0/8 είναι host-local: η διεύθυνση 127.0.0.100 δεν είναι προσβάσιμη από κανένα εξωτερικό δίκτυο, οπότε η ιδιότητα «καμία έκθεση προς τα έξω» διατηρείται πλήρως. Στον φάκελο lab/ παραδίδουμε και το docker-compose.yml (ιδιωτικό bridge 172.30.0.0/24, container 172.30.0.10, χωρίς ports:) ώστε η ίδια δοκιμή να αναπαραχθεί αυτούσια σε οποιονδήποτε host με Docker. Το σημαντικό είναι ότι όλη η ανάλυση είναι 100% πραγματική: κάθε γραμμή output στα screenshots προέρχεται από πραγματική εκτέλεση των εργαλείων εναντίον του στόχου.

Όλα τα prompts έχουν εξομαλυνθεί σε ένα ουδέτερο kali@lab, ώστε να μην εκτίθεται καμία πληροφορία του πραγματικού μηχανήματος.

Γιατί αυτά τα τέσσερα εργαλεία (και με αυτή τη σειρά)

Το vulnerability triage απαντά σε τέσσερα διαδοχικά ερωτήματα, και κάθε εργαλείο είναι φτιαγμένο να απαντά σε ένα:

1. «Τι τρέχει εδώ και τι έκδοση;» — Το nmap κάνει service & version discovery: ποιες θύρες είναι ανοιχτές, ποια υπηρεσία, ποιο banner. Είναι το θεμέλιο· χωρίς αυτό σαρώνεις στα τυφλά.
2. «Ταιριάζει κάτι με γνωστά μοτίβα ευπαθειών/εκθέσεων;» — Το nuclei τρέχει χιλιάδες templates που δοκιμάζουν συγκεκριμένες συνθήκες (exposures, misconfigurations, CVEs) και επιστρέφουν δομημένα, σοβαρότητα-ανά-εύρημα αποτελέσματα.
3. «Τι λέει ειδικά ο web server για misconfigurations;» — Το nikto είναι ένας ιστορικός web scanner εστιασμένος σε server misconfig, επικίνδυνα αρχεία και banner-based ελέγχους. Παράγει πολλά σήματα — μερικά χρυσάφι, μερικά θόρυβο.
4. «Είναι αληθινό; Απόδειξέ το.» — Το curl (ή ο browser, ή ένα proxy) στα χέρια του αναλυτή είναι το εργαλείο της επαλήθευσης. Εδώ ένα σήμα γίνεται εύρημα ή πεθαίνει ως false positive.

Η σειρά έχει σημασία: πλατύ -> στοχευμένο -> επιβεβαίωση. Οι εκδόσεις που χρησιμοποιήθηκαν: Nmap 7.94SVN, nuclei v3.11.0 (templates v10.4.5), Nikto v2.6.0, curl 8.x.

nmap — Χαρτογράφηση υπηρεσιών και το πρώτο banner

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

Το nmap είναι ο de facto χάρτης κάθε engagement. Πριν σαρώσεις για ευπάθειες, πρέπει να ξέρεις τι σαρώνεις: ποιες θύρες απαντούν, ποια υπηρεσία τρέχει σε καθεμία, και — κρίσιμα — ποια έκδοση δηλώνει. Το version detection (-sV) και τα default scripts (-sC, μέσω της μηχανής NSE) μετατρέπουν ένα «ανοιχτό port 8080» σε «Apache httpd 2.4.49, τίτλος σελίδας X, και — για κοίτα — υπάρχει .git/».

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

+-------------------------+--------------------------------------------------------+
| Flag                    | Τι κανει                                                |
+-------------------------+--------------------------------------------------------+
| -sV                     | Service/version detection (banner, product, version)   |
| -sC                     | Default NSE scripts (http-title, http-git, robots...)  |
| -p<ports>               | Ποιες θυρες (π.χ. -p8080, -p- για ολες τις 65535)       |
| -Pn                     | Skip host discovery -> "treat host as up" (χρησιμο σε   |
|                         | loopback/filtered hosts)                                |
| -T<0-5>                 | Timing template (T4 = γρηγορα, T2 = discreet)           |
| -A                      | Aggressive: -sV -sC -O + traceroute μαζι                |
| -oN / -oX / -oG         | Output σε normal / XML / grepable αρχειο                |
| --script <name>         | Συγκεκριμενο NSE script (π.χ. --script http-git)        |
+-------------------------+--------------------------------------------------------+

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

nmap -sV -sC -p8080 -Pn 127.0.0.100

Το πραγματικό αποτέλεσμα

Μέσα σε 6 δευτερόλεπτα, το nmap μας έδωσε τρία ξεχωριστά σήματα ταυτόχρονα. Πρώτον, το banner: Apache httpd 2.4.49 ((Unix)). Δεύτερον — και εντυπωσιακά — το NSE script http-git όχι μόνο εντόπισε το εκτεθειμένο .git/, αλλά διάβασε και το remote: http://git.meltemi.lab/internal/logistics-portal.git. Τρίτον, το http-robots.txt ανέφερε 4 disallowed entries και μας τις έδωσε: /admin/ /backup/ /.git/ /config/.

Ήδη εδώ ένας έμπειρος αναλυτής έχει σχηματίσει υπόθεση: το .git/ είναι το ενδιαφέρον· το banner θέλει επαλήθευση· το robots.txt είναι χρήσιμο context. Αλλά ακόμη δεν έχουμε αποδείξει τίποτα. Έχουμε σήματα.

nuclei — Template-based scanning με σοβαρότητα ανά εύρημα

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

Το nuclei της ProjectDiscovery άλλαξε τον τρόπο που σκεφτόμαστε το vuln scanning. Αντί για έναν μονολιθικό σαρωτή, είναι μια μηχανή που εκτελεί templates: μικρά, αναγνώσιμα YAML αρχεία που περιγράφουν ακριβώς πώς να ελεγχθεί μια συνθήκη (ποιο request να σταλεί, ποιο matcher να ταιριάξει στην απόκριση) και τι σοβαρότητα έχει. Η κοινότητα συντηρεί χιλιάδες templates (εδώ φορτώθηκαν 6.868). Το κρίσιμο πλεονέκτημα: τα καλά templates δοκιμάζουν τη συνθήκη, δεν μαντεύουν από banner. Αυτό, όπως θα δούμε, κάνει το nuclei πολύ πιο ακριβές από τους παλιάς σχολής banner-based ελέγχους.

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

+----------------------------------+-----------------------------------------------+
| Flag                             | Τι κανει                                       |
+----------------------------------+-----------------------------------------------+
| -u <url>                         | Ο στοχος (μπορει και -l list.txt)              |
| -tags <a,b,c>                    | Τρεξε μονο templates με αυτα τα tags           |
| -severity <levels>               | Φιλτραρε ανα σοβαροτητα (info..critical)       |
| -t <path>                        | Τρεξε συγκεκριμενο template/φακελο             |
| -no-color                        | ANSI-clean output (για logs/screenshots)       |
| -stats / -si <sec>               | Live στατιστικα προοδου καθε N δευτερολεπτα     |
| -jsonl -o out.jsonl              | Δομημενο output (ιδανικο για pipeline/SIEM)     |
| -rl <n> / -c <n>                 | Rate limit / concurrency (ευγενικο scanning)   |
| -update-templates                | Ενημερωση της βασης templates                   |
+----------------------------------+-----------------------------------------------+

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

nuclei -u http://127.0.0.100:8080/ \
  -tags exposure,git,misconfig,tech,cve \
  -severity info,low,medium,high,critical \
  -no-color -stats -si 5

Το πραγματικό αποτέλεσμα

Δεκατέσσερα matches, αλλά ας τα διαβάσουμε με κριτικό μάτι. Τα δέκα http-missing-security-headers και το waf-detect και το apache-detect είναι όλα σοβαρότητας info — χρήσιμο context, μηδενική άμεση σοβαρότητα. Το εύρημα που ξεχωρίζει είναι ένα: [git-config] [medium] http://127.0.0.100:8080/.git/config.

Και εδώ το πιο διδακτικό σημείο ολόκληρου του άρθρου: παρότι το banner λέει «Apache 2.4.49», το nuclei δεν σήμανε το CVE-2021-41773. Γιατί; Επειδή το template του συγκεκριμένου CVE δεν κοιτάζει το banner — στέλνει το πραγματικό traversal payload και ελέγχει αν επιστρέφει περιεχόμενο του /etc/passwd. Εφόσον ο στόχος δεν είναι πραγματικά ευάλωτος, το template δεν ταίριαξε. Αυτό είναι το nuclei στα καλά του: ακρίβεια μέσω δοκιμής, όχι μαντεψιάς. Κρατήστε το — γιατί το nikto θα κάνει ακριβώς το αντίθετο.

nikto — Web server misconfigurations και ο banner-based έλεγχος

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

Το nikto είναι ένας από τους παλαιότερους web scanners και παραμένει χρήσιμος για γρήγορο έλεγχο server misconfigurations: επικίνδυνα/εκτεθειμένα αρχεία, default files, ελλείποντα headers, ρυθμίσεις που διαρρέουν πληροφορία. Είναι θορυβώδης εξ ορισμού — τρέχει χιλιάδες γνωστά paths — και ένα μεγάλο μέρος της αξίας του εξαρτάται από το πόσο καλά ξέρεις να φιλτράρεις το output του. Κρίσιμο χαρακτηριστικό για το σημερινό μάθημα: το nikto κάνει banner-based version checks. Αυτό είναι ταυτόχρονα το δυνατό και το αδύναμο σημείο του.

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

+----------------------------------+-----------------------------------------------+
| Flag                             | Τι κανει                                       |
+----------------------------------+-----------------------------------------------+
| -h <host>                        | Ο στοχος (host ή URL)                          |
| -p <port>                        | Θυρα (π.χ. 8080)                               |
| -ssl / -nossl                    | Εξαναγκασμος TLS ή plain                        |
| -Tuning <x>                      | Ποιες κατηγοριες ελεγχων (π.χ. 1=file, b=id)    |
| -nointeractive                   | Χωρις prompts (για scripting/CI)               |
| -Format / -o                     | Output format (csv,xml,htm) + αρχειο           |
| -Display V                       | Verbose (δειχνει και requests)                  |
| -useragent <ua>                  | Custom User-Agent                              |
+----------------------------------+-----------------------------------------------+

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

nikto -h 127.0.0.100 -p 8080 -nointeractive

Το πραγματικό αποτέλεσμα

Το nikto μας έδωσε 11 items. Δύο κατηγορίες μας ενδιαφέρουν. Πρώτον, η καλή είδηση: εντόπισε ανεξάρτητα το /.git/HEAD και το /.git/config. Αυτή είναι η τρίτη ανεξάρτητη επιβεβαίωση του ίδιου ευρήματος (nmap -> nuclei -> nikto), κάτι που αυξάνει κατακόρυφα την εμπιστοσύνη μας ότι το .git/ είναι πραγματικά εκεί.

Δεύτερον, η επικίνδυνη γραμμή: Apache/2.4.49 appears to be outdated (current is at least 2.4.66). Αυτό είναι το banner-based σήμα. Ένας βιαστικός αναλυτής θα σκεφτεί αμέσως: «2.4.49 -> CVE-2021-41773 -> critical path traversal / RCE» και θα το γράψει στο report ως κρίσιμο. Και θα κάνει λάθος. Το nikto δεν δοκίμασε το exploit· απλώς διάβασε το banner και το σύγκρινε με μια βάση εκδόσεων. Το σήμα είναι πραγματικό (το banner όντως λέει 2.4.49), αλλά το συμπέρασμα (άρα είναι ευάλωτος) είναι υπόθεση. Ώρα να την ελέγξουμε.

Χειροκίνητη επαλήθευση — από το σήμα στην απόδειξη

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

Εδώ κλείνει η αλυσίδα. Δύο ερωτήματα έμειναν ανοιχτά: (Α) το εκτεθειμένο .git/ είναι πραγματικά αξιοποιήσιμο εύρημα ή απλώς ένα κενό directory; (Β) το «Apache 2.4.49 -> CVE-2021-41773» είναι αληθινό ή banner-θόρυβος; Και τα δύο τα απαντάμε με το ταπεινότερο εργαλείο του κόσμου: το curl. Η αρχή είναι απλή και ανυποχώρητη — κανένα εύρημα δεν μπαίνει σε report χωρίς χειροκίνητη επιβεβαίωση.

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

# [A] VALIDATE: είναι το εκτεθειμένο .git πραγματικό;
curl -s http://127.0.0.100:8080/.git/config
curl -s http://127.0.0.100:8080/.git/HEAD
# [B] KILL FALSE POSITIVE: banner λέει 2.4.49 -> είναι όντως ευάλωτο σε CVE-2021-41773;
curl -s -o /dev/null -w 'status=%{http_code}\n' \
  'http://127.0.0.100:8080/cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd'
curl -s 'http://127.0.0.100:8080/cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd'

Το πραγματικό αποτέλεσμα

Δύο απαντήσεις, κρυστάλλινες.

(Α) Το .git/ είναι αληθινό εύρημα. Το curl στο /.git/config δεν επέστρεψε κενό ή μια σελίδα σφάλματος — επέστρεψε πραγματικό περιεχόμενο git config: το [core] section, το [remote "origin"] με το url = http://git.meltemi.lab/internal/logistics-portal.git, και ένα [user] με name = deploy-bot και email = [email protected]. Αυτό δεν είναι θεωρητικός κίνδυνος. Ένα εκτεθειμένο .git/ σημαίνει ότι ένας επιτιθέμενος μπορεί να κατεβάσει ολόκληρο το ιστορικό του repository (με εργαλεία όπως το git-dumper), να διαβάσει τον source code, να ανακαλύψει hardcoded credentials, API keys, εσωτερικά endpoints και τη λογική της εφαρμογής. Ταξινομείται ως High, επαληθευμένο, με ξεκάθαρο blast radius.

(Β) Το «CVE-2021-41773» είναι false positive. Το traversal payload επέστρεψε status=404 και <h1>404 Not Found</h1> — καμία γραμμή root:x:0:0 από το /etc/passwd. Ο server δεν είναι ευάλωτος. Το banner Apache/2.4.49 ήταν παραπλανητικό (πλαστό/decoy). Το εντυπωσιακό «critical» που θα κοσμούσε ένα αυτοματοποιημένο report μόλις πέθανε με μία εντολή. Αυτή είναι η αξία της επαλήθευσης: όχι μόνο επιβεβαιώνει τα αληθινά, αλλά και αφαιρεί τα ψεύτικα — που είναι εξίσου σημαντικό, γιατί κάθε false positive που φτάνει στον πελάτη κοστίζει χρόνο, αξιοπιστία και εμπιστοσύνη.

Από τα σήματα στο επαληθευμένο εύρημα — ο πυρήνας του triage

Ας δούμε ολόκληρη τη διαδρομή σε ένα καρέ. Τρεις σαρωτές παρήγαγαν περίπου 25 γραμμές output. Το triage τις πέρασε από ένα ανθρώπινο φίλτρο και κατέληξε σε ακριβώς ένα προτεραιοποιημένο, αποδεδειγμένο εύρημα και ακριβώς ένα false positive που έπρεπε να απορριφθεί.

Η ροή της σκέψης, βήμα-βήμα:

1. De-duplication. Το εκτεθειμένο .git/ εμφανίστηκε σε τρία εργαλεία. Δεν είναι τρία findings· είναι ένα, με τριπλή επιβεβαίωση. Αντίθετα, τα ελλείποντα headers εμφανίστηκαν και στο nuclei και στο nikto — πάλι ένα θέμα, όχι δεκαπέντε.
2. Διαχωρισμός σοβαρότητας. Τα info-level σήματα (headers, waf-detect, apache-detect) είναι πραγματικά αλλά χαμηλής προτεραιότητας hygiene. Δεν διορθώνεις πρώτα αυτά.
3. Το ερώτημα του blast radius. Ανάμεσα στα εναπομείναντα, ποιο δίνει τη μεγαλύτερη αξία σε έναν επιτιθέμενο; Το .git/ — γιατί ξεκλειδώνει source code και μυστικά. Αυτό γίνεται το κορυφαίο εύρημα.
4. Η δοκιμή της απόδειξης. Πριν το γράψουμε, το αποδεικνύουμε με curl. Και πριν γράψουμε το «critical CVE», επίσης το δοκιμάζουμε — και το απορρίπτουμε.

Το δίδαγμα είναι ποσοτικό και ανελέητο: οι σαρωτές παράγουν σήματα· οι άνθρωποι παράγουν αποδείξεις. Αυτό το χάσμα είναι ολόκληρος ο λόγος ύπαρξης του validated exposure management.

Αντιστοίχιση με MITRE ATT&CK — τι κάνει η αλυσίδα

Το vulnerability scanning και το information gathering αντιστοιχούν στην τακτική Reconnaissance του MITRE ATT&CK. Χαρτογραφούμε τις τεχνικές για τους αμυνόμενους — ώστε ένα SOC να αναγνωρίζει αυτά τα μοτίβα στα logs του — και όχι για να τις οπλοποιήσουμε. Η εκμετάλλευση (T1190) αναφέρεται ως ο κατάντη κίνδυνος που ξεκλειδώνει το εύρημά μας, δεν εκτελέστηκε.

+-------------+------------------------------------------+--------------------------+
| Technique   | Ονομα                                    | Που στην αλυσιδα          |
+-------------+------------------------------------------+--------------------------+
| T1595.002   | Active Scanning: Vulnerability Scanning  | nuclei + nikto templates |
| T1595.001   | Active Scanning: Scanning IP/ports       | nmap -sV service disco   |
| T1592.002   | Gather Victim Host Info: Software        | Apache/2.4.49 banner     |
| T1213       | Data from Information Repositories       | εκτεθειμενο /.git/ ->    |
|             |                                          | source & secrets         |
| T1190       | Exploit Public-Facing Application        | ο κινδυνος που ανοιγει   |
|             |                                          | το .git (ΔΕΝ εκτελεστηκε)|
+-------------+------------------------------------------+--------------------------+

Η αξία της αντιστοίχισης είναι πρακτική: όταν μεταφράζεις ένα σήμα σε ένα ATT&CK technique ID, το συνδέεις αυτόματα με τεκμηριωμένα detections και mitigations. Ένα SOC που ξέρει ότι δέχεται T1595.002 activity μπορεί να στήσει alerting για ασυνήθιστο όγκο 404, γνωστά scanner User-Agents (nuclei/nikto), και μαζικά requests σε ευαίσθητα paths όπως /.git/.

Επαλήθευση — γιατί εμπιστευόμαστε αυτά τα ευρήματα

Η μεθοδολογία μας στηρίζεται σε έναν κανόνα: κανένα εύρημα δεν στέκεται σε ένα μόνο εργαλείο.

• Εκτεθειμένο .git/ (VALIDATED, High) — εμφανίστηκε στο nmap (http-git script, μαζί με το remote), στο nuclei (git-config, medium), και στο nikto (/.git/HEAD + /.git/config). Τρεις ανεξάρτητες πηγές. Και, καθοριστικά, το περιεχόμενο ανακτήθηκε χειροκίνητα με curl — είδαμε το πραγματικό config με το remote και την ταυτότητα του deploy-bot. Τέσσερις οπτικές, ίδιο συμπέρασμα.
• «CVE-2021-41773» (FALSE POSITIVE, killed) — προήλθε αποκλειστικά από banner-based inference του nikto. Το nuclei, που δοκιμάζει τη συνθήκη, δεν το επιβεβαίωσε. Και η χειροκίνητη δοκιμή του exploit επέστρεψε 404. Δύο ανεξάρτητες ενδείξεις ότι δεν υπάρχει ευπάθεια, συν η απουσία θετικού από τον ακριβέστερο σαρωτή. Απορρίπτεται με βεβαιότητα.

Αυτή η διασταύρωση δεν είναι φορμαλισμός. Είναι η διαφορά ανάμεσα σε ένα report που ο πελάτης εμπιστεύεται και σε ένα report που τον στέλνει να κυνηγήσει φαντάσματα.

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

Στην πράξη, αυτή η αλυσίδα σκοντάφτει σε προβλέψιμα σημεία:

• nmap δεν βλέπει τον host — σε loopback ή σε φιλτραρισμένους στόχους, το host discovery μπορεί να αποτύχει. Λύση: -Pn ώστε το nmap να θεωρήσει τον host «up» και να προχωρήσει στο port scan.
• nuclei δεν έχει templates / είναι παλιά — στο πρώτο τρέξιμο κάνε nuclei -update-templates. Χωρίς αυτά, το scan βγάζει μηδέν matches και μοιάζει «σπασμένο».
• nuclei σαρώνει και άλλες θύρες/hosts — ορισμένα network-level templates δοκιμάζουν και υπηρεσίες πέρα από το web (π.χ. το τοπικό SSH του ίδιου του host στη loopback). Είναι φυσιολογικός θόρυβος· περιόρισέ το με -tags ή σκόπευσε συγκεκριμένα templates με -t.
• nikto: «Required module not found: JSON / XML::Writer» — το nikto χρειάζεται μερικά Perl modules. Λύση: εγκατέστησέ τα (cpan JSON XML::Writer ή μέσω πακέτων διανομής) ή δείξε το PERL5LIB σε μια φορητή εγκατάσταση των modules.
• Πάρα πολύ output από nikto — χρησιμοποίησε -Tuning για να περιορίσεις τις κατηγορίες ελέγχων και -Format htm -o report.html για ευανάγνωστο αποτέλεσμα.
• False positives παντού — αυτό δεν είναι bug, είναι η φύση των σαρωτών. Η λύση δεν είναι «καλύτερος σαρωτής»· είναι triage και χειροκίνητη επαλήθευση, ακριβώς όπως δείξαμε.

Άμυνα & γιατί το scan δεν αρκεί — η καρδιά του άρθρου

Κάθε σήμα που είδαμε αντιστοιχεί σε μια συγκεκριμένη αμυντική ενέργεια. Αλλά το βαθύτερο μάθημα είναι μεθοδολογικό, όχι τεχνικό. Ας δούμε και τα δύο.

1. Μην εκθέτετε ποτέ .git/, .env, backups και config. Το εκτεθειμένο .git/ είναι από τα πιο υποτιμημένα και πιο καταστροφικά misconfigurations στο web. Ένα git-dumper μετατρέπει το εκτεθειμένο directory σε ολόκληρο τον source code σας — με το ιστορικό του, όπου συχνά κρύβονται credentials που «διαγράφηκαν» αλλά ζουν στα commits. Η άμυνα: block στον web server κάθε πρόσβαση σε .git/, .svn/, .env, *.bak, *.sql, .DS_Store· deploy artifacts (όχι working copies) στο production· και secret scanning στο CI/CD ώστε τα μυστικά να μη φτάνουν ποτέ στο repo.

2. Ενεργοποιήστε security headers. Content-Security-Policy, Strict-Transport-Security (HSTS), X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy. Χαμηλή σοβαρότητα το καθένα, αλλά μαζί μειώνουν το attack surface για XSS, clickjacking και MIME-sniffing επιθέσεις — και είναι από τα φθηνότερα hardening measures που υπάρχουν.

3. Patch & version hygiene — αλλά μη βασίζεστε στο banner. Ναι, κρατήστε τον Apache/nginx ενημερωμένο. Αλλά προσέξτε το αντίστροφο δίδαγμα: το banner δεν είναι απόδειξη ευπάθειας. Πολλοί οργανισμοί «κρύβουν» ή αλλάζουν banners (server_tokens off, WAF rewrites, backported patches που κρατούν παλιό version string). Ένας αμυνόμενος που εμπιστεύεται τυφλά τα banners θα κυνηγά φαντάσματα· ένας που τα αγνοεί μπορεί να χάσει πραγματικά προβλήματα. Η απάντηση και στις δύο περιπτώσεις είναι η ίδια: επαλήθευση.

4. Και το κρίσιμο: το scan παράγει σήματα, όχι απόδειξη. Εδώ είναι η ουσία. Ένας οργανισμός που «τρέχει έναν vulnerability scanner κάθε μήνα» και θεωρεί ότι κάνει exposure management αυταπατάται. Ο σαρωτής θα παράγει εκατοντάδες findings, ανακατεμένα info-level θόρυβο με πραγματικά προβλήματα, μαζί με false positives σαν το «critical Apache CVE» που είδαμε. Χωρίς triage (de-duplication, προτεραιοποίηση κατά blast radius) και χωρίς validation (χειροκίνητη απόδειξη ότι το εύρημα είναι αληθινό και εκμεταλλεύσιμο), το output είναι θόρυβος που δημιουργεί ψευδή αίσθηση ασφάλειας — ή, χειρότερα, alert fatigue που θάβει το ένα πραγματικό εύρημα κάτω από εκατό ασήμαντα.

Αυτή είναι ακριβώς η προσέγγιση της Audax: validated, human-led exposure management. Δεν παραδίδουμε το raw output ενός σαρωτή. Παραδίδουμε τα ευρήματα που αποδείξαμε ότι σας εκθέτουν, προτεραιοποιημένα κατά πραγματικό ρίσκο, με τα false positives ήδη αφαιρεμένα. Είναι η μετάβαση από το «έχουμε έναν σαρωτή» στο συνεχές, επικυρωμένο exposure management (CTEM) — και η βάση για την απόδειξη ανθεκτικότητας που απαιτούν η NIS2 και ο DORA, όπου το ζητούμενο δεν είναι «τρέξαμε ένα scan» αλλά «αποδεδειγμένη ικανότητα εντοπισμού και διαχείρισης της έκθεσης».

Δυνατά σημεία της αλυσίδας

• Μηδενικό κόστος, ώριμα εργαλεία. nmap, nuclei και nikto είναι open source και de facto πρότυπα. Η μεθοδολογία μεταφέρεται αυτούσια σε κάθε ομάδα.
• Συμπληρωματικότητα. Το nmap δίνει το θεμέλιο, το nuclei την ακρίβεια της δοκιμής, το nikto την ευρύτητα του web coverage. Μαζί καλύπτουν διαφορετικές οπτικές του ίδιου στόχου.
• Διασταυρώσιμα αποτελέσματα. Η επικάλυψη (το .git σε τρία εργαλεία) δεν είναι σπατάλη — είναι επιβεβαίωση.
• Αυτοματοποιήσιμο. Το nuclei με -jsonl τροφοδοτεί pipelines και SIEM· η αλυσίδα μπαίνει εύκολα σε CI/CD ή σε προγραμματισμένα scans.

Περιορισμοί και αδυναμίες

• Θόρυβος & false positives. Όπως δείξαμε, οι σαρωτές (ιδίως banner-based έλεγχοι) παράγουν ψευδώς θετικά. Χωρίς triage, το output παραπλανά.
• Καμία ιεράρχηση επιχειρησιακού ρίσκου. Ένα εργαλείο δεν ξέρει ότι το .git/ σας περιέχει τα production secrets ενώ το άλλο repo είναι άδειο. Η προτεραιοποίηση κατά business impact είναι ανθρώπινη.
• Coverage gaps. Το authenticated scanning, η business-logic λογική, τα chained exploits και τα IDOR/access-control θέματα σπάνια πιάνονται από generic σαρωτές. Θέλουν manual testing.
• Ευθύνη scope. Ένας ισχυρός σαρωτής σε λάθος χέρια/scope είναι επικίνδυνος. Το rate limiting, το authorization και το σαφές engagement scope είναι υποχρεωτικά.

Θέματα ασφάλειας κατά τη χρήση

• Scope & εξουσιοδότηση πάνω απ’ όλα. Σαρώνετε μόνο ό,τι σας ανήκει ή ό,τι έχετε εντολή. Το nuclei/nikto σε δίκτυο τρίτου, ακόμη και «κατά λάθος», είναι επίθεση.
• Rate limiting & αποφυγή DoS. Ορισμένα templates/checks μπορούν να επιβαρύνουν έναν εύθραυστο server. Χρησιμοποιήστε -rl/-c και συνεννοηθείτε για παράθυρα δοκιμών.
• Ευαίσθητα ευρήματα. Το curl στο /.git/config κατέβασε πραγματικά (lab) credentials. Σε πραγματικό engagement, τέτοια δεδομένα είναι εμπιστευτικά evidence: κρυπτογραφημένα at-rest, ελεγχόμενη πρόσβαση, ασφαλής διαγραφή.
• Καθαρισμός. Μετά την άσκηση σταματήσαμε τον lab στόχο και διατηρούμε μόνο ελεγχόμενα, εικονικά τεκμήρια.

Πού μπορεί να χρησιμοποιηθεί επαγγελματικά

• Penetration testing: η αλυσίδα recon -> scan -> triage -> validation είναι το πρώτο κεφάλαιο κάθε web engagement.
• Attack Surface Management: περιοδικό scanning εξωτερικών assets, με validation ώστε τα tickets να περιέχουν μόνο πραγματικά ευρήματα.
• Vulnerability Management: τροφοδοσία ενός προγράμματος διαχείρισης ευπαθειών με προτεραιοποιημένα, επαληθευμένα δεδομένα.
• DevSecOps / CI-CD: nuclei σε pipeline για να πιάνει exposures (εκτεθειμένα .git/, .env, misconfig) πριν φτάσουν στο production.
• Purple Teaming & compliance: επαλήθευση ότι το SOC βλέπει τη scanning δραστηριότητα — στοιχείο που στην Audax εντάσσουμε στις υπηρεσίες adversary validation.

Πότε δεν πρέπει να χρησιμοποιηθεί

• Ποτέ σε συστήματα τρίτων χωρίς γραπτή εξουσιοδότηση. Είναι παράνομο.
• Όχι ως υποκατάστατο πλήρους pentest. Οι σαρωτές δεν πιάνουν business logic, chained attacks ή access-control θέματα. Είναι η αρχή, όχι το τέλος.
• Όχι «τρέξε και παράδωσε το raw output». Report χωρίς triage και validation βλάπτει περισσότερο απ’ όσο ωφελεί.
• Όχι σε production χωρίς rate limiting & παράθυρο. Ο κίνδυνος διαθεσιμότητας είναι πραγματικός.

Τελική αξιολόγηση

Η αλυσίδα nmap -> nuclei -> nikto -> χειροκίνητη επαλήθευση είναι το standard toolkit της φάσης vulnerability assessment — και για καλό λόγο. Καλύπτει το φάσμα από τη χαρτογράφηση μέχρι την ακριβή δοκιμή, με μηδενικό κόστος αδειοδότησης. Στο εργαστήριό μας, μέσα σε λίγα λεπτά, μετατρέψαμε τον θόρυβο τριών σαρωτών σε ένα επαληθευμένο, High εύρημα (εκτεθειμένο .git/) και απορρίψαμε ένα εντυπωσιακό false positive (banner-based CVE) που θα είχε μολύνει κάθε αυτοματοποιημένο report.

Η αξία, όμως, δεν είναι στα εργαλεία — είναι στη μεθοδολογία. Τα εργαλεία τα κατεβάζει ο καθένας. Το να διαβάσεις 25 γραμμές output και να πεις «αυτό το ένα έχει σημασία, εκείνο το critical είναι ψεύτικο, να η απόδειξη» — αυτό είναι η δουλειά, και αυτό είναι που δεν αυτοματοποιείται.

Συμπέρασμα

Οι vulnerability scanners είναι απαραίτητοι, αλλά επικίνδυνα παρεξηγημένοι. Παράγουν σήματα με ταχύτητα και κλίμακα που κανένας άνθρωπος δεν φτάνει — και ακριβώς γι’ αυτό, χωρίς ανθρώπινο triage και validation, παράγουν και ψευδή ασφάλεια με την ίδια ταχύτητα και κλίμακα. Είδαμε πώς τέσσερα ώριμα εργαλεία, δεμένα σε μια λογική αλυσίδα, μετατρέπουν το raw scanning σε ένα τεκμηριωμένο, προτεραιοποιημένο εύρημα — και πώς το πιο σημαντικό βήμα δεν είναι κανένας σαρωτής, αλλά το curl που αποδεικνύει ή απορρίπτει. Αυτή είναι η μετάβαση από το «έχω σαρωτές» στο «έχω επαληθευμένη εικόνα της έκθεσής μου».

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

Το εργαστήριο δείχνει τι είναι δυνατό. Το ερώτημα για κάθε οργανισμό είναι αν αυτή η ικανότητα — να μετατρέπει σήματα σε αποδεδειγμένα, προτεραιοποιημένα ευρήματα — υπάρχει συνεχώς στο δικό του, ζωντανό περιβάλλον, και αν μπορεί να το αποδείξει.

Το Erevos AI είναι η ετήσια managed υπηρεσία Continuous Threat Exposure Management (CTEM) της Audax: συνδυάζει την ανθρώπινη εμπειρία της offensive ομάδας μας με αυτοματοποίηση κλίμακας, για να χαρτογραφεί συνεχώς την επιφάνεια επίθεσης, να επικυρώνει τα σενάρια που πραγματικά σας εκθέτουν (αφαιρώντας τον θόρυβο και τα false positives) και να παράγει τεκμηριωμένη απόδειξη ανθεκτικότητας για NIS2 & DORA. Δεν είναι πλατφόρμα που σας αφήνει μόνους με ένα dashboard γεμάτο σήματα· είναι μια ομάδα που τρέχει τον κύκλο scan–triage–validate–harden μαζί σας.

Human-led. Machine-scaled. Technically proven.

Αν θέλετε να μετατρέψετε αυτή τη μεθοδολογία σε μόνιμη ικανότητα στο δικό σας περιβάλλον, η Audax Cybersecurity μπορεί να σας βοηθήσει — από στοχευμένο penetration testing και adversary validation, μέχρι το Erevos AI για συνεχή, αποδεδειγμένη κάλυψη — με πλήρη ευθυγράμμιση σε NIS2 & DORA.

Επισκεφθείτε το https://www.audax.gr για να μάθετε περισσότερα.