Поставщика Asus атаковали вымогатели. Хакеры заявляют, что украли 1 ТБ данных

Компания Asus сообщила, что один из ее поставщиков пострадал от хакерской атаки. При этом вымогательская группировка Everest заявила, что похитила терабайт данных сразу у трех компаний — Asus, Qualcomm и ArcSoft. По словам злоумышленников, утечка затрагивает не просто документы, а исходники ПО для камер смартфонов, ИИ-модели и внутренний софт. Представители Asus уверяют, что проблема коснулась только одного из поставщиков компании: злоумышленники смогли добраться до части исходных кодов ПО для камер телефонов. При этом компания настаивает, что никакого ущерба ее собственным системам, продуктам или данным клиентов нанесено не было. В компании добавили, что уже усиливают безопасность цепочки поставок. При этом в заявлении не раскрывается ни имя скомпрометированного поставщика, ни детали того, какие именно данные украли хакеры. Тем временем вымогательская группировка Everest опубликовала на своем сайте в даркнете скриншоты якобы украденных файлов.
В заявлении злоумышленников говорится, что они похитили терабайт данных у компаний Asus, ArcSoft и Qualcomm. Хакеры пишут, что им удалось украсть:
модули бинарной сегментации;
исходники и патчи;
дампы RAM и логи памяти;
ИИ-модели и веса;
внутренние инструменты OEM-производителей и прошивки;
тестовые видео и данные калибровки двойных камер;
наборы изображений;
логи сбоев и отчеты отладки;
информацию о работе HDR и постобработки;
тестовые APK и экспериментальные приложения;
скрипты и решения для автоматизации;
файлы бинарной калибровки.
Представители Asus пока никак не комментировали заявления группировки. Также неизвестно, на самом ли деле атака затронула Qualcomm и ArcSoft. В компании не ответили на вопросы СМИ о том, были ли украденные материалы собственностью самой Asus или других компаний.

Источник: https://xakep.ru/2025/12/09/asus-leak/

Эксперты заметили, что стилер Lumma заразил устройство северокорейского хакера

Во время анализа логов стилера Lumma исследователи из компании Hudson Rock обнаружили, что вредонос заразил устройство северокорейского хакера, связанного с кражей криптовалюты на 1,4 млрд долларов с биржи Bybit. Как рассказывают специалисты, одной из найденных ими улик стали учетные данные, обнаруженные на зараженном устройстве. Среди них фигурировал email-адрес trevorgreer9312@gmail.com, который ранее в своих отчетах упоминали исследователи из компании Silent Push. Сопоставив данные с находками Silent Push, аналитики пришли к выводу, что зараженное устройство использовалось в инфраструктуре, которая связана с крупной атакой на биржу Bybit. Напомним, этот взлом произошел в феврале 2025 года, и его связывали с северокорейскими хакерами, предположительно из группировки Lazarus. Дело в том, что упомянутый email-адрес фигурировал при регистрации домена bybit-assessment.com, который создали за несколько часов до ограбления Bybit. Сайт выдавал себя за биржу и являлся частью фишинговой инфраструктуры. Хотя владелец зараженной системы, вероятно, не был напрямую причастен к самому криптоограблению, исследователи напоминают, что «правительственные» хакеры часто используют общие ресурсы, включая машины для разработки, фишинговые домены, наборы учетных данных и коммуникационную инфраструктуру. Зараженное Lumma устройство работало на базе процессора Intel Core i7 12-го поколения, имело 16 ГБ оперативной памяти, содержало установленные Visual Studio Professional 2019 и Enigma Protector. Так как Enigma обычно применяют для упаковки исполняемых файлов, чтобы обходить защиту, эксперты предположили, что обнаружили хорошо оборудованную рабочую станцию для создания малвари и управления инфраструктурой. История браузера и данные о приложениях жертвы добавили деталей. Трафик шел через американский IP с помощью Astrill VPN, однако в настройках браузера использовался упрощенный китайский язык, а история переводов включала прямые запросы на корейском языке. Также отмечается, что структура папок Dropbox намекала на то, что туда загружались украденные данные для последующего доступа. Стоит отметить, что в ноябре 2025 года в своей статье ИБ-исследователь Мауро Элдрич (Mauro Eldritch) сообщал, что северокорейские хакеры, выдававшие себя за кандидатов на должности в западных ИТ-компаниях, тоже использовали Astrill VPN для маскировки IP-адресов. Исследователи полагают, что пострадавший от Lumma хакер готовился к фишинговой атаке. Так, были куплены домены вроде callapp.us и callservice.us, а также поддомены типа zoom.callapp.us, которые использовались для обмана жертв, вынуждая их скачивать поддельное ПО или обновления. Локальный IP-адрес фальшивого установщика Zoom также вел к этой же машине. При этом нет никаких признаков того, что хакер заметил компрометацию, что дало ИБ-исследователям редкий шанс изучить, как северокорейские хакеры ведут свои операции. В Hudson Rock даже создали симулятор зараженной машины, позволяющий другим специалистам изучить софт, активность в браузере и украденные данные.

Источник: https://xakep.ru/2025/12/09/apt-machine/

Думали, что Cursor просто пишет код? А он еще и секреты ворует (если попросить правильно)

Более 30 уязвимостей обнаружено в популярных средах разработки с встроенным ИИ, и все они позволяют злоумышленникам с помощью сочетания prompt-инъекций и штатных функций IDE незаметно воровать данные или удалённо выполнять команды. Исследователь Ари Марзуки (MaccariTA) назвал серию проблем IDEsaster — и под удар попали такие инструменты, как Cursor, Windsurf, Kiro.dev, GitHub Copilot, Zed.dev, Roo Code, Junie и Cline. Для 24 уязвимостей уже присвоены CVE-идентификаторы. По словам исследователя, наиболее поразительным открытием стало то, что единые цепочки атак срабатывали буквально во всех проверенных AI-IDE. Разработчики помощников и расширений годами считали встроенные функции IDE безопасными, но ситуация меняется, когда в экосистему добавляются автономные ИИ-агенты: привычные механизмы начинают работать как инструменты для кражи данных или исполнения произвольного кода. Суть уязвимостей заключается в комбинации трёх типичных для AI-IDE векторов: обход защит LLM через prompt-инъекции, автоматическое выполнение действия агентом без участия пользователя и использование легитимных возможностей IDE для выхода за пределы предполагаемой зоны безопасности. В отличие от прежних сценариев, где prompt-инъекции комбинировались с уязвимыми инструментами, IDEsaster использует обычные функции среды разработки для утечки данных или запуска команд. Хакеры могут подменять контекст множеством способов: вставлять скрытые символы в текст или URL, подменять данные через Model Context Protocol, отравлять MCP-инструменты или заставлять легитимный сервер MCP обрабатывать внешние вредоносные данные. Исследователь обнаружил цепочки атак, позволяющие считывать секретные файлы, создавать JSON-файлы со ссылками на ресурсы атакующего, менять настройки IDE, пересобирать рабочие конфигурации и в итоге добиваться выполнения произвольного кода. Особенно опасно то, что многие AI-агенты автоматически одобряют изменения в файлах проекта, что открывает путь к атаке без какого-либо участия пользователя. Марзуки рекомендует использовать AI-IDE только для доверенных проектов, проверять любые сторонние источники и URL на скрытые инструкции, подключаться лишь к проверенным MCP-серверам и тщательно следить за их работой. Разработчикам он советует ограничивать возможности инструментов LLM, минимизировать векторы prompt-инъекций, усиливать системные подсказки, применять песочницы и отдельно тестировать защиту от обхода путей, утечек данных и внедрения команд. Параллельно появились сведения и о других уязвимостях в инструментах разработки с ИИ. В OpenAI Codex CLI выявлена критическая ошибка, позволяющая выполнять команды при запуске за счёт безоговорочного доверия конфигурации MCP. В Google Antigravity нашли цепочки атак на основе непрямых prompt-инъекций, позволяющих красть учётные данные или вставлять постоянный бэкдор. А новая категория уязвимостей PromptPwnd демонстрирует, как можно обмануть связанных с CI/CD ИИ-агентов и заставить их выполнять привилегированные действия. Все эти находки подчёркивают, что ИИ-агенты значительно расширяют поверхность атаки: модели не различают реальные инструкции пользователя и вредоносные фрагменты, незаметно попавшие в контекст. Как отметил исследователь Рейн Даэлман, это создаёт угрозу утечки секретов, внедрения команд и компрометации репозиториев для любых проектов, использующих ИИ для автоматизации задач. Марзуки считает, что такие случаи показывают необходимость нового подхода к безопасности — парадигмы Secure for AI, которая учитывает, как ИИ-компоненты могут быть использованы в атаке на протяжении всего жизненного цикла продукта.

Источник: https://www.securitylab.ru/news/566949.php

Telegram выкатил поддержку Passkey эксклюзивно для России

Telegram включил авторизацию по Passkey для аккаунтов с российскими номерами телефона. Пользователям стала доступна система входа по криптографическому ключу, который хранится в менеджере паролей устройства и позволяет войти в аккаунт в одно касание, без ввода номера телефона и одноразового кода. Функция работает в актуальных версиях клиента Telegram для Android (12.2.10) и iOS (12.2.3). Чтобы её активировать, необходимо в настройках мессенджера открыть раздел «Конфиденциальность», выбрать пункт «Ключи доступа» и добавить новый ключ. При создании Telegram использует биометрию или код разблокировки устройства, а сам Passkey сохраняется в системном хранилище или подключенном менеджере паролей. Один аккаунт может иметь несколько ключей, а на одном устройстве может храниться несколько профилей. При входе в обновлённый клиент Telegram на Android или iOS приложение либо сразу предлагает выбрать ключ доступа, либо показывает под полем «Номер телефона» ссылку «используйте ключ доступа». После выбора эта опция запускает менеджер паролей, который подтверждает личность пользователя по лицу, отпечатку пальца или PIN-коду, а затем передаёт мессенджеру нужный Passkey. Такой ключ одновременно заменяет и номер телефона, и одноразовый код подтверждения, но при включённой двухфакторной защите по прежнему требуется ввод облачного пароля. Сейчас Passkeys доступны только для аккаунтов с российскими номерами. Редакция tginfo связывает это с тем, что в России начали блокировать доставку SMS с кодами для входа в Telegram, и новая опция даёт пользователям альтернативный механизм авторизации, не зависящий от SMS или звонков. В других странах проблем с доставкой кодов нет, и Telegram, по оценке авторов, не спешит ослаблять привязку аккаунтов к номерам телефонов, поскольку использует её для борьбы со спамом. Ключи доступа могут синхронизироваться между устройствами через Google Password Manager, iCloud Passwords или другие менеджеры паролей с поддержкой Passkeys. Пользователям рекомендуют проверить настройки автозаполнения и используемый аккаунт в Android или iOS. В случае потери или кражи устройства сам Passkey остаётся в защищённой зоне хранилища паролей, а удалить ключ, привязанный к аккаунту, можно в настройках конфиденциальности Telegram. Поддержка Passkeys заявлена для официальных клиентов Telegram для Android, iOS и Telegram Desktop на Windows при наличии Windows Hello. На данный момент ключи доступа не работают в Telegram Desktop для macOS и Linux, отдельном клиенте Telegram для macOS (Swift), веб-версиях WebK и WebA, в Telegram X и других неофициальных приложениях.

Источник: https://www.securitylab.ru/news/566987.php

В Avast нашли критическую уязвимость: эксплойт даёт права SYSTEM

Исследователи из SAFA сообщили о серьёзной уязвимости в антивирусе Avast: драйвер aswSnx.sys содержит сразу четыре бага, объединённых под номером CVE-2025-13032. Брешь затрагивает версии программы до 25.3 на Windows. Проблема позволяет локальному злоумышленнику получить права SYSTEM, что делает историю особенно неприятной. Необычный нюанс: чтобы добраться до уязвимого кода, атакующему нужно не вырваться из песочницы, как обычно, а наоборот — попасть в неё. Внутренний механизм Avast допускает работу с рядом IOCTL-команд только для «особенных» процессов, и именно это ограничение исследователи смогли обойти, зарегистрировав собственный исполняемый файл в качестве одного из компонентов песочницы. SAFA выбрали Avast для анализа из-за его популярности и богатого набора пользовательских интерфейсов в защитных драйверах. Особое внимание они уделили компонентам, обрабатывающим данные из пользовательского режима. Драйвер aswSnx оказался подходящей целью: множество IOCTL-обработчиков с очень мягкими ACL и знакомые паттерны работы со строками и структурами.
Ручной аудит вскрыл ключевую проблему: двойное считывание пользовательских структур UNICODE_STRING. Значение длины строки сначала использовалось для выделения памяти, а затем считывалось повторно — что позволяло изменить его между двумя операциями и добиться контролируемого переполнения буфера. Аналогичные ошибки затрагивали и другие поля, включая pString и pData, причём часть указателей никак не проверялась, что приводило к отказу в обслуживании. По ходу анализа всплыли и дополнительные уязвимости: повторяющиеся двойные проходы по строкам для определения размера, неверное использование snprintf при завершении процесса, а также отдельный вариант проблемы с pData, где длина и копирование снова расходились.
В версии 25.3 Avast закрыла найденные дыры: драйвер теперь корректно копирует пользовательские структуры в память ядра, повторно использует исходные длины, проверяет размеры буферов и валидирует указатели. Уязвимость получила 9,9 балла из 10 по CVSS, что неудивительно: для эксплуатации нужны минимальные права, а результатом может стать полный контроль над системой. Эксплойт SAFA успешно заработал на Windows 11, так что компаниям стоит обновиться как можно скорее, ограничивать локальные права и следить за подозрительными попытками повышения привилегий. История снова напоминает: даже защитные продукты могут содержать опасные ошибки в коде ядра.

Источник: https://www.anti-malware.ru/news/2025-12-08-111332/48323