НАСА сообщает о хакерских атаках на свои спутники

НАСА сообщает о хакерских атаках на свои спутники

Из четырех атак две были успешны: злоумышленники два раза получили возможность выдавать свои команды на один из спутников, которые используются для наблюдения за климатом Земли.



Согласно данным расследования специалистов ВВС США, хакеры использовали спутниковую информационную станцию SvalSat, которая базируется в Шпицбергене, Норвегия. SvalSat обеспечивает доступ к данным и передачу файлов через интернет, что и стало "дверью" для хакеров, получивших с помощью SvalSat доступ к управлению спутником, сообщает CNews.

Первая атака на спутник Landsat-7 (управляется НАСА и Геологической службой США) состоялась 20 октября 2007 года: в течение 12 минут спутник испытывал помехи и не функционировал должным образом. 23 июля 2008 года ситуация с Landsat-7 полностью повторилась.

20 июня 2008 года атаке подвергся спутник НАСА Terra EOS AM-1, который в результате 2 минуты испытывал проблемы с управлением. Данная атака хакеров завершилась успехом: они полностью завладели контролем над аппаратом, но не подали никаких команд. Это обстоятельство также, видимо, заставило американскую разведку подозревать в нападении китайских военных хакеров, в задачи которых не входило повреждение чужого спутника.

22 октября 2008 года атака на Terra EOS AM-1 повторилась, на этот раз она длилась 9 минут, и хакеры вновь получили полный контроль над системами космического аппарата.

Беспрецедентные случаи успешной атаки на спутники обеспокоили американских специалистов и наверняка найдут эмоциональный отклик у конгрессменов. Доступ к элементам управления спутника позволит злоумышленнику повредить или уничтожить спутник, а также направить его в сторону других космических аппаратов, в том числе и пилотируемых. Таким образом кибертерроризм может получить совершенно новое и очень опасное оружие. Разумеется, военные спутники гораздо лучше защищены от подобных атак, но обилие и важность коммерческих спутников делает "космический" хакинг очень опасным явлением.

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

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