Pull to refresh

Comments 61

Страшно у вас жить, в общежитии то.

P.S.
На сколько я знаю, с vk.com — все усложнилось, пароли там идут не совсем plain-text.
И да, в ICQ нет SSL?

Да, с vk действительно уже не всё так просто. Хотя без SSL всё равно вход не защищён, т.к. javascript, отвечающий за передачу пароля, теоретически, можно подменить при MITM.

Насчёт ICQ — я сам ей не пользуюсь, а у жертвы бы установлен QIP 2005, его процесс аутентификации был полностью виден.
например ICQ передает пароль открытым текстом, vk.com тоже, кажется, до сих пор так делает

Логин и пароль передаются по SSL Кажется, на сайт login.vk.com
QIP 2005, стоявший на целевой машине, передавал пароль таким образом, что в дампе его можно было увидеть без проблем. Возможно в новых версиях с этим лучше.
QIP 2005 давно уже не поддерживается и почти никем не используется. Более того, в QIP2005 была уязвимость, которая позволяла вытащить пароль прямо из памяти процесса, зная нужный адрес.
Именно туда — более того, если заходить на 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-таблицу со статистикой там же, выявляя другие подозрительные устройства в сети.
При чём тут схема подключения? Возможность статической записи от этого вообще не зависит. Разве что в локальной сети со статической записью может быть лучше, т.к. там нет таких обрывов, как при плохом сигнале в 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 (если, конечно, целевой сервер его поддерживает), это будет быстро. Склеивать свой инсталлятор с файлом можно тоже потоково, без перекомпиляции (например дописыванием оригинального файла в конец моего инсталлятора. При запуске — он уже мог бы прочитать свой исполняемый файл и найти место, где начинается оригинальный бинарник).
Как страшно жить-то.
В очередной раз понял, что если тебя до сих пор не «поимели», то это означает лишь то что ты пока что никого серьёзно не заинтересовал.

Реквестирую статью о противодействиях такому роду атак.
Симпа Карма-фидбэк с меня. :)
статическая arp-таблица спасет отца русской демократии.
Статическая ARP-таблица для всего интернета? :)
Ведь даже если не иметь доступ к WiFi сети — можно было атаковать канал связи между роутерами, но тут уже игра была бы с роутером повайдера, а там возможно есть сигнализация подобных атак и тогда могут быть последствия.
Мда, при чем тут интернет, скажи на милость? Как, зачем и где работает 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 не нашёл.

Проблема ещё в том, что я бы не очень надейлся на сознательность провайдеров — мне кажется, что они не защищают клиентов от проблем…
Насколько я понял, провайдер знает, какие IP-адреса какому MAC-адресу на каком физическом порту коммутатора выданы, и может отфильтровывать на уровне коммутатора «плохие» ARP-пакеты.

Вот здесь более подробно описано (вообще по ссылке и про спуфинг и про методы защиты хорошо написали)
Всё разбивается о тот факт, что провайдеры домашнего интернета не занимаются такой хорошей тонкой настройкой — если бы они блокировали MAC/IP на порту, то я бы не смог поменять MAC на своём роутере без последствий, а я могу — интернет продолжает работать.
Верно. Тут где-то пару месяцев назад уже общались с одним из домовых провайдеров — он подтвердил, что ничем таким не занимаются, поэтому сети очень уязвимы (соседи друг перед другом уязвимы). Но пригрозил ответственностью ;)
Этот риск не твой, т.к. эту угрозу тебе никак не смягчить. Хождение в интернет из дома через туннель на удаленном серваке не рассматриваем, т.к. тут мы теряем в «доступности», а именно об этом забывают почти все новички в ИБ, начинают усилять целостность и конфиденциальность, в ущерб третьей стороне треугольника.
В расчетах ИБ-рисков есть такое понятие, как степень уязвимости. Если взять степень уязвимости к arp-спуфингу домашней сети из статьи (разделяемая среда, без шифрования), то она равна 5 из 5. Сеть провайдера тоже подвержена, но степень уже будет 2 из 5, т.к. воспользоваться уязвимостью сложнее и заметят ее раньше (коммутируемая среда, средства мониторинга). А если провайдер реализовал dhcp option 82 (все чаще встречаю), то вообще, уязвимость имеет вес 0.5 из 5.
К каждому риску надо подходить индивидуально и меры, которые надо принимать, тоже индивидуальны. В случае со статьей, смягчить риск поможет статическая arp-таблица на клиенте (и на точке, опционально), о чем и был мой комментарий выше. Причем на клиенте достаточно одной статической записи.
Соседу брандмауэр с политикой запрета исходящих соединений по умолчанию для всех приложений, кроме разрешенных не помешал бы.
Если бэкдор установлен и запущен с правами LocalSystem (аналог root), то, как мне кажется, он мог бы открыть себе порт в брандмауэре. Разве что, пришлось бы написать чуть больше кода.
Вы правы, причем многие «хорошие» приложения при установке так делают. Сторонний брандмауэр, конфигурация которого защищена паролем, будет более устойчив.
Да, те брандмауэры, которые ставятся в винде, уязвимы перед софтом, работающим на той же машине. Поэтому исходящие соединения надо блокировать в роутере или ином внешнем «аппаратном» firewall'е. Но ему, увы, не укажешь список разрешенных программ — только списки разрешенных ip и портов.
А я-то думал в общежитиях только квасят и прелюбодействуют!
Ваши статьи — пример качественного и наглядного описания реализации сетевой атаки. А то ведь большинство ресурсов в интернетах ограничивается тупым описанием сферических в вакууме принципов, далеких от реальной ситуации. Да что там, даже на семинарах серьезных ИБ компаний часто рассматриваются вообще неприменимые на практике способы для искусственных сред.
P.S. Позвольте спросить, какие же обстоятельства сложились так, что появился повод для проведения новой атаки, как следует из начала повествования? Чем жертва провинилась?
За отзыв спасибо, но о поводе предпочту промолчать. Там всё слишком по-детски, да и не хочется выносить сор из избы. Скажу лишь, что ситуация уже улажена, сервис получил команду на деинсталляцию и при следующем включении ПК будет удалён.
Что предложите для фильтрации вместо мака? Гостевая зона, как я понял из описания, позволяет создать еще одну AP со своим SSID и ее юзеры будут отделены от юзеров основной SSID. Я не совсем понимаю, в чем смысл этого?
Является ли хорошой защитой запрет вещания SSID?
А зачем фильтрация? Ставим более-менее надежный пароль, сообщаем его людям, которым мы доверяем — и всё. Пароль на домашних роутерах тоже можно взломать, но в большинстве случаев игра не будет стоить свеч. Более серьёзный подход — аутентификация по сертификатам, но роутер уже нужен более дорогой, и я такое не настраивал.

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

Запрет вещания SSID защиты не добавит.
Согласен. Хороший пример: Wi-Fi в Сапасне (поезд такой). При коннекте к его сети при попытке пингануть всю подсеть в ARP-таблице видим везде 1 МАС-адрес: самого роутера. Т.е. он и отвечает на все ARP-запросы. Т.е. подменить записи у других компов не выйдет. Эти пакеты дальше роутера не уйдут. Как реализовано на практике — не готов сказать. Возможно, подсеть уменьшена до 255.255.255.255 (т.е. до 1 хоста). Но это лишь предпрложение
Это и есть то, что в 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 тоже стал работать.
В общем-то вывод из статьи простой — качайте софт с торрентов, там (при наличии доверенного релизера) подменить скачиваемый файл практически невозможно
Можно подменить скачиваемый torrent-файл и запросы клиента к трекеру. Понадобится чуть больше технической работы, но, при скачивании с торрентов, если пользователь не будет вглядываться в список пиров, вполне можно подменить скачиваемый файл на свой.
Вообще всё верно, ведь нет первичного доверенного источника. Как не крути, а плясать всё должно от глобальных центров сертификации. В общем, цифровые подписи — наше всё.
> Если нужно скачать инсталлятор, качайте его по https.
HTTPS тоже можно прозрачно проксировать:
habrahabr.ru/post/138328/
Насколько я понял, почитав код по ссылке, там проксируется зашифрованный поток на уровне TCP-сокета. То есть расшифровать передаваемые данные, или модифицировать их нельзя, значит на безопасность соединения такое проксирование никак не влияет. Собственно SSL как раз и предназначен для того, чтобы MITM был невозможен.
Рекомендую посмотреть как бэкдор будет работать на машине с KIS/KAV, очень сильно удивитесь.
Конкретно описанный в статье бекдор или любой, произвольно взятый?
Имел ввиду описанный в статье.
Сейчас попробую проверить, но буду весьма удивлен если KIS что-то заметит. У него ведь нет искусственного интеллекта.
Установил на виртуалку триальную версию Kaspersky Internet Security 2012.

Установке и функционированию бэкдора антивирус никак не помешал. Почему-то я совсем не удивлен.

Единственная польза от KIS в данном случае — то что при проверке файла вручную можно было увидеть информацию от KSN о том. что этот файл замечен в сети впервые, то есть не является каким-то популярным инсталлятором. Но кто эту информацию будет смотреть?

Проверять на Norton Internet Security — уж извините — не буду, слишком уж тормозят у меня на не очень мощном ноуте, да ещё и под виртуалкой эти монструозные %BrandName% Internet Security.

Кто хочет самостоятельно потестировать состоятельность антивирусов в данном случае — может скачать инсталлятор бэкдора (само собой тестируем его под виртуалкой)
После установки бинарные файлы складываются в %WINDOWS%\updsvc\
А вот и отчет от virustotal по инсталлятору:

Detection ratio:	0 / 43

Как-то всё грустно, ни одна эвристика даже не пискнула.
Если в бэкдоре есть только интерпретация кода и нет вызовов посторонних exe'шников вроде cmd.exe, то KAV/KIS ничего не увидят.
Для интепретации кода происходит вызов «постороннего» exe-шника csc.exe. Да и вызов cmd.exe уже есть.
Ещё можно свою беспроводную точку доступа поставить с таким же SSID как у сети атакуемых клиентов, но на другом канале (отличном от легитимной сети) и более сильным сигналом (либо просто осуществлять дисконнект). Тогда клиенты переподключаться на нас будут. Тогда не будет этого танца с бубнами насчёт ARP-спуфинга и его тормознутости
В данном случае интересующий клиент был подключен к точке проводом.
Only those users with full accounts are able to leave comments. Log in, please.