@zabbius18 июн 2014 в 13:39

Еще один способ перехвата трафика через ARP Spoofing

6 мин

87K

Информационная безопасность *

+39

Комментарии 30

@AEP 18 июн 2014 в 14:26

Идеи навскидку, возможно глупые: traceroute до чего угодно, ping шлюза (смотреть на ttl, который NAT'ом уменьшается на 1)

@zabbius 18 июн 2014 в 14:43

Спасибо, traceroute и правда палит контору.

@JDima 18 июн 2014 в 14:45

А в нем можно просто не уменьшать TTL? Наверняка ведь можно.

Но каким параноиком надо быть, чтобы при подключении к новой сети первым делом делать tracert?

@kay 19 июн 2014 в 07:22

iptables -t mangle -I PREROUTING -j TTL --ttl-inc 1

@zabbius 19 июн 2014 в 08:43

Спасибо, добавил в пост.

@JDima 18 июн 2014 в 14:44

было бы интересно почитать в комментах, как такую схему все таки можно запалить, не имея в сети l3 маршрутизации.

www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/dynarp.html
И всё, ARP атаки исключены. Вкратце: когда порт видит входящий ARP пакет, он сверяет комбинацию IP/mac/порт с имеющимся в таблице, которая заполняется либо из наблюдения за DHCP обменом, либо руками. Попытаетесь подставить чужие — пакет дропнут и алерт поднимут.

Следующий момент. Как только вы шлете пакет с новым маком до того, как заекспайрился старый (обычно — несколько минут), и на порту свитча настроен port-security с лимитом в один мак, то вы сразу спалились. Как и в предыдущем случае, спалитесь сразу номером порта, а не только маком.

А причем тут L3 маршрутизация вообще?

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

Обычно на шлюзе детекторов L2 атак нет вообще, ну помимо общего функционала CoPP :) Ну как он отличит корректный arp пакет от некорректного, если оба прилетают с одного L3 интерфейса? Какая-то навороченная эвристика? От нее будет больше вреда, чем пользы. Отключить обработку GARP'ов? Ну это в большинстве сред вызовет беду.

Такие вещи всегда детектируются на уровне L2 порта. И нет никакой разницы, атакуете вы шлюз или соседа.

@zabbius 18 июн 2014 в 14:57

Все так. Если все свичи в сети с детекторами, то ловить нечего. Но часто бывает, что нормальные умные свичи только в «центре», а вокруг все разнесено на неуправляемых. Такой случай и описан.

@JDima 18 июн 2014 в 15:08

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

@JDima 18 июн 2014 в 15:19

Ну и кстати arp — все-таки широковещательный пакет. Если в центре стоит умный свитч, а от него расходится гирлянда безмозглых, он все равно получит копию arp пакета, не соответствующего информации из таблицы DHCP. Помешать атаке в пределах ветки гирлянды он не сможет, но вот тревогу поднять — запросто.

@zabbius 18 июн 2014 в 15:21

А вот нет. Спуфинг производится не широковещательными пакетами. ARP Reply получает только атакуемый. В этом и идея поста.

@JDima 18 июн 2014 в 15:27

Хотя да, тоже верно. Но не ошибитесь и не начните атаковать того, к кому идти через умный свитч :)

Ну и, понятное дело, сам умный свитч вы таким образом атаковать не сможете, так как он помнит, какой мак запрашивал по DHCP присылаемый в ARP IP адрес.

@zabbius 18 июн 2014 в 15:34

В таком раскладе умный свитч как раз в роли шлюза будет. Ему будет сгружен честный DHCPшный мак. А вот в роли жертвы — да, не получится.

@KarasikovSergey 18 июн 2014 в 18:27

А разве древний Cain не тоже самое делает? Там надо указать лишь две точки(не обязательно шлюз) и вуаля — он еще для самых ленивых перехваченную инфу по полочкам разложит и отпарсит.

@zabbius 18 июн 2014 в 18:30

Отпарсить — это дело десятое, если трафик перехвачен. Насчет то же самое — не уверен. Как минимум он спуфит оба хоста. Как максимум может спалить реальный адрес. И самый главный недостаток — он под винду, где тривиальные вещи по настройке сети превращаются в головную боль.

@KarasikovSergey 18 июн 2014 в 18:46

Это удобный и безотказный инструмент, куда встроено помимо собственно спуфинга еще несколько полезных вещей. И мак там эмулируется, а уж айпи так и вовсе не проблема. Насчет отпарсить не проблема — в пентесте и так много мелкой работы, тут хоть некоторая значительная часть с плеч сваливается.

@zabbius 18 июн 2014 в 18:54

В свое время он был лучшим. Но сейчас, насколько я знаю, все пользуются не им, а Kali Linux.

@zabbius 18 июн 2014 в 19:10

@KarasikovSergey 19 июн 2014 в 06:58

Не знаю, в чем проблема пользоваться и тем, и другим. Я в работе использую Cain в обязательном порядке, Kali Linux тоже, но практика показывает, что «обычные» уязвимости в большинстве случаев прикрыты и самый верный вариант проникновения изнутри — это слабая парольная политика и человеческий фактор(юзеры с админскими правами, plain-text аутентификация на сервисах, инвентарная документация в общем доступе). Метасплоит вообще в наше время архиредко срабатывает — слишком оперативные обновления ПО сейчас.

@zabbius 18 июн 2014 в 19:11

Кстати, есть ли где-нибудь детальное описалово, как он (Cain) работает внутри?

@AEP 18 июн 2014 в 19:16

Еще предлагаю со шлюза попинговать жертву. Или послать какой-нибудь пакет на закрытый порт. Правильно ли я понимаю, что ICMP-ответ или TCP RST пойдет через NAT и тем самым спалит посредника через IP источника?

@zabbius 18 июн 2014 в 19:24

Интересное замечание, надо проверить, скорее всего так и будет и в итоге ответа на шлюзе без tcpdump мы не увидим. В случае, когда нужен полноценный двусторонний обмен, придется по-честному спуфить обоих.

@AEP 18 июн 2014 в 19:47

Еще непроверенная идея: со шлюза послать nping'ом какой-нибудь UDP-пакет с произвольным заспуфленным IP источника, с самим шлюзом в качестве IP назначения, и с broadcast'ом (ff:ff:ff:ff:ff:ff) в качестве MAC'а назначения. По идее, такое должно пройти через NAT (где бы он ни был), вернуться, и тем самым выдать себя.

@AEP 18 июн 2014 в 19:57

А нет, не прокатывает. L2 Broadcast'ы почему-то не попадают в FORWARD.

@zabbius 18 июн 2014 в 20:00

В общем случае да, должно сработать. Возможно, надо их в iptables разрешить. Написал, а потом подумал, что такой пакет шлюз сам тут же и поймает не отходя от кассы. IP-то его.

@AEP 18 июн 2014 в 20:04

Пакеты наружу таки уходят. Злоумышленник их tcpdump'ом видит. Просто на машине злоумышленника эти пакеты не попадают ни в INPUT, ни в FORWARD (проверял через -j LOG). Если использовать в качестве MAC'а назначения не ff:ff:ff:ff:ff:ff, а MAC злоумышленника, то и tcpdump видит, и протоколируется, и через NAT проходит, и возвращается. Только толку от этого нет, т.к. надо знать MAC.

@zabbius 18 июн 2014 в 20:10

В INPUT точно не могут попадать. Туда попадает только то, что послано на IP адаптера, а у нас IP назначения другой. В FORWARD по идее должно лезть, но, видимо, мак мешает…

@AEP 18 июн 2014 в 20:21

Собственно, разобрался.

См. github.com/torvalds/linux/blob/master/net/ethernet/eth.c, функцию eth_type_trans(). Она метит полученные пакеты с MAC'ом назначения ff:ff:ff:ff:ff:ff как PACKET_BROADCAST. А теперь см. github.com/torvalds/linux/blob/master/net/ipv4/ip_forward.c, функцию ip_forward(). Она в первую очередь отбрасывает все пакеты, помеченные не как PACKET_HOST.

@KleinenberG 6 июл 2014 в 10:37

Я правилбно понимаю, это так же можно провернуть в офисной сети с поднятой VM на ноуте

@JDima 6 июл 2014 в 11:14

Конечно же можно. Если поймают — надают по шарам и выгонят с работы. Часть способов ловли я описал выше, есть и другие, подразумевающие более глубокий анализ трафика на стороннем IDS.

@KleinenberG 6 июл 2014 в 14:14

Да не, я коллегу предупрежу, прост ради практики.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий