Топ-5 ИБ-событий недели по версии Jet CSIRT

Новое вредоносное ПО для АСУ ТП FrostyGoop

В своем отчете специалисты Dragons проанализировали работу ВПО FrostyGoop в кампании, направленной на систему отопления крупного города. Кибератака оставила более 600 многоквартирных домов без горячей воды на протяжении 48 часов. ВПО направлено на ICS-системы, используемые для управления и мониторинга оборудованием в промышленности, позволяя контролировать процессы на предприятиях. FrostyGoop разработан специально для АСУ ТП и может напрямую взаимодействовать с промышленными системами управления. В исследуемом инциденте использовался протокол Modbus для атаки на контроллеры ENCO с открытым портом TCP 502. Злоумышленникам удалось отправить команды на котроллеры оборудования, что позволило изменить показатели температуры и привело к подаче холодной воды вместо горячей. FrostyGoop не является единственным примером подобного ВПО, что лишний раз подчеркивает необходимость создания и постоянной актуализации комплексной системы защиты критической инфраструктуры на предприятиях.

Исправлена уязвимость в плагине AuthZ в Docker

Специалисты Docker опубликовали бюллетень по уязвимости CVE-2024-41110 (CVSS 10), ей подвержен Docker Engine версий до 19.03.15, 20.10.27, 23.0.14, 24.0.9, 25.0.5, 26.0.2, 26.1.4, 27.0.3 и 27.1.0 и пользователи, применяющие плагины авторизации для контроля доступа. Злоумышленнику достаточно отправить API запрос с Content-Length равным 0. В результате, если не установлено запрещающее правило, запрос будет одобрен, и злоумышленник получит несанкционированный доступ с возможностью повышения привилегий. Как выяснилось, об этой уязвимости в Docker знали с 2018 года. Изначально исправление было выпущено в Docker Engine 18.09.1 в январе 2019-го, но его по ошибке не включили в последующие обновления. Специалисты компании рекомендуют обновиться до версий с исправлениями. Если обновление невозможно, необходимо отказаться от использования плагина AuthZ и ограничить доступ к API Docker.

Разбор кампании по распространению вредоносного ПО

Специалисты Check Point обнаружили вредоносную кампанию из более чем 3000 аккаунтов и 2200 репозиториев на GitHub по распространению вредоносного ПО. Злоумышленники маскируют аккаунты под легитимные, добавляя репозиториям звезды, создавая копии и накручивая подписки. Кампания направлена на различные сферы: моды для игр, взломанное платное ПО, утилиты для накрутки подписчиков в социальных сетях и др. Использование нескольких учетных записей, выполняющих различные действия — от добавления звезд до размещения репозитория, фиксации шаблона фишинга и размещения вредоносных релизов, — позволяет злоумышленникам минимизировать свои потери при их блокировке со стороны GitHub. В отчете представлен перечень C2 серверов, используемых в кампании, и хеши распространяемых вредоносных семплов. Для противодействия таким угрозам рекомендуется использовать многоуровневую защиту, включая обучение сотрудников по вопросам кибербезопасности, регулярное обновление программного обеспечения и использование надежных решений для защиты от вредоносного ПО.

PKfail позволяет обойти Secure Boot

PKfail — это ошибка в цепочке поставок, которая затрагивает механизм Secure Boot в системе UEFI (Unified Extensible Firmware Interface). Secure Boot предназначен для защиты системы от загрузки неподписанных или вредоносных компонентов, что обеспечивает безопасность при загрузке операционной системы. PKfail позволяет злоумышленникам обойти защиту Secure Boot и установить вредоносное ПО. Эксперты компании Binarly обнаружили, что сотни моделей устройств от крупных производителей (Lenovo, HP, Intel, MSI, Gigabyte и др.) использовали тестовые ключи платформы Platform Key (PK). Компании должны были заменить их сгенерированными безопасными ключами, так как это один из компонентов цепочки доверенной загрузки. Если этого не сделать, есть очень серьезный риск ее обхода. Учитывая, что количество моделей устройств, подверженных PKfail, превысило 900, рассчитывать на оперативное обновление прошивки от производителей не стоит. Для минимизации риска можно использовать сертифицированные средства защиты классов МДЗ или СДЗ.

Получение доступа к удаленным данным на GitHub

Исследователи из Truffle Security обнаружили, что данные из удаленных репозиториев GitHub (публичных или частных) и из удаленных копий (форков) репозиториев все еще могут быть доступны. В статье рассматриваются три основных аспекта доступа к данным на GitHub: возможность получить данные коммитов из удаленного форка по хешу, возможность получить в форке данные несинхронизированных коммитов из upstream репозитория по хешу после его удаления и возможность получения доступа к приватным данным публичного репозитория по хешу. Это возможно потому, что удаляются только ссылки на данные коммита из стандартного пользовательского интерфейса GitHub и из стандартных операций с git, но эти данные все еще существуют и доступны (если известен хеш коммита). Коммиты можно найти с помощью API GitHub, что делает данные еще более уязвимыми. Данная логика не является уязвимостью или ошибкой, а изначально заложена в git и, соответственно, в GitHub. При проверке репозиториев популярных компаний были обнаружены десятки валидных API-ключей, которые остались в копиях после удаления.