НеИБи

RSA-260 все Забыли вам рассказать, что вчера, 3 сентября, инженер Эрик Лу из Cognition опубликовал в X 130-значное число и подписал: «divides RSA-260». То есть легендарное 862-битное число из челленджа RSA Labs 1991 года наконец-то факторизовали. Предыдущий рекорд (RSA-250, 829 бит) пал шесть с половиной лет назад, и тогда на него ушло 2700 ядро-лет. А тут — 862 бита, и мы даже не знаем, на чем считали. Никаких деталей о ресурсах. Ходят шутки про «бумагу и карандаш», но интрига реально не хилая. Для ИБ событие не рядовое. Конечно, RSA-2048 не сломали, разница между 862 и 2048 битами колоссальна, и сложность растет экспоненциально. Но практический предел классической факторизации отодвинулся до 862 бит. RSA-1024 больше не выглядит чем-то недосягаемым, а 1024-битные ключи до этого считались неприкасаемыми для всех кроме спецслужб. Теперь картинка меняется. В принципе, переход на постквантовую криптографию происходит уже сегодня. RSA падет рано или поздно, вопрос только за счет нового алгоритма или квантов. И вчерашний дроп этому лишь доброе напоминание. @antiinfosec

Где вы были 12 лет назад? В базе данных PostgreSQL, на которой держится заметная часть интернета, в том числе Netflix, Instagram, Spotify, Uber, не говоря уже о бесчисленных корпоративных системах, нашли дыру, которая в этом году пошла бы в 7 класс. Уязвимость, существующая с 2014 года, позволяла любому, у кого есть доступ к репликации, получить полный контроль над сервером. Исследователи из Cyera дали уязвимости имя PostGREShell и номер CVE-2026-6471. Хотя через два года можно было бы ей паспорт выдавать. Для синхронизации баз данных в PostgreSQL есть специальный протокол репликации, и для него заводится учетная запись с атрибутом Replication. Такие учетки есть везде — для бэкапов, мониторинга, CDC-пайплайнов. Их воспринимают как технический мусор, которому можно доверять. Обычно эти учетки не могут делать ничего опасного, но исследователи нашли способ обойти это ограничение. Проблема в том, что PostgreSQL позволяет подгружать внешние плагины для обработки потока репликации. Имя плагина передается напрямую в системную функцию dlopen(), которая загружает разделяемые библиотеки. При этом имя никак не проверяется. Можно передать любой путь до файла на диске, использовать ../ для выхода за пределы директорий или даже указать Windows UNC-путь. Загруженный код выполняется с правами системного пользователя postgres. А дальше вызов внутреннего API для получения суперпользователя, прямая запись в таблицу pg_authid, и, вуаля,вы суперпользователь навсегда. Уязвимость затрагивает все версии PostgreSQL с 9.4 по 18.2. Патчи уже вышли в версиях 18.6, 17.11, 16.15, 15.19 и 14.24. Разработчики закрыли дыру, но это не значит, что проблема решена. Атака оставляет после себя бэкдор: вредоносный плагин может включить подключения без пароля, скопировать себя в надежное место и пережить даже попытку отката прав. Поэтому учетки после обновления придется отдельно перепроверить. @antiinfosec

Ваш код не ваш, если разработчику не нравится ваша страна Представьте, вы спокойно собираете проект, устанавливаете очередную библиотеку через npm, и вдруг ваш диск заполняется файлами с сердечками вместо рабочих данных. Нет, это не сбой и не вирус в классическом понимании. Это protestware, когда разработчик намеренно встраивает в код деструктивную логику не ради денег, а ради идеи. И с каждым годом таких случаев становится все больше. Специалист ИБ из YADRO опубликовал статью с разбором нескольких хрестоматийных примеров. Самый известный — библиотека node-ipc, которая добавила в свои зависимости модуль "peacenotwar". При установке он проверял IP-адрес через геосервисы, и, если пользователь находился в России или Беларуси, заменял все файлы на диске на «символы мира» (сердечки). Причем код был обфусцирован, а вредоносная логика пряталась в хуках postinstall. Еще один случай — colors.js и faker.js. Тогда мейнтейнер внес бесконечный цикл с не-ASCII символами, который блокировал event loop Node.js, вызывая отказ в обслуживании. А es5-ext, который используется в webpack, получал проверку времени и локали. Если системное совпадало с российскими часовыми поясами или локаль была ru_RU, то запускалась 100% загрузка CPU в бесконечном цикле. Технически protestware может прятаться где угодно. В коде времени исполнения, в хуках жизненного цикла npm, в скриптах сборки или даже в тестах. Активируется он тоже по-разному: геолокация по IP, системная локаль, часовой пояс, переменные окружения, hostname или просто дата и время. То есть злоумышленник может настроить бомбу так, чтобы она взорвалась только у конкретной компании или в конкретной стране. Автор предупреждает, что protestware — это не просто «идейный баннер» в консоли, который раздражает, но не опасен. Вредоносный код может заблокировать работу приложения, повредить или удалить данные, саботировать бизнес-процессы и ограничить работу пользователей из определенных регионов. А поскольку антивирусы такой код не видят (он вроде от известного автора и кажется легитимным), а вредоносная логика может не проявлять себя долгое время, обнаружить его непросто. Бороться с этим, к сожалению, нелегко. Автор предлагает композиционный анализ (SCA) и формирование SBOM, чтобы знать все зависимости, статический анализ кода на поиск конструкций, связанных с геолокацией (geoip, country, locale), удалением данных (rm -rf, delete, wipe) или выполнением внешних команд, динамический анализ в изолированной среде, мониторинг изменений в репозиториях (смена мейнтейнеров или необычно крупные коммиты перед релизом). Если подозрительный пакет обнаружен — изолировать его, заблокировать скомпрометированную версию и откатить к более ранней. В идеале — создать форк и сопровождать его самостоятельно. Для профилактики автор рекомендует принципы Zero Trust для зависимостей, фиксированные версии, изоляцию сборки, подписание артефактов и использование внутренних репозиториев. И напоминает, что популярность проекта, количество звезд на GitHub или размер сообщества — еще не гарантии безопасности. Контролировать нужно весь сторонний код, независимо от его известности. @antiinfosec