НеИБи

MFA не поможет Если вам всегда казалось, что двухфакторная аутентификация — это панацея, то обязательно изучите эту новинку. JSCeal — это V8-байткод малварь, которая умеет не только воровать пароли и куки, но и использовать их для активного восстановления браузерной сессии. Что позволяет обойти Google-аутентификацию вместе с MFA, потому что злоумышленник просто выдает себя за уже аутентифицированного пользователя. Впервые JSCeal задокументировали в июле 2025 года, но с тех пор малварь активно развивается и до сих пор используется в кампаниях. Распространяется JSCeal через фейковые объявления на Facebook и Google, которые ведут на поддельные сайты криптобирж вроде TradingView, где жертве предлагают скачать «инсталлятор». Загрузка происходит в два этапа: через PowerShell доставляются два ZIP-архива — один с Node.js, второй с самим вредоносным payload и вспомогательными модулями. Это часть более крупной кампании SourTrade, активной с конца 2024 года, которая нацелена на трейдеров и инвесторов в 12 странах и на 25 языках. Отличие SourTrade в том, что финальный вредонос собирается прямо в памяти браузера из легитимных компонентов и инструкций, то есть готового файла на диске просто не существует. Функционально JSCeal перечисляет установленные браузеры (Chrome, Edge, Brave, Opera, Vivaldi и даже Cốc Cốc), вытаскивает сохраненные пароли, куки, OAuth-токены. Второй модуль отвечает за слежку. Запись нажатий клавиш и скриншоты. Третий —локальный прокси с подменой контента на лету. Малварь генерирует и устанавливает свой сертификат, перехватывает и модифицирует запросы для конкретных сервисов, включая Binance, Bybit и Ledger. Это позволяет не просто пассивно перехватывать трафик, а активно подменять страницы, блокировать хосты и очищать куки по команде. Разработчики JSCeal позаботились и о защите от анализа. Код обфусцирован с помощью javascript-obfuscator через четыре группы трансформаций. Присутствует замена имен на бессмысленные идентификаторы, разбивка строк с RC4-шифрованием, control-flow flattening (превращение логики в бесконечный цикл с переключателем состояний) и прокси-функции-обертки. Поверх этого — компиляция в V8-байткод, что добавляет еще один слой сложности. Check Point разработала пайплайн для статической деобфускации, но сам факт, что такие усилия требуются, говорит о серьезности подхода авторов. Как заметила исследовательница Александра Дониек, по отдельности эти техники не делают малварь невзламываемой, но вместе они выводят ее за рамки стандартных рабочих процессов аналитиков. @antiinfosec

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