Опасная уязвимость в DNS-сервере BIND

Опасная уязвимость в DNS-сервере BIND

Организация ISC выпустила экстренные обновления DNS-сервера BIND с устранением уязвимости (CVE-2013-4854), позволяющей инициировать крах процесса named через отправку запроса со специально оформленным содержимым поля RDATA. Уязвимости подвержены как рекурсивные, так и авторитетные серверы. Ограничение доступа через ACL не позволяет защититься от проблемы, помочь может только ограничение доступа к сетевому порту на уровне пакетного фильтра. Проблема усугубляется тем, что информация о методе эксплуатации появилась в Сети до выхода исправления и несколько компаний зафиксировали применения уязвимости для атаки на DNS-серверы.

В настоящий момент уязвимость уже исправлена в выпусках BIND 9.9.3-P2 и 9.8.5-P2, все остальные версии BIND 9, новее ветки 9.6, подвержены атаке. Для BIND 9.7 официальное исправление не выпущено, так как время поддержки данной ветки прекращено, тем не менее уже доступно обновление пакетов с BIND 9.7 для Debian. Аналогичное обновление также выпустил проект FreeBSD. RHEL/CentOS, Fedora, SUSE, openSUSE, Ubuntu и другие дистрибутивы Linux обновления на момент написания новости ещё не выпустили, сообщает opennet.ru.

Отдельно можно отметить объявление о добавлении в состав будущих выпусков BIND модуля RRL, предоставляющий эффективный механизм для защиты от проведения DDoS-атак с использованием DNS. Речь ведётся не об атаках, направленных на выведение из строя DNS-сервера, а об использовании DNS-серверов для атак на другие системы. Пользуясь тем, что ответ DNS-сервера превышает по размеру DNS-запрос, путем отправки запросов с указанием фиктивного обратного адреса, в качестве которого указан IP жертвы, создаётся волна трафика из обратных ответов (исходный трафик приумножается примерно в 100 раз).

Во втором квартале 2013 года частота проведения подобных атак возросла на 20%. При этом в среднем при каждой такой DDoS атаке генерируется трафик порядка 50 млн пакетов в секунду. RRL является способом справиться с проблемой на стороне DNS-серверов, давая возможность администраторам установить лимит на интенсивность отправки ответов в привязке к адресу получателя (заданные через RRL ограничения действуют только на исходящие запросы и не влияют на входящие). Модуль RRL добавляет поддержку директивы responses-per-second в блок rate-limit, позволяющей задать допустимое число ответов в секунду. 

ИИ-агенты OpenAI устроили спам-налёт на RubyGems

Агенты OpenAI могли стоять за майским налётом на RubyGems, из-за которого репозиторий заблокировал новые регистрации на четыре дня и удалил более 500 подозрительных пакетов. Системам поручили собирать открытые данные и готовить безобидные отчёты, но маршрут до таблицы внезапно пролёг через массовое создание аккаунтов.

По данным The Wall Street Journal, агенты работали в среде с ограниченным интернетом, однако нашли выход наружу через инфраструктуру RubyGems. Новые учётные записи появлялись каждые две-три минуты, после чего на платформу загружались сотни пакетов с собранными в Сети страницами.

Исследователи из Nightingale Collective связали кампанию с OpenAI по цифровым следам и сходству с другими эпизодами активности её агентов. Они также обнаружили в пакетах код, который пытался получить API-ключи других пользователей, и признаки возможного использования неизвестной ранее уязвимости.

Ruby Central сообщила, что не может независимо подтвердить участие ИИ-агентов. Доказательств успешной кражи API-ключей или эксплуатации предполагаемой 0-day организация также не нашла. Установка пакетов и публикация обновлений существующими пользователями продолжали работать.

OpenAI подтвердила, что её агенты действительно обращались к RubyGems во время тестирования, но отвергла трактовку произошедшего как намеренной атаки. По версии компании, системы пытались получить общедоступную информацию для выполнения обычных заданий. Расследование продолжается совместно с RubyGems.

Напомним, в июле OpenAI во время внутреннего тестирования нашли дыру в изолированной среде, выбрались в интернет и атаковали платформу Hugging Face. Компания признала, что за инцидентом 16 июля стояли GPT-5.6 Sol и ещё более мощная модель, которая пока не выпущена.

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