anonymous@RULINUX.NET~# | Last login: 2024-11-17 09:33:08 |
Регистрация Вход | Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск |
Форум - Security | [RSS] |
Сами Камкар (Samy Kamkar), исследователь безопасности, известный созданием различных замысловатых устройств для проведения атак, таких как кейлоггер в USB-зарядке телефона, представил свою новую разработку - PoisonTap. В рамках проекта PoisonTap подготовлена практическая реализация атаки BadUSB, позволяющая получить доступ к прокэшированным в браузере сессионным cookie и параметрам аутентификации через подключение к USB-порту компьютера специального устройства. Атака применима к заблокированным компьютерам, независимо от используемых ОС, и может быть совершена когда владелец на время отлучился от своего ПК, оставив его с заблокированным экраном без присмотра.
Для атаки используется самый дешёвый одноплатный компьютер Raspberry Pi Zero, продаваемый за $5. На устройство загружен дистрибутив Linux, настроенный для эмуляции сетевого адаптера по USB, по DHCP объявляющий себя в качестве шлюза для локальной подсети 128.0.0.0. При подключении такого устройства к USB-порту, компьютер жертвы воспринимает его как новую сетевую плату, через которую доступен шлюз для обращения к локальной сети, охватывающей половину адресного пространства (устройство представляется как 1.0.0.1 с сетевой маской 128.0.0.0). Новый сетевой интерфейс менее приоритетен на компьютере жертвы, но так как подсеть задана явно, то подпадающий под эту подсеть трафик уходит через новый сетевой интерфейс независимо от наличия шлюза по умолчанию на более приоритетном интерфейсе.
На устройстве запускается подставной DNS-сервер, выдающий фиктивные ответы для запросов имён хостов, что позволяет переадресовать к PoisonTap все запросы и сохранить в кэше привязку доменов к сторонним адресам, в том числе организовать доступ к внутренним хостам локальной сети при помощи техники DNS rebinding.
Для сбора данных на устройстве PoisonTap запускается специальное приложение с реализацией простого http-сервера, который перехватывает все незашифрованные запросы по HTTP с компьютера жертвы. Если на компьютере пользователя остаётся открытым web-браузер, то с большой долей вероятности некоторые страницы периодически обращаются во вне, например, для обновления рекламных блоков, статистики, AJAX-вставок и т.п. Перехватив такое обращение программа атакущего обрабатывает его и генерирует ответ, в зависимости от запроса содержащий специально оформленный HTML или JavaScript.
Через подстановку скрытых блоков iframe организуется обращение к списку популярных сайтов из web-браузера жертвы (используется список из миллиона сайтов от рейтинга Alexa). Если пользователь ранее открывал участвующий в переборе сайт и у него прокэшированы параметры сеанса, то браузер вместе с запросом отправит имеющиеся cookie, а так как трафик контролируется на устройстве атакующего, незашифрованные cookie будут перехвачены. В том числе перехватываются cookie для сайтов, ранее открытых по HTTPS, если данные cookie были установлены без флага Secure, т.е. отправляются и для HTTPS и для HTTP.
Кроме того, в перехваченном трафике выявляются и подменяются популярные JavaScript-библиотеки, запрашиваемые через типовые сети доставки контента. Подменённые библиотеки, например JQuery, могут применяться для продолжения атаки после отсоединения USB-устройства. Так как подменённые JavaScript-библиотеки оседают в кэше, то в дальнейшем, при открытии пользователем страниц, запрашивающих данные JavaScript-библиотеки, будет выдан вариант из кэша, в который в процессе атаки был встроен код атакующего. Данным способом можно обеспечить перехват сессионных Cookie для будущих входов на сайты, к которым в данный момент не имеется активных сеансов.
В процессе атаки также может быть запущен JavaScript-код, выполняющий функции бэкдора. При помощи WebSocket скрипт устанавливает соединение с внешним сервером атакующего (не с PoisonTap, а с реальным внешним хостом) и поддерживает данное соединение в активном состоянии. Пока соединение активно, атакующий может со стороны внешнего сервера в любое время передать команду скрипту и выполнить подстановку iframe или запустить код на JavaScript в контексте текущего сайта.
Сурс новости на опеннете
Презентация на ютубе
Dr.uid(*) (2016-11-17 16:05:03)
Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/48.0
|
|
|
Скрыть
Re:Атака на заблокированный ПК через USBнасчет быдлоадминов хз, да и нет под рукой USB Ethernet. |
Скрыть
Re:Атака на заблокированный ПК через USBте что использовал, на нетбуках, подхватывались NetworkManager ом при втыкании автоматом anonymous(*)(2016-11-17 20:38:13)
Отредактировано anonymous по причине : купил очки и мужественно исправил опечатки мой ласковый и нежный w3m, ня! |
Скрыть
Re:Атака на заблокированный ПК через USB "Available to all users" тебя не спасает, "Connect automatically" вроде по умолчанию произойдёт для нового устройства. Как он должен работать тем более не ясно: по Vendor ID/Device ID ты идендифицируешь железку (кто бы ей мешал их фальсифицировать, кстати), а коннекшены там более высокоуровневая вещь - один и тот же вайвай-адаптер со своим Vendor ID/Device ID может коннектиться к разным точкам и это будут разные подключения.
|
Скрыть
Re:Атака на заблокированный ПК через USB> "Available to all users" тебя не спасает
|
Скрыть
Re:Атака на заблокированный ПК через USBсейчас основная настройка сети идет через системд не ? |
Скрыть
Re:Атака на заблокированный ПК через USB> сейчас основная настройка сети идет через системд не ?
|
Скрыть
Re:Атака на заблокированный ПК через USB> только что зарелизили новую няшку
anonymous(*)(2016-11-18 05:06:07)
Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 |
Скрыть
Re:Атака на заблокированный ПК через USBТ.е. вот этот пиздец называется импрувд саппортом. Ну-ну. |
Скрыть
Re:Атака на заблокированный ПК через USBГном тоже говно. Мне, пожалуй, нравится в принципе только КДЕ. Но не нравится то, что они из неё сделали. Красношляп используется в этерпрайзе - это как минимум резон с него не слезать чтобы не заводить плохих привычек (хотя федоркин dnf уже меня испортил - постоянно путаюсь где его использовать, а где - yum ) |
|
|
|
Этот тред читают 2 пользователя: |
Анонимных: 2 Зарегистрированных: 0 |
Re:Атака на заблокированный ПК через USB
очередное забавное поделие. несколько моментов (для *nix):
1) необходимость рутовых привилегий для добавления/конфига интерфейса в систему;
2) необходимость (частный случай, ога ..) как-то обойти некий "доверенный список" из "$ arptables -L". да, детишки, да, arptables придумали не зря.. ;
3) стоит как-то подробнее на нюансах проксирования/переадресации/редиректа и учесть кэш уже сформированных маршрутов ядра, в который новый интерфейс не влазит вообще никак. вопрос форварда (при грамотной настройке == fail) и/или запуска прокси (тут интереснее, но вангую необходимость рута) на usb, чтобы таки достучаться до адреса в инете. т.е. пока не вижу никаких причин разрешать/пропускать в сеть вопли абсолютно левого интерфейса.
лирическое отступление: в этих ваших люниксах при разработке таблиц фильтрации на уровень приложений "забили болт" не просто так. здесь вам не там: "It is very important to understand that iptables was and is specifically built to work on the headers of the Internet and the Transport layers. It is possible to do some very basic filtering with iptables in the Application and Network access layers as well, but it was not designed for this, nor is it very suitable for those purposes."(c). любое дополнение в систему стороннего интерфейса с последующим разрешением ему болтать с кем попадя - анальная кара быдлоадмину. поправьте, если ошибаюсь..
мой ласковый и нежный w3m, ня!