Комментарии 61
Страшно у вас жить, в общежитии то.
P.S.
На сколько я знаю, с vk.com — все усложнилось, пароли там идут не совсем plain-text.
И да, в ICQ нет SSL?
P.S.
На сколько я знаю, с vk.com — все усложнилось, пароли там идут не совсем plain-text.
И да, в ICQ нет SSL?
например ICQ передает пароль открытым текстом, vk.com тоже, кажется, до сих пор так делает
Логин и пароль передаются по SSL Кажется, на сайт login.vk.com
QIP 2005, стоявший на целевой машине, передавал пароль таким образом, что в дампе его можно было увидеть без проблем. Возможно в новых версиях с этим лучше.
Именно туда — более того, если заходить на https://vk.com/login.php, то соединение будет полностью зашифрованным, если не ошибаюсь. Значок шифрования, по крайней мере, будет.
ARP-spoofing. От него можно защититься даже на SOHO роутере. Например для популярного девайса Dlink DIR-300/320 можно включить Guest Zone, которая изолирует клиентов друг от другаВ ряде случаев роутер можно прописать статически при старте системы в ARP-таблицу. Я дла этого скриптик простой прописывал в автозагрузку в Windows. Главное, чтоб соединение с сетью было уже установлено. Иначе ARP-таблицы ещё не будет существовать.
С этим проблема — если компьютер является ноутбуком, и подключается к разным AP, у которых один и тот же IP-адрес шлюза, то нужно будет при смене AP каждый раз создавать статическую запись заново.
Статическая таблица ARP имеет свойство сбрасываться при отключении сетевого интерфейса.
Если клиенты в WiFi, то да, а если по проводу, то не выйдет, т.к. дырок в роутере на всех не хватает — ставят дополнительные свичи (это и локальный трафик в ЛС сильно ускоряет), а в них уже клиенты беззащитны друг перед другом. В провайдерских «домовых сетях», кстати, тоже, если напрямую подключены (большинство квартир так).
Хороший инструмент для проверки уязвимости своей ЛС к ARP-спуфингу — HonixBox ( iron.snop.ru/ ) — подключиться телнетом и выполнить команду ARP_SP ON. Или через API BB_ARP_SP. А через его встроенный веб-сервер можно смотреть ARP-таблицу со статистикой там же, выявляя другие подозрительные устройства в сети.
Хороший инструмент для проверки уязвимости своей ЛС к ARP-спуфингу — HonixBox ( iron.snop.ru/ ) — подключиться телнетом и выполнить команду ARP_SP ON. Или через API BB_ARP_SP. А через его встроенный веб-сервер можно смотреть ARP-таблицу со статистикой там же, выявляя другие подозрительные устройства в сети.
При чём тут схема подключения? Возможность статической записи от этого вообще не зависит. Разве что в локальной сети со статической записью может быть лучше, т.к. там нет таких обрывов, как при плохом сигнале в wi-fi, из-за чего при переподключении к сетке у пользователя обнулится таблица
Я про «которая изолирует клиентов друг от друга». Если клиенты подключены к роутеру через отдельный свич (а не по wifi, и не напрямую в дырки роутера), то роутер не сможет изолировать клиентов — они могут общаться через свич напрямую независимо от желания роутера. Соответственно роутер никак не может повлиять на их ARP-таблицы, т.к. они построятся без его участия на основе бродкастов в свич-сети.
Вы ошибаетесь. Если роутер выдаст по DHCP маску посдести в такой сети 255.255.255.255 (или последняя цифра 254, я сейчас точно не помню, практики настройки оборудования немного, поэтому попутать могу), то сколько бы свитчей не было, компьютер кроме роутера в ARP-таблице ничего не увидит и все запросы на любые IP пойдут роутеру напрямую. А он уже сам будет ими рулить. Броадкаст такой подсетисети всё равно будет ограничен компом и роутером, т.к. подсеть по факту будет состоять из 2 компов (роутера и компьютера, подключившегося к сети). Другое дело, если вы вручную подключите комп и выдадите ему вручную IP и другую маску. Но тогда ожидайте кучу проблем в сети: у вас одна маска, у потенциальных жертв — другая. Как минимум потеря пакетов между вами и потенциальными жертвами
Обычный Ethernet-свич не проверяет маски подсети. Более того, он про существование IP вообще ничего не знает. Бродкасты в ethernet'е идут на mac-адрес ff:ff:ff:ff:ff:ff, т.е. гарантированно попадут всем подключенным к свичу клиентам. Клиентские ethernet-контроллеры тоже обычно ничего про IP не знают, т.е. передадут пакет выше. И только на уровне ОС можно фильтровать по маске перед включением записи в ARP-таблицы, но не факт что всегда фильтруется. И потом, что мешает атакующему вытеснять оттуда mac роутера своим mac'ом, и, более того, самим стать DHCP-сервером и назначать те маски, какие нужны? Т.е. до тех пор, пока сам коммутатор не откажется «бродкастировать бродкасты», у сетевого хулигана много возможностей.
Прокси отдает файл клиенту (клиент ничего не заподозрит, так как исходный файл был не больше 20 мегабайт, а, значит, предыдущие три пункта задержали старт закачки всего на несколько секунд)
Как-то слишком быстро… Файл нужно скачать с целевого сервера. И тут зависит от скорости соединения с этим сервером. Потом его встроить и скомпилить. Потом его выдать… Даже если в локальной сети, то очень странно, что займёт секунды
Скорость скачивания у нас около пары мегабайт в секунду. Да, зависит от сервера, но в данном случае сервер оказался достаточно быстрым. На перекомпиляцию — чуть больше секунды. Выдача скомпилированного файла с сервера инъекций на прокси сервер и отдача его клиенту идёт уже параллельно и потоково. Итого — подвисание секунд на 10-15. К тому же число «20 мегабайт» можно и уменьшить, если беспокоиться насчёт этого.
И это уже детали моей не очень аккуратной реализации. По нормальному — чтобы проверить файл на то, что он является исполняемым и не имеет цифровой подписи — достаточно скачать лишь некоторые его фрагменты через Range-Request (если, конечно, целевой сервер его поддерживает), это будет быстро. Склеивать свой инсталлятор с файлом можно тоже потоково, без перекомпиляции (например дописыванием оригинального файла в конец моего инсталлятора. При запуске — он уже мог бы прочитать свой исполняемый файл и найти место, где начинается оригинальный бинарник).
И это уже детали моей не очень аккуратной реализации. По нормальному — чтобы проверить файл на то, что он является исполняемым и не имеет цифровой подписи — достаточно скачать лишь некоторые его фрагменты через Range-Request (если, конечно, целевой сервер его поддерживает), это будет быстро. Склеивать свой инсталлятор с файлом можно тоже потоково, без перекомпиляции (например дописыванием оригинального файла в конец моего инсталлятора. При запуске — он уже мог бы прочитать свой исполняемый файл и найти место, где начинается оригинальный бинарник).
Как страшно жить-то.
В очередной раз понял, что если тебя до сих пор не «поимели», то это означает лишь то что ты пока что никого серьёзно не заинтересовал.
Реквестирую статью о противодействиях такому роду атак.
Симпа Карма-фидбэк с меня. :)
В очередной раз понял, что если тебя до сих пор не «поимели», то это означает лишь то что ты пока что никого серьёзно не заинтересовал.
Реквестирую статью о противодействиях такому роду атак.
статическая arp-таблица спасет отца русской демократии.
Статическая ARP-таблица для всего интернета? :)
Ведь даже если не иметь доступ к WiFi сети — можно было атаковать канал связи между роутерами, но тут уже игра была бы с роутером повайдера, а там возможно есть сигнализация подобных атак и тогда могут быть последствия.
Ведь даже если не иметь доступ к WiFi сети — можно было атаковать канал связи между роутерами, но тут уже игра была бы с роутером повайдера, а там возможно есть сигнализация подобных атак и тогда могут быть последствия.
Мда, при чем тут интернет, скажи на милость? Как, зачем и где работает arp, догадываешься?
Догадываюсь более чем.
Интернет тут при том, что теоретически вклиниться можно в любой точке сети. Даже если я защищу свою локальную сеть, то никто не помешает злоумышленнику провести ARP-spoofing на роутеры, которые находятся в цепочке между тобой и запрашиваемым сервером. Например, если «стать» между «Сеть провайдера» и «Роутер жертвы» (на рисунке в посте), то есть провести атаку на шлюз «Роутера жертвы» и сам «Роутер жертвы», то никакие защиты внутри локальной сети жертвы не помогут, в том числе статическая ARP-таблица.
Интернет тут при том, что теоретически вклиниться можно в любой точке сети. Даже если я защищу свою локальную сеть, то никто не помешает злоумышленнику провести ARP-spoofing на роутеры, которые находятся в цепочке между тобой и запрашиваемым сервером. Например, если «стать» между «Сеть провайдера» и «Роутер жертвы» (на рисунке в посте), то есть провести атаку на шлюз «Роутера жертвы» и сам «Роутер жертвы», то никакие защиты внутри локальной сети жертвы не помогут, в том числе статическая ARP-таблица.
Защитить клиентов друг от друга — уже обязанность провайдера. У него и знаний, и умного оборудования побольше чем у клиентов. Я сам с серьёзным оборудованием не работал, но беглый гуглинг показал, что есть такая вещь, как DHCP snooping, которая защищает от подобных проблем.
Цитата из ссылки:
«DHCP snooping can be configured on LAN switches to harden the security on the LAN to allow only clients with specific IP/MAC addresses to have access to the network.»
Я не очень понимаю как они защищаются от ARP spoofing'a (хотя пишут, что как-то защищает), на странице, посвящённой атаке ARP spoofing'a, есть всего 3 вида решения: статические ARP-таблицы (ИМХО нежизнеспособно в рамках реальной жизни), системы обнаружения/предотвращения вторжений и отдельные техники уровня ОС конечных устройств, ничего про DHCP snooping не нашёл.
Проблема ещё в том, что я бы не очень надейлся на сознательность провайдеров — мне кажется, что они не защищают клиентов от проблем…
«DHCP snooping can be configured on LAN switches to harden the security on the LAN to allow only clients with specific IP/MAC addresses to have access to the network.»
Я не очень понимаю как они защищаются от ARP spoofing'a (хотя пишут, что как-то защищает), на странице, посвящённой атаке ARP spoofing'a, есть всего 3 вида решения: статические ARP-таблицы (ИМХО нежизнеспособно в рамках реальной жизни), системы обнаружения/предотвращения вторжений и отдельные техники уровня ОС конечных устройств, ничего про DHCP snooping не нашёл.
Проблема ещё в том, что я бы не очень надейлся на сознательность провайдеров — мне кажется, что они не защищают клиентов от проблем…
Насколько я понял, провайдер знает, какие IP-адреса какому MAC-адресу на каком физическом порту коммутатора выданы, и может отфильтровывать на уровне коммутатора «плохие» ARP-пакеты.
Вот здесь более подробно описано (вообще по ссылке и про спуфинг и про методы защиты хорошо написали)
Вот здесь более подробно описано (вообще по ссылке и про спуфинг и про методы защиты хорошо написали)
Этот риск не твой, т.к. эту угрозу тебе никак не смягчить. Хождение в интернет из дома через туннель на удаленном серваке не рассматриваем, т.к. тут мы теряем в «доступности», а именно об этом забывают почти все новички в ИБ, начинают усилять целостность и конфиденциальность, в ущерб третьей стороне треугольника.
В расчетах ИБ-рисков есть такое понятие, как степень уязвимости. Если взять степень уязвимости к arp-спуфингу домашней сети из статьи (разделяемая среда, без шифрования), то она равна 5 из 5. Сеть провайдера тоже подвержена, но степень уже будет 2 из 5, т.к. воспользоваться уязвимостью сложнее и заметят ее раньше (коммутируемая среда, средства мониторинга). А если провайдер реализовал dhcp option 82 (все чаще встречаю), то вообще, уязвимость имеет вес 0.5 из 5.
К каждому риску надо подходить индивидуально и меры, которые надо принимать, тоже индивидуальны. В случае со статьей, смягчить риск поможет статическая arp-таблица на клиенте (и на точке, опционально), о чем и был мой комментарий выше. Причем на клиенте достаточно одной статической записи.
В расчетах ИБ-рисков есть такое понятие, как степень уязвимости. Если взять степень уязвимости к arp-спуфингу домашней сети из статьи (разделяемая среда, без шифрования), то она равна 5 из 5. Сеть провайдера тоже подвержена, но степень уже будет 2 из 5, т.к. воспользоваться уязвимостью сложнее и заметят ее раньше (коммутируемая среда, средства мониторинга). А если провайдер реализовал dhcp option 82 (все чаще встречаю), то вообще, уязвимость имеет вес 0.5 из 5.
К каждому риску надо подходить индивидуально и меры, которые надо принимать, тоже индивидуальны. В случае со статьей, смягчить риск поможет статическая arp-таблица на клиенте (и на точке, опционально), о чем и был мой комментарий выше. Причем на клиенте достаточно одной статической записи.
Соседу брандмауэр с политикой запрета исходящих соединений по умолчанию для всех приложений, кроме разрешенных не помешал бы.
Если бэкдор установлен и запущен с правами LocalSystem (аналог root), то, как мне кажется, он мог бы открыть себе порт в брандмауэре. Разве что, пришлось бы написать чуть больше кода.
А я-то думал в общежитиях только квасят и прелюбодействуют!
Ваши статьи — пример качественного и наглядного описания реализации сетевой атаки. А то ведь большинство ресурсов в интернетах ограничивается тупым описанием сферических в вакууме принципов, далеких от реальной ситуации. Да что там, даже на семинарах серьезных ИБ компаний часто рассматриваются вообще неприменимые на практике способы для искусственных сред.
P.S. Позвольте спросить, какие же обстоятельства сложились так, что появился повод для проведения новой атаки, как следует из начала повествования? Чем жертва провинилась?
Ваши статьи — пример качественного и наглядного описания реализации сетевой атаки. А то ведь большинство ресурсов в интернетах ограничивается тупым описанием сферических в вакууме принципов, далеких от реальной ситуации. Да что там, даже на семинарах серьезных ИБ компаний часто рассматриваются вообще неприменимые на практике способы для искусственных сред.
P.S. Позвольте спросить, какие же обстоятельства сложились так, что появился повод для проведения новой атаки, как следует из начала повествования? Чем жертва провинилась?
Что предложите для фильтрации вместо мака? Гостевая зона, как я понял из описания, позволяет создать еще одну AP со своим SSID и ее юзеры будут отделены от юзеров основной SSID. Я не совсем понимаю, в чем смысл этого?
Является ли хорошой защитой запрет вещания SSID?
Является ли хорошой защитой запрет вещания SSID?
А зачем фильтрация? Ставим более-менее надежный пароль, сообщаем его людям, которым мы доверяем — и всё. Пароль на домашних роутерах тоже можно взломать, но в большинстве случаев игра не будет стоить свеч. Более серьёзный подход — аутентификация по сертификатам, но роутер уже нужен более дорогой, и я такое не настраивал.
В гостевой зоне можно запретить клиентам сети взаимодействовать друг с другом, а значит ARP-Spoofing будет невозможен. Это касается и прочих видов атак по локальной сети. Для этого нужно создать гостевой SSID, а основным не пользоваться вообще. Недостаток — не будет локальной сети.
Запрет вещания SSID защиты не добавит.
В гостевой зоне можно запретить клиентам сети взаимодействовать друг с другом, а значит ARP-Spoofing будет невозможен. Это касается и прочих видов атак по локальной сети. Для этого нужно создать гостевой SSID, а основным не пользоваться вообще. Недостаток — не будет локальной сети.
Запрет вещания SSID защиты не добавит.
Согласен. Хороший пример: Wi-Fi в Сапасне (поезд такой). При коннекте к его сети при попытке пингануть всю подсеть в ARP-таблице видим везде 1 МАС-адрес: самого роутера. Т.е. он и отвечает на все ARP-запросы. Т.е. подменить записи у других компов не выйдет. Эти пакеты дальше роутера не уйдут. Как реализовано на практике — не готов сказать. Возможно, подсеть уменьшена до 255.255.255.255 (т.е. до 1 хоста). Но это лишь предпрложение
Это называется proxy arp
Это и есть то, что в WiFi-роутерах называют «изоляцией клиентов».
Я считал, что пароль+фильтрация = чуть больше защиты, чем просто пароль.
Ага, так вы предлагаете и владельцу пользоваться гостевой зоной. При этом, как я понимаю, раз нет использования основной сети, то и вероятность подбора пароля к ней падает до нуля, правильно?
Кстати, нашел в своем роутере опцию «Изоляция AP». Мол клиенты wifi будут между собой изолированы, но, похоже, остальное будет доступно, надо проверить.
Ага, так вы предлагаете и владельцу пользоваться гостевой зоной. При этом, как я понимаю, раз нет использования основной сети, то и вероятность подбора пароля к ней падает до нуля, правильно?
Кстати, нашел в своем роутере опцию «Изоляция AP». Мол клиенты wifi будут между собой изолированы, но, похоже, остальное будет доступно, надо проверить.
Фильтрация по MAC, как и сокрытие SSID — похоже на security through obscurity. Какую-то мизерную защиту они может и дают, но от них будет больше вреда, если вы будете полагаться на них, считать себя защищённым и будете пренебрегать другими мерами (надежные пароли, WPA2, проверка контрольных сумм скачиваемых инсталляторов).
> раз нет использования основной сети, то и вероятность подбора пароля к ней падает до нуля, правильно?
Да, но пароль можно точно так же подобрать и к гостевой сети, разницы тут нет.
Если ваш роутер позволяет осуществить изоляцию клиентов для основной зоны, то гостевую можно и не поднимать.
> раз нет использования основной сети, то и вероятность подбора пароля к ней падает до нуля, правильно?
Да, но пароль можно точно так же подобрать и к гостевой сети, разницы тут нет.
Если ваш роутер позволяет осуществить изоляцию клиентов для основной зоны, то гостевую можно и не поднимать.
Является ли хорошой защитой запрет вещания SSID?
Скрытый SSID можно увидеть через aircrack (вернее, его часть, тулзу airodump). Как только какой-нить клиент попытается подключиться к сети (даже со скрытым SSID), он пошлёт запросы с её SSID, на что та ответит вежливым приветом. Вот SSID и вычислили.
Для домашних сетей arp-запись роутера можно прописать статически. Настроить WPA2.
Что касается команд – cmd.exe почему-то с точки зрения Windows считается программой с UI, а системным службам взаимодействовать с пользователем нельзя. Запустить cmd.exe из службы так и не удалось.
Очень интересно… Вы случайно флаг UseShellExecute сбросить не забыли? Сам по себе процесс сервиса как правило является UI-процессом (по крайней мере, PE-заголовки не отличаются), да и консольный сервис сделать можно, так что проблема не в этом.
Нет, с флагами у меня было всё нормально.
После некоторого тестирования оказалось, что, действительно, можно вызывать cmd из сервисов.
Просто я тестировал шелл командой «dir», и получалось так, что при запуске в виде приложения команда выполнялась, а при запуске из сервиса — ответа не было, бот словно «зависал», и не отвечал на последующие команды.
А настоящей причиной такого поведения оказалось то, что при запуске «dir» из сервиса выдавался листинг директории «C:\Windows\system32» длиной около 120 килобайт. И тут, похоже, сервер отвергал длинное сообщение, а используемая библиотека XMPP почему-то переставала после этого нормально работать.
Когда сделал обрезание вывода до 1000 символов, cmd тоже стал работать.
После некоторого тестирования оказалось, что, действительно, можно вызывать cmd из сервисов.
Просто я тестировал шелл командой «dir», и получалось так, что при запуске в виде приложения команда выполнялась, а при запуске из сервиса — ответа не было, бот словно «зависал», и не отвечал на последующие команды.
А настоящей причиной такого поведения оказалось то, что при запуске «dir» из сервиса выдавался листинг директории «C:\Windows\system32» длиной около 120 килобайт. И тут, похоже, сервер отвергал длинное сообщение, а используемая библиотека XMPP почему-то переставала после этого нормально работать.
Когда сделал обрезание вывода до 1000 символов, cmd тоже стал работать.
В общем-то вывод из статьи простой — качайте софт с торрентов, там (при наличии доверенного релизера) подменить скачиваемый файл практически невозможно
> Если нужно скачать инсталлятор, качайте его по https.
HTTPS тоже можно прозрачно проксировать:
habrahabr.ru/post/138328/
HTTPS тоже можно прозрачно проксировать:
habrahabr.ru/post/138328/
Насколько я понял, почитав код по ссылке, там проксируется зашифрованный поток на уровне TCP-сокета. То есть расшифровать передаваемые данные, или модифицировать их нельзя, значит на безопасность соединения такое проксирование никак не влияет. Собственно SSL как раз и предназначен для того, чтобы MITM был невозможен.
Рекомендую посмотреть как бэкдор будет работать на машине с KIS/KAV, очень сильно удивитесь.
или Norton Internet Security
Конкретно описанный в статье бекдор или любой, произвольно взятый?
Сейчас попробую проверить, но буду весьма удивлен если KIS что-то заметит. У него ведь нет искусственного интеллекта.
Установил на виртуалку триальную версию Kaspersky Internet Security 2012.
Установке и функционированию бэкдора антивирус никак не помешал. Почему-то я совсем не удивлен.
Единственная польза от KIS в данном случае — то что при проверке файла вручную можно было увидеть информацию от KSN о том. что этот файл замечен в сети впервые, то есть не является каким-то популярным инсталлятором. Но кто эту информацию будет смотреть?
Проверять на Norton Internet Security — уж извините — не буду, слишком уж тормозят у меня на не очень мощном ноуте, да ещё и под виртуалкой эти монструозные %BrandName% Internet Security.
Кто хочет самостоятельно потестировать состоятельность антивирусов в данном случае — может скачать инсталлятор бэкдора (само собой тестируем его под виртуалкой)
После установки бинарные файлы складываются в %WINDOWS%\updsvc\
А вот и отчет от virustotal по инсталлятору:
Установке и функционированию бэкдора антивирус никак не помешал. Почему-то я совсем не удивлен.
Единственная польза от KIS в данном случае — то что при проверке файла вручную можно было увидеть информацию от KSN о том. что этот файл замечен в сети впервые, то есть не является каким-то популярным инсталлятором. Но кто эту информацию будет смотреть?
Проверять на Norton Internet Security — уж извините — не буду, слишком уж тормозят у меня на не очень мощном ноуте, да ещё и под виртуалкой эти монструозные %BrandName% Internet Security.
Кто хочет самостоятельно потестировать состоятельность антивирусов в данном случае — может скачать инсталлятор бэкдора (само собой тестируем его под виртуалкой)
После установки бинарные файлы складываются в %WINDOWS%\updsvc\
А вот и отчет от virustotal по инсталлятору:
Detection ratio: 0 / 43
Ещё можно свою беспроводную точку доступа поставить с таким же SSID как у сети атакуемых клиентов, но на другом канале (отличном от легитимной сети) и более сильным сигналом (либо просто осуществлять дисконнект). Тогда клиенты переподключаться на нас будут. Тогда не будет этого танца с бубнами насчёт ARP-спуфинга и его тормознутости
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Войны в песочнице – Часть 3. ARP-Spoofing, бесполезность фильтрации по MAC-адресу и опасность установки неподписанного ПО