Как организовать MITM, используя ICMP redirect.

Итак, напомню. MITM (man-in-the-middle) — общее название для типа атак, когда хакер получает возможность манипулировать трафиком, передаваемым между двумя хостами. Самая классика — это ARP poisoning и DNS spoofing. Хотя ясное дело: и разных протоколов много, и технологий, а потому методов есть еще целый пучок. С парочкой из них мы сейчас и познакомимся.
Первый метод — ICMP redirect. Эта техника основана не на какой-то баге, а на вполне  декларированной фиче протокола. Но давай обо всем по порядку — сначала общая теория.
Давай представим ситуацию. У нас есть хост А и B, а также роутеры R1 и R2 (см. рис. 1).

С хоста A данные надо послать на хост B, а на хосте А в таблице маршрутизации прописан дефолтный путь — через R1. Таким образом, когда хост А пошлет пакет данных хосту B, он пошлет их через R1. R1, в свою очередь, получив этот пакет данных, посмотрит таблицу маршрутизации и увидит, что для того, чтобы переслать данные на хост B, он должен отправить их на роутер R2. И перешлет их на R2.
Но если на R1 включена нотификация ICMP redirect, то R1 заметит, что R2 и хост A находятся в одном сегменте. А из этого, в свою очередь, следует, что путь напрямую от A к R2 и далее,
то есть без участия R1, будет рациональнее. Если все «сходится», то R1 посылает на хост А сообщение ICMP redirect. Если ОС хоста А поддерживает такого вида сообщения, то она сама добавит новый маршрут в свою таблицу. Вообще, по стандарту только сетевые девайсы имеют право отправлять такие сообщения, но, как ты понимаешь, для нас это прямой путь для наших манипуляций :).
Теперь давай ближе к практике. Все, что нам требуется в качестве инструмента, — это отправлять ICMP redirect запросы. Формат пакета — на рис. 2.

Поясню, так как это важно. Код — 1, тип — 5, которые указывают, что это именно redirect для хоста, потом стандартная чек-сумма. Далее должен быть IP-адрес более «правильного» роутера. И самый «скользкий кусок» для нас — заголовок IP пакета и первые 8 байт тела пакета, который был  получен роутером, но для которого есть более короткий путь. Что с этим делать, я объясню
чуть позже.
Дальше. Необходимо знать остальные правила, по которым действуют ОС, получающие ICMP redirect пакеты. В смысле, для того, чтобы ОС обработала пакет и добавила новый роут по нему, должны соблюдаться следующие условия:

1. IP-адрес нового роутера должен быть в той же подсети, что и сам хост.
2. Сам ICMP redirect должен прийти от роутера, который используется хостом.
3. В качестве нового роутера не может быть указан сам хост.
4. Новый роут не может быть добавлен для IP-адреса, который находится в той же подсети, что и сам хост.
5. И самое тривиальное — ОС должна поддерживать и обрабатывать ICMP redirect пакеты.

Начнем с конца. На самом деле ICMP redirect кажется вполне юзабельной фичей — динамически находятся более правильные маршруты. Но фактически он будет использоваться в сети лишь в том случае, если сама архитектура сети некорректна. При правильной таких проблем просто не возникает. Наверное, это и стало причиной, по которой от этой технологии постепенно все отказываются: вроде как большинство современных *nix-систем по умолчанию не обрабатывает их, а сетевые девайсы их не генерят. Но приятное исключение составляют ОС до Windows XP/2003 включительно — в них ICMP redirect поддерживается и включен по умолчанию (в Vista/2008 — отключен).
Если обобщить описанные выше правила, то для проведения успешной атаки мы должны соблюсти следующие моменты:

1. Мы должны находиться в той же подсети, что и хост нашей жертвы (хост А).
2. Хост, роут до которого мы хотим изменить (хост B), должен находиться в другой подсети.

Достаточно просто, но куда же делся тот «скользкий кусок»? По теории, для того, чтобы добавить новый роут на хост, мы должны в тело ICMP redirect’а добавить IP-заголовок и часть тела пакета от хоста (рис. 3). Но откуда нам его взять для атаки, если мы не видим данных между роутером и хостом? В теории это стало бы для нас нерешабельной проблемой, но на практике все гораздо проще, так как винда не смотрит, «а посылала ли она этот пакет». Главное, чтобы было некое «тело». Кроме того, отсутствие этой проверки позволяет добавить нам в таблицу маршрутизации роуты даже до хостов, к которым наша жертва никогда и не подключалась.

Теперь практический пример. Общее описание ситуации:
• 192.168.79.130 — жертва на Win XP;
• 192.168.79.137 — хост атакующих, то есть нас;
• 192.168.79.2 — основной роутер жертвы, он же «gateway»;
• 8.8.8.8 — DNS-сервер жертвы (от Гугла).

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

Провести атаку можно различными тулзами — это и классический Ettercap, и виндовый Intercepter-NG. Но мне приглянулся Responder от SpiderLabs. Это набор тулзенок на Python’е, специально сделанный для различных атак в Windows-сетях. Атака проводится всего
одной командой:

python Icmp-Redirect.py -I eth0 -i 192.168.79.137 -g 192.168.79.2 -t 192.168.79.130 -r 8.8.8.8

 Расписывать, что есть что, не буду. Если соотнести с общей схемой сети, то все должно быть понятно. Можно разве что отметить несколько моментов. Во-первых, новый роут добавляется временно — на десять минут.
Но мы можем повторять атаку сколько угодно раз. Во-вторых, мы можем добавить любое количество роутов до хостов (даже к тем, к которым жертва еще не подключалась). В-третьих, сама эта атака будет полудуплексная (half-duplex), то есть подключения из «внешних» сетей мы перехватить не сможем, поскольку обмануть таким образом сам роутер не получится.
Кроме того, при проведении MITM-атаки нам надо будет учитывать, что подключение к удаленному хосту надо делать со своего IP-адреса, а не от имени жертвы, по этой же причине. Итог атаки можно увидеть на рис. 4.