Обнаружена более ранняя версия мощного кибер-оружия Stuxnet 0.5

Обнаружена более ранняя версия мощного кибер-оружия Stuxnet 0.5

Корпорация Symantec объявляет об обнаружении более ранней версии одного из наиболее интеллектуальных вирусов –  Stuxnet, впервые в истории использованного в качестве кибер-оружия. Версия с номером 0.5 была активна с 2007 по 2009 год, а её применение могло быть начато ещё в ноябре 2005 года, когда был зарегистрирован её первый C&C-сервер. В отличие от своего более известного преемника – версии 1.001, версия 0.5 использовала совершенно другой механизм атаки. Эксперты Symantec обнаружили также, что более ранняя версия вируса была частично создана на той же той же платформе, что и Flamer.

Полученные экспертами Symantec в ходе исследования данные показали, что Stuxnet версии 0.5 был специально создан для атаки на промышленные установки SIMATIC 400 Station и SIMATIC  H-Station (центрифуги для обогащения урана) иранского завода, расположенного около города Натанз. Атака была построена на выведении из строя центрифуг за счёт создания пятикратных перепадов давления в центрифугах, объединённых в каскады – вирус управлял клапанами  управления подачи и сброса газообразного гексафторида урана. При этом он маскировал свою деятельность, демонстрируя оператору заранее сохранённый снимок монитора нормального состояния центрифуги.

Более поздние версии вируса разрушали центрифуги за счёт управления скоростью их вращения и были обнаружены в июле 2010 года после того, как они стали поражать системы за пределами первоначальной цели. И если факт серьёзного нарушения работы иранского завода по обогащению урана близ города Натанз атаками поздних версий Stuxnet считается общепризнанным, то степень успешности атак более ранних версий вируса до сих пор не раскрыта.

Несмотря на семилетний возраст угрозы и дату её деактивации, Symantec зарегистрировала небольшое количество пассивных заражений по всему миру в течение последнего года.

 

Рисунок 1. Пассивные заражения, обнаруженные за последний год

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

Группа компаний «Солар» проверила, насколько хорошо большие языковые модели справляются с двумя самыми трудоёмкими задачами в безопасной разработке — триажем уязвимостей и их исправлением в коде. Итог исследования получился довольно показательный: популярные общедоступные модели ускоряют работу, но пока слишком часто ошибаются, чтобы полностью на них полагаться.

Эксперты Solar appScreener протестировали шесть LLM на 20 крупных приложениях на Java и Python, каждое объёмом более 100 тысяч строк кода. Для анализа использовали как облачные модели — GigaChat 3 PRO, ChatGPT 5.2 и DeepSeek 3.2, так и локальные решения on-premise, включая ChatGPT OSS, Mistral и специализированные модели DerTriage и DerCodeFix.

Сначала с помощью SAST-анализа в проектах нашли около 12 тысяч уникальных срабатываний, из которых почти 20% пришлись на уязвимости высокой критичности. После этого все модели получили одинаковый промпт с описанием уязвимости, фрагментом кода, трассой достижимости и идентификаторами CWE.

На этапе триажа результаты оказались неровными. В Java-проектах среди облачных моделей лучше всех выступил ChatGPT с точностью 60,9%, а DeepSeek показал лишь 50%. В Python-коде картина поменялась: DeepSeek добрался до 80%+, а ChatGPT показал 52,7%. Но лучший результат среди локальных решений продемонстрировала DerTriage — более 80% точности и для Java, и для Python.

С кодфиксом ситуация похожая. Для Java ChatGPT показал 61,8% точности, DeepSeek — 45,5%. В Python их показатели составили 46,6% и 44,8% соответственно. Локальная модель DerCodeFix снова оказалась впереди: 78,2% точности на Java и 83,1% на Python.

Главный вывод исследования простой: LLM действительно экономят время, но на самых ответственных этапах безопасной разработки универсальные модели пока не дают нужной надёжности. Если команда безоговорочно доверится таким инструментам, есть риск пропустить критичные уязвимости.

В «Соларе» также напоминают ещё об одной проблеме: использование облачных моделей может стать каналом утечки исходного кода. Поэтому для задач безопасной разработки компания рекомендует смотреть в сторону локальных моделей on-premise, которые работают в закрытом контуре и всё равно требуют проверки со стороны AppSec-инженера.

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