GNU/Linux

Представлен первый стабильный выпуск проекта Pwnagotchi, развивающего инструмент для взлома беспроводных сетей, оформленный в виде электронного питомца, напоминающего игрушку Тамагочи. Основной прототип устройства построен построен на основе платы Raspberry Pi Zero W (предоставляется прошивка для загрузки с SD-карты), но возможно использование и на других платах Raspberry Pi, а также в любом Linux-окружении, в котором имеется беспроводной адаптер, поддерживающий работу в режиме мониторинга. Управление производится через подключение LCD-экрана или через web-интерфейс. Код проекта написан на языке Python и распространяется под лицензией GPLv3.

Для поддержания хорошего настроения питомца его необходимо кормить сетевыми пакетами, отправляемыми участниками беспроводных сетей на этапе согласования нового соединения (handshake). Устройство находит доступные беспроводные сети и пытается перехватывать handshake-последовательности. Так как handshake отправляется только при подключении клиента к сети, устройство использует различные приёмы для обрыва текущих подключений и принуждения пользователей выполнить операции переподключения к сети. В ходе перехвата накапливается база пакетов, включающих хэши, которые можно использовать для подбора ключей WPA.

Проект примечателен использованием методов обучения с подкреплением AAC (Actor Advantage Critic) и нейронной сети на базе долгой краткосрочной памяти (LSTM), которые получили распространение при создании ботов для прохождения компьютерных игр. Тренировка модели обучения осуществляется по мере работы устройства, учитывая прошлый опыт для выбора оптимальной стратегии совершения атаки на беспроводные сети. При помощи машинного обучения Pwnagotchi динамически подбирает параметры перехвата трафика и выбирает интенсивность принудительного обрыва сеансов пользователей. Также поддерживается и ручной режим работы, при котором атака производится "в лоб".

Для перехвата необходимых для подбора WPA-ключей видов трафика используется пакет bettercap. Перехват осуществляется как в пассивном режиме, так и с проведением известных видов атак, вынуждающих клиентов повторно отправлять в сеть идентификаторы PMKID. Перехваченные пакеты, охватывающие все формы handshake, поддерживаемые в hashcat, сохраняются в PCAP-файлах с расчётом, один файл на каждую беспроводную сеть.

По аналогии с тамагочи поддерживается определение находящихся поблизости других устройств, а также опционально возможно участие в построении общей карты охвата. Для соединения устройств Pwnagotchi по WiFi используется протокол Dot11. Находящиеся поблизости устройства обмениваются полученными данными о беспроводных сетях и организуют совместную работу, разделяя между собой каналы для проведения атаки.

Функциональность Pwnagotchi может расширяться через плагины, в форме которых реализованы такие функции как система автоматического обновления ПО, создание резервных копий, привязка захваченных handshake к GPS-координатам, публикация данных о взломанных сетях в сервисах onlinehashcrack.com, wpa-sec.stanev.org, wigle.net и PwnGRID, дополнительные индикаторы (потребление памяти, температура и т.п.) и осуществление словарного подбора паролей для перехваченных handshake.

Представлен выпуск сборочного инструментария Qbs 1.14. Это первый выпуск после ухода компании Qt Company от разработки проекта, подготовленный силами сообщества, заинтересованного в продолжении разработки Qbs. Для сборки Qbs в числе зависимостей требуется Qt, хотя сам Qbs рассчитан на организацию сборки любых проектов. Qbs использует упрощённый вариант языка QML для определения сценариев сборки проекта, что позволяет определять достаточно гибкие правила сборки, в которых могут подключаться внешние модули, использоваться функции на JavaScript и создаваться произвольные правила сборки.

Используемый в Qbs язык сценариев адаптирован для автоматизации генерации и разбора сценариев сборки интегрированными средами разработки. Кроме того, Qbs не генерирует make-файлы, а сам, без посредников, таких как утилита make, контролирует запуск компиляторов и компоновщиков, оптимизируя процесс сборки на основе детального графа всех зависимостей. Наличие изначальных данных о структуре и зависимостях в проекте позволяет эффективно распараллеливать выполнение операций в несколько потоков. Для крупных проектов, состоящих из большого числа файлов и поддиректорий, производительность повторной пересборки с использованием Qbs может опережать make в разы - пересборка выполняется почти мгновенно и не заставляет разработчика тратить время на ожидание.

Напомним, что год назад компанией Qt Company было принято решение о прекращении разработки Qbs. Qbs развивался как замена qmake, но в конечном счёте было решено использовать CMake в качестве основной сборочной системы для Qt в долгосрочной перспективе. Разработка Qbs теперь продолжена в форме независимого проекта, поддерживаемого силами сообщества и заинтересованными разработчиками. Для разработки пока продолжает использоваться инфраструктура Qt Company. Поддержка Qbs 1.14.0 встроена в Qt Creator 4.10.1, а следующий выпуск Qbs 1.15 ожидается одновременно с Qt Creator 4.11.

Основные новшества Qbs 1.14:

Поддержка Visual Studio 2019 и clang-cl (альтернативный интерфейс командной строки Clang, совместимый на уровне опций с компилятором cl.exe из состава Visual Studio);

Поддержка инструментариев разработки для встраиваемых устройств IAR, KEIL и SDCC, позволяющая использовать Qbs для проектов, развиваемых для нескольких аппаратных платформ;

Добавлены конфигурационный файлы и сборочные скрипты для системы непрерывной интеграции Travis CI, позволяющие собирать и тестировать каждый рецензируемый в Gerrit набор патчей для Qbs;

Полностью переработан Docker-образ на основе Debian, который можно использовать в качестве сборочного и тестового окружения;

Прекращена поддержка старых версий Android NDK (‹19).

Исследователи из компании ESET выявили распространение неизвестными злоумышленниками вредоносной сборки Tor Browser. Сборка позиционировалась как официальная русская версия Tor Browser, в то время как к проекту Tor её создатели не имеют никакого отношения, а целью создание была подмена кошельков Bitcoin и QIWI.

Для введения пользователей в заблуждение создатели сборки зарегистрировали домены tor-browser.org и torproect.org (отличается от официального сайта torproJect.org отсутствием буквы "J", что многими русскоязычными пользователями остаётся незамеченным). Оформление сайтов было стилизовано под официальный сайт Tor. На первом сайте выводилась страница с предупреждением об использовании устаревшей версии Tor Browser и предложением установить обновление (ссылка вела на сборку с троянским ПО), а на втором содержимое повторяло страницу для загрузки Tor Browser. Вредоносная сборка была формирована только для Windows.

Троянский Tor Browser с 2017 года продвигался на различных русскоязычных форумах, в обсуждениях связанных с даркнетом, криптовалютами, обходом блокировок Роскомнадзора и вопросами обеспечения конфиденциальности. Для распространения браузера на pastebin.com также было создано множество страниц, оптимизированных для вывода в топе поисковых систем по темам, связанным с различными незаконными операциями, цензурой, именами известных политиков и т.п. Страницы с рекламой фиктивной версией браузера на pastebin.com были просмотрены более 500 тысяч раз.

Фиктивная сборка была основана на кодовой базе Tor Browser 7.5 и кроме встроенных вредоносных функций, небольшой корректировки User-Agent, отключения проверки цифровых подписей для дополнений и блокирования системы установки обновлений была идентична официальному Tor Browser. Вредоносная вставка сводилась к прикреплению обработчика контента в штатное дополнение HTTPS Everywhere (в manifest.json был добавлен дополнительный скрипт script.js). Остальные изменения были произведены на уровне корректировки настроек, а все бинарные части оставались от официального Tor Browser.

Интегрированный в HTTPS Everywhere скрипт при открытии каждой страницы обращался к управляющему серверу, который возвращал JavaScript-код, который следовало исполнить в контексте текущей страницы. Управляющий сервер функционировал как скрытый сервис Tor. Через выполнения JavaScript-кода злоумышленники могли организовать перехват содержимого web-форм, подстановку или скрытие произвольных элементов на страницах, отображение фиктивных сообщений и т.п. Тем не менее, при анализе вредоносного кода было зафиксирован только код для подмены реквизитов QIWI и кошельков Bitcoin на страницах приёма платежей в darknet. В ходе вредоносной деятельности на используемых для подмены кошельках накопилось 4.8 Bitcoin, что соответствует примерно 40 тысячам долларов.

Компания Google объявила об усилении в Chrome режима межсайтовой изоляции, обеспечивающего обработку страниц с разных сайтов в отдельных изолированных процессах. Режим изоляции на уровне сайтов позволяет обезопасить пользователя от атак, которые могут быть совершены через используемые на сайте сторонние блоки, такие как внешние скрипты и iframe-вставки, или для блокирования течки данных через встраивание легитимных блоков (например, с запросами к банковским сервисам, на которых может быть аутентифицирован пользователь) на вредоносных сайтах.

При разделении обработчиков в привязке к домену, в каждом процессе находятся данные только одного сайта, что затрудняет совершение атак, направленных на межсайтовый захват данных. В настольных версиях Chrome разделение обработчиков в привязке к домену, а не вкладке, реализовано начиная с Chrome 67. В Chrome 77 подобный режим был активирован и для платформы Android.

Для снижения накладных расходов режим изоляции сайтов в Android включается только если на странице зафиксирован вход при помощи пароля. Chrome запоминает факт использования пароля и включает защиту и для всех дальнейших обращений к сайту. Защита также применяется сразу для избранного списка предопределённых сайтов, популярных среди пользователей мобильных устройств. Выборочный метод активации и добавленные оптимизации позволили удержать рост потребления памяти из-за увеличения числа работающих процессов в среднем на уровне 3-5%, вместо 10-13%, наблюдаемых при активации изоляции для всех сайтов.

Новый режим изоляции активирован для 99% пользователей Chrome 77 на Android-устройствах, снабжённых как минимум 2 Гб ОЗУ (для 1% пользователей режим остался отключённым для мониторинга за производительностью). Включить или отключить режим изоляции сайтов вручную можно через настройку "chrome://flags/#enable-site-per-process".

В настольной редакции Chrome вышеотмеченный режим изоляции сайтов теперь усилен для противостояния атакам, нацеленным на полную компрометацию процесса с обработчиком контента. Улучшенный режим изоляции позволит защитить данные сайтов от двух дополнительных видов угроз: утечек данных в результате атак по сторонним каналам, таких как Spectre, и утечек после полной компрометации процесса-обработчика при успешной эксплуатации уязвимостей, позволяющих получить контроль над процессом, но не достаточных для обхода sandbox-изоляции. В Chrome для Android подобная защита будет добавлена позднее.

Суть метода в том, что управляющий процесс запоминает как какому сайту рабочий процесс имеет доступ и запрещает обращение к другим сайтам, даже если атакующий получит контроль над процессом и попытается получить доступ к ресурсам другого сайта. Ограничения охватывают ресурсы, связанные с аутентификацией (сохранённые пароли и Cookie), загружаемыми напрямую по сети данными (фильтруются и привязываются в текущему сайту HTML, XML, JSON, PDF и прочие типы файлов), данными во внутренних хранилищах (localStorage), полномочиями (выданные сайту разрешения доступа к микрофону и т.п.) и сообщениями, передаваемыми через API postMessage и BroadcastChannel. Все подобные ресурсы связываются меткой с исходным сайтом и проверяются на стороне управляющего процесса на предмет возможности передачи по запросу из рабочего процесса.

Из связанных с Chrome событий также можно отметить начало утверждения включения в Chrome поддержки функции Scroll-To-Text, дающей возможность формировать ссылки на отдельные слова или фразы, без явного указания в документе меток при помощи тега "a name" или свойства "id". Синтаксис подобных ссылок планируется утвердить в качестве web-стандарта, который пока находится на стадии черновика. Маска для перехода (по сути выполняется поиск с прокруткой) отделяется от обычного якоря признаком ":~:". Например, при открытии ссылки "https://opennet.ru/51702/#:%7E:text=Chrom%D0%B5" страница сдвинется на позицию с первым упоминанием слова "Chromе" и данное слово будет подсвечено. Возможность добавлена в ветку Canary, но для включения требует запуска с флагом "--enable-blink-features=TextFragmentIdentifiers".

Другим интересным предстоящим изменением в Chrome является возможность заморозки неактивных вкладок, позволяющая автоматически выгрузить из памяти вкладки, которые находятся в фоновом состоянии более 5 минут и не выполняют имеющих значение действий. Решение о пригодности той или иной вкладки для заморозки принимаются на основе эвристики. Изменение добавлено в ветку Canary, на базе которой будет сформирован выпуск Chrome 79, и включается через флаг "chrome://flags/#proactive-tab-freeze".

Во входящем в состав ядра Linux драйвере rtlwifi для беспроводных адаптеров на чипах Realtek выявлена уязвимость (CVE-2019-17666), которая потенциально может быть эксплуатирована для организации выполнения кода в контексте ядра при отправке специально оформленных кадров.

Уязвимость вызвана переполнением буфера в коде с реализацией режима P2P (Wifi-Direct). При разборе кадров NoA (Notice of Absence) отсутствует проверка размера одного из значений, что позволяет добиться записи хвоста данных в область за границей буфера и переписать информацию в следующих за буфером структурах ядра.

Атака может быть совершена через отправку специально оформленных кадров на систему с активным сетевым адаптером на базе чипа Realtek с поддержкой технологии Wi-Fi Direct, позволяющей двум беспроводным адаптерам установить соединение напрямую без точки доступа. Для эксплуатации проблемы подключение к беспроводной сети атакующего не требуется, также не требуется выполнения каких-либо действий со стороны пользователя, достаточно нахождения атакующего в зоне охвата беспроводного сигнала.

Рабочий прототип эксплоита пока ограничивается удалённым вызовом краха ядра, но потенциально уязвимость не исключает возможности организации выполнения кода (предположение пока только теоретическое, так как прототипа эксплоита для выполнения кода ещё нет, но выявивший проблему исследователь уже работает над его созданием).

Проблема проявляется начиная с ядра 3.12 (по другим данным, проблема проявляется начиная с ядра 3.10), выпущенного в 2013 году. Исправление пока доступно только в виде патча. В дистрибутивах проблема остаётся неисправленной. Проследить за устранением уязвимостей в дистрибутивах можно на данных страницах: Debian, SUSE/openSUSE, RHEL, Ubuntu, Arch Linux, Fedora. Вероятно уязвимость также затрагивает и платформу Android.