Mozilla засветила ключ подписи Firefox и Thunderbird в GitHub

Mozilla засветила ключ подписи Firefox и Thunderbird в GitHub

Mozilla засветила ключ подписи Firefox и Thunderbird в GitHub

Mozilla заменила GPG-ключ, которым подписывала некоторые сборки Firefox и Thunderbird. Причина в этот раз серьёзная: незашифрованную копию секретного ключа случайно загрузили в закрытый репозиторий GitHub. Ключ использовался для подписи Linux-архивов, RPM-пакетов и файлов контрольных сумм.

Теоретически его обладатель мог бы подписать поддельные установщики, выдав их за официальные релизы Mozilla. Однако компания оценивает риск атаки на цепочку поставок как низкий.

Репозиторий был доступен лишь небольшой группе сотрудников Mozilla, которые и без того имели законный доступ к ключу. Проверка журналов аудита не выявила признаков того, что секретом воспользовался кто-то посторонний. Поэтому старый ключ отозвали и выпустили новый.

Большинству пользователей ничего делать не придётся. Тем, кто самостоятельно проверяет GPG-подписи загруженных файлов, необходимо импортировать новый ключ и данные об отзыве прежнего.

Чуть больше хлопот может достаться владельцам Linux-систем, устанавливающим Firefox из RPM-пакетов. В зависимости от дистрибутива им придётся вручную обновить ключ, иначе свежие версии браузера могут перестать устанавливаться.

Mozilla опубликовала отдельные инструкции для Fedora, RHEL, Rocky Linux, AlmaLinux, openSUSE и SUSE. Пользователей Thunderbird эта часть не касается: официальных RPM-пакетов почтовый клиент не выпускает.

Новый подключ действует до 5 августа 2028 года. Публичный ключ и сведения об отзыве старого доступны в актуальных файлах KEY для Firefox Nightly и на сервере keys.openpgp.org.

Mozilla также пообещала принять меры, чтобы секретные ключи больше не отправлялись гулять по репозиториям.

34% систем управления ЦОД работает на устаревших прошивках

Треть систем управления инженерной инфраструктурой ЦОД работает на устаревших прошивках. Специалисты «Информзащиты» изучили 66 395 BMS и выяснили, что неактуальное программное обеспечение установлено на 34% устройств. Но старая версия — лишь начало: 84% систем обмениваются данными по небезопасным протоколам, а 800 содержат известные эксплуатируемые уязвимости из каталога KEV.

Хуже всего обстоят дела с системами мониторинга электропитания: устаревшие прошивки обнаружены на 59% устройств. У OT-систем показатель составляет 48%, у BMS — 40%, у IoT-оборудования и интеллектуальных датчиков — 37%, у источников бесперебойного питания — 23%.

Обновлять такие системы сложнее, чем офисные компьютеры. Новую прошивку необходимо проверить на совместимость с контроллерами, датчиками, шлюзами и диспетчерским ПО.

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

Свежая прошивка тоже не волшебная таблетка. Около 84% BMS используют протоколы без достаточной аутентификации и шифрования, включая BACnet и MODBUS. Устройство может одновременно иметь старое ПО, известную уязвимость и принимать команды, толком не проверяя отправителя.

Напрямую из интернета доступны лишь 369 исследованных BMS — менее 1%. Однако закрытый внешний периметр не спасает: 14% систем в инфраструктуре ЦОД находились всего в одном сетевом переходе от связанного с интернетом узла. У PDU эта доля достигает 41%. Злоумышленнику достаточно взломать соседнюю ИТ-, IoT- или сетевую систему, а затем переместиться в технологический сегмент.

Эксперты рекомендуют провести инвентаризацию инженерных устройств, закрыть уязвимости KEV, изолировать BMS, контролировать подрядчиков и следить за командами в технологических протоколах. Потому что резервный контроллер с той же дырявой прошивкой — это не киберзащита, а второй шанс наступить на те же грабли.

RSS: Новости на портале Anti-Malware.ru