ARP-spoofing: старая песня на новый лад
Об arp-спуфинге известно уже давно. С момента публикации первых материалов по этой проблеме прошло много лет. Было написано много программ как реализующих данный тип атак, так и призванных защитить от этих самых атак. А с недавних пор такую защиту стали внедрять и в персональные межсетевые экраны. Казалось бы: тема исчерпала себя. Однако полигон для работы мозгов все же остается...
суть вопроса
В этой статье мы рассмотрим атаку типа ARP-spoofing как со стороны атакующего, так и со стороны жертвы (того пользователя, против которого направлена атака).
Итак, исходные данные:
- локальная сеть типа Ethernet, построенная на неуправляемых коммутаторах;
- отсутствие статических ARP-таблиц у жертвы;
- наличие персонального файрволла у жертвы;
- атакующий должен создать фиктивную запись в ARP-таблице жертвы в обход персонального файрволла.
анализ работы персонального файрволла
В последнее время внедрение защиты от ARP-спуфинга стало популярной идеей среди разработчиков персональных межсетевых экранов. Я точно не знаю, какой производитель первым реализовал данный механизм. Однако первый продукт, попавший мне на глаза, с такой функцией был Agnitum Outpost Firewall. Потом компания «Агава» объявила о выходе своего Agava Firewall с поддержкой аналогичной защиты. И, насколько мне известно, лаборатория Касперского тоже вдохновилась идеей включения подобной функции в будущую версию Kaspersky Internet Security 8.0.
Как же работают перечисленные файрволлы? На самом деле, не смотря на то, что продукты разные, защита у них построена по схожему принципу: если приходит ARP-ответ, а система не посылала ARP-запрос - делается вывод, что была попытка фиктивной записи в ARP-таблицу. Это логично, ведь вероятность того, что придет достоверный ARP-ответ притом, что запрос не посылался, равна нулю.
Рис. 1. Параметры Agnitum Outpost Firewall 2008 по пресечению ARP poisoning.
Некоторые персональные файрволлы (к примеру, Outpost, см. рис. 1) принимают только самый первый ответ на ARP-запрос, считая остальные запросы фиктивными. Выходит, если атакующему удастся ответить на запрос раньше, чем придет легитимный ответ – файрволл примет его ответ, а легитимный ответ будет отброшен. То есть произойдет подмена записи в ARP-таблице жертвы. Но этот путь очень тернист: послать свой ответ раньше, чем придет легитимный ответ, не так-то просто. Есть более легкий способ провести атаку. Действительно: существует же возможность модифицирования ARP- таблицы путем посылки фиктивных ARP-запросов. Такие ответы файрволлы с легкостью пропускают.
Кроме того, внесение компьютера в список атакующих в том случае, если от него пришел ARP-ответ, когда система не посылала запроса, не всегда является правильным решением. Пример (см. рис. 2): компьютер А посылает ARP-запрос компьютеру В от имени компьютера С. В итоге компьютер В пошлет ARP-ответ компьютеру С. Но компьютер С запроса не посылал. Соответственно, файрволл, находящийся на компьютере С, сочтет компьютер В атакующей системой. Какой практический толк от такой атаки? Если файрволл сконфигурирован на внесение в «черный список» системы, которая, по его мнению, производила попытку атаки, мы получим DoS-атаку. Ведь в итоге связь легитимного компьютера с жертвой нарушится.
Рис. 2. Ложная тревога файерволла.
Вывод: современные персональные межсетевые экраны не могут эффективно предотвращать атаки, направленные на изменение записей ARP-таблицы.
анализ работы программ, реализующих атаку типа ARP poisoning
Современные программы такого типа предоставляют два вида атаки:
- атака пакетами ARP request;
- атака пакетами ARP reply.
Особенностью пакетов ARP reply является их направленность: заранее известно, на какие физические и IP-адреса нужно отправлять ответ. У пакетов ARP request заранее неизвестно, какой именно станции их отправлять. Поэтому поля получателя (в Ethernet-кадре) заполняются как Broadcast. Такой пакет получат все станции подсети, которой принадлежит компьютер, отправляющий ARP-запрос. В случае, если физический адрес компьютера, принимающего запрос, совпадает с адресом, указанном в поле ARP-протокола ARP request пакета – компьютер отвечает на такой запрос пакетом ARP reply. В противном случае такой пакет отбрасывается.
Рассмотрим реализации этих двух типов атак на примере утилиты Cain&Able.
Атака ARP reply пакетами обычно выглядит так: сначала жертве единожды посылается request-пакет, а потом уже посылаются reply-пакеты через заданный промежуток времени. Это делается для того, чтобы у жертвы в ARP-таблице наверняка появилась запись об адресах подменяемого узла. Если в данный момент времени такой записи не будет, то жертва, принимая пакет ARP reply, никаких данных в свою таблицу не внесет. Значит, никакой подмены не произойдет.
Атака request-пакетами имеет следующий вид: посылаются пакеты ARP request через заданный промежуток времени. При чем обычно адреса получателя указываются не как Broadcast, а как истинный адрес получателя. То есть такой пакет будет послан только жертве. Другие станции подсети такой пакет не получат. Это разумно: атака становится направленной. Зачем другим станциям получать такой пакет? Их таблицу он не отравит. А вот если на какой-то станции стоит ПО для поиска аномалий в сети – это раскроет сам факт атаки. А аномалия здесь налицо: пойман пакет, в котором физический адрес не соответствует легитимному IP-адресу.
Некоторые снифферы (например, ettercap) отравляют ARP-таблицу только reply-пакетами. Атака выглядит так (см. рис. 3): компьютеру B сначала посылается какой-нибудь фиктивный пакет от компьютера A. Ettercap создает ICMP-echo пакет от IP-адреса компьютера C. После этого посылаются пакеты ARP reply с IP-адресом компьютера C, но МАС-адресом компьютера атакующего. В том случае, если у компьютера B в ARP-таблице нет данных о компьютере C – он отправит ARP-request, на что получит фиктивный ARP reply. А если в ARP-таблице компьютера B присутствует запись о компьютере C, то приходящие фиктивные пакеты ARP-reply также отравят таблицу.
Рис. 3. Схема работы ettercap.
В случае с ettercap, такая атака будет полностью пресечена, например, Аутпостом: по-умолчанию этот файрволл сконфигурирован на запрет приема ICMP-echo пакетов. Значит, никакого ARP request компьютер жертвы не отправит. Следовательно, ни один ARP reply не пройдет через Аутпост и не отравит ARP-таблицу.
После того, как в ARP-таблицах появятся фиктивные записи, трафик от атакованных компьютеров будет проходить через компьютер атакующего. Такой тип атак называется «Man in the Middle» (человек посередине, MitM). Чтоб связь не разрывалась между компьютерами, компьютер атакующего должен модифицировать проходящий трафик. Модификация заключается в изменении физических (MAC) адресов в полях Ethernet-пакетов: меняется адрес отправителя с легитимного адреса на адрес атакующего.
ARP-poisoning и port-security
Теперь представим ту же ситуацию, но теперь сеть построена на управляемых коммутаторах, на которых настроена привязка физических адресов к портам коммутатора. Обсуждение создания VLAN-ов и других мер противодействия выходит за рамки данной статьи.
Очень часто на форумах по сетевой безопасности можно встретить суждения вроде: «Привязка MAC-адреса компьютера к порту управляемого коммутатора не пресекает саму атаку MitM, но она поможет найти физическое расположение нарушителя». Это действительно так. Но зачастую люди, высказывающиеся таким образом, забывают, один серьезный факт. Даже при привязке физического адреса компьютера к порту коммутатора можно отравить ARP-таблицу фиктивной записью от имени третьего лица. То есть (см. рис. 5): компьютер С может создать запись в ARP-таблице компьютера А от имени компьютера В. Конечно, атаки MitM здесь не получится, но зато возможна DoS-атака. И неопытный администратор может долго пытаться найти ответ на вопрос: каким образом в ARP-таблице появилась запись с MAC-адресом 00:11:22:33:44:55, если он не принадлежит ни одному компьютеру в сети? Ведь port- security должен пресекать посылки пакетов с фиктивными MAC-адресами! На самом деле, все очень просто: при привязке физического адреса к порту коммутатора, коммутатор проверяет приходящие на этот порт пакеты по заголовкам Ethernet. ARP-пакеты имеют 4 поля с физическими адресами: два принадлежат уровню Ethernet (адрес отправителя и адрес получателя) и два – собственно ARP-протоколу (так же адрес отправителя и адрес получателя). Значит, достаточно задать верными поля Ethernet, а поле ARP-протокола с физическим адресом отправителя любым и такой пакет спокойно пройдет через коммутатор и создаст фиктивную запись в таблице жертвы.
Рис. 4. ARP poisining через коммутатор с включенной опцией port-security.
методы борьбы
Из описанных выше пунктов можно сделать несколько выводов о том, как более эффективно бороться с ARP poisoning атаками как на уровне персональных файрволлов, так и силами сетевого оборудования:
- фильтровать ARP-пакеты, в которых физический адрес отправителя в полях Ethernet- и ARP-протоколов различны;
- фильтровать пакеты ARP request, где физический адрес отправителя в заголовке Ethernet-кадра не является broadcast.
Конечно, эти меры полностью не искоренят проблему атаки ARP poisoning: ведь остается возможность отправить ARP-request с фиктивным физическим адресом отправителя на broadcast. Или ждать ARP request от жертвы и попытаться отправить ARP reply до того, как то же самое сделает легитимный компьютер, которому предназначался ARP request. Однако поле действия злоумышленника значительно сузится.
Кроме того, существует один универсальный метод борьбы с атакой MitM, основанной на атаке ARP poisoning. Суть этого метода (см. рис. 5): периодически посылать пакеты, в которых будет передаваться информация о MAC-адресе отправителя не только в поле Ethernet, но и в теле самого пакета. Когда такой пакет пройдет через атакующего, его компьютер подменит MAC-адрес отправителя, а данные пакета останутся как есть. На принимающей стороне компьютер увидит, что адреса отправителя различаются в поле Ethernet и в данных, в которые отправитель вставил свой адрес. Конечно, в этом способе есть свои минусы: требуется дополнительное ПО на всех компьютерах подсети. Кроме того, если есть необходимость совместной работы с компьютерами, в которых нет такого ПО, надо выбрать какой-то протокол, куда можно вставлять свои данные. Например, можно выбрать пакет ICMP-echo. А вот выбор ARP request/ARP reply будет плохой идеей: сниффер атакующего может не пропустить такие пакеты через себя дальше. Ведь эти пакеты могут восстановить легитимные записи в ARP-таблице жертвы.
Рис. 5. Обнаружение атаки MitM.
Несмотря на то, что описанный мною метод не встречался мне лично нигде – приписывать себе его авторство не стану: наверняка кто-то до меня додумался до того же самого. Просто мне не попадалась эта публикация :)
ARP Builder
Для проведения тестов с ARP-пакетами мне потребовалась утилита, которая может конструировать такие пакеты с разными параметрами. К сожалению, все найденные мною утилиты либо не работали под Windows XP, либо не предлагали визуально простого создания пакетов. Поэтому пришлось создать свою. Выкладываю ее на обозрение читателей (http://www.securitylab.ru/software/313490.php). Утилита будет полезна для проверки настроек персональных файерволлов и сетевого оборудования. А сомневающиеся могут воспользоваться ею для проверки фактов, изложенных мною в этой статье :)
Рис. 6. Внешний вид программы ARP Builder.
заключение
В данной статье были рассмотрены методы реализации атаки типа ARP poisining и методы противодействия. Надеюсь, в ближайшем будущем производители персональных сетевых экранов внесут соответствующие корректировки в следующие выпуски своих продуктов, а администраторы локальных сетей еще раз подумают о том, насколько правильно настроено сетевое оборудование.
Агиевич Игорь aka Shanker. Впервые опубликовано на Securitylab
суть вопроса
В этой статье мы рассмотрим атаку типа ARP-spoofing как со стороны атакующего, так и со стороны жертвы (того пользователя, против которого направлена атака).
Итак, исходные данные:
- локальная сеть типа Ethernet, построенная на неуправляемых коммутаторах;
- отсутствие статических ARP-таблиц у жертвы;
- наличие персонального файрволла у жертвы;
- атакующий должен создать фиктивную запись в ARP-таблице жертвы в обход персонального файрволла.
анализ работы персонального файрволла
В последнее время внедрение защиты от ARP-спуфинга стало популярной идеей среди разработчиков персональных межсетевых экранов. Я точно не знаю, какой производитель первым реализовал данный механизм. Однако первый продукт, попавший мне на глаза, с такой функцией был Agnitum Outpost Firewall. Потом компания «Агава» объявила о выходе своего Agava Firewall с поддержкой аналогичной защиты. И, насколько мне известно, лаборатория Касперского тоже вдохновилась идеей включения подобной функции в будущую версию Kaspersky Internet Security 8.0.
Как же работают перечисленные файрволлы? На самом деле, не смотря на то, что продукты разные, защита у них построена по схожему принципу: если приходит ARP-ответ, а система не посылала ARP-запрос - делается вывод, что была попытка фиктивной записи в ARP-таблицу. Это логично, ведь вероятность того, что придет достоверный ARP-ответ притом, что запрос не посылался, равна нулю.
Рис. 1. Параметры Agnitum Outpost Firewall 2008 по пресечению ARP poisoning.
Некоторые персональные файрволлы (к примеру, Outpost, см. рис. 1) принимают только самый первый ответ на ARP-запрос, считая остальные запросы фиктивными. Выходит, если атакующему удастся ответить на запрос раньше, чем придет легитимный ответ – файрволл примет его ответ, а легитимный ответ будет отброшен. То есть произойдет подмена записи в ARP-таблице жертвы. Но этот путь очень тернист: послать свой ответ раньше, чем придет легитимный ответ, не так-то просто. Есть более легкий способ провести атаку. Действительно: существует же возможность модифицирования ARP- таблицы путем посылки фиктивных ARP-запросов. Такие ответы файрволлы с легкостью пропускают.
Кроме того, внесение компьютера в список атакующих в том случае, если от него пришел ARP-ответ, когда система не посылала запроса, не всегда является правильным решением. Пример (см. рис. 2): компьютер А посылает ARP-запрос компьютеру В от имени компьютера С. В итоге компьютер В пошлет ARP-ответ компьютеру С. Но компьютер С запроса не посылал. Соответственно, файрволл, находящийся на компьютере С, сочтет компьютер В атакующей системой. Какой практический толк от такой атаки? Если файрволл сконфигурирован на внесение в «черный список» системы, которая, по его мнению, производила попытку атаки, мы получим DoS-атаку. Ведь в итоге связь легитимного компьютера с жертвой нарушится.
Рис. 2. Ложная тревога файерволла.
Вывод: современные персональные межсетевые экраны не могут эффективно предотвращать атаки, направленные на изменение записей ARP-таблицы.
анализ работы программ, реализующих атаку типа ARP poisoning
Современные программы такого типа предоставляют два вида атаки:
- атака пакетами ARP request;
- атака пакетами ARP reply.
Особенностью пакетов ARP reply является их направленность: заранее известно, на какие физические и IP-адреса нужно отправлять ответ. У пакетов ARP request заранее неизвестно, какой именно станции их отправлять. Поэтому поля получателя (в Ethernet-кадре) заполняются как Broadcast. Такой пакет получат все станции подсети, которой принадлежит компьютер, отправляющий ARP-запрос. В случае, если физический адрес компьютера, принимающего запрос, совпадает с адресом, указанном в поле ARP-протокола ARP request пакета – компьютер отвечает на такой запрос пакетом ARP reply. В противном случае такой пакет отбрасывается.
Рассмотрим реализации этих двух типов атак на примере утилиты Cain&Able.
Атака ARP reply пакетами обычно выглядит так: сначала жертве единожды посылается request-пакет, а потом уже посылаются reply-пакеты через заданный промежуток времени. Это делается для того, чтобы у жертвы в ARP-таблице наверняка появилась запись об адресах подменяемого узла. Если в данный момент времени такой записи не будет, то жертва, принимая пакет ARP reply, никаких данных в свою таблицу не внесет. Значит, никакой подмены не произойдет.
Атака request-пакетами имеет следующий вид: посылаются пакеты ARP request через заданный промежуток времени. При чем обычно адреса получателя указываются не как Broadcast, а как истинный адрес получателя. То есть такой пакет будет послан только жертве. Другие станции подсети такой пакет не получат. Это разумно: атака становится направленной. Зачем другим станциям получать такой пакет? Их таблицу он не отравит. А вот если на какой-то станции стоит ПО для поиска аномалий в сети – это раскроет сам факт атаки. А аномалия здесь налицо: пойман пакет, в котором физический адрес не соответствует легитимному IP-адресу.
Некоторые снифферы (например, ettercap) отравляют ARP-таблицу только reply-пакетами. Атака выглядит так (см. рис. 3): компьютеру B сначала посылается какой-нибудь фиктивный пакет от компьютера A. Ettercap создает ICMP-echo пакет от IP-адреса компьютера C. После этого посылаются пакеты ARP reply с IP-адресом компьютера C, но МАС-адресом компьютера атакующего. В том случае, если у компьютера B в ARP-таблице нет данных о компьютере C – он отправит ARP-request, на что получит фиктивный ARP reply. А если в ARP-таблице компьютера B присутствует запись о компьютере C, то приходящие фиктивные пакеты ARP-reply также отравят таблицу.
Рис. 3. Схема работы ettercap.
В случае с ettercap, такая атака будет полностью пресечена, например, Аутпостом: по-умолчанию этот файрволл сконфигурирован на запрет приема ICMP-echo пакетов. Значит, никакого ARP request компьютер жертвы не отправит. Следовательно, ни один ARP reply не пройдет через Аутпост и не отравит ARP-таблицу.
После того, как в ARP-таблицах появятся фиктивные записи, трафик от атакованных компьютеров будет проходить через компьютер атакующего. Такой тип атак называется «Man in the Middle» (человек посередине, MitM). Чтоб связь не разрывалась между компьютерами, компьютер атакующего должен модифицировать проходящий трафик. Модификация заключается в изменении физических (MAC) адресов в полях Ethernet-пакетов: меняется адрес отправителя с легитимного адреса на адрес атакующего.
ARP-poisoning и port-security
Теперь представим ту же ситуацию, но теперь сеть построена на управляемых коммутаторах, на которых настроена привязка физических адресов к портам коммутатора. Обсуждение создания VLAN-ов и других мер противодействия выходит за рамки данной статьи.
Очень часто на форумах по сетевой безопасности можно встретить суждения вроде: «Привязка MAC-адреса компьютера к порту управляемого коммутатора не пресекает саму атаку MitM, но она поможет найти физическое расположение нарушителя». Это действительно так. Но зачастую люди, высказывающиеся таким образом, забывают, один серьезный факт. Даже при привязке физического адреса компьютера к порту коммутатора можно отравить ARP-таблицу фиктивной записью от имени третьего лица. То есть (см. рис. 5): компьютер С может создать запись в ARP-таблице компьютера А от имени компьютера В. Конечно, атаки MitM здесь не получится, но зато возможна DoS-атака. И неопытный администратор может долго пытаться найти ответ на вопрос: каким образом в ARP-таблице появилась запись с MAC-адресом 00:11:22:33:44:55, если он не принадлежит ни одному компьютеру в сети? Ведь port- security должен пресекать посылки пакетов с фиктивными MAC-адресами! На самом деле, все очень просто: при привязке физического адреса к порту коммутатора, коммутатор проверяет приходящие на этот порт пакеты по заголовкам Ethernet. ARP-пакеты имеют 4 поля с физическими адресами: два принадлежат уровню Ethernet (адрес отправителя и адрес получателя) и два – собственно ARP-протоколу (так же адрес отправителя и адрес получателя). Значит, достаточно задать верными поля Ethernet, а поле ARP-протокола с физическим адресом отправителя любым и такой пакет спокойно пройдет через коммутатор и создаст фиктивную запись в таблице жертвы.
Рис. 4. ARP poisining через коммутатор с включенной опцией port-security.
методы борьбы
Из описанных выше пунктов можно сделать несколько выводов о том, как более эффективно бороться с ARP poisoning атаками как на уровне персональных файрволлов, так и силами сетевого оборудования:
- фильтровать ARP-пакеты, в которых физический адрес отправителя в полях Ethernet- и ARP-протоколов различны;
- фильтровать пакеты ARP request, где физический адрес отправителя в заголовке Ethernet-кадра не является broadcast.
Конечно, эти меры полностью не искоренят проблему атаки ARP poisoning: ведь остается возможность отправить ARP-request с фиктивным физическим адресом отправителя на broadcast. Или ждать ARP request от жертвы и попытаться отправить ARP reply до того, как то же самое сделает легитимный компьютер, которому предназначался ARP request. Однако поле действия злоумышленника значительно сузится.
Кроме того, существует один универсальный метод борьбы с атакой MitM, основанной на атаке ARP poisoning. Суть этого метода (см. рис. 5): периодически посылать пакеты, в которых будет передаваться информация о MAC-адресе отправителя не только в поле Ethernet, но и в теле самого пакета. Когда такой пакет пройдет через атакующего, его компьютер подменит MAC-адрес отправителя, а данные пакета останутся как есть. На принимающей стороне компьютер увидит, что адреса отправителя различаются в поле Ethernet и в данных, в которые отправитель вставил свой адрес. Конечно, в этом способе есть свои минусы: требуется дополнительное ПО на всех компьютерах подсети. Кроме того, если есть необходимость совместной работы с компьютерами, в которых нет такого ПО, надо выбрать какой-то протокол, куда можно вставлять свои данные. Например, можно выбрать пакет ICMP-echo. А вот выбор ARP request/ARP reply будет плохой идеей: сниффер атакующего может не пропустить такие пакеты через себя дальше. Ведь эти пакеты могут восстановить легитимные записи в ARP-таблице жертвы.
Рис. 5. Обнаружение атаки MitM.
Несмотря на то, что описанный мною метод не встречался мне лично нигде – приписывать себе его авторство не стану: наверняка кто-то до меня додумался до того же самого. Просто мне не попадалась эта публикация :)
ARP Builder
Для проведения тестов с ARP-пакетами мне потребовалась утилита, которая может конструировать такие пакеты с разными параметрами. К сожалению, все найденные мною утилиты либо не работали под Windows XP, либо не предлагали визуально простого создания пакетов. Поэтому пришлось создать свою. Выкладываю ее на обозрение читателей (http://www.securitylab.ru/software/313490.php). Утилита будет полезна для проверки настроек персональных файерволлов и сетевого оборудования. А сомневающиеся могут воспользоваться ею для проверки фактов, изложенных мною в этой статье :)
Рис. 6. Внешний вид программы ARP Builder.
заключение
В данной статье были рассмотрены методы реализации атаки типа ARP poisining и методы противодействия. Надеюсь, в ближайшем будущем производители персональных сетевых экранов внесут соответствующие корректировки в следующие выпуски своих продуктов, а администраторы локальных сетей еще раз подумают о том, насколько правильно настроено сетевое оборудование.
Агиевич Игорь aka Shanker. Впервые опубликовано на Securitylab
Сетевые решения. Статья была опубликована в номере 04 за 2008 год в рубрике технологии
