Австралийская CubePilot 24 июля сообщила о перехвате DNS для домена cubepilot.org. История неприятна не только из-за подмены трафика: компания предупредила, что в тот день злоумышленник мог перехватывать введённые учётные данные, а сейчас ещё идёт проверка целостности опубликованных прошивок.
Для русскоязычной ИТ-аудитории это показательный случай. Когда компрометируют DNS и успевают выпустить сертификаты, проблема быстро выходит за рамки «не работал сайт»: под удар попадают личные кабинеты, служебные учётные записи, документация и каналы доставки обновлений.
Что произошло 24 июля
По данным BleepingComputer и самой CubePilot, атакующий 24 июля получил контроль над DNS-настройками домена компании. После этого трафик на сервисы CubePilot можно было перенаправлять через чужую инфраструктуру, а выданные TLS-сертификаты делали атаку особенно убедительной: у пользователя открывается знакомый адрес, HTTPS на месте, браузер молчит.
CubePilot прямо предупредила клиентов: если 24 июля они вводили логины и пароли на сервисах компании, эти данные могли быть скомпрометированы. В зону риска попали как минимум портал и форум. Компания попросила сменить пароли у себя и на других сервисах, если там использовалась та же комбинация.
Какие сервисы отключили и зачем
CubePilot заявила, что вернула контроль над доменом в тот же день, 24 июля, и отозвала мошеннически выпущенные сертификаты. Компания также сообщила об инциденте в Australian Cyber Security Centre и правоохранительные органы, а часть систем временно вывела из эксплуатации для расследования.
Под отключение попали OEM-сервисы, форум сообщества и портал документации. Гендиректор CubePilot Филип Роуз отдельно написал в LinkedIn, что в качестве меры предосторожности отключён и ERP-портал. Для бизнеса это болезненно, но логика понятна: если неясно, насколько глубоко атакующий успел встроиться в поток данных, безопаснее остановить внешние сервисы, чем потом разбираться с подменёнными файлами, заказами или реквизитами.
Проверка прошивок стала главным вопросом
Самая чувствительная часть истории касается не веб-сайта, а файлов обновлений. CubePilot сообщила, что ещё проверяет целостность опубликованных образов прошивок и не рекомендует устанавливать файлы, загруженные 24 и 25 июля, пока проверка не завершена. Образы, скачанные до 24 июля, компания на момент уведомления считала безопасными.
Именно здесь инцидент становится важным для разработчиков в embedded, IoT и промышленном ПО. Если ломают не сервер приложений, а DNS и доверенную сертификатную обвязку, под угрозой оказываются весь контур поставки: бинарники, SDK, документация, служебные уведомления и страницы авторизации. Для компаний с собственными механизмами обновления это уже не сетевая неприятность, а риск для цепочки поставки.
Значение для рынка
Для российского и СНГ-рынка вывод довольно приземлённый: валидный HTTPS давно не гарантирует, что пользователь попал именно туда, куда собирался. Если компания раздаёт прошивки, дистрибутивы или закрытую документацию через собственный домен, ей нужны жёсткие процедуры у регистратора, контроль выпуска сертификатов, независимая проверка файлов и готовый сценарий быстрого отзыва доверия. Иначе одна удачная атака на DNS превращает «витрину» компании в точку входа для компрометации клиентов.
Следующий шаг теперь за CubePilot: завершить проверку образов, восстановить сервисы и отдельно сообщить клиентам, где риск подтвердился. Оригиналы сообщений: BleepingComputer и официальные уведомления CubePilot.