}

// шаг 4: подчищаем за собой следы

closesocket(fsocket);

Откомпилировав демонстрационный пример find.c, запустите его на атакуемом узле, а на узле атакующего наберите:

netcat "адрес атакуемого" 666

Убедитесь, что никакие, даже самые жесткие и недемократические настройки брандмауэра не препятствуют нормальной жизнедеятельности червя. Внимательнейшим образом изучите все логи – вы не видите в них ничего подозрительного? Вот! Я тоже не вижу. И хотя IP-адрес атакующего в них исправно присутствует, он ничем не выделяется среди сотен тысяч адресов остальных пользователей и разоблачить хакера может лишь просмотром содержимого всех TCP/IP-пакетов. Пакеты, отправленные злоумышленником, будут содержать shell-код, который легко распознать на глаз. Однако, учитывая, что каждую секунду сервер перемолачивает не один мегабайт информации, просмотреть все пакеты становится просто нереально, а автоматизированный поиск требует вирусной сигнатуры, которой на латентной стадии эпидемии еще ни у кого нет.

reuse exploit, или молчание брандмауэра II

Допустим, разработчики операционных систем исправят свой грубый ляп с дескрипторами сокетов, равномерно рассеяв их по всему 32-битному пространству, что сделает лобовой перебор довольно неэффективным, особенно если в функции getpeername будет встроен детектор такого перебора, реагирующий в случае подозрения на атаку все возрастающим замедлением. И что тогда? А ничего! Опытные хакеры (и грамотно спроектированные черви) перейдут к плану «Б», насильно делая re-bind уже открытому порту.

Возможность повторного использования адресов – это вполне легальная возможность, и предусмотрена она не случайно. В противном случае проектирование разветвленных сетевых приложений с сильно развитой иерархической структурой оказалось бы чрезвычайно затруднено (кто программировал собственные серверы, тот поймет, ну а кто не программировал, просто не в состоянии представить, чего он избежал).

Если говорить коротко: делать bind на уже открытый порт может только владелец этого порта (т.е. процесс, открывший данный порт, или один из его потомков, унаследовавших дескриптор соответствующего сокета), да и то лишь при том условии, что сокет не имеет флага эксклюзивности (SO_EXCLUSIVEADDRUSE). Тогда, создав новый сокет и вызвав функцию setsockopt, присваивающую ему атрибут SO_REUSEADDR, shell-код сможет сделать bind и listen, после чего все последующие подключения к атакованному серверу будут обрабатываться уже не самим сервером, а зловредным shell-кодом!

Рисунок 7. Атакующий засылает на уязвимый сервер shell-код, который делает re-bind на открытый публичный порт и перехватывает

все последующие соединения (и соединения, устанавливаемые атакующим в том числе)

Программная реализация данной атаки вполне тривиальна и отличается от эксплоита bind.c одной-единственной строкой:

setsockopt(rsocket, SOL_SOCKET, SO_REUSEADDR, &n_reuse, sizeof(n_reuse))

присваивающей сокету атрибут SO_REUSEADDR. Однако вместо открытия порта с нестандартным номером данный код захватывает основной порт уязвимой службы, не вызывая никаких претензий у брандмауэра.

Листинг 4. Ключевой фрагмент shell-кода, осуществляющий re-bind открытого порта