Tor SSH Hijack: 333 Δόλια Exit Relays, το Ebury Backdoor και η Υποκλοπή Συνδέσεων SSH

1. Περίληψη (Executive Summary)

Μέσα στο τριήμερο 1–5 Οκτωβρίου 2026, μια καμπάνια υποκλοπής SSH συνδέσεων δούλευε μέσα στο Tor δίκτυο. Ο ερευνητής που δημοσιεύει ως kaba σκανάρισε στις 2 Οκτωβρίου όλα τα ~3.000 exit relays και βρήκε 333 να redirect-άρουν συνδέσεις SSH προς τις ίδιες 12 IP. Την Παρασκευή 3 Οκτωβρίου ειδοποίησε το network-health team του Tor — μετά την υποκλοπή του δικού του login, μέσα σε δικό του honeypot.

Το Tor Project επιβεβαίωσε με επίσημο post (5/10): servers operators είχαν χακαριστεί, το torrc τους είχε τροποποιηθεί ώστε μη-exits να μετατρέπονται σε exits αποκλειστικά για να εκτελεστεί η επίθεση SSH. Το postmortem του operator Quetzalcoatl έδειξε τον ένοχο δραπέτη: Ebury 1.8.3, το OpenSSH backdoor που τεκμηριώνεται από το 2009 (MITRE ATT&CK S0377). Το στραβά δάχτυλο του «τυχαίου»: 26 από τους 27 άλλους compromised servers ήταν στο ίδιο hosting (FranTech/BuyVM) — η κοινότητα συζητά ανοιχτά το σενάριο compromise σε επίπεδο hoster.

Το απόγειο: στις 4 Οκτωβρίου, τα σχετικά relays έφταναν το 7,46% της exit capacity του Tor (consensus weight). Οι directory authorities τα «σφράγισαν» (BadExit) και μέχρι τις 5 Οκτωβρίου κανένα δεν παρέμενε στο consensus. Τα θύματα; Όποιος έκανε password login σε SSH server μέσω Tor και δέχτηκε τον δόλιο host key. Το Tor Project, η κοινότητα των operators και ένας ερευνητής με ένα honeypot έστρωσαν το κύκλωμα πριν προλάβει να αποδώσει σε κλίμακα.

2. Tor 101: γιατί το exit relay είναι το «τελευταίο χιλιόμετρο»

Ένα κύκλωμα Tor δουλεύει έτσι: η σύνδεσή σου περνά από guard → middle → exit. Κανένα hop δεν βλέπει ταυτόχρονα ποιος είσαι ΚΑΙ πού πας — γι' αυτό το Tor δουλεύει για ανωνυμία. Όμως το exit relay βλέπει τον προορισμό και όλο το traffic που βγαίνει προς το πραγματικό internet. Το TLS σε προστατεύει από το exit· το SSH δεν είναι πάντα TLS.

Εδώ χτυπά το ρελόλι: το SSH κρυπτογραφεί την session, αλλά πιστοποιεί τον server με το host key — και η ανθρώπινη ρουτίνα «ναι, δέχτομαι» (TOFU: Trust On First Use) είναι η πόρτα. Ένας δόλιος exit που σε ΟΔΗΓΕΙ σε δικό του SSH server παρουσιάζει δικό του host key. Αν το client σου τρέχει με StrictHostKeyChecking=accept-new ή — χειρότερα — με defaults που ρωτούν «δεκτό;», ένα Enter αρκεί. Ο δόλιος server καταγράφει το password, «γυρνά» τη σύνδεση στον πραγματικό στόχο με proxy/relay και εσύ δουλεύεις κανονικά, δεν καταλαβαίνεις τίποτα.

3. Πώς στήθηκε η επίθεση: από το Ebury στο MITM

3.1 Η αλυσίδα, βήμα-βήμα

Ομως, η ουσία δεν είναι το redirect. Είναι ο τρόπος κατάκτησης των relays. Το reconstruction από τα νήματα του forum δίνει την παρακάτω αλυσίδα:

3.2 Το Ebury: 17 χρόνια SSH backdoor — και ακόμη κερδίζει

Το Ebury (MITRE ATT&CK S0377) τεκμηριώνεται από το 2009 — ναι, πριν το Stuxnet. Ο ερευνητής Marc-Etienne M. Leveille (ESET), co-author της αρχικής ανάλυσης 2014 και του 2024 report, το παρακολουθεί επί 13 χρόνια και το σχόλιό του στο thread αξίζει αναφορά: «πολλοί servers έχουν μολυνθεί από Ebury στο παρελθόν, αλλά οι περισσότεροι θύματα, για καλούς ή κακούς λόγους, επέλεξαν να μην αποκαλύψουν τον compromise».

Τι κάνει το Ebury τόσο επικίνδυνο για αυτή την περίπτωση: ζει στο στρώμα. Αντικαθιστά/τροποποιεί το OpenSSH, εγκαθιστά rootkit μέσω libkeyutils, καταγράφει credentials, μοιράζεται persistence, και — το κρίσιμο — αποκρύπτει τα ίχνη από τα logs. Ο Marc-Etienne σημειώνει χαρακτηριστικά στο thread: αν το Ebury ήταν ήδη παρών, η ίδια η γραμμή log που θα σε προειδοποιούσε μπορεί να μην θα υπήρχε ποτέ.

Η μετάδοσή του, ιστορικά: ή μέσω compromised hosting providers (management servers → τα VPS των πελατών κληρονομούν Ebury), ή μέσω κλεμμένων credentials από μολυσμένα hosts. Δεν είναι τυχαίο που και οι δύο υποψίες είναι «ζωντανές» εδώ.

3.3 Το honeypot πείραμα του kaba — πώς αποκαλύφθηκε

Ο kaba δεν ήταν «passive observer». Έτρεξε sshesame — ένα SSH honeypot που καταγράφει ό,τι του στέλνεται — και πιάσε στο ψαχτούρι: όταν η σύνδεσή του περνούσε από δόλιο exit, το password του υποκλάπηκε. Ο δόλιος server τότε:

# Ο δόλιος server κάνει Ο ΙΔΙΟΣ login στον στόχο (honeypot του kaba)
# με τα κλεμμένα credentials — μέσω paramiko (Python SSH lib):
# 1) τσεκάρει αν έχει sudo διαθέσιμο
# 2) τρέχει perl probe με το pattern του Quetzalcoatl postmortem
echo "U=$(id -u) S=$(command -v sudo >/dev/null 2>&1 && \
  (sudo -n true 2>/dev/null && echo nopass || echo maybe) || echo none)" perl
# 3) όταν το sshesame δεν «συμπεριφέρθηκε» όπως το περίμενε — αποσυνδέθηκε

Το pattern του perl probe ταυτίστηκε με αυτό που περιέγραψε το postmortem του Quetzalcoatl — δύο ανεξάρτητες πηγές, ίδια υπογραφή. Αυτό σημαίνει: οι επιτιθέμενοι είχαν automated pipeline — όχι χειροκίνητο χάκινγκ, αλλά βιομηχανική διαδικασία με credential theft → sudo probe → lateral movement.

4. Χρονολόγιο

5. Το ερώτημα FranTech/BuyVM: τυχαία συγκέντρωση ή hoster-level compromise;

Η πιο ζουμερή λεπτομέρεια δεν είναι το redirect — είναι η γεωγραφία του μολυσματικού σύννεφου. Ο kaba: «26 από τους 27 άλλους compromised relay servers ήταν hosted στο FranTech/BuyVM. Μήπως τους χακάρισαν σε επίπεδο hoster;». Ερώτημα που δεν έχει επίσημη απάντηση ακόμη — αλλά δεν είναι θεωρία συνωμοσίας: το Ebury έχει τεκμηριωθεί ξανά σε compromised hosting providers, όπου τα management servers της εταιρείας μολύνονταν και τα VPS/containers των πελατών κληρονομούσαν το backdoor.

Από την άλλη πλευρά: χρήστης BuyVM σε σχετικό thread με HN-publikum tone: «τα VMs μου unaffected (KVM-22, KVM-31, KVM-33, KVM-43) — το host OS boot-άρει από read-only USB», υπονοώντας ότι το επίπεδο πρόσβασης ενός hoster-level compromise δεν είναι αυτόματο. Και το επώδυνο context: ο ίδιος ο hoster transitioning σε Cloudzy AI (η συγχώνευση σήμανε ότι το hosting pane μοιράζεται πλέον με περισσότερα χέρια).

6. Ποιοι Κινδυνεύουν (και τι ΔΕΝ κινδυνεύει)

Προσοχή στην ακρίβεια: δεν υπάρχει επιβεβαιωμένο «μαζικό» ποσό κλοπής credentials από παραγωγικούς servers. Το μόνο επιβεβαιωμένο θύμα κλοπής είναι το honeypot του kaba — που ήταν σχεδιασμένο για να πιάνει τέτοια. Η απειλή είναι ριζικά πραγματική ως μηχανισμός, ελεγχόμενη σε έκταση μέχρι στιγμής.

7. Τα canaries που λειτούργησαν

Αυτό που κρατάμε ως defensive story — δεν χάθηκε τίποτα σε κλίμακα, και γιατί:

• Το host key warning του SSH — το παλαιότερο defence-in-depth του internet δούλεψε. Κανείς που είδε το warning και δεν πάτησε Enter, δεν χάθηκε.
• Το honeypot sshesame — όχι μόνο εντόπισε την επίθεση, αλλά χαρτογράφησε το TTP (paramiko, perl probe, sudo discovery). Το offensive tool γίνεται defensive intel.
• Το network-health pipeline — user report (3/10) → flagging (4/10) → καθάρισμα consensus (5/10). Λιγότερο από 48 ώρες από report σε απόρριψη από authorities. Ορισμένα bugs του γρήγορου κόστους θα ήθελαν τέτοιο SLA.
• Η κουλτούρα disclosure — ο Quetzalcoatl μπήκε στο φόρουμ με πλήρη timeline (ακόμα κι αν δεν είχε όλες τις απαντήσεις), ο kaba δημοσίευσε data, ο Marc-Etienne συνεισέφερε 13 χρόνια institutional knowledge. Αυτή είναι η «immune system» του Tor.

8. SSH Hardening Playbook

8.1 Για οποιονδήποτε κάνει SSH (μέσω Tor ή όχι)

• Password authentication: OFF. PasswordAuthentication no στο sshd_config. Αν κλέβεται, κλέβεται παντού — το Tor απλώς το κάνει πιο εύκολο.
• ed25519 keys ως default. Σε OpenSSH 10.3+: εξετασε mldsa44-ed25519 (post-quantum hybrid) — προστασία και για το αύριο.
• FIDO2/U2F hardware keys (Yubikey κ.λπ.) — υποστηρίζονται από OpenSSH 8.2+ (ssh-keygen -t ed25519-sk). Και εδώ ξεκάθαρο: password-protected key ≠ MFA — το passphrase προστατεύει το «τι έχεις», δεν προσθέτει second factor.
• Host key pinning: StrictHostKeyChecking=yes + known_hosts φυλαγμένο. Αν ο server σου αλλάξει host key, η σύνδεση πρέπει να κόβεται — όχι να «ρουτάρει».
• SSH CA / certificates για fleets — αντί για το TOFU-like first-use, δηλαδή πιστοποιημένα host keys με σύντομη διάρκεια ζωής.
• MFA στο SSH plane — όπως συμπέρανε και ο Jonathan Proulx (MIT CSAIL) που είδε Ebury πριν από μια δεκαετία: «ακόμα κι αν κωδικός ή κλειδί διαρρεύσει, πια δεν αρκεί».
• Μην δέχεσαι ποτέ το «IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY» με Enter-κουλτούρα. Είτε αλλάξεις περιβάλλον, είτε ελέγχεις out-of-band (π.χ. από άλλο δίκτυο) το host key.

8.2 Αν τρέχεις Tor relay / VPS με σημασία

• Audit torrc — αναγνώρισες αλλαγές σε ExitPolicy/ExitRelay που δεν έκανες εσύ. Το torrc tampering ήταν η «κάρτα πρόσβασης» της επίθεσης.
• Παρακολούθησε για αυτόματη φόρτωση kernel modules, tunnelling interfaces και ανεξήγητη χρήση μνήμης — το επίσημο checklist του Tor Project (hiro, 5/10).
• Ψάξε για Ebury — libkeyutils patterns, unlinked .so, suspicious sshd binaries. Η ESET έχει detection tools από το 2024 report.
• Μην κρατάς sudo password σε cleartext scripts — το postmortem του Quetzalcoatl το λέει ωμά: ήταν ο «επιταχυντής» του lateral movement.
• Ring-fencing: separate management plane από τα relays. Το obfs4 bridge + WireGuard gateway + SSH jump host σε το ίδιο VPS = single point of failure (και το «πώς» του Quetzalcoatl).
• Σκέψου τη διαφοροποίηση της υποδομής: αν ένα hoster συγκεντρώνει πολλαπλά compromised relays, άλλαξε σπίτι. Ο Quetzalcoatl το απεφάσισε ήδη.
• Αν μολυνθείς: rebuild from scratch — όχι cleanup in-place. Το Ebury μπορεί να είναι 17 χρόνια «αόρατο»· το μόνο σίγουρο clean state είναι το format + restore από trusted backup + νέα keys.

9. Ανίχνευση & Δείγματα IOCs

9.1 Σημάδια ότι ένα relay είναι «γυρισμένο»

# 1) torrc αλλαγές που δεν έκανες
diff /etc/tor/torrc /backup/torrc.bak        # ExitPolicy / ExitRelay αλλαγές;
grep -E "ExitRelay|ExitPolicy" /etc/tor/torrc

# 2) unexpected kernel modules (hiro checklist)
lsmod | less                                  # modules που δεν ανήκεις;
journalctl -k | grep -i "module"              # module load events

# 3) tunnelling interfaces που δεν φτιάξαες
ip -details link show | grep -Ei "tun|tap|wg|obfs"

# 4) Ebury patterns (libkeyutils rootkit)
ls -la /lib/*/libkeyutils* 2>/dev/null       # timestamps/size sanity
find / -name "libkeyutils.so*" -newer /etc/hostname 2>/dev/null
file /usr/sbin/sshd | grep -v "ELF"           # sshd πρέπει να είναι ELF

# 5) «ανεξήγητη μνήμη»
systemd-cgtop | head -20                      # unexplained memory usage

9.2 Σημάδια στο SSH client-side (θύμα-πλευρά)

• Host key warning που εμφανίζεται μόνο μέσω Tor — δοκίμασε από άλλο δίκτυο: αν το host key είναι οκ εκτός Tor, το πρόβλημα είναι στο κύκλωμα, όχι στον server.
• Συνδέσεις που «παγώνουν» ή κόβονται μόνο όταν περνούν από συγκεκριμένα exits.
• Unexpected known_hosts entries για servers που δεν επισκέπτεσαι.
• SSH sessions που «δουλεύουν αργά» χωρίς λόγο — classic MITM proxying latency.

10. Γιατί είναι Σημαντικό

1. Το «τελευταίο χιλιόμετρο» είναι η ασθενέστερη ζώνη — σε κάθε δίκτυο. Δεν έχει σημασία πόσο άψογη είναι η ανωνυμία της αναχώρησης, αν η προσγείωση ελέγχεται από δόλιο. Το Tor το ξέρει — γι' αυτό το BadExit system υπάρχει. Αλλά το βάζει στο τραπέζι: πώς σκληρύνουμε το SSH-on-Tor workload; Το prompt-injection των AI agents, το egress τραφίκ των κλαouds, το exit relay του Tor — το μοτίβο είναι το ίδιο.

2. Το Ebury δείχνει ότι malware ζει σε «10-year» timeframes. Το 2009 έδωσε γέννηση. Το 2024 έδωσε πλήρη documentation. Το 2026 πήρε τη σκυτάλη σε Tor relays. Σημαίνει: defence που «κλίνει» στην αισιοδοξία ότι «ο παλιός malware δεν πιάνει πια» είναι defence που χάνει. Το Ebury είναι ζωντανό επιβεβαιωμένο proof.

3. Η Tor κοινότητα δείχνει πώς δουλεύει η «υγιής» incident response. User report → official notice → flagging → cleanup → postmortem → ESET involvement → community hardening thread. Τρεις ημέρες από σημείο «κάποιος με υποκλάπηκε» σε «δίκτυο καθαρό + δημοσιοποιημένο playbook». Όσο «ανοιχτό» και αν φαίνεται το ερώτημα «πώς μπήκαν;», η διαδικασία δούλεψε άψογα.

4. Το «hoster cluster» δείχνει πού πάει το supply-chain risk. 26/27 compromised servers στον ίδιο hoster δεν είναι στατιστικό noise. Το επόμενο στάδιο supply-chain δεν είναι μόνο τα packages — είναι οι hosters και τα management planes τους.

Συχνές Ερωτήσεις (FAQ)

13. Γλωσσάρι

15. Παράρτημα: Εντολές Ελέγχου

15.1 SSH client: pinning + keys

# Νέο ed25519 κλειδί (default σωστή επιλογή)
ssh-keygen -t ed25519 -a 100 -C "me@host"

# FIDO2 hardware key (OpenSSH 8.2+, Yubikey κ.λπ.)
ssh-keygen -t ed25519-sk -C "me@host-fido2"

# Pinning: στο ~/.ssh/config
Host myserver
    HostName myserver.example.com
    User me
    IdentityFile ~/.ssh/id_ed25519
    StrictHostKeyChecking yes
    IdentitiesOnly yes

# PQ hybrid (OpenSSH 10.3+)
ssh-keygen -t mldsa44-ed25519 -a 100 -C "me@host-pq"

15.2 Relay operator: audit τύπου hiro (5/10)

# torrc audit: υπάρχουν αλλαγές που δεν έκανες;
grep -E "^(ExitRelay|ExitPolicy|ORPort)" /etc/tor/torrc

# Kernel modules: τί φορτώθηκε «μόνο του»;
lsmod
journalctl -k --since "7 days ago" | grep -iE "module|inspect"

# Tunnelling interfaces που δεν φτιάξαες
ip -details link show

# Memory sanity
systemd-cgtop -1

# Ebury / libkeyutils sanity
file "$(command -v sshd)"
find /lib /usr/lib -name "libkeyutils*" -exec file {} \;
crontab -l 2>/dev/null; ls /etc/cron* /var/spool/cron 2>/dev/null
systemctl list-units --type=service --state=running | grep -vE "^(tor|sshd|systemd)"

15.3 Network-side: παρακολούθησε εξόδους

# Αν έχεις SSH traffic μέσω Tor, βάλε canary: honeypot sshesame
# https://github.com/jaksi/sshesame
sshesame -config sshesame.yaml

# Στο client: δοκίμασε το ίδιο host από άλλο δίκτυο/χωρίς Tor
ssh -o ProxyCommand=none -o StrictHostKeyChecking=yes user@host
# Αν το host key «τέλεια» εκτός Tor αλλά warning μέσα από Tor:
#   το κύκλωμα Tor είναι ύποπτο — report στο network-health

Σχετικά Άρθρα

Πηγές & Διαφάνεια

• Tor Forum — «[tor-relays] Security incident affecting some relay operators» (hiro, Tor Project, 05/10/2026) — επίσημη ανακοίνωση: torrc tampering, μετατροπή μη-exits σε exits, flagging & directory authority rejections
• Tor Forum — Quetzalcoatl postmortem (07/10/2026) — Ebury 1.8.3, Contabo management server, FranTech exits, cleartext sudo password, WGDashboard timeline
• Tor Forum — kaba: η ανάλυση 02/10 + ο εντοπισμός FranTech/BuyVM (08/10/2026) — 26/27 compromised servers στο ίδιο hoster, sshesame honeypot, paramiko + perl probe
• Tor Forum — «Man-in-the-middle attack SSH in tor» (31/08/2026) — πρώτες αναφορές + επιβεβαίωση GeKo
• MITRE ATT&CK S0377 — Ebury — τεκμηρίωση malware από το 2009
• ESET WeLiveSecurity — Ebury research (Marc-Etienne M. Leveille — co-author 2014 paper & 2024 report)
• Tor Project — Bad relays documentation — πώς γίνεται το flagging & reporting
• jaksi/sshesame — το SSH honeypot που χαρτογράφησε την επίθεση
• Επιπλέον κάλυψη (δευτερογενής): Cyber Kendra (15/10), news.lavx.hu — για χρονομέτρηση διάδοσης

Διαφάνεια: Το άρθρο είναι reconstruction από πρωτογενείς πηγές — τα νήματα του forum του Tor Project (επίσημο post του hiro, postmortem του Quetzalcoatl, τα δεδομένα και τα στατιστικά του kaba, οι αναλύσεις του Marc-Etienne M. Leveille/ESET). Τα νούμερα (333 exits, 12 IPs, 7,46% consensus weight, 26/27 FranTech/BuyVM) προέρχονται από την ανάλυση του kaba σε δημόσια Tor directory data όπως δημοσιεύθηκαν στην κοινότητα. Ο αρχικός μηχανισμός αρχικής παραβίασης των servers παραμένει υπό έρευνα — ό,τι είναι υπόθεση σημειώνεται ως τέτοια. Δεν παραθέτουμε κώδικα εκμετάλλευσης — μόνο defensive ανάλυση. Τα Tor/SSH/OpenSSH είναι σήματα κατατεθέντα των αντίστοιχων projects· χρησιμοποιούνται αποκλειστικά για ενημερωτικούς σκοπούς.