ФБР расследует «взрыв» Белого дома

ФБР расследует «взрыв» Белого дома

Федеральное бюро расследований США начало расследование по факту взлома хакерами аккаунта агентства Associated Press в соцсети, на котором было размещено не соответствующее действительности сообщение о взрывах в Белом доме и ранении президента США Барака Обамы, сообщает ИТАР-ТАСС.

Начало расследования подтвердила журналистам представитель ФБР Дженни Ширер, однако никаких других деталей она не привела.

Ответственность за взлом взяли на себя хакеры из Сирии «Сирийская электронная армия», сообщает ВВС.

Ранее эта группировка взломала в соцсети аккаунты ВВС и американских телекомпаний CBS и NPR.

Аккаунт АР временно прекратил работу, и АР попросило пользователей игнорировать все сообщения «до дальнейшего извещения».

Майк Бейкер, один из репортеров АР, на своей странице в соцсети написал, что «нападение на AP произошло через час после того, как некоторые из нас получили хорошо замаскированный фишинг-имейл».

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

В данном случае электронное сообщение выглядело так, как будто оно было отправлено одним из сотрудников АР, в котором другим сотрудникам компании предлагалось просмотреть на «очень важную» статью на сайте газеты Washington Post.

Ссылка вела на поддельный сайт, который просил сотрудников АР ввести их логин и пароль.

Напомним, аккаунт Associated Press в соцсети был взломан вечером 23 апреля.

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

Поддельное сообщение о ранении Обамы успело скопировать в свою новостную ленту агентство ИТАР-ТАСС. Позже оно дало опровержение. Отреагировали на ложное сообщение и рынки: в момент появления твита индекс Dow Jones упал на 131 пункт, но вскоре восстановил прежний уровень.

Баги в ядре 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