Нестандартные backdoor-ы в *nix. Как создать свой необычный backdoor

Xakep, номер #046, стр. 046-054-4

Так что задачи, стоящие перед нами, - сделать трафик между Б и А "неаномальным" и предотвратить выдачу нестандартных результатов при сканирование хоста А. Начнем со сканирования. Допустим, на хосте А на 80 порту крутится веб-сервер, а для удаленного управления на 22 порту висит sshd. Будет крайне подозрительно, если на машине вдруг появится открытый порт 31337, так что банальная привязка нашего бэкдора к какому-нибудь порту - простое проявление неуважения к админу :). Один из выходов - создать ситуацию, когда при посылке специфического пакета на 22-й или 80 порт на хосте А выполнялись нужные нам действия, например, вываливался шелл. Как это реализовать? Прежде всего мы можем попатчить демоны, ввести дефолтовые рутовые логины и т.д., но это как-то неоригинально и неинтересно :). Лично мне нравятся более хитрые способы.

Аутентификация по заголовку пакетов

Возьмем стандартную процедуру хэндшейка TCP-протокола. Здесь клиент при посылки SYN-пакета серверу волен выбирать любые значения, например, для такого поля, как Sequence number. Допустим, мы присваиваем этому полю значение n. В ответ сервак отсылает SYN/ACK-пакет, в котором тоже (по идее) рандомно выбирает секвенс m. Теперь строим механизм аутентификации, для чего на стороне клиента ксорим клиентский секвенс и секвенс сервера (n^m), затем получившееся значение ксорим с неким заранее выбранным ключевым словом (n^m^keyword), известным серверу и клиенту, применяем к получившемуся значению тоже заранее определенную хэш-функцию (к примеру, MD5: md5(m^n^keyword)), запихиваем выходное значение этой функции (опять к примеру) в поле Identification IP-хэдэра и в поле Window TCP-хэдэра. Получившийся пакет шлется на сервер, где производятся точно такие же операции генерации хэша. Этот хэш впоследствии сравнивается с полями Identification и Window поступившего пакета. Если значения совпадают, то на сервере, как не сложно догадаться, происходит то, что нужно нам, если нет - тогда то, что нужно админу. Естественно, есть минусы этого механизма: суммарная длина полей Identification и Window составляет 32 бита, в результате чего осуществить подбор ключа - относительно легкая задача, хотя и требует посылки достаточно большого количества SYN-пакетов. Если говорить о реализации этого метода, то на стороне клиента это должна быть программа, эмулирующая IP и TCP уровни TCP/IP-стека, а на стороне сервера, для чистоты эксперимента, - кернел-модуль, модифицирующий процедуры обработки IP и TCP пакетов.

Теперь представим ситуацию, когда на нашем порутанном хосте А нет открытых TCP-портов или же весь TCP-трафик между этим хостом и Интернетом рубится на файрволе. Здесь мы можем применить достаточно простой трюк: выбрать машину Г в одном сегменте с А, на которой имеются доступные из внешней сети TCP-порты, и мониторить все хэндшейки между этим хостом и внешней сеткой. А далее по накатанной: если Identification и Window совпадают с локальным хэшем, то хост А спуфит IP хоста Г и уже от его имени ведет диалог с клиентом. Админа это повергнет в шок еще сильнее - он просто запарится выяснять, какая машинка в этом сегменте действительно забэкдорена. Реализация данного метода на стороне клиента такая же, как и в предыдущем случае, за исключением фильтрации левых RST-пакетов, которые могут пойти с хоста Г. На стороне же сервера это немного сложнее: помимо IP и TCP уровня придется патчить и более низкий уровень (чаще всего это Ethernet), но ведь для нас нет преград!