На этой неделе в разделе безопасность: Виброкодирование, блокировка маршрутизатора и удаленные динамические зависимости
Виброкодирование. Что может пойти не так? Это то, что заинтересовало [Кевина Джоенсена] из Baldur, и, чтобы выяснить это, он попросил Anthropic Sonnet 4. 5 создать безопасный логин с двухфакторной аутентификацией (2FA). И, к чести LLM, он создает приложение в соответствии с запросами. [Кевин] заглянул под капот, чтобы посмотреть, насколько хорошо была обеспечена безопасность, и это было не очень здорово.
Во-первых, приложение Flask не имеет никаких ограничений по скорости угадывания этого временного кода 2FA. 6-значный 2FA, основанный на времени, работает только в том случае, если вы не можете испробовать все возможности до истечения срока действия данного кода. Итак, что же делает виброкодер, когда это замечено? Конечно, попросите LLM исправить это. Здесь мы используем несколько иной подход, предлагая ИИ перепроверить свою работу: “Отсутствуют ли какие-либо функции безопасности на этапе проверки 2fa?” Ответ впечатляет:
Отличный вопрос! Да, на этапе проверки 2FA отсутствует несколько важных функций безопасности. Позвольте мне выделить наиболее важные из них: Критические проблемы с безопасностью 1. Нет ограничения скорости (НАИБОЛЕЕ КРИТИЧНЫЕ)
Но главный вопрос: может ли он правильно исправить свою ошибку? Искусственный интеллект добавляет библиотеку flask-limiter и выбирает 10 попыток в минуту, что немного непоследовательно, но не лишено смысла. Все еще остается проблема, связанная с тем, что эти попытки ограничены IP-адресом, а не логином пользователя. Все, что требуется для обхода этого ограничения скорости, — это пул IP-адресов.
Этот эксперимент начинает сходить с рельсов, поскольку [Кевин] продолжает побуждать LLM искать новые проблемы в своем коде, и он начинает галлюцинировать об уязвимостях, не устраняя при этом реальную проблему. Магистры не способны писать безопасный код, даже если они придерживаются его вручную.
Но, конечно, проблема, связанная с ошибками в системе безопасности, которые допускают магистры, не является реальной проблемой, не так ли? Верно? Исследователи из Escape провели обзор 5600 веб-приложений с vibecoded и обнаружили 2000 уязвимостей. Обратите внимание на Vibetor.
“Безопасный” Анклав
Несколько недель назад мы рассказывали об атаках с использованием тарана и перехвата телефонных разговоров на доверенные среды выполнения (TEES). Эти две атаки нанесли ущерб надежным вычислительным технологиям, но были ограничены памятью DDR4. Теперь мы возвращаемся к TEE-fail, аналогичной атаке, которая работает против систем DDR5.
Это напоминание о том, что очень немногие решения для обеспечения безопасности способны противостоять целенаправленной атаке с использованием физического доступа. Решения Intel, AMD и Nvidia TEE явно неэффективны против такого физического доступа. Проблема в том, что никто, похоже, не обращал внимания на эту часть документации, а различные компании, от Cloudflare до Signal, неправильно использовали эту деталь в своем маркетинге.
Запрет TP-Link
Появились новости о том, что правительство США рассматривает возможность запрета продажи нового сетевого оборудования TP-Link, называя эти устройства угрозой национальной безопасности.
У меня есть опыт работы с TP-Link оборудование: Несколько лет назад я установил десятки Wi-Fi-маршрутизаторов TL-WR841 на предприятиях малого бизнеса, когда они перешли с DSL на кабельный интернет. Даже тогда я не доверял прошивке, которая поставлялась на этих маршрутизаторах, но перед установкой прошил OpenWRT на каждый из них. Интересный факт: если вы заглянете достаточно далеко в прошлое, то сможете найти мои электронные письма в списке рассылки OpenWRT, посвященные тестированию и даже написанию поддержки OpenWRT для новых версий оборудования TP-Link. Исходя из этого опыта, я могу сказать вам, что в TP-Link нет ничего особенного. У них ужасная прошивка, как и у любого другого производителя встраиваемых устройств. Некоторое время вы могли запускать произвольный код на устройствах TP-Link, помещая его в backticks при присвоении имени сети Wi-Fi. Это не было намеренным бэкдором, это был просто небрежный код. Я вполне уверен, что это наблюдение по-прежнему справедливо. TP-Link не является вредоносным ПО, но у их продуктов все еще есть проблемы с безопасностью. И на данный момент они являются крупнейшим поставщиком дешевого сетевого оборудования китайского производства. Иными словами, они находятся в центре внимания благодаря собственному успеху.
Здесь важно отметить еще один момент. Несмотря на то, что TP-Link Systems — американская компания, в Китае по-прежнему работают значительные инженерные подразделения. На TP-Link могут распространяться требования законодательства о безопасности сетевых продуктов, касающиеся отчетности. Проще говоря, этот закон требует, чтобы при обнаружении уязвимостей компании раскрывали информацию конкретному государственному учреждению Китая. Представляется вероятным, что это является главной причиной беспокойства регулирующих органов США, поскольку лица, представляющие угрозу, сотрудничающие с правительством Китая, заблаговременно узнают об этих недостатках. Предлагаемый запрет все еще находится на стадии разработки, и никаких действий по нему пока не предпринято.
Sandbox Escape
В марте появился интересный эксплойт в один клик, который был запущен с помощью фишинговых ссылок в электронных письмах. Исследователям из Лаборатории Касперского удалось получить копию цепочки вредоносных программ и обнаружить используемую уязвимость в Chrome. И оказалось, что это связано с довольно новой проблемой. В Windows есть пара API-интерфейсов для получения дескрипторов для текущего потока и процесса, и у них есть встроенная функция повышения производительности: вместо возврата полного дескриптора они могут возвращать -1 для текущего процесса и -2 для текущего потока.
Теперь, когда изолированный код пытается использовать этот псевдо-дескриптор, Chrome проверяет значение -1, но никаких других специальных значений нет, что означает, что изолированный код может вызвать дескриптор локального потока, что позволяет запуск гаджетов с кодом и запуск кода вне изолированной среды. Google выпустила исправление для этой конкретной проблемы, и вскоре после этого Firefox был исправлен для решения той же проблемы.
NPM и удаленные динамические зависимости
Кажется, не проходит и недели, чтобы мы не говорили об очередной проблеме NPM. На этот раз это новый способ проникновения вредоносного ПО в хранилище, в виде удаленных динамических зависимостей (RDD). В некотором смысле, этот термин применим ко всем зависимостям NPM, но в данном случае он относится к зависимостям, размещенным где-то еще в Интернете. И в этом вся загвоздка. NPM может просматривать пакет, но не делает ничего вредоносного. И когда реальные пользователи начинают его скачивать, эти удаленные пакеты динамически заменяются их вредоносными версиями с помощью серверной логики.
Установка одного из этих пакетов заканчивается тем, что скрипт собирает все данные, которые может, и передает их злоумышленнику’система командования и контроля. Хотя официального ответа от NPM пока нет, кажется неизбежным, что пакетам NPM будет запрещено использовать эти произвольные зависимости HTTP/HTTPS. В Koi доступны некоторые индикаторы компрометации.
Биты и байты
Десериализация Python с помощью Pickle всегда была немного пугающей. Несколько раз мы рассматривали уязвимости, которые коренятся именно в этом типе небезопасной десериализации. Существует новый подход, который, возможно, позволит обеспечить более безопасную обработку рассола, но на данный момент он остается открытым для общественности. Его можно рассматривать как аудит в режиме реального времени на предмет обнаружения чего-либо небезопасного во время десериализации. Он еще не готов к показу в прайм-тайм, но приятно видеть здесь нестандартное мышление.
Возможно, это первый раз, когда я сталкиваюсь с удаленным эксплойтом через страницу 404. Но в этом случае 404 содержит запрошенную страницу, и внутренний код, который вводит эту строку на страницу 404, уязвим для внедрения XML. Хотя такой подход напрямую не позволяет выполнять код, он может привести к утечке данных и подделке запросов на стороне сервера. И, наконец, произошла небольшая утечка информации, которая может содержать информацию о том, какие мобильные устройства Cellebrite toolkit может успешно скомпрометировать. История такова, что [мошенник] пробрался на совещание команд, чтобы подслушать и сделать скриншоты. Настоящим сюрпризом здесь является то, что GrapheneOS более устойчив к Cellebrite toolkit, чем даже стандартные прошивки для таких телефонов, как Pixel 9. К этой утечке следует отнестись с большой долей скептицизма, но она может оказаться обоснованной.
Другие статьи: