Взламывает заблокированные/защищённые паролем компьютеры через USB, внедряет постоянный бэкдор на основе WebSocket, раскрывает внутренний роутер и похищает cookie-файлы с помощью Raspberry Pi Zero и Node.js.

(невероятная HTML5 canvas-анимация от Ara)

PoisonTap обходит следующие механизмы безопасности:

• Защищённые паролем экраны блокировки
• Таблицу маршрутизации, приоритет и порядок служб сетевых интерфейсов
• Политику Same-Origin
• X-Frame-Options
• HttpOnly cookie
• атрибут cookie SameSite
• Двухфакторную/многофакторную аутентификацию (2FA/MFA)
• DNS-пиннинг
• Cross-Origin Resource Sharing (CORS)
• защиту cookie по HTTPS, когда флаг cookie Secure и HSTS не включены

Демонстрация

PoisonTap создан для Raspberry Pi Zero за $5 и не требует дополнительных компонентов, кроме micro-USB кабеля и microSD-карты. Также он может работать на любом Raspberry Pi (1/2/3) с переходником Ethernet-to-USB/Thunderbolt или на других устройствах, способных эмулировать USB-гаджеты, таких как USB Armory и LAN Turtle.

Живая демонстрация и дополнительные подробности доступны в видео:

Контактное лицо: @SamyKamkar // https://samy.pl

Релиз: 16 ноября 2016 года

Исходный код и загрузка: https://github.com/samyk/poisontap

Как работает PoisonTap

PoisonTap создаёт каскадный эффект, эксплуатируя существующее доверие к различным механизмам машины и сети, включая USB/Thunderbolt, DHCP, DNS и HTTP, и тем самым вызывает эффект снежного кома: эксфильтрацию информации, доступ к сети и установку полупостоянных бэкдоров.

Если кратко, PoisonTap выполняет следующее:

Перехват сети

• Атакующий подключает PoisonTap (например, «вооружённый» Raspberry Pi Zero) к заблокированному компьютеру (даже если компьютер защищён паролем)
• PoisonTap эмулирует Ethernet-устройство (например, Ethernet через USB/Thunderbolt) -- по умолчанию Windows, OS X и Linux распознают Ethernet-устройство, автоматически загружая его как сетевое устройство с низким приоритетом и выполняя через него DHCP-запрос, даже когда машина заблокирована или защищена паролем
• PoisonTap отвечает на DHCP-запрос и выдаёт машине IP-адрес, однако DHCP-ответ формируется так, чтобы сообщить машине, что всё IPv4-пространство (0.0.0.0 - 255.255.255.255) является частью локальной сети PoisonTap, а не небольшая подсеть (например, 192.168.0.0 - 192.168.0.255)
  • Обычно было бы неважно, если к машине подключается вторичное сетевое устройство, поскольку ему будет присвоен более низкий приоритет, чем существующему (доверенному) сетевому устройству, и оно не заменит шлюз для интернет-трафика, но...
  • Любая защита на основе таблицы маршрутизации / приоритета шлюза / порядка служб сетевых интерфейсов обходится из-за приоритета «LAN-трафика» над «интернет-трафиком»
  • PoisonTap использует этот сетевой доступ, даже оставаясь устройством с низким приоритетом, потому что подсеть устройства с низким приоритетом получает более высокий приоритет, чем шлюз (маршрут по умолчанию) устройства с самым высоким приоритетом
  • Это означает, что если трафик направляется на 1.2.3.4, то в обычных условиях он попал бы на маршрут по умолчанию/шлюз основного (не-PoisonTap) сетевого устройства, но PoisonTap на самом деле получает этот трафик, потому что «локальная» сеть/подсеть PoisonTap якобы содержит 1.2.3.4 и любой другой существующий IP-адрес ;)
  • Из-за этого весь интернет-трафик проходит через PoisonTap, даже если машина подключена к другому сетевому устройству с более высоким приоритетом и настоящим шлюзом (реальному Wi-Fi, Ethernet и т.д.)

Выуживание cookie

• Пока веб-браузер работает в фоне, одна из открытых страниц, скорее всего, выполнит HTTP-запрос в фоне (например, чтобы загрузить новую рекламу, отправить данные в аналитическую платформу или просто продолжить отслеживать ваши перемещения по вебу) через AJAX или динамические теги script/iframe
  • Вы можете убедиться в этом сами: откройте devtools/inspector (обычно Cmd+Shift+I или Ctrl+Shift+I), зайдите на часто посещаемый сайт, откройте вкладку Network и наблюдайте, как удалённые ресурсы продолжают запрашиваться, даже если вы не совершаете никаких действий на странице
• При таком HTTP-запросе, поскольку весь трафик выходит через устройство PoisonTap, PoisonTap на лету подделывает DNS, возвращая свой собственный адрес, из-за чего HTTP-запрос попадает на веб-сервер PoisonTap (Node.js)
  • Если DNS-сервер указывает на внутренний IP (LAN), для которого PoisonTap не может получить привилегии, атака продолжает работать, поскольку внутренний DNS-сервер будет выдавать публичные IP-адреса для атакуемых доменов, а именно публичные IP-адреса PoisonTap уже перехватил
  • Как только внутренний DNS-сервер ответит, веб-браузер обратится к публичному IP и в любом из сценариев в конечном итоге попадёт на веб-сервер PoisonTap (Node.js)
• Когда веб-сервер Node получает запрос, PoisonTap отвечает таким ответом, который может быть интерпретирован и как HTML, и как Javascript — оба варианта корректно выполняются (многие сайты загружают HTML или JS в фоновых запросах)
• Затем эта не зависящая от HTML/JS страница порождает множество скрытых iframe, каждый из которых ведёт на другой домен из Alexa top-1-миллиона
  • Любая защита «X-Frame-Options» на домене обходится, поскольку теперь HTTP-сервером является PoisonTap, который сам выбирает, какие заголовки отправлять клиенту
  • Поскольку к сайту выполняется каждый iframe HTTP-запрос (например, http://nfl.com/PoisonTap), HTTP-cookie отправляются из браузера на «публичный IP», перехваченный PoisonTap, который быстро записывает cookie/информацию аутентификации, сохраняя десятки тысяч cookie пользователя в PoisonTap
  • Любая защита cookie «HttpOnly» обходится, и эти cookie захватываются, поскольку на самом домене не выполняется никакой Javascript — он используется лишь для первичной загрузки iframe
  • Любая защита Cross-Origin Resource Sharing или Same-Origin Policy обходится, поскольку запрашиваемый домен выглядит для браузера легитимным
  • Поскольку мы захватываем cookie, а не учётные данные, любая реализованная на сайте 2FA/MFA обходится, когда атакующий использует cookie для входа. Это объясняется тем, что мы не выполняем функцию входа, а продолжаем уже авторизованную сессию, которая не запускает двухфакторную аутентификацию
  • Если сервер использует HTTPS, но cookie явно не устанавливают флаг Secure, защита HTTPS обходится и cookie отправляется в PoisonTap

Удалённо доступные веб-бэкдоры

• Пока PoisonTap создавал тысячи iframe, заставляя браузер загружать каждый из них, эти iframe — вовсе не пустые страницы, а бэкдоры на HTML+Javascript, которые кэшируются бессрочно
• Поскольку PoisonTap принудительно кэширует эти бэкдоры на каждом домене, бэкдор привязан к этому домену, что позволяет атакующему использовать cookie домена и в будущем запускать same-origin запросы, даже если пользователь сейчас не авторизован
  • Например, при загрузке iframe http://nfl.com/PoisonTap PoisonTap принимает перенаправленный интернет-трафик и отвечает на HTTP-запрос через веб-сервер Node
  • Добавляются дополнительные HTTP-заголовки для бессрочного кэширования страницы
• Фактический ответ страницы представляет собой комбинацию HTML и Javascript, которая создаёт постоянный WebSocket к веб-серверу атакующего (через Интернет, а не на устройстве PoisonTap)
  • WebSocket остаётся открытым, позволяя атакующему в любой момент в будущем подключиться обратно к заражённой машине и выполнять запросы к любому origin, на котором реализован бэкдор (сайты Alexa top 1,000,000 -- см. ниже)
  • Если бэкдор открыт на одном сайте (например, nfl.com), но атакующий хочет атаковать другой домен (например, pinterest.com), он может загрузить на nfl.com iframe, ведущий на бэкдор pinterest.com (http://pinterest.com/PoisonTap)
  • И снова любая защита «X-Frame-Options», Cross-Origin Resource Sharing и Same-Origin Policy на домене полностью обходится, поскольку запрос попадёт в кэш, оставленный PoisonTap, а не на настоящий домен

Бэкдор на внутреннем роутере и удалённый доступ

• Единственная сеть, которую PoisonTap не может перехватить, — это фактическая LAN-подсеть настоящего сетевого интерфейса (например, если Wi-Fi подсеть пользователя — 192.168.0.x, эта сеть не затрагивается), но...
• PoisonTap принудительно кэширует бэкдор на специальном хосте, а именно на IP целевого роутера с префиксом «.ip.samy.pl», например 192.168.0.1.ip.samy.pl, по сути создавая постоянную DNS-rebinding атаку
  • При использовании PoisonTap в качестве DNS-сервера (жертва использует публичный DNS-сервер) PoisonTap временно отвечает специализированным IP-адресом PoisonTap (1.0.0.1), то есть любые запросы в этот момент попадут на веб-сервер PoisonTap
  • Если же DNS-сервер настроен на внутреннюю сеть (например, 192.168.0.x), выполняется дополнительный специально сформированный запрос к 1.0.0.1**.pin.**ip.samy.pl, который сообщает моему специализированному DNS-серверу (в публичном Интернете) временно отвечать на любой адрес [ip.address].ip.samy.pl «закреплённым» адресом (1.0.0.1) в течение нескольких секунд
  • Затем PoisonTap быстро устанавливает бэкдор на http://192.168.0.1.ip.samy.pl/PoisonTap, который на данный момент указывает на устройство PoisonTap по адресу 1.0.0.1, позволяя получить доступ к бэкдору и закэшировать его с устройства PoisonTap
• Защита DNS-пиннинга и DNS-rebinding обходится за счёт исчерпания таблицы DNS-пиннинга сотнями тысяч запросов, выполненных только что, и в будущем rebinding не требуется — это делает атаку постоянной в течение длительного времени (спасибо Matt Austin за то, что поделился этой атакой со мной!)
• Теперь, когда бэкдор принудительно закэширован на http://192.168.0.1.ip.samy.pl/PoisonTap, любые будущие запросы к 192.168.0.1.ip.samy.pl попадут на незакреплённый IP-адрес, из-за чего вместо него будет резолвиться адрес 192.168.0.1, указывающий напрямую на роутер
• Это означает, что если загрузить хост 192.168.0.1.ip.samy.pl/PoisonTap в iframe удалённо через бэкдор, можно выполнять AJAX GET/POST к любой другой странице внутреннего роутера полностью удалённо, обеспечивая тем самым удалённый доступ к внутреннему роутеру
  • Это может привести к другим атакам на роутер, к которому у атакующего изначально могло не быть доступа, например к использованию учётных данных администратора по умолчанию для перезаписи DNS-серверов или к раскрытию других уязвимостей аутентификации

Краткое описание DNS-сервера:

• [ip.addy].ip.samy.pl обычно отвечает адресом [ip.addy]
• 192.168.0.1.ip.samy.pl -> 192.168.0.1 (A-запись)
• [ip.addy].pin.ip.samy.pl временно (~5 секунд) направляет *.ip.samy.pl на [ip.addy]
  • 1.0.0.1.pin.ip.samy.pl -> 1.0.0.1
  • 192.168.0.1.ip.samy.pl -> 1.0.0.1 (A-запись, короткий TTL)
  • (примерно через 5 секунд)
  • 192.168.0.1.ip.samy.pl -> 192.168.0.1 (A-запись)

Дополнительные удалённо доступные веб-бэкдоры

• Кроме того, PoisonTap заменяет тысячи распространённых CDN-файлов Javascript, например Google и jQuery CDN, корректным кодом плюс бэкдором, который даёт атакующему доступ к любому домену, загружающему заражённый CDN-файл Javascript
• Поскольку бэкдор оставлен на каждом домене, это позволяет атакующему удалённо заставлять заражённый браузер выполнять same-origin запросы (AJAX GET/POST) практически к любому крупному домену, даже если у жертвы сейчас нет открытых окон с этим доменом
• Теперь бэкдор будет жить и на любом дополнительном сайте, который также использует один из этих заражённых HTTP-фреймворков Javascript на CDN, когда жертва посещает этот сайт

Защита от PoisonTap

Защита на стороне сервера

Если вы запускаете веб-сервер, защита от PoisonTap проста:

• Используйте исключительно HTTPS, по крайней мере для аутентификации и аутентифицированного контента
  • Честно говоря, вам следует использовать исключительно HTTPS и всегда перенаправлять HTTP-контент на HTTPS, не позволяя обманом заставить пользователя передавать учётные данные или другую личную информацию (PII) по HTTP
• Убедитесь, что на cookie включён флаг Secure, чтобы предотвратить утечку HTTPS-cookie через HTTP
• При использовании удалённых Javascript-ресурсов применяйте атрибут тега script Subresource Integrity
• Используйте HSTS для предотвращения атак понижения версии HTTPS

Защита на десктопе

• Заливка цементом ваших USB- и Thunderbolt-портов может быть эффективной
• Закрытие браузера каждый раз, когда вы отходите от машины, может сработать, но это совершенно непрактично
• Отключение USB/Thunderbolt-портов также эффективно, хотя тоже непрактично
• Блокировка компьютера не даёт эффекта, поскольку сетевой и USB-стеки продолжают работать, пока машина заблокирована. Однако переход в зашифрованный режим сна, в котором для расшифровки памяти требуется ключ (например, FileVault2 + глубокий сон), решает большинство проблем, так как ваш браузер больше не будет выполнять запросы, даже после пробуждения

Загрузка

Исходный код: https://github.com/samyk/poisontap

Установка / Состав файлов

Примечание: Если вы обнаружили, что устройство НЕ ведёт себя как Ethernet-контроллер автоматически (например, в старых версиях Windows), вы можете изменить VID и PID в pi_startup.sh```bash

Instructions adjusted from https://gist.github.com/gbaman/50b6cca61dd1c3f88f41

sudo bash

If Raspbian BEFORE 2016-05-10, then run next line:

BRANCH=next rpi-update

echo -e "\nauto usb0\nallow-hotplug usb0\niface usb0 inet static\n\taddress 1.0.0.1\n\tnetmask 0.0.0.0" >> /etc/network/interfaces echo "dtoverlay=dwc2" >> /boot/config.txt echo -e "dwc2\ng_ether" >> /etc/modules sudo sed --in-place "/exit 0/d" /etc/rc.local echo "/bin/sh /home/pi/poisontap/pi_startup.sh" >> /etc/rc.local mkdir /home/pi/poisontap chown -R pi /home/pi/poisontap apt-get update && apt-get upgrade apt-get -y install isc-dhcp-server dsniff screen nodejs

• pi_poisontap.js - Этот файл запускается через Node.js на Raspberry Pi Zero и является HTTP-сервером, отвечающим за обработку любых HTTP-запросов, перехваченных PoisonTap, хранение собранных cookie и внедрение кэшированных бэкдоров.
• pi_startup.sh - Этот файл запускается при старте Raspberry Pi Zero, чтобы настроить устройство на эмуляцию Ethernet-over-USB-гаджета, поднять наш вредоносный DHCP-сервер, разрешить перенаправление трафика, DNS-спуфинг и запустить указанный выше pi_poisontap.js.
• target_backdoor.js - Этот файл добавляется в начало любых JavaScript-файлов, связанных с CDN, тем самым внедряя в них бэкдор, например, в URL jQuery на Google CDN.
• target_injected_xhtmljs.html - Это код, который внедряется в непреднамеренные/фоновые HTTP/AJAX-запросы на машине жертвы и запускает всю атаку. Он устроен так, что может интерпретироваться и как HTML, и как JavaScript, и при этом выполнять один и тот же код. Кроме того, потрясающий HTML5 canvas создан невероятным Ara oen CodePen, и его нельзя было не включить. Это та графическая феерия, которая появляется, когда страница переходит под контроль PoisonTap.
• poisontap.cookies.log - Этот файл создается после того, как машина пользователя начинает отправлять HTTP-запросы на PoisonTap, и записывает cookie из браузера вместе со связанным URL/доменом, которому он принадлежит.

Часто задаваемые вопросы

• В: Как добавить дополнительные домены для внедрения бэкдора?
• О: Список доменов, в которые будет внедряться бэкдор, задается в target_injected_xhtmljs.html функцией getDoms(). Этот список, в свою очередь, заполняется скриптом alexa1m.sh из корня репозитория. Если вы хотите добавить дополнительные домены в этот список, просто измените оператор return в getDoms().
• В: Как использовать перехваченные cookie?
• О: Вы можете использовать Document.cookie API прямо из консоли JavaScript в браузере, чтобы устанавливать cookie. В этом посте на StackOverflow также есть несколько советов, специфичных для Chrome, например расширение Chrome Cookie Inspector.
• В: Как очистить машину от Poisontap?
• О: Вам следует очистить локальный DNS-кэш ОС, а также все кэши браузеров. Возможно, вам также потребуется аннулировать все авторизованные на тот момент сеансы, из которых могли утечь cookie. Убедитесь, что при этом аннулируются существующие cookie, а не просто выполняется выход из системы. (Если вы хотите безопасно работать с устройством PoisonTap на своей текущей машине, обязательно закройте все браузеры — после этого вы сможете безопасно подключить его к машине).

Контакты

Контактное лицо: @SamyKamkar

Вы можете посмотреть другие мои проекты или связаться со мной на https://samy.pl.