ssh-enum

Statistische Validierungsstudie von CVE-2016-6210

Eine reproduzierbare Neuuntersuchung der OpenSSH-Benutzernamensaufzählung mittels statistischer Analyse.

Dieses Projekt untersucht CVE-2016-6210, einen dokumentierten OpenSSH-Zeit-Seitenkanal, erneut, um festzustellen, ob er auf einem modernen Ubuntu-Server mit Standard-PAM-Konfiguration weiterhin beobachtbar ist.

Anstatt davon auszugehen, dass das veröffentlichte Verhalten noch zutrifft, bewertet das Projekt Authentifizierungszeitmessungen, die durch manuelles Probing, Hydra und Metasploit gesammelt wurden, mithilfe des Welch-t-Tests und Cohen's d, um echte Zeitsignale von Messrauschen zu unterscheiden.

Die Studie ergab keinen statistisch signifikanten Zeitunterschied bei der getesteten Standardkonfiguration, was den Wert reproduzierbarer Experimente und evidenzbasierter Validierung veröffentlichter Sicherheitsbehauptungen demonstriert.

⚠️ Rechtlicher Hinweis

Dieses Projekt wurde vollständig in einer selbst betriebenen, isolierten Laborumgebung durchgeführt. Alle Ergebnisse gelten ausschließlich für die getestete Konfiguration. Testen Sie niemals Systeme, die Ihnen nicht gehören oder für die Sie keine ausdrückliche schriftliche Genehmigung zum Testen haben.

🎯 Problemstellung

Benutzernamensaufzählung - die Fähigkeit festzustellen, ob ein bestimmter Benutzername auf einem entfernten System existiert, ohne gültige Anmeldedaten. Es ist ein kritischer erster Schritt in der Angriffskette, der zur Kompromittierung von Konten führt:``` Reconnaissance → [User Enumeration] → Password Attack → Access ↑ This project investigates here

Wenn ein Angreifer durch Analyse der Serverantworten zwischen „dieser Benutzer existiert“ und „dieser Benutzer existiert nicht“ unterscheiden kann, kann er den Schlüsselraum für anschließende
Brute-Force- oder Credential-Stuffing-Angriffe drastisch reduzieren.

SSH ist ein häufiges Ziel, weil es nahezu universell exponiert ist, Passwortauthentifizierung unterstützt und ältere Implementierungen messbare Zeitunterschiede zwischen gültigen und ungültigen Benutzernamen aufwiesen (CVE-2016-6210).

**Diese Untersuchung stellt zwei Fragen:**

1. Gibt modernes OpenSSH auf Ubuntu 22.04.5 LTS mit Standardkonfiguration die Existenz von Benutzernamen über Antwortnachrichten, Zeitmessungen oder von Werkzeugen gemeldete Signale preis?
2. Wenn ein Angreifer den Versuch dennoch unternimmt, welche Artefakte hinterlässt er? und wie zuverlässig können diese erkannt werden?

---

## 🖥️ Laboraufbau

Alle Tests wurden in einem vollständig isolierten host-only virtuellen Netzwerk ohne Internetverbindung durchgeführt.

| Rechner  | Betriebssystem | Rolle | IP               | SSH-Version |
|----------|----------------|-------|------------------|-------------|
| Angreifer | Kali Linux 2024.1 | Offensive Werkzeuge, Analyse-Skripte | 192.168.56.5 | — |
| Ziel     | Ubuntu Server 22.04.5 LTS | Ausführung von OpenSSH mit **Standard**-Konfiguration | 192.168.56.10 | OpenSSH 8.9p1 |

**SSH-Konfiguration des Ziels (`/etc/ssh/sshd_config` Standardwerte):**```
PasswordAuthentication yes
UsePAM yes                  # Key setting — normalises timing via dummy hash
PermitRootLogin prohibit-password
MaxAuthTries 6
LogLevel INFO

UsePAM yes ist die kritische Härtungseinstellung. Sie zwingt OpenSSH, für nicht existierende Benutzer eine Dummy-bcrypt-Berechnung durchzuführen, die dem Zeitverhalten einer echten Passwortprüfung entspricht. Dies wurde speziell als Gegenmaßnahme für CVE-2016-6210 eingeführt.

🔬 Methodik

Jede Angriffsmethode wurde als unabhängiger Test mit einem sauberen Log-Status ausgeführt:```bash

Reset log state on target before each trial

sudo truncate -s 0 /var/log/auth.log

After attack: collect evidence

sudo cp /var/log/auth.log ~/evidence/trial-N-auth.log

Erhobene Beweise pro Testlauf:
- Tool stdout/stderr (wörtlich gespeichert)
- `/var/log/auth.log` vom Ziel
- Antwortzeitmessungen über `time.perf_counter()` in `manual_ssh.py`
- SSH-Banner, das vor jedem Authentifizierungsversuch abgegriffen wurde

### Angriffsmethoden

| Methode                      | Werkzeug                              | Wortliste               | Zweck                                                |
|------------------------------|---------------------------------------|-------------------------|------------------------------------------------------|
| Manuelles SSH                | `ssh` CLI + Paramiko                  | 50 gebräuchliche Benutzernamen | Basislinie; Rohantworten prüfen                      |
| Hydra-Brute-Force            | `hydra`                               | gleiche 50              | Automatisiert; nutzt Hydras eingebauten Enum-Modus   |
| Metasploit-Modul             | `auxiliary/scanner/ssh/ssh_enumuser`  | gleiche 50              | Dediziertes Enumerationsmodul des Frameworks         |
| Banner-Fingerprinting        | benutzerdefinierter `BannerFingerprinter` | N/A                   | Version-Leck ohne Authentifizierung, CVE-Prüfung     |
| Timing-Analyse               | benutzerdefinierter `ResponseAnalyzer` | gültige vs. ungültige Teilmenge | Statistische Seitenkanalprüfung                      |

---

## Was gebaut wurde

Dieses Projekt geht über das reine Ausführen von Werkzeugen hinaus – es kapselt jeden Angriff und die gesamte Erkennungslogik in einer strukturierten Python-Codebasis und bietet einen Orchestrator, der die gesamte Pipeline Ende-zu-Ende ausführt.

### Angriffswerkzeuge (`src/attack_tools/`)

**`ManualSSHEnumerator`** — Testet jeden Benutzernamen N-mal mit `paramiko` und zeichnet präzises Timing, Ergebnistyp und SSH-Banner auf. Berechnet Mittelwert/Standardabweichung pro Benutzername. Entscheidend ist, dass es die Verbindungen zwischen den Versuchen **nicht** wiederverwendet, sodass jede Stichprobe die vollständige serverseitige Verarbeitungszeit erfasst.

**`BannerFingerprinter`** — Holt das SSH-Banner über einen rohen TCP-Socket (keine Anmeldedaten erforderlich). Analysiert Implementierungsname, Versionszeichenfolge und OS-Hinweis. Kreuzverweise mit einem lokalen CVE-Register. Eine Version wie `OpenSSH_8.9p1 Ubuntu-3ubuntu0.6` zeigt die genaue Serversoftware an – möglicherweise ausreichend, um bekannte Schwachstellen zu identifizieren, bevor eine Authentifizierung versucht wird.

**`HydraAutomation`** — Subprocess-Wrapper um Hydra. Analysiert stdout, um erfolgreiche Anmeldungen, Fehlermeldungen und Hydras eigenes Enumerationsurteil (`does not support user enumeration`) zu extrahieren.

**`MetasploitScanner`** — Schreibt ein temporäres Ressourcenskript und steuert `msfconsole` über Subprocess. Analysiert Ausgabe auf Härtungserkennung und gefundene Benutzernamen.

### Erkennungswerkzeuge (`src/detection_tools/`)

**`LogParser`** — Regex-basierter auth.log-Parser, der fünf SSH-Ereignistypen unterstützt: `failed_invalid_user`, `failed_valid_user`, `pre_auth_reject`, `accepted`, `disconnected`. Gibt strukturierte Ereignis-Dicts mit Zeitstempel, Ereignistyp, Benutzername, Quell-IP und Port zurück.

**`ResponseAnalyzer`** — Führt Welch's t-Test auf Zeitverteilungen von gültigen vs. ungültigen Benutzernamen durch. Berechnet Zeitdifferenz (ms), p-Wert, Cohen's d Effektstärke und eine Schlussfolgerung in einfacher Sprache. Schwelle: Delta ≥ 5ms UND p < 0.05 löst eine Seitenkanalwarnung aus.

**`EnumerationDetector`** — Vier Erkennungsmuster:
- **Schnelle Benutzerabfragen**: gleitendes Fenster – gleiche IP, ≥10 verschiedene Benutzernamen innerhalb von 60s
- **Wortlist-Korrelation**: Übereinstimmungsrate zwischen versuchten Benutzernamen und bekannten Angriffslisten
- **Sequentielles Timing**: Variationskoeffizient der Lücken zwischen Versuchen (niedriger CoV → Tool)
- **Verteilte Abfrage**: gleicher Benutzername von mehreren IPs (Credential-Stuffing-Aufklärung)

**`AlertingSystem`** — Leichter Alarmemitter. Erzeugt zeitgestempelte JSON-Alarme auf stdout. Erweiterbar mit E-Mail/SIEM/Webhook-Integrationen nach Bedarf.

### Orchestrator

**`run_investigation.py`** — CLI-Treiber, der alle vier Phasen nacheinander ausführt und Ergebnisse nach `data/results/` schreibt. Führen Sie `--help` für die vollständige Verwendung aus.```bash
python run_investigation.py \
    -target 192.168.xx.xxxx \
    -usernames data/wordlists/common-usernames-50.txt \
    -log data/sample-logs/auth.log \
    -known-valid root ubuntu \
    -samples 10

Beobachtungen & Erkenntnisse

Erkenntnis 1: Antwortkonsistenz — Die Kernverteidigung

Getestete Hypothese: Gibt OpenSSH eine andere Fehlermeldung für einen nicht existierenden Benutzer zurück als für einen existierenden Benutzer mit falschem Passwort?```bash

Non-existent user

$ ssh [email protected] Permission denied (publickey,password).

Existing user, wrong password

$ ssh [email protected] Permission denied (publickey,password).

**Ergebnis:** Die Antworten sind byteweise identisch. Das Protokoll gibt nichts preis.

**Warum:** Seit OpenSSH 7.3 erzwingt `UsePAM yes` auf dem Server die Ausführung einer Dummy-`crypt()`-Operation für nicht existierende Benutzer, die sowohl das Timing als auch den Fehlerpfad einer echten fehlgeschlagenen Authentifizierung nachbildet. Der Fix war eine direkte Reaktion auf CVE-2016-6210.

---

### Ergebnis 2: Kein Timing-Seitenkanal erkannt

**Getestete Hypothese:** Selbst wenn die Fehlermeldungen übereinstimmen, gibt es einen messbaren Timing-Unterschied zwischen gültigen und ungültigen Benutzernamen, der statistisch ausgenutzt werden könnte?

Zehn Timing-Stichproben wurden für jeden der 50 Benutzernamen gesammelt. Bekannt gültige Benutzer (aus dem System bestätigt) wurden mit dem Pool ungültiger Benutzer verglichen.

| Metrik                      | Wert                                |
|-----------------------------|-------------------------------------|
| Mittleres Timing — ungültige Benutzer | ~312 ms                             |
| Mittleres Timing — gültige Benutzer   | ~311 ms                             |
| Differenz                   | **~1 ms**                           |
| Welch-t-Test p-Wert         | > 0.40                              |
| Fazit                       | **Kein unterscheidbarer Seitenkanal** |

Die Differenz von ~1 ms liegt weit unterhalb der Rauschschwelle von 5 ms und ist statistisch nicht signifikant (p >> 0.05). Die Dummy-Hash-Berechnung von OpenSSH ist effektiv.

---

### Ergebnis 3: Hydra meldet keine Unterstützung für Aufzählung

Hydras SSH-Enumeration-Modus basiert auf einem von drei Signalen: unterschiedliche Fehlermeldungen, unterschiedliches Timing oder unterschiedliches Verbindungsverhalten. Da alle drei normalisiert sind, meldet Hydra explizit:```
[ERROR] target ssh://192.168.56.10:22/ does not support user enumeration
[STATUS] 50/50 tries completed, 0 valid logins found

Beobachteter Nebeneffekt: Trotz des Fehlschlags der Aufzählung werden alle 50 Versuche in /var/log/auth.log mit Quell-IP, Zeitstempel und versuchtem Benutzernamen protokolliert. Die Anwesenheit des Angreifers ist vollständig sichtbar.

Fund 4: Metasploit erkennt Härtung vor Abschluss des Scans

Das Modul auxiliary/scanner/ssh/ssh_enumuser prüft die OpenSSH-Version aus dem Banner, bevor es eine Aufzählung versucht. Versionen ≥ 7.3 mit UsePAM yes werden als gehärtet markiert und das Modul wird vorzeitig beendet:``` [] 192.168.xx.xxxx:22 - SSH - Checking for vulnerability [] 192.168.xx.xxxx:22 - SSH - Target is not vulnerable: OpenSSH 8.9p1 (hardened)

Dies ist ein nützlicher Befund: Schon das Banner verrät einem Angreifer die defensive Haltung des Servers, noch bevor ein Enumeration-Versuch unternommen wird.

---

### Befund 5: Erkennung ist zuverlässig, selbst wenn die Enumeration fehlschlägt

Die wichtigste Erkenntnis aus Verteidigersicht: **Der Angriff erzeugt Lärm, selbst wenn er nicht erfolgreich ist.** Alle vier Erkennungsmuster feuerten korrekt gegen die gesammelte auth.log:

| Erkennung                    | Auslöser                                              | Schweregrad |
|------------------------------|-------------------------------------------------------|-------------|
| Schneller Benutzer-Scan      | Kali-IP testete 50 Benutzernamen in <60s              | HOCH        |
| Wortlisten-Korrelation       | 48/50 versuchte Namen stimmten mit Wortliste überein  | HOCH        |
| Zeitliches Muster            | Inter-Versuch CoV = 0,04 (Werkzeug-Signatur)          | MITTEL      |
| Banner-only Probe            | Pre-Auth-Trennungen vor dem Senden eines Benutzernamens| NIEDRIG    |

---

## Gedankengang

### Warum zuerst manuelle SSH-Enumeration?

Der Instinkt, mit manuellen Tests zu beginnen, war methodisch fundiert: Bevor man der Werkzeugausgabe vertraut, muss man verstehen, was das rohe Protokoll tatsächlich sagt. Die Ausführung von `ssh ghost@target` und die Beobachtung der exakten Fehlermeldung sagt einem, ob es *überhaupt* etwas zu enumerieren gibt, bevor man Zeit in Automatisierung investiert.

Die erste Beobachtung, dass `Permission denied (publickey,password)` unabhängig davon, ob der Benutzer existiert, identisch aussieht, war der zentrale Befund. Alles Folgende diente der Validierung dieses Ergebnisses.

### Getroffene Annahmen (und erneute Überprüfung)

Die anfängliche Annahme war, dass Hydra und Metasploit *leistungsfähiger* sein würden als manuelle Tests, also dass Werkzeuge bei manuellem Scheitern noch erfolgreich sein könnten. Dies stellte sich als falsch in der erwarteten Richtung heraus, aber richtig im *Warum*: Werkzeuge fügen hier keine Fähigkeit hinzu, weil das Protokoll selbst das Signal nicht preisgibt. Werkzeuge sind nur Automatisierung über dasselbe Protokoll.

Eine zweite Annahme, die einer Überprüfung wert ist: Der erste manuelle Versuch war merklich langsamer als die folgenden, und der Versuch mit erfolgreichem Passwort war schnell. Dies wurde zunächst als mögliches Zeitsignal interpretiert. Bei näherer Betrachtung war die Verlangsamung auf den Overhead des TCP-Verbindungsaufbaus bei neuem Netzwerkzustand (ARP-Auflösung, Verbindungsaufbau) zurückzuführen, nicht auf die serverseitige Verarbeitungszeit. Eine Kontrolle dafür – durch Messung ab `time.perf_counter()` *nach* dem TCP-Handshake oder durch Verwerfen der ersten Stichprobe – wäre strenger gewesen. Die Implementierung von `ManualSSHEnumerator` adressiert dies, indem sie 10 Stichproben pro Benutzernamen sammelt und Mittelwert/Standardabweichung ausgibt, was das Rauschen der ersten Stichprobe verdünnt.

### Was sich während des Projekts geändert hat

Der ursprüngliche Umfang war eng: Führe drei Werkzeuge aus, dokumentiere, ob sie funktionieren. Das Projekt entwickelte sich in zwei Richtungen:

**Nach innen (tiefere Analyse):** Als die ersten Ergebnisse negativ waren, stellte sich natürlich die Frage *warum* – was zum Lesen der OpenSSH-Changelogs, von CVE-2016-6210 und der `UsePAM`-Implementierung führte. Den Mechanismus zu verstehen, ist wertvoller, als nur das Ergebnis zu dokumentieren.

**Nach außen (Erkennungswende):** Ein negatives Angriffsergebnis ist dennoch ein nützlicher defensiver Datenpunkt. Die Wende zu „obwohl die Enumeration fehlschlug, was hat der Server gesehen?" führte zu den Komponenten Log-Analyse und Detection Engineering, was eine eindimensionale Werkzeugausführung in eine zweiseitige Untersuchung verwandelte.

### Was würde anders gemacht werden

Die Zeitmessungen wurden über ein Host-Only-Virtual-Netzwerk durchgeführt, das weniger Jitter einführt als ein reales Netzwerk, aber auch bedeutet, dass die Ergebnisse optimistisch sind. In einer realen Umgebung mit TCP-Latenz, Jitter und erneuten Übertragungen wäre die Rauschuntergrenze höher und die Zeitanalyse würde mehr Stichproben pro Benutzernamen benötigen. Eine robustere Methodik würde über einer simulierten WAN-Verbindung testen (mit `tc netem`, um kontrollierte Latenz und Jitter einzuführen), um zu sehen, wie die Schlussfolgerungen unter realistischen Bedingungen Bestand haben.

---

## Sicherheitsrisiken

Auch wenn die Enumeration in diesem Labor nicht erfolgreich war, sind die Angriffsfläche und die damit verbundenen Risiken wie folgt:

**Falls Enumeration *möglich* wäre (z. B. älteres OpenSSH, `UsePAM no`, eigener PAM-Stack):**
- Angreifer könnten eine Brute-Force-Kampagne auf bestätigte gültige Benutzernamen eingrenzen, was das Erkennungsrisiko drastisch senkt und die Effizienz erhöht.
- In Kombination mit Password Spraying (ein häufiges Passwort für alle gültigen Benutzernamen) umgeht dies `MaxAuthTries`-Sperren pro Benutzer.

**Risiken, die selbst bei Enumeration-Resistenz bestehen:**
- Das SSH-Banner gibt die exakte OpenSSH-Version und das Betriebssystem preis. Ein Angreifer, der `OpenSSH_8.9p1` sieht, kann sofort prüfen, ob CVE-2024-6387 (regreSSHion) zutrifft, bevor er ein einziges Authentifizierungspaket sendet.
- Alle Enumeration-Versuche werden mit Quell-IP protokolliert. Fehlt die Log-Überwachung, könnte ein langsamer Angriff (ein Versuch pro Stunde) Tausende von Benutzernamen testen, ohne ratenbasierte Alarme auszulösen.
- `PasswordAuthentication yes` hält die passwortbasierte Angriffsfläche offen, selbst wenn Enumeration nicht praktikabel ist. Nach OSINT durchgeführte Credential-Angriffe (mit geleakten Passwortlisten gegen OSINT-abgeleitete Benutzernamen) erfordern überhaupt keine serverseitige Enumeration.

---

## Abhilfestrategien

| Bedrohung                 | Abhilfe                                                                | Erforderliche Konfigurationsänderung |
|---------------------------|------------------------------------------------------------------------|--------------------------------------|
| Timing-Seitenkanal        | `UsePAM yes` sicherstellen (Standard auf Ubuntu)                       | Keine – bereits Standard             |
| Offenlegung der Banner-Version | `VersionAddendum none` und `DebianBanner no` in `sshd_config`      | Ja                                   |
| Passwortbasierte Angriffe | `PasswordAuthentication no` – nur Schlüssel-Authentifizierung          | Ja                                   |
| Brute Force nach OSINT    | `fail2ban` mit `sshd`-Jail                                            | Installation + Konfiguration         |
| Langsame Enumeration      | Log-Versand an SIEM; Alarm bei >N verschiedenen Benutzernamen/IP/Stunde | SIEM erforderlich                   |
| Root-Login                | `PermitRootLogin no`                                                   | Ja (Standard ist `prohibit-password`)|
| Pre-Auth-Trennungen       | `MaxStartups 10:30:60` zur Ratenbegrenzung unauthentifizierter Verbindungen | Ja                               |

**Mindestempfehlungen für `sshd_config`-Ergänzungen für eine gehärtete Bereitstellung:**```
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
MaxStartups 10:30:60
VersionAddendum none
LogLevel VERBOSE

Zukünftige Erweiterungen

Das aktuelle Projekt testet ein Protokoll in einer Konfiguration. Natürliche Erweiterungen:

Weitere Dienste auf demselben Host enumerieren. SMTP (VRFY/EXPN), LDAP (Attributabfragen), HTTP-Anmeldeformulare und SNMP sind alles häufige Username-Leak-Vektoren auf demselben Rechner, der bei SSH gehärtet ist. Eine vergleichende Studie über Dienste hinweg würde ein vollständigeres Risikobild ergeben.

Nicht-Standard-SSH-Konfigurationen testen. UsePAM no, benutzerdefinierte PAM-Module, Kerberos-Authentifizierungs-Backends und ältere OpenSSH-Versionen (die in eingebetteten Systemen, Netzwerkgeräten eingesetzt werden) können immer noch Timing-Leaks aufweisen. Das Testen derselben Pipeline gegen eine bewusst verwundbare Konfiguration würde den Kontrast aufzeigen.

Live-Erkennung mit inotify. Die aktuelle Erkennung läuft im Nachhinein gegen eine kopierte Logdatei. Eine produktionsreife Version würde inotify (oder tail -f + einen Parser-Thread) verwenden, um in nahezu Echtzeit zu erkennen und zu warnen, innerhalb von Sekunden nach Beginn eines Enumeration-Versuchs.

Netzwerkebenen-Erkennung. Auth.log ist ein hostbasiertes Artefakt. Ergänzen Sie es mit Paketebenen-Erkennung: kurzlebige TCP-Verbindungen zu Port 22, die geschlossen werden, bevor der Authentifizierungs-Handshake abgeschlossen ist, sind ein Anzeichen für reines Banner-Fingerprinting. Dies könnte als Zeek- oder Suricata-Regel implementiert werden.

Jupyter-Notebooks für statistische Berichte. Die gesammelten Timing-Daten eignen sich zur Visualisierung - Box-Plots der Timing-Verteilungen pro Benutzername, Streudiagramme der Versuchshäufigkeit über die Zeit, Heatmaps der Quell-IPs. Notebooks würden die Analyse reproduzierbar und teilbar machen.

Projektstruktur```

ssh-enumeration-analysis/ │ ├── README.md ├── run_investigation.py ← Full pipeline orchestrator (start here) ├── requirements.txt │ ├── src/ │ ├── attack_tools/ │ │ ├── init.py │ │ ├── manual_ssh.py ← Paramiko-based timing probe │ │ ├── banner_fingerprinter.py ← No-auth banner grab + CVE lookup │ │ ├── hydra_automation.py ← Hydra subprocess wrapper │ │ └── metasploit_scanner.py ← MSF console automation │ │ │ └── detection_tools/ │ ├── init.py │ ├── log_parser.py ← auth.log regex parser │ ├── response_analyzer.py ← Welch t-test + Cohen's d │ ├── pattern_detector.py ← 4 detection patterns │ └── alerting_system.py ← JSON alert emitter │ ├── data/ │ ├── sample-logs/ │ │ ├── auth-baseline.log ← Normal SSH activity (no attacks) │ │ ├── auth-hydra-run.log ← Captured during Hydra trial │ │ └── auth-msf-run.log ← Captured during Metasploit trial │ │ │ ├── wordlists/ │ │ ├── common-usernames-50.txt │ │ └── common-usernames-100.txt │ │ │ └── results/ ← Auto-generated (gitignored) │ ├── investigation-summary.json │ ├── manual-enumeration-results.json │ ├── timing-analysis.json │ └── detection-report.json │ ├── tests/ │ ├── test_enumeration.py │ ├── test_detection.py │ └── test_log_parser.py │ ├── case-study/ │ └── User_Enumeration_attempt_using_manual_SSH.docx │ └── screenshots/ ├── manual-ssh-same-response.png ├── hydra-no-enumeration-support.png ├── metasploit-hardened-detected.png ├── auth-log-hydra-evidence.png └── detection-alerts-output.png

---

## ⚡ Schnellstart```bash
# 1. Clone and install dependencies
git clone https://github.com/Alisha-chaudhary/ssh-enum
cd ssh-enum
pip install -r requirements.txt

# 2. Run just the banner fingerprint (no credentials needed)
python -c "
from src.attack_tools.banner_fingerprinter import BannerFingerprinter
r = BannerFingerprinter().grab('192.168.xx.xxxx')
print(r.raw_banner, r.cves)
"

# 3. Run the full investigation pipeline
python run_investigation.py \
    -target 192.168.xx.xxxx \
    -usernames data/wordlists/common-usernames-50.txt \
    -log data/sample-logs/auth-hydra-run.log \
    -known-valid root ubuntu \
    -samples 10

# 4. Analyse a log file only (no live target needed)
python -c "
from src.detection_tools.pattern_detector import EnumerationDetector
d = EnumerationDetector('data/sample-logs/auth-hydra-run.log')
import json; print(json.dumps(d.run_all(), indent=2))
"

Anforderungen:``` paramiko>=3.3.1 scipy>=1.11.0 Hydra and Metasploit must be installed separately (pre-installed on Kali Linux).

---

## 📚 Referenzen

| Ressource                                                                              | Relevanz                                       |
|---------------------------------------------------------------------------------------|-------------------------------------------------|
| [CVE-2016-6210](https://nvd.nist.gov/vuln/detail/CVE-2016-6210)                       | Der Timing-Seitenkanal, den dieses Projekt getestet hat |
| [CVE-2024-6387 (regreSSHion)](https://nvd.nist.gov/vuln/detail/CVE-2024-6387)         | Unauth. RCE in OpenSSH ≤ 9.7                    |
| [OpenSSH sshd_config manual](https://man.openbsd.org/sshd_config)                     | `UsePAM`, `MaxAuthTries`, `VersionAddendum`     |
| [OWASP — User Enumeration](https://owasp.org/www-community/attacks/User_Enumeration)  | Allgemeine Enumeration-Angriffsmuster           |
| [RFC 4252 — SSH Authentication Protocol](https://tools.ietf.org/html/rfc4252)         | Protokollspezifikation; definiert Verhalten von Fehlermeldungen |
| [fail2ban documentation](https://www.fail2ban.org/wiki/index.php/Main_Page)           | Ratenbegrenzung und IP-Sperrung                 |

---

## 🎓 Gezeigte Fähigkeiten

| Bereich                 | Nachweise                                                                                                |
|-------------------------|----------------------------------------------------------------------------------------------------------|
| SSH-Protokollinterna    | Verständnis der `UsePAM`-Timing-Normalisierung, CVE-2016-6210-Fix, Offenlegung von Bannerinformationen   |
| Offensive Sicherheit    | Praktische Nutzung von Hydra, Metasploit und benutzerdefiniertem Paramiko-Probieren in einer strukturierten Methodik |
| Statistische Analyse    | Welch's t-Test, Cohen's d, Variationskoeffizient angewendet auf Timing-Daten                             |
| Erkennungsentwicklung   | Log-basierte IOC-Erkennung über vier Musterarten; strukturierte Alarmausgabe                             |
| Python-Entwicklung      | Dataclasses, Type Hints, Subprocess-Automation, Regex-Parsing, statistische Bibliotheken                  |
| Sicherheitsforschung    | Hypothese → kontrolliertes Experiment → Beweissammlung → dokumentierte Ergebnisse → handlungsorientierte Schlussfolgerungen |

---

**Status:** Abgeschlossen | **Getestet auf:** Ubuntu Server 22.04 LTS + OpenSSH 8.9p1 | Kali Linux 2024.1

ssh-enum

Beliebteste

Über

ssh-enum

Statistische Validierungsstudie von CVE-2016-6210

Inhaltsverzeichnis

🎯 Problemstellung

🔬 Methodik

Reset log state on target before each trial

After attack: collect evidence

Beobachtungen & Erkenntnisse

Erkenntnis 1: Antwortkonsistenz — Die Kernverteidigung

Non-existent user

Existing user, wrong password

Fund 4: Metasploit erkennt Härtung vor Abschluss des Scans

Zukünftige Erweiterungen

Projektstruktur```