Войны в песочнице – Часть 3. ARP-Spoofing, бесполезность фильтрации по MAC-адресу и опасность установки неподписанного ПО



    Прошло чуть более года с момента публикации предыдущих статей (1, 2), и только недавно обстоятельства сложились так, что у меня появился повод для проведения новой атаки.

    В этот раз физического доступа к сетевой инфраструктуре нет. Есть лишь ноутбук с доступом в интернет по Wi-Fi. Жертва – сосед по общежитию — подключена к другой точке доступа (DIR-320) по Ethernet, но пароль для подключения к точке известен почти всем, т.к. её хозяин предпочитает использовать в качестве средства разграничения доступа фильтрацию по MAC-адресам, добавляя и удаляя адреса из базы по мере необходимости. Моего MAC-адреса в списке разрешенных нет.

    Ок, подключаемся, делаем несколько тестов, и видим, что фильтрация MAC-адресов происходит только на сетевом уровне, то есть точка доступа не отказывается:
    • пересылать мои фреймы в Ethernet сегмент, и доставлять ответы
    • отвечать на ARP-запросы и принимать ARP-ответы


    Единственное что точка доступа отказывается делать, так это взаимодействовать с чужаком на сетевом уровне, то есть IP-адрес она мне через DHCP не выдаёт, пропинговать её нельзя и в интернет через неё тоже не выйти.


    ARP-Spoofing


    Для тех кто не знает что такое ARP и ARP-Spoofing – небольшой ликбез. Сетевой уровень, на котором используются IP-адреса, используется поверх канального уровня (на нём используются MAC-адреса, задающиеся производителями сетевой карты). Отправляя IP-пакет, компьютер должен обернуть его в Ethernet-фрейм, указав MAC-адрес получателя (или шлюза). Чтобы узнать MAC-адрес получателя, компьютер делает широковещательный ARP-запрос вида «Компьютер с ip a.b.c.d, отзовись!». Компьютер a.b.c.d отвечает ARP-ответом вида «a.b.c.d – это я, мой MAC-адрес следующий: 00:11:22:33:44:55». Причем ответ можно посылать даже если не было запроса и он будет обработан. Все компьютеры поддерживают кэш соответствий IP → MAC и при каждом удобном случае (получен ARP-запрос/ответ) его обновляют.

    Никакой аутентификации на уровне ARP нет, на чем и основана атака ARP-spoofing. Достаточно представиться (отправить ARP-ответ) роутеру жертвой, а жертве роутером, чтобы проксировать через себя их трафик.



    Но, раз в интернет точка доступа меня не пускает, то классический вариант ARP-спуфинга – встать между жертвой и роутером – не пройдёт. Раз так, можно встать не между жертвой и роутером, а вместо роутера. Идём на рынок, покупаем USB-WiFi адаптер, подключаемся встроенным адаптером (отключив на нём IP-протокол) к целевой сети, а вторым – к своей, чтобы иметь канал в интернет. Создаём в VirtualBox виртуальную машину с двумя адаптерами, первый соединяем мостом с целевой сетью, на втором делаем NAT. Настраиваем NAT внутри виртуальной машины-роутера, запускаем на ней же arpspoof с целью убедить компьютер жертвы, что MAC-адрес роутера сменился на наш.



    В результате жертва будет отправлять пакеты не настоящему роутеру, а нашему, который сможет маршрутизировать их в интернет, просматривая и модифицируя. Практически стандартная схема ARP-спуфинга. Лишь с одним небольшим недостатком – она не работает. Точнее работает, но с такими перебоями, что жертва не может не заметить проблем с сетью.

    Посмотрев на трафик в сети, можно понять почему. Да, мы уведомляем раз в секунду роутер жертвы о том что адрес 192.168.0.105 принадлежит нам, и жертву о том, что ip адрес 192.168.0.1 принадлежит нам. Однако в сети есть и другая ARP-активность. Например роутер периодически вещает в сеть «192.168.0.109, где ты?», причем такого адреса в сети нет. Причины этой активности не очень ясны – возможно на роутере прокинут порт с внешнего ip на этот адрес. Но ни к чему хорошему такая общительность со стороны роутера не приводит. Компьютер жертвы видит этот широковещательный запрос, и, хоть запрос и не относится к нему, обновляет у себя в кэше информацию о MAC-адресе роутера. В итоге получается race condition, и жертва отправляет исходящие пакеты то на наш адрес, то на адрес настоящего роутера.

    Что же делать? Раз роутер так волнуется из-за несуществующих ip-адресов, нужно его утихомирить, например, сказав ему что эти адреса принадлежат нам. Итак:
    • Раз в пару секунд посылать широковещательный запрос ARP request всем адресам сегмента, чтобы выяснить, кто же есть в сети
    • Раз в десять секунд для каждого IP-адреса, который мы давно не видели в сети, отправлять ARP reply роутеру, сообщая, что этот адрес принадлежит нам


    После добавления такой функциональности в виде скрипта на python, парсящего вывод tcpdump arp и рассылающего ARP-запросы и ответы, сбоев связи стало гораздо меньше. Когда какой-либо компьютер подключается к сети, он обычно начинает свою деятельность с ARP запроса своего IP и IP роутера, вследствие чего мы видим что он появился и перестаем выдавать себя за него. Когда компьютер отключается, мы видим что он отключился и занимаем его место. В итоге у роутера теперь нет поводов посылать широковещательные ARP-запросы и сбивать компьютер жертвы с толку.

    Получение контроля над машиной


    Прослушивание http-трафика, или использование sslstrip, с целью прослушать трафик ssl-enabled сайтов нас сейчас не интересует – во-первых это старо, во-вторых в трафике ничего интересного мы не найдём. Хочется получить полный контроль над целевой машиной.

    Бэкдор


    Для максимальных привилегий наша программа-бэкдор должна запускаться от имени LocalSystem. Для этого пишем Windows Service (на C# это пара десятков строк, которые к тому же генерирует IDE). Для управления будем использовать протокол Jabber (agsXMPP). Сервис будет при запуске коннектиться к Jabber-серверу, и ожидать команд. Управлять им можно будет с помощью любого Jabber-клиента, посылая команды через чат. Что касается команд – cmd.exe почему-то с точки зрения Windows считается программой с UI, а системным службам взаимодействовать с пользователем нельзя. Запустить cmd.exe из службы так и не удалось. В итоге было решено вместо команд оболочки cmd передавать боту код на C#, который он будет интепретировать и возвращать результат, получается достаточно универсальный «шелл».



    Инсталлятор


    Инсталлятор хранит в себе исполняемый файл и библиотеки сервиса и при запуске делает следующее:
    1. Сохранить файлы сервиса в какое-нибудь укромное место в директории %WINDOWS%
    2. Инсталлировать сервис
    3. Сделать HTTP GET на http://google.com/success (зачем это нужно – станет понятно позже)


    Установка


    Теперь нужно как-то заставить клиента запустить наш инсталлятор.

    Посмотрим на автоматические обновления, может быть удастся подменить их. По HTTP-заголовкам выясняем, что на машине в качестве браузера стоит Opera, но, как оказалось, её обновления идут по https, так что нам они не по зубам. Обновления от Microsoft идут по plain-http, но там, наверняка, каждый файл обновления имеет цифровую подпись, которая проверяется перед запуском, всё-таки в MS не школьники работают.

    Ок, с автоматическими обновлениями ничего поделать не удается, остаётся надеяться на невнимательность пользователя. Попробуем внедрить инсталлятор в первый попавшийся скачиваемый исполняемый файл.

    Для этого пишем прозрачный прокси (на Twisted это чуть более сотни строк), который помимо своих обычных обязанностей выполняет следующие действия:
    • Если URL запроса равен google.com/serviceinstaller, то в качестве ответа отдаём созданный ранее бинарник инсталлятора
    • Если URL запроса равен google.com/success, то доложить мне об успехе и перейти в режим обычного честного прокси
    • Если код ответа сервера равен 200, Content-Type принадлежит списку ['application/octet-stream', 'application/x-msdownload', 'application/exe', 'application/x-exe', 'application/dos-exe', 'vms/exe', 'application/x-winexe', 'application/msdos-windows', 'application/x-msdos-program', 'application/binary'], и Content-Length не превышает 20 мегабайт, то:
      1. Скачать файл
      2. Отправить файл POST-запросом на основную машину (т.к. там Windows) для дальнейшего анализа
      3. Ответ на POST-запрос отправить клиенту (соответственно подправив заголовки Content-Length и Content-MD5)


    Запускаем этот прокси-сервер на роутере-виртуалке и перенаправляем с помощью iptables весь HTTP трафик на него.

    Теперь пишем на C# проект-обертку, главная программа которого в качестве ресурса включает в себя в качестве ресурса исполняемый файл original.exe (пока что создадим просто пустой файл с таким именем). Прописываем в манифесте обертки, что она должна запускаться с правами администратора. Код обертки крайне прост:
    1. Скачать по адресу google.com/serviceinstaller и запустить инсталлятор нашего сервиса
    2. Сохранить встроенный ресурс original.exe во временный файл и запустить его


    После этого пишем вспомогательный веб-сервер, который для каждого полученного запроса выполняет следующие действия:
    1. Сохранить полученные данные в файл original.exe
    2. Если original.exe является исполняемым файлом и не имеет цифровой подписи, то запустить перестроение проекта-обертки, и вернуть результат компиляции. Иначе вернуть исходный файл без изменений.


    На этом с кодингом покончено. Теперь запускаем все компоненты, и смотрим, как оно должно работать:
    1. Пользователь идёт скачать какой-нибудь инсталлятор игры или ещё чего-то (неподписанных инсталляторов в интернете сейчас хватает, тот же Notepad++, который является весьма удобной и популярной программой)
    2. Прокси-сервер получает HTTP-запрос, пересылает его серверу, получает от сервера заголовки ответа, видит по заголовкам что скачиваемый файл — потенциальный кандидат на то, чтобы внедрить в него наш инсталлятор
    3. Прокси-сервер скачивает файл до конца, и посылает его серверу инъекций
    4. Сервер инъекций проверяет, что это действительно исполняемый файл (а то мало ли что в application/octet-stream могло передаваться), проверяет что файл без подписи, значит модифицировать его можно без опасности разоблачения (контрольные суммы инсталлятора всё равно никто не смотрит, даже если на сайте они выложены)
    5. Сервер инъекций компилирует бинарник-обертку, встраивая в него оригинальный исполняемый файл и возвращает результат прокси-серверу
    6. Прокси отдает файл клиенту (клиент ничего не заподозрит, так как исходный файл был не больше 20 мегабайт, а, значит, предыдущие три пункта задержали старт закачки всего на несколько секунд)
    7. Клиент запускает скачанный файл, получает запрос UAC (точно такой же, какой был бы от оригинального файла), акцептует его
    8. Скачивается и запускается наш инсталлятор, делает своё черное дело, сообщает об успехе нам
    9. Запускается оригинальный инсталлятор


    Запустив всё, ждём. И, спустя пару дней, видим в логах сервера инъекций:



    и в логах прокси-сервера:



    Теперь можно идти к соседу и порадовать его, показав фокусы, которые мы можем делать с его компом (перезагрузить, выдать страшные звуки из аудиосистемы и т.п).

    Выводы


    • Фильтрация по MAC-адресу. Не полагайтесь на неё. От взломщика это не спасет. От студента, который хочет попользоваться интернетом за ваш счёт – тоже, он просто сменит MAC-адрес на любой из подслушанных.
    • ARP-spoofing. От него можно защититься даже на SOHO роутере. Например для популярного девайса Dlink DIR-300/320 можно включить Guest Zone, которая изолирует клиентов друг от друга.
    • MITM. Не пользуйтесь незащищёнными средствами связи (например ICQ передает пароль открытым текстом, vk.com тоже, кажется, до сих пор так делает. UPD: ICQ и vk уже используют SSL для аутентификации). Если нужно скачать инсталлятор, качайте его по https. Если он раздается только по http, то проверьте после скачивания цифровую подпись файла. Если цифровой подписи нет, то сверьте контрольные суммы с указанными на сайте (желательно контрольные суммы на сайте смотреть по другому интернет-каналу).
    • Антивирус. Не полагайтесь на него, человек всегда будет умнее программы. Не знаю, как бы тут поступил другой антивирус, но Microsoft Security Essentials, стоящий на компьютере жертвы, на все вышеописанные манипуляции никак не отреагировал.
    • Мораль. Повторю совет из первой части: не будьте «плохим парнем», может быть ваш сосед как раз ищет себе жертву.

    ______________________
    Текст подготовлен в Хабра Редакторе от © SoftCoder.ru
    Share post

    Similar posts

    Comments 61

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

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

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

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

        Логин и пароль передаются по SSL Кажется, на сайт login.vk.com
          0
          QIP 2005, стоявший на целевой машине, передавал пароль таким образом, что в дампе его можно было увидеть без проблем. Возможно в новых версиях с этим лучше.
            0
            QIP 2005 давно уже не поддерживается и почти никем не используется. Более того, в QIP2005 была уязвимость, которая позволяла вытащить пароль прямо из памяти процесса, зная нужный адрес.
            +1
            Именно туда — более того, если заходить на https://vk.com/login.php, то соединение будет полностью зашифрованным, если не ошибаюсь. Значок шифрования, по крайней мере, будет.
              0
              Что ж, это радует.
                0
                Это распространяется только на процедуру логирования. Дальше трафик будет снова незашифрованным
            0
            ARP-spoofing. От него можно защититься даже на SOHO роутере. Например для популярного девайса Dlink DIR-300/320 можно включить Guest Zone, которая изолирует клиентов друг от друга
            В ряде случаев роутер можно прописать статически при старте системы в ARP-таблицу. Я дла этого скриптик простой прописывал в автозагрузку в Windows. Главное, чтоб соединение с сетью было уже установлено. Иначе ARP-таблицы ещё не будет существовать.
              0
              С этим проблема — если компьютер является ноутбуком, и подключается к разным AP, у которых один и тот же IP-адрес шлюза, то нужно будет при смене AP каждый раз создавать статическую запись заново.
                0
                Статическая таблица ARP имеет свойство сбрасываться при отключении сетевого интерфейса.
                  0
                  Если клиенты в WiFi, то да, а если по проводу, то не выйдет, т.к. дырок в роутере на всех не хватает — ставят дополнительные свичи (это и локальный трафик в ЛС сильно ускоряет), а в них уже клиенты беззащитны друг перед другом. В провайдерских «домовых сетях», кстати, тоже, если напрямую подключены (большинство квартир так).

                  Хороший инструмент для проверки уязвимости своей ЛС к ARP-спуфингу — HonixBox ( iron.snop.ru/ ) — подключиться телнетом и выполнить команду ARP_SP ON. Или через API BB_ARP_SP. А через его встроенный веб-сервер можно смотреть ARP-таблицу со статистикой там же, выявляя другие подозрительные устройства в сети.
                    0
                    При чём тут схема подключения? Возможность статической записи от этого вообще не зависит. Разве что в локальной сети со статической записью может быть лучше, т.к. там нет таких обрывов, как при плохом сигнале в wi-fi, из-за чего при переподключении к сетке у пользователя обнулится таблица
                      0
                      Я про «которая изолирует клиентов друг от друга». Если клиенты подключены к роутеру через отдельный свич (а не по wifi, и не напрямую в дырки роутера), то роутер не сможет изолировать клиентов — они могут общаться через свич напрямую независимо от желания роутера. Соответственно роутер никак не может повлиять на их ARP-таблицы, т.к. они построятся без его участия на основе бродкастов в свич-сети.
                        0
                        Вы ошибаетесь. Если роутер выдаст по DHCP маску посдести в такой сети 255.255.255.255 (или последняя цифра 254, я сейчас точно не помню, практики настройки оборудования немного, поэтому попутать могу), то сколько бы свитчей не было, компьютер кроме роутера в ARP-таблице ничего не увидит и все запросы на любые IP пойдут роутеру напрямую. А он уже сам будет ими рулить. Броадкаст такой подсетисети всё равно будет ограничен компом и роутером, т.к. подсеть по факту будет состоять из 2 компов (роутера и компьютера, подключившегося к сети). Другое дело, если вы вручную подключите комп и выдадите ему вручную IP и другую маску. Но тогда ожидайте кучу проблем в сети: у вас одна маска, у потенциальных жертв — другая. Как минимум потеря пакетов между вами и потенциальными жертвами
                          0
                          Обычный Ethernet-свич не проверяет маски подсети. Более того, он про существование IP вообще ничего не знает. Бродкасты в ethernet'е идут на mac-адрес ff:ff:ff:ff:ff:ff, т.е. гарантированно попадут всем подключенным к свичу клиентам. Клиентские ethernet-контроллеры тоже обычно ничего про IP не знают, т.е. передадут пакет выше. И только на уровне ОС можно фильтровать по маске перед включением записи в ARP-таблицы, но не факт что всегда фильтруется. И потом, что мешает атакующему вытеснять оттуда mac роутера своим mac'ом, и, более того, самим стать DHCP-сервером и назначать те маски, какие нужны? Т.е. до тех пор, пока сам коммутатор не откажется «бродкастировать бродкасты», у сетевого хулигана много возможностей.
                  +2
                  Прокси отдает файл клиенту (клиент ничего не заподозрит, так как исходный файл был не больше 20 мегабайт, а, значит, предыдущие три пункта задержали старт закачки всего на несколько секунд)

                  Как-то слишком быстро… Файл нужно скачать с целевого сервера. И тут зависит от скорости соединения с этим сервером. Потом его встроить и скомпилить. Потом его выдать… Даже если в локальной сети, то очень странно, что займёт секунды
                    +1
                    Скорость скачивания у нас около пары мегабайт в секунду. Да, зависит от сервера, но в данном случае сервер оказался достаточно быстрым. На перекомпиляцию — чуть больше секунды. Выдача скомпилированного файла с сервера инъекций на прокси сервер и отдача его клиенту идёт уже параллельно и потоково. Итого — подвисание секунд на 10-15. К тому же число «20 мегабайт» можно и уменьшить, если беспокоиться насчёт этого.

                    И это уже детали моей не очень аккуратной реализации. По нормальному — чтобы проверить файл на то, что он является исполняемым и не имеет цифровой подписи — достаточно скачать лишь некоторые его фрагменты через Range-Request (если, конечно, целевой сервер его поддерживает), это будет быстро. Склеивать свой инсталлятор с файлом можно тоже потоково, без перекомпиляции (например дописыванием оригинального файла в конец моего инсталлятора. При запуске — он уже мог бы прочитать свой исполняемый файл и найти место, где начинается оригинальный бинарник).
                    +4
                    Как страшно жить-то.
                    В очередной раз понял, что если тебя до сих пор не «поимели», то это означает лишь то что ты пока что никого серьёзно не заинтересовал.

                    Реквестирую статью о противодействиях такому роду атак.
                    Симпа Карма-фидбэк с меня. :)
                      0
                      статическая arp-таблица спасет отца русской демократии.
                        0
                        Статическая ARP-таблица для всего интернета? :)
                        Ведь даже если не иметь доступ к WiFi сети — можно было атаковать канал связи между роутерами, но тут уже игра была бы с роутером повайдера, а там возможно есть сигнализация подобных атак и тогда могут быть последствия.
                          0
                          Мда, при чем тут интернет, скажи на милость? Как, зачем и где работает arp, догадываешься?
                            0
                            Догадываюсь более чем.
                            Интернет тут при том, что теоретически вклиниться можно в любой точке сети. Даже если я защищу свою локальную сеть, то никто не помешает злоумышленнику провести ARP-spoofing на роутеры, которые находятся в цепочке между тобой и запрашиваемым сервером. Например, если «стать» между «Сеть провайдера» и «Роутер жертвы» (на рисунке в посте), то есть провести атаку на шлюз «Роутера жертвы» и сам «Роутер жертвы», то никакие защиты внутри локальной сети жертвы не помогут, в том числе статическая ARP-таблица.
                              +1
                              Защитить клиентов друг от друга — уже обязанность провайдера. У него и знаний, и умного оборудования побольше чем у клиентов. Я сам с серьёзным оборудованием не работал, но беглый гуглинг показал, что есть такая вещь, как DHCP snooping, которая защищает от подобных проблем.
                                0
                                Цитата из ссылки:
                                «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 не нашёл.

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

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

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

                              Запрет вещания SSID защиты не добавит.
                                0
                                Согласен. Хороший пример: Wi-Fi в Сапасне (поезд такой). При коннекте к его сети при попытке пингануть всю подсеть в ARP-таблице видим везде 1 МАС-адрес: самого роутера. Т.е. он и отвечает на все ARP-запросы. Т.е. подменить записи у других компов не выйдет. Эти пакеты дальше роутера не уйдут. Как реализовано на практике — не готов сказать. Возможно, подсеть уменьшена до 255.255.255.255 (т.е. до 1 хоста). Но это лишь предпрложение
                                  0
                                  Это называется proxy arp
                                    0
                                    Это и есть то, что в WiFi-роутерах называют «изоляцией клиентов».
                                    0
                                    Я считал, что пароль+фильтрация = чуть больше защиты, чем просто пароль.
                                    Ага, так вы предлагаете и владельцу пользоваться гостевой зоной. При этом, как я понимаю, раз нет использования основной сети, то и вероятность подбора пароля к ней падает до нуля, правильно?
                                    Кстати, нашел в своем роутере опцию «Изоляция AP». Мол клиенты wifi будут между собой изолированы, но, похоже, остальное будет доступно, надо проверить.
                                      0
                                      Фильтрация по MAC, как и сокрытие SSID — похоже на security through obscurity. Какую-то мизерную защиту они может и дают, но от них будет больше вреда, если вы будете полагаться на них, считать себя защищённым и будете пренебрегать другими мерами (надежные пароли, WPA2, проверка контрольных сумм скачиваемых инсталляторов).

                                      > раз нет использования основной сети, то и вероятность подбора пароля к ней падает до нуля, правильно?
                                      Да, но пароль можно точно так же подобрать и к гостевой сети, разницы тут нет.

                                      Если ваш роутер позволяет осуществить изоляцию клиентов для основной зоны, то гостевую можно и не поднимать.
                                    0
                                    Является ли хорошой защитой запрет вещания SSID?

                                    Скрытый SSID можно увидеть через aircrack (вернее, его часть, тулзу airodump). Как только какой-нить клиент попытается подключиться к сети (даже со скрытым SSID), он пошлёт запросы с её SSID, на что та ответит вежливым приветом. Вот SSID и вычислили.

                                    Для домашних сетей arp-запись роутера можно прописать статически. Настроить WPA2.
                                    +2
                                    Что касается команд – cmd.exe почему-то с точки зрения Windows считается программой с UI, а системным службам взаимодействовать с пользователем нельзя. Запустить cmd.exe из службы так и не удалось.


                                    Очень интересно… Вы случайно флаг UseShellExecute сбросить не забыли? Сам по себе процесс сервиса как правило является UI-процессом (по крайней мере, PE-заголовки не отличаются), да и консольный сервис сделать можно, так что проблема не в этом.
                                      +2
                                      Нет, с флагами у меня было всё нормально.

                                      После некоторого тестирования оказалось, что, действительно, можно вызывать cmd из сервисов.

                                      Просто я тестировал шелл командой «dir», и получалось так, что при запуске в виде приложения команда выполнялась, а при запуске из сервиса — ответа не было, бот словно «зависал», и не отвечал на последующие команды.

                                      А настоящей причиной такого поведения оказалось то, что при запуске «dir» из сервиса выдавался листинг директории «C:\Windows\system32» длиной около 120 килобайт. И тут, похоже, сервер отвергал длинное сообщение, а используемая библиотека XMPP почему-то переставала после этого нормально работать.

                                      Когда сделал обрезание вывода до 1000 символов, cmd тоже стал работать.
                                      –2
                                      В общем-то вывод из статьи простой — качайте софт с торрентов, там (при наличии доверенного релизера) подменить скачиваемый файл практически невозможно
                                        +3
                                        Можно подменить скачиваемый torrent-файл и запросы клиента к трекеру. Понадобится чуть больше технической работы, но, при скачивании с торрентов, если пользователь не будет вглядываться в список пиров, вполне можно подменить скачиваемый файл на свой.
                                          0
                                          Вообще всё верно, ведь нет первичного доверенного источника. Как не крути, а плясать всё должно от глобальных центров сертификации. В общем, цифровые подписи — наше всё.
                                        0
                                        > Если нужно скачать инсталлятор, качайте его по https.
                                        HTTPS тоже можно прозрачно проксировать:
                                        habrahabr.ru/post/138328/
                                          0
                                          Насколько я понял, почитав код по ссылке, там проксируется зашифрованный поток на уровне TCP-сокета. То есть расшифровать передаваемые данные, или модифицировать их нельзя, значит на безопасность соединения такое проксирование никак не влияет. Собственно SSL как раз и предназначен для того, чтобы MITM был невозможен.
                                          0
                                          Рекомендую посмотреть как бэкдор будет работать на машине с KIS/KAV, очень сильно удивитесь.
                                            0
                                            или Norton Internet Security
                                              0
                                              Конкретно описанный в статье бекдор или любой, произвольно взятый?
                                                0
                                                Имел ввиду описанный в статье.
                                                0
                                                Сейчас попробую проверить, но буду весьма удивлен если KIS что-то заметит. У него ведь нет искусственного интеллекта.
                                                  0
                                                  Установил на виртуалку триальную версию Kaspersky Internet Security 2012.

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

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

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

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

                                                  Detection ratio:	0 / 43

                                                    0
                                                    Как-то всё грустно, ни одна эвристика даже не пискнула.
                                                      0
                                                      Если в бэкдоре есть только интерпретация кода и нет вызовов посторонних exe'шников вроде cmd.exe, то KAV/KIS ничего не увидят.
                                                        0
                                                        Для интепретации кода происходит вызов «постороннего» exe-шника csc.exe. Да и вызов cmd.exe уже есть.
                                                  0
                                                  Ещё можно свою беспроводную точку доступа поставить с таким же SSID как у сети атакуемых клиентов, но на другом канале (отличном от легитимной сети) и более сильным сигналом (либо просто осуществлять дисконнект). Тогда клиенты переподключаться на нас будут. Тогда не будет этого танца с бубнами насчёт ARP-спуфинга и его тормознутости
                                                    0
                                                    В данном случае интересующий клиент был подключен к точке проводом.

                                                  Only users with full accounts can post comments. Log in, please.