Windows-версия Hola Browser оказалась в центре supply chain-атаки: вместе с браузером некоторым пользователям доставляли незаявленный исполняемый файл, который исследователи связали с криптомайнером. История важна не только как еще один инцидент из мира endpoint-безопасности: для разработчиков, IT-руководителей и команд, которые привыкли доверять подписанным дистрибутивам, это очередное напоминание, что компрометация цепочки поставок давно стала не экзотикой, а рабочим инструментом злоумышленников.
О проблеме, как пишет BleepingComputer, стало известно во время регулярных сертификационных проверок AppEsteem, которые Hola Browser ранее проходил успешно. В ходе очередного цикла аудита специалисты Sophos и другие компании, участвующие в оценке, обнаружили, что в некоторых случаях в систему устанавливался файл me.exe по пути C:Program FilesHola. Файл не входил в сертифицированный набор компонентов, не имел цифровой подписи, не содержал временной метки, использовал обфускацию и мог записывать данные в память. Уже этого набора признаков достаточно, чтобы любой security-ревьюер перестал верить в «случайный технический артефакт».
Дальнейший анализ Sophos показал более неприятную картину. По данным исследователей, бинарник содержал признаки майнера Monero. Вредоносный компонент добавлял исключение в Windows Defender, копировал себя в Program Files под именем HolaMonitorService.exe, создавал автозапускаемый системный сервис hola_monitor_svc и активировался, когда компьютер простаивал. То есть речь идет не о шумной поломке, которая сразу валит систему, а о вполне прагматичной схеме монетизации: занять чужой CPU в фоне и постараться не попадаться на глаза. Для корпоративной среды такой сценарий неприятен вдвойне: снаружи это выглядит как «всего лишь» деградация производительности, а внутри может означать, что процесс доставки ПО уже был взломан и доверять ему по умолчанию больше нельзя.
Hola подтвердила, что действительно столкнулась с компрометацией цепочки поставок. По словам компании, инцидент также независимо выявила фирма Sygnia. При этом вендор утверждает, что затронуто было около 0,1% пользователей и у него нет признаков доступа к пользовательским данным, их кражи или иной компрометации. Генеральный директор Hola Ави Раз Коэн заявил, что компания полностью перестроила pipeline дистрибуции, внедрила усиленную проверку code signing, ужесточила контроль доступа и добавила непрерывный мониторинг инфраструктуры. Набор мер правильный, но рынок уже не первый год живет в реальности, где подобные обещания звучат после инцидента, а не до него. В этом и состоит неприятная, но полезная часть новости: многие процессы безопасной поставки до сих пор воспринимаются как «желательно», пока кто-то не получает майнер вместе с браузером.
У Hola Browser и родственных сервисов Hola есть и дополнительный контекст, который делает историю чувствительнее для репутации компании. Израильская Hola известна прежде всего по Hola VPN, сервису для обхода географических ограничений с помощью маршрутизации трафика через устройства других пользователей или через платную прокси-инфраструктуру. В прошлом компанию уже критиковали за непрозрачные практики обращения с трафиком, в том числе в связи с Luminati Networks, где бесплатные пользователи фактически становились прокси-нодами. Это не доказывает связь с нынешним инцидентом, но влияет на восприятие: когда у продукта и без того сложная история доверия, любая supply chain-атака бьет не только по безопасности, но и по остаткам репутационного кредита.
Для русскоязычной IT-аудитории здесь несколько практических выводов. Во-первых, компрометация дистрибутива давно перестала быть проблемой только крупных вендоров или open source-экосистемы. Если продукт устанавливается на Windows-машины и обновляется через собственную инфраструктуру, его pipeline уже представляет интерес для злоумышленников. Во-вторых, стандартный чек-лист «скачали с официального сайта, антивирус не ругается, значит все нормально» больше не работает как достаточная мера. В этом кейсе вредоносный компонент пытался сам исключить себя из контроля Defender и прятался под именем, похожим на легитимный сервис. Во-третьих, сертификация и периодические проверки действительно работают, но как механизм обнаружения, а не как магическая гарантия. Hola Browser ранее сертификацию проходил, однако это не помешало атакующим внедрить лишний бинарник между циклами контроля.
Если смотреть шире, инцидент хорошо ложится в общий тренд последних лет: злоумышленники все чаще выбирают не прямой взлом конечной машины, а более выгодную точку входа в виде поставщика, пакета, библиотеки или канала обновлений. Причина проста и почти цинична в своей логике. Взлом одной инфраструктурной точки дает доступ сразу к множеству устройств, а доверие к «официальной» поставке часто выше, чем к любому вложению из письма. Для компаний это означает, что AppSec, DevSecOps и endpoint-защита уже нельзя держать в разных организационных коробках. Проверка артефактов сборки, контроль подписей, inventory фактически доставленных файлов, поведенческий мониторинг на хостах и регулярная переаттестация каналов дистрибуции должны быть одной цепочкой, а не набором красивых слов в презентации для аудита.
Самый неудобный вопрос после этой истории звучит не как именно злоумышленники проникли в Hola, а почему рынок по-прежнему узнает о подобных инцидентах в основном постфактум, когда на клиентские машины уже что-то доехало. Пока вендоры строят «нулевое доверие» для пользователей, им придется научиться применять тот же принцип к собственным сборкам и релизным конвейерам. Подробности кейса и цитату CEO можно сверить в публикации .