Воздушный дуршлаг: история взлома крупного беспроводного провайдера
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-25 16:52:59.636666
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
хм, помоему ничего нового.
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-25 17:41:03.550000
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
Выходи за меня! ;*
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-25 19:30:38.166666
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
мм, учту это в своей научной работе XD)))
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-25 23:18:37.716666
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
лол, а сертификат валидный где взять для https-сервера? тут явно клиентос лопух, не посмотрел куда его закинуло.
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-25 23:45:21.393333
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
я вот юзаю свой usb-modem с 2008 года, а он же тоже беспроводной =) и по дому кинул wi-fi свой.
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-26 01:33:06.550000
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
неть!!
за меня!!! =)
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-26 05:02:25.396666
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
Молодчинка, Кристина.
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-26 20:43:50.563333
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
ничего нового +1
На счет DIR-300 не знаю, но на 320 или asus wl-5** можно поднять свой http сервер (и не только) со всеми возможностями и запитать его от аккумулятора, вот тебе и не расположишься в кафе ;)
Прошол большой промежуток времени, код сообщения изменился. Повторите ввод кода.
грамотеи блин, прошЕл.
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-27 01:55:17.490000
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
Молодец =)
не вижу смысла в коде следующего после "// Проверка существования и доступа для записи файла."
это вообще к чему? это ж палево
|
|
|
|
|
взлом крупного беспроводного провайдера - 2010-08-27 08:18:43.643333
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
ну и нахрена нужен был DIR-300?
когда всё это можно было проделать средствами обычной Windows + ettercap
|
|
|
|
|
взлом провайдера - 2010-08-27 08:24:18.900000
|
|
|
79084195O6O
Сообщений: 321
Оценки: 0
Присоединился: 2009-09-25 14:44:51.560000
|
послушайте, с проводными сетями на самом деле ситуация точно такая же, просто про вместо того, чтобы написать про ARP POISON, вы написали какую-то шнягу про D-Link DIR-300… - это примерно как в баню идти со своим самоваром.
|
|
|
|
|
Атака на коммутатор Ethernet - 2010-08-27 10:02:04.470000
|
|
|
Gоndon
Сообщений: 119
Оценки: 0
Присоединился: 2010-05-28 13:00:45.096666
|
Реакция коммутатора вполне ожидаема: таблица коммутации мгновенно заполняется MAC-адресами, занимая весь объем доступной памяти. К примеру, Switch 2950 Cisco может держать в памяти не более 8000 MAC-адресов. Команда show mac-address-table позволяет просматривать таблицу коммутации. На первом этапе она выглядит следующим образом:
После запуска ArpFlood, свободного места в таблице больше не остается:
У этого результата есть два важных следствия: потеря управления и переход коммутатора в режим хаба. Рассмотрим их немного подробнее.
С первых секунд атаки коммутатор плохо реагирует на попытки удаленного управления. Индикация происходит медленно, а время отклика на команды – неоправданно велико. Однако, это никак не отражается на основной функции коммутатора и его пропускная способность не страдает. Т.е. удар приходится только по системе управления, а не по основному функционалу устройства.
Далее, коммутатор не обладая достаточным объемом памяти, чтобы хранить всю корреспонденцию MAC-адресов, обязан перейти в режим хаба, что позволяет злоумышленнику просматривать видеопоток:
Таким образом, злоумышленник получает весь объем обмена трафиком между клиентом (XBOX) с адресом 192.168.101.3 и сервером 192.168.101.4. Следует отметить, что существует два варианта развития ситуации в зависимости от того, происходил ли обмен трафиком между клиентом и сервером до начала атаки.
В первом варианте, где атака начинается раньше "общения" между сервером и клиентом, коммутатор не успевает записать их MAC-адреса в таблицу коммутации и, под наплывом флуда, переходит в режим хаба раньше, чем клиент посылает запрос на сервер. Соответственно, все запросы клиента и ответы сервера появляются на всех портах и доступны злоумышленнику в полном объеме.
Во втором варианте, атака начинается после того, как MAC-адреса клиента и сервера записаны в таблицу коммутации, что означает невозможность прослушивания. Но, поскольку срок "жизни" записей в таблице коммутации ограничен, по истечению этого времени коммутатор теряет последние сведения о "правильной" коммутации, не может их получить из-за переполнения памяти, и далее развитие событий происходит по первому варианту.
Информация к размышлению: по умолчанию, время "жизни" записи в таблице коммутации для Switch 2950 Cisco составляет 5 минут.
Это время можно переопределить командой "mac-address-table aging-time", как это сделано в следующем примере, где описываемый параметр задан значением "10 секунд".
Еще одним следствием атаки станет возрастание трафика на всех портах коммутатора, перешедшего в режим хаба. Ведь то, что ранее транслировалось только между двумя портами, теперь оказывается доступным на каждом порту, что, разумеется, немедленно сказывается на конечных пользователях.
Кроме того, любой коммутатор обладает ограничением по суммарной полосе пропускания. Например, для Cisco Catalyst 2950T-24 этот показатель составляет 8,8 Гбит/с (т.е. суммарный поток трафика между всеми портами не может превышать 8,8 бит/с). Это значит, что при значительных объемах трафика, поступающего на все порты, общая полоса пропускания может превысить возможности коммутатора.
Атака локальной сети предприятия.
Обычная схема локальной сети предприятия предусматривает использование коммутаторов ядра, пограничных коммутаторов и коммутаторов распределения. Вот вариант атаки на такую сеть:
- Через IPBX предприятия осуществляется голосовая телефонная связь.
- Злоумышленник наводняет случайными MAC-адресами коммутатор С.
- Коммутатор С ассоциирует записи в таблице коммутации с физическим портом, через который подключен злоумышленник.
- Коммутатор D ассоциирует записи в таблице коммутации с физическим портом, через который подключен коммутатор С.
- Коммутатор Е ассоциирует записи в таблице коммутации с физическим портом, через который подключен коммутатор D.
Продолжительность процедуры зависит только от числа коммутаторов. Чуть раньше или чуть позже, злоумышленник все равно получает возможность прослушивать VoIP-трафик, находясь в любом месте на территории предприятия. Любой коммутатор имеет ограничения. Например, если коммутаторы С и Е будут представлены устройствами Cisco 2950 с предельным объемом таблицы коммутации в 8000 записей, а коммутатор D – Cisco 6509 с ограничением в 64000 записей, злоумышленник спокойно насытит память коммутаторов С и Е, а потом, не прекращая процесса, доведет до того же состояния и коммутатор D, поскольку флуд все равно будет продолжать распространяться, а коммутатор ядра просто "обязан" его записывать.
Из чего можно сделать вывод о влиянии атаки на сеть всего предприятия в целом, даже если она построена стандартным трехуровневым способом с коммутатором Cisco Catalyst серии 6500 в ядре.
Неэффективные способы защиты.
Одним из возможных вариантов защиты заключается в уменьшении времени жизни записей в таблице коммутации. Особой пользы от этого, правда, нет: коммутатор все равно остается уязвимым во время атаки. Быстро освободившись от записей флуда, он точно так же снова их наберет при повторении атаки.
Еще один вариант – приобретение более высокопроизводительных коммутаторов, имеющих больше памяти для размещения записей таблицы коммутации. Вот список коммутаторов Cisco с предельно допустимыми объемами записей таблиц коммутации:
Cisco Catalyst 2924 XL - 2000
Cisco Catalyst 2948 G-GE-TX - 16000
Cisco Catalyst 2950 Series - 8000
Cisco Catalyst 2955 Series - 8000
Cisco Catalyst 2960 Series - 8000
Cisco Catalyst 2970 Series - 8000
Cisco Catalyst 3550-12G - 12000
Cisco Catalyst 3550-12T - 12000
Cisco Catalyst 3550-24 - 8000
Cisco Catalyst 3550-24-DC - 8000
Cisco Catalyst 3550-24 PWR - 8000
Cisco Catalyst 3550-24-FX - 8000
Cisco Catalyst 3550-48 - 8000
Cisco Catalyst 3560 Series - 12000
Cisco Catalyst 3750G-24TS - 12000
Cisco Catalyst 3750G-24WS - 12000
Cisco Catalyst 3750G-24T - 12000
Cisco Catalyst 3750G-12S - 12000
Cisco Catalyst 3750-24TS - 12000
Cisco Catalyst 3750-24FS - 12000
Cisco Catalyst 3750-24PS - 12000
Cisco Catalyst 3750-48TS - 12000
Cisco Catalyst 3750-48PS - 12000
Cisco Catalyst 3750G-24TS-1U - 12000
Cisco Catalyst 3750G-24PS - 12000
Cisco Catalyst 3750G-48TS - 12000
Cisco Catalyst 3750G-48PS - 12000
Cisco Catalyst 3750G-16TD - 12000
|
|
|
|
|
ARP SPOOF - атака на провайдера - 2010-08-27 10:14:00.003333
|
|
|
79084195O6O
Сообщений: 321
Оценки: 0
Присоединился: 2009-09-25 14:44:51.560000
|
Рассмотрим атаку типа 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-poisoning
Современные программы такого типа предоставляют два вида атаки:
- Атака arp-request пакетами
- Атака arp-reply пакетами
Особенностью arp-reply пакетов является их направленность: заранее известно на какие физические и IP адреса нужно отправлять ответ. У arp-request пакетов заранее неизвестно какой именно станции их отправлять. Поэтому поля получателя (в Ethernet-кадре) заполняются как Broadcast. Такой пакет получат все станции подсети, которой принадлежит компьютер, отправляющий arp-запрос. В случае, если физический адрес компьютера принимающего запрос совпадает с адресом, указанном в поле ARP-протокола arp-request пакета – компьютер отвечает на такой запрос arp-reply пакетом. В противном случае такой пакет отбрасывается.
Рассмотрим реализации этих двух типов атак на примере утилиты Cain&Able.
Атака arp-reply пакетами обычно выглядит так: сначала жертве единожды посылается arp-request пакет, а потом уже посылаются arp-reply пакеты через заданный промежуток времени. Это делается для того, чтобы у жертвы в arp-таблице наверняка появилась запись об адресах подменяемого узла. Если в данный момент времени такой записи не будет, то жертва, принимая пакет arp-reply, никаких данных в свою таблицу не внесёт. Значит, никакой подмены не произойдёт.
Атака arp-request пакетами имеет следующий вид: посылаются пакеты arp-request через заданный промежуток времени. При чём обычно адреса получателя указываются не как Broadcast, а как истинный адрес получателя. То есть такой пакет будет послан только жертве. Другие станции подсети такой пакет не получат. Это разумно: исключается особенность arp-request пакета и атака становится направленной. Зачем другим станциям получать такой пакет? Их таблицу он не отравит. А вот если на какой-то станции стоит ПО для поиска аномалий в сети – это раскроет сам факт атаки. А аномалия здесь налицо: пойман пакет, в котором физический адрес не соответствует легитимному IP-адресу.
Некоторые снифферы (например, ettercap) отравляют arp-таблицу только 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-протокола с физическим адресом отправителя любым и такой пакет спокойно пройдёт через коммутатор и создаст фиктивную запись в таблице жертвы.
Рис №5: arp-poisining через коммутатор с включенной опцией port-security
ARP Builder
Для проведения тестов с arp-пакетами мне потребовалась утилита, которая может конструировать такие пакеты с разными параметрами. К сожалению, все найденные мною утилиты либо не работали под Windows XP, либо не предлагали визуально простого создания пакетов. Поэтому пришлось создать свою. Выкладываю её на обозрение читателей. Утилита будет полезна для проверки настроек персональных файерволлов и сетевого оборудования. А сомневающиеся могут воспользоваться ею для проверки фактов, изложенных мною в этой статье :)
|
|
|
|
|
взлом крупного провайдера - 2010-08-27 11:42:51.026666
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
да, действительно вся фишка в том, что это работает и в беспроводных сетях тоже
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-29 10:41:52.826666
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
а как сделать чтобы днс все запросы на один и тот же ip направлял? что написать в hosts ??
|
|
|
|
|
RE: Воздушный дуршлаг: история взлома крупного беспроводного провайдера - 2010-08-29 17:15:36.370000
|
|
|
Guest
Сообщений: 83368
Оценки: 51
Присоединился: None
|
Это u-tel )))ГыГЫ)))
|
|
|
|
|
ettercap NG-0.7.3 - DNS - 2010-08-30 21:48:08.390000
|
|
|
79084195O6O
Сообщений: 321
Оценки: 0
Присоединился: 2009-09-25 14:44:51.560000
|
quote:
а как сделать чтобы днс все запросы на один и тот же ip направлял? что написать в hosts ??
dns_spoof
Этот плагин перехватывает DNS запросы и отвечает на них поддельным ответом. Вы можете выбрать запросы на которые плагин должен ответить, изменив etter.dns файл. Плагин перехватывает А, PTR и MX запросы. Если это был запрос типа А, имя ищется в файле и IP-адрес посылается в качестве ответа (вы можете использовать групповые символы в имени). Если это был PTR запрос, IP ищется в файле и имя возвращается абоненту (за исключением тех именем, которые содержат шаблон). В случае MX запроса заготовлен специальный ответ. Хост разрешается из файта mail.host с поддельным адресом, где дополнительная запись содержится в mail.host. Первый адрес или хост который соответствует таблице будет сообщено абоненту, так что будьте внимательны при оформлении таблицы.
|
|
|
|
|
|
