🖱 Кликбейтный заголовок, чтоб тыкнул каждый пентестер

Даа, именно для пентестеров, и снова не для аппсеков. Когда-нибудь, ребят, когда-нибудь. 🙂

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

Что от вас нужно, чтобы попасть в историю:
🟢 В первую очередь — Вы;
🟢 Крутые истории успехов или не менее яркие провалы — за них иногда любят даже сильнее, так что не стесняйтесь;
🟢 Курьёзы, факапы и истории, которые уже давно пора рассказать не только коллегам в курилке.

📌

Самое главное: важны именно ваш подход, идея и креативность. Никто не ждёт от вас полного описания эксплуатации и step-by-step гайдов, оставьте их для отчётов и багбаунти.


Что категорически НЕ нужно делать:
🟣 Разглашать NDA (не стоит лишаться работы ради премии, правда?)
🟣 Делать что-то на грани закона (или за ней).
🟣 И, конечно, никакого блэка во всех его проявлениях. Я серьёзно — даже не думайте 😑.

❔ Зачем всё это затевается

Мероприятие проводится уже в третий раз, и его главная цель — выделить и наградить лучших спецов отрасли, а ещё показать, какой вклад они вносят в развитие пентеста и российского сообщества.

И самое приятное — участие полностью бесплатное. Можно отправлять хоть одну, хоть несколько историй, главное — не тянуть до последнего момента (хотя, кого я обманываю, конечно будете тянуть до 29 июня, сам бы так сделал) Заявка на участие — это всего лишь рассказ о вашем лучшем проекте в свободной форме.

Подать заявку и узнать детали можно здесь — ТЫК

Жду ваших крутых историй и обещаю за вас болеть, даже если вы не аппсек из бигтеха 🤣

Всем хорошего понедельника и удачной недели😇


А я умираю от аллергии

Всем хорошего понедельника и удачной недели😇


А я умираю от аллергии

Обучение appsec-ов
Вечерний #meme

#meme

Ну вот и разгрузка для четверга (почти пятницы)

#meme

Автор предыдущего поста

🔗 ServerMess, или почему serverless — это тихий ужас AppSec-а

ПРЕДУПРЕЖДЕНИЕ

ТЕМА УРОВНЯ /b/

Всем снова привет! Давно я не выносил вам мозг про уязвимости, но, сами понимаете, молчать больше нельзя. Сегодня поговорим о ServerMess — как serverless-архитектуры тихо и незаметно ломают безопасность.


🤯 Что за "ServerMess" вообще такой?

Это такой скрытый хаос, который случается, когда разработчики на радостях пилят десятки Lambda-функций, Azure Functions и Cloud Functions и связывают их через event-driven подход. Сначала выглядит всё красиво: события летят, функции реагируют, разработчики довольны. Но потом наступает утро, и ты понимаешь, что у тебя под капотом полная жесть, а не архитектура. События запускают друг друга, вызывая функции, о которых уже никто не помнит, и весь этот цепной балаган уже никак не контролируется обычными инструментами безопасности.


❌ Что реально сломано (примеры которые я смог найти)

Если интересно, то сделаю про OpenSource решения (Knative, OpenFaaS, Fission)

1️⃣ AWS Lambda + EventBridge

Есть приложение, публикующее события вроде “OrderPlaced” через AWS EventBridge. Лямбды подписываются и радостно реагируют на это событие. Проблема в том, что EventBridge легко может стать открытым для публикации всем подряд. И вот уже злоумышленник с минимальными правами отправляет туда фейковое событие:


{
"Source": "orders.service",
"DetailType": "OrderPlaced",
"Detail": "{ \"orderId\": \"an.mtv\", \"userEmail\": \"attacker@test.local\" }"
}


И понеслось, кто-то шлёт письма не тому, кто-то обновляет статистику фальшивыми заказами, а кто-то (если повезло хакеру) ещё и читает данные из базы.

2️⃣ Azure Functions через Event Grid

В Azure разработчики любят триггеры через Event Grid. Проблема: часто это просто HTTP-вебхуки, которые случайно забывают закрыть ключами или хотя бы SAS-токенами. Злоумышленник спокойно отправляет фейковый запрос на публичную функцию, и вот уже кто-то получает нежелательные письма, а кто-то регистрирует тысячи новых пользователей. В общем, опасность тут настоящая.


❓ Почему классические средства защиты (DAST, SAST, WAF) в пролёте

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

WAF вообще бесполезен, если атака идёт через внутренний канал событий типа SQS или Pub/Sub.

🔍 Как искать такой скрытый трэш

- Включайте Distributed Tracing типа AWS X-Ray или Azure Application Insights, чтобы увидеть, кто и как вызывает ваши функции.
- Используйте инфраструктурные сканеры (Prowler, Checkov, ScoutSuite), чтобы находить открытые топики и очереди.
- Фаззинг событий: берёте свой скриптик и отправляете мутные payload’ы прямо в очереди, смотрите на реакцию ваших функций.

🌐 Как защищаться и спать спокойно

- Каждой функции своя минимальная IAM-роль, никакой общей помойки с * правами.
- Не доверяйте данным из событий по дефолту: строгая валидация схемы и событий.
- Закрывайте триггеры аутентификацией и проверкой источника (хотя бы через HMAC или VPC Service Controls в GCP).
- Настройте мониторинг аномалий в событиях. Если количество вызовов резко возросло — это повод проснуться ночью и проверить, не хакнули ли вас уже.


🌐 Заключение

Serverless — это круто, пока не начинается бардак. Если вы строите свою инфраструктуру на Lambda, Azure или GCP Cloud Functions, то пора посмотреть на неё трезвыми глазами. Иначе в один прекрасный день она сама посмотрит на вас глазами удивлённого безопасника, которого только что взломали через тихий и незаметный Event Injection.


Для ознакомления

Безопасность serverless-приложений – ТЫК (Youtube)
Всё, что вы хотели знать о бессерверных технологиях, но боялись спросить – ТЫК
The Ten Most Critical Risks for Serverless Applications v1.0 – ТЫК
Lock-down OpenFaaS for the public Internet – ТЫК

#appsec

#неmeme

#meme

Вот вам и менее трагичное

🛠IngressNightmare или как снова что-то нашли

Всем привет, и да, я снова тут с постом, который никто особо не ждал, ведь выше есть пост, но пройти мимо такой темы я не смог. Сегодня расскажу более подробно про свежий и крайне неприятный инцидент в Kubernetes-мире.

❓Что стряслось и почему все в панике

Короче, ребята из Wiz недавно нашли серию критических уязвимостей в контроллере Ingress-NGINX для Kubernetes. Назвали это всё красиво и драматично – IngressNightmare. И поверьте, название выбрали неспроста: если коротко, то это пять CVE, из-за которых атакующий может спокойно выполнить код на ingress-контроллере и буквально угнать весь кластер со всеми секретами. И самое весёлое, что атакующему даже не нужны учётные записи или пароли, хватит одного кривого HTTP-запроса.

🔍 Технические подробности для тех, кто любит копаться в кишках

Суть этих уязвимостей кроется в недостаточной проверке входящих данных, которые разработчики Ingress-NGINX радостно вставляли напрямую в конфиги NGINX. Из-за этого через безобидные, казалось бы, аннотации (auth-url, auth-tls-match-cn, mirror-target) можно было внедрить произвольные директивы. Ну, например, какую-нибудь такую прелесть:

ssl_engine /tmp/malicious.so;


Именно это использовали исследователи Wiz в своём PoC. Ты просто отправляешь HTTP-запрос с большим телом, NGINX сохраняет это тело как временный файл, а потом через специальный AdmissionReview-запрос (без аутентификации!) загружает твою вредоносную .so библиотеку. И всё, поздравляю, теперь ты внутри контейнера с контроллером. Дальше читаешь секреты, токены и вообще делаешь, что хочешь.

‼️ Кто в опасности и как проверить себя любимого

Если ваша версия Ingress-NGINX ниже v1.12.1 (а ещё 1.11.5 и 1.10.7), то у вас серьёзные проблемы:
🔵 Узнать текущую версию можно через:

kubectl -n ingress-nginx get deploy ingress-nginx-controller -o=jsonpath='{.spec.template.spec.containers[0].image}'


🔵 Или через GitLab, найдя в манифестах YAML или Helm-чартах строку:

image: ingress-nginx/controller:v1.12.0


❔ Как с этим жить дальше

Что делать, если вы попали в этот клуб неудачников с уязвимой версией:

1. Срочно обновляйтесь до v1.12.1;

2. Пока не обновились, отключите admission-контроллер (controller.admissionWebhooks.enabled=false);

3. Ограничьте доступ к admission webhook с помощью Network Policy. Только API-сервер должен туда стучаться;

4. Просмотрите audit-логи Kubernetes и ищите подозрительные Ingress’ы с странными аннотациями.

Если вы не можете обновиться сразу (а кто из нас может?), хотя бы проверьте, что webhook не светит в интернет. В Wiz уже подсчитали, что около 6500 кластеров с открытым admission webhook доступны снаружи. Возможно, среди них есть и ваш.

👀 Личное мнение и мораль сей басни

Вот казалось бы, мелочь – не проверить пару строк кода, не закрыть пару портов, но в итоге получаешь катастрофу, достойную отдельного поста в моём канале. В очередной раз понимаешь, насколько всё хрупко и насколько важна роль команд AppSec и DevSecOps в крупных компаниях. В общем, проверьте свои кластеры, обновитесь и берегите нервы, они вам ещё пригодятся.

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

#devsecops #appsec

⚙️ IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX

Wiz Research обнаружила CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 и CVE-2025-1974, серию RCE в контроллере Ingress NGINX для Kubernetes, получившем название IngressNightmare. Использование этих уязвимостей приводит к несанкционированному доступу злоумышленников к чувствительным данным, хранящимся во всех namespace'ах кластера Kubernetes, что может привести к его захвату.

Nuclei шаблон для проверки:

id: exposed-ingress-nginx-admission

info:
name: Publicly exposed Ingress NGINX Admission
author: Wiz research
severity: high
description: Ingress Nginx admission controller endpoint should not be exposed
metadata:
max-request: 1
tags: ssl,tls

ssl:
- address: "{{Host}}:{{Port}}"

matchers:
- type: dsl
dsl:
- 'contains(issuer_org, "nil1")'
- 'contains(subject_org, "nil2")'
- 'contains(subject_an, "nginx")'
condition: and

extractors:
- type: json
name: issuer_org
json:
- ".issuer_org[0]"

- type: json
name: subject_org
json:
- ".subject_org[0]"

- type: json
name: subject_an
json:
- ".subject_an[0]"

Подробнее (на англ.)

➡️ Research

#nginx #ingress #cve

✈️ Pentest HaT

🌐 Service Mesh Security

🔗 Service Mesh — это умный посредник между микросервисами, который управляет их взаимодействием, маршрутизацией трафика и безопасностью. Он добавляет шифрование, балансировку нагрузки и политику доступа, не требуя изменений в самих сервисах. Без него каждая команда разрабатывает свои костыли для этих задач, что быстро превращается в хаос.

Когда погружаешься в Service Mesh, кажется, что это волшебная штука, которая решает все проблемы. Но потом вспоминаешь, что безопасность сама себя не настроит, а уязвимости появляются там, где их меньше всего ждёшь.

В статье разобрал всё это подробнее:
🔵Какие ошибки в безопасности Service Mesh встречаются чаще всего;
🔵Как атакуют Istio и Linkerd, и почему mTLS — не панацея;
🔵Какие практики реально работают, а какие просто звучат красиво.

✏️С примерами, кейсами и полезными ссылками, чтобы не наступать на чужие грабли.

❤️Спасибо всем, кто помогал материалами, вопросами и обсуждениями! Хотел добавить мемы, но Service Mesh — та штука, где смеяться начинаешь только после того, как настроил правильно(Мне было просто лень)

Статья в Teletype – Service Mesh в дикой природе или как не стать жертвой атак
Статья на HABR – Service Mesh в дикой природе или как не стать жертвой атак

#blueteam #appsec

#meme

Я тебе не верю! JWT, JWS, JWE и Zero Trust

С ростом сложности распределённых систем и микросервисов обеспечение безопасности обмена данными становится не просто задачей, а ключевым условием существования современных приложений. JWT, являясь уже стандартом передачи идентификационных и авторизационных данных, требует глубокого понимания тонкостей своей реализации в первую очередь безопасниками. Особенно это касается применения JWS, JWE и интеграции принципов архитектуры/философии Zero Trust.

JWT – JSON Web Token
JWS – JSON Web Signature
JWE – JSON Web Encryption

✏️ Подпись и целостность токенов

JWS предназначен для защиты целостности и подтверждения подлинности JWT. Важно отметить, что подпись JWS не шифрует содержимое токена, а лишь предотвращает его модификацию.

Основные алгоритмы, применяемые в JWS:
🔵 RS256 (RSA Signature с SHA-256)
🔵 ES256 (ECDSA Signature с SHA-256)

На что стоит обратить внимание при проверке JWS:
🔵 Алгоритм подписи;
🔵 Валидность публичного ключа;
🔵 Корректная валидация всех полей claims (aud, iss, exp и др.).

Частая ошибка, которую допускают разработчики - отсутствие проверки используемого алгоритма, что может привести к атакам типа "none algorithm" или подмене алгоритма подписи.

Пример:

token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
return publicKey, nil
})


🌐 Шифрование чувствительных данных

В отличие от JWS, JWE предназначен для защиты конфиденциальности данных внутри JWT. Использование JWE позволяет гарантировать, что только владелец приватного ключа сможет прочитать данные токена.

При реализации JWE важно обеспечить:
🟢 Надежное управление ключами;
🟢 Правильный выбор алгоритмов (например, RSA-OAEP и AES-GCM);
🟢 Отсутствие утечек ключей и материалов шифрования в логах или памяти.

👮‍♀️ Zero Trust и JWT

Zero Trust требует, чтобы каждый запрос проверялся независимо, не доверяя никаким промежуточным слоям. JWT идеально вписывается в эту модель при некоторых условиях:
🟢 Независимой проверки JWT каждым микросервисом;
🟢 Минимального lifetime токенов;
🟢 Глубокой валидации всех claims и строгой политики доступа.

А в ваших микросервисах всё так ?)

«Безопасность — не продукт, а процесс»

Наверное, одно из моих любимых выражений, которую не понимают многие люди из ИБ

❔ Уязвимый фрагмент кода для анализа

Как я и говорил, что немного меняю подход к обучающим постам, теперь в каждом из них будет идти код с ошибкой (Я могу и сам ошибиться в ошибке, не серчайте 🤪).

Так вот, что тут не так и где беда?


func ValidateToken(tokenString string, publicKey *rsa.PublicKey) (*jwt.Token, error) {
token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
return nil, fmt.Errorf("Неожиданный алгоритм подписи: %v", token.Header["alg"])
}
return publicKey, nil
})
if err != nil {
return nil, err
}
return token, nil
}


Телеграмм не позволяет делить открытие скрытого текста, поэтому ответ будет отправлен спустя 1 день.

Также мне нужна обратная связь по ЯП. Я умею в Go, Python, немного в Java и JS. Вы не будте против, если при коде на других языках, Вас будет проверять ИИ?

Подсказка:
Обрати внимание на то, что код проверяет только тип алгоритма, но не конкретный алгоритм и не проверяет claims. Почему это может быть критично?

❕ Заключение и краткие рекомендации

Для повышения безопасности JWT необходимо:
🟢 Всегда явно проверять указанный алгоритм подписи (например, RS256);
🟢 Обязательно проверять и валидировать все критически важные claims (iss, aud, exp);
🟢 Использовать JWE для защиты чувствительных данных внутри JWT;
🟢 Следовать Zero Trust модели с обязательной независимой валидацией JWT каждым сервисом.

В заключение мне хочется сказать, что тема JWT стала основным, что я спрашиваю у людей на собеседовании, потому что это БАЗА, которую нужно знать.

#appsec

Монолог, о котором никто не просил

И вот я снова на связи. За эти долгие пару месяцев молчания в моей рабочей и личной жизни произошло очень многое. И да, разделил я это не случайно, ведь у всех нас уже как минимум по две личности. Одна ходит на работу и улыбается коллегам, а вторая, приходя домой, пытается забыться и отдохнуть. Напоминает сериал «Разделение», только с менее мрачным антуражем. И нет, мне правда нравится моя работа и коллеги, особенно то, как мы строим нашу маленькую безопасность в большой компании. (В момент написания поста я тоже работаю, просто мой инструмент тестируется.)

Никогда не умел в предисловия, но я постараюсь научиться, а пока получайте дозу серого настроения, которое у меня получается передавать идеально.

Что меня сподвигло написать этот пост? Понимание того, что канал стоит и не приносит эмоций читателям. Статей нет, мемов нет, изредка что-то появляется, но души будто уже нет. Вот это меня и стало пугать. А что делать в таких ситуациях, я не знаю. Просто «пусть будет и лежит» мне не нравится. Поэтому вы сейчас и читаете мои бредни.

Это мой маленький монолог, чтобы снова начать писать на канал. Тут будут наши успехи и неудачи, не судите строго.

🔵 Глава 1. Личное

Что ж, у меня всё хорошо. (Тут можно было бы и закончить про личное, но мне очень нравится рассказывать истории.) Да, после всех трудностей и невзгод я заново учусь получать удовольствие от того, что просто хожу по улице, еду в такси или читаю чаты. Это довольно сложно, когда имеешь такое реалистичное видение жизни и воспринимаешь всё как задачу, которую нужно решить, причем как можно скорее. Из особых успехов хочу отметить, что Сырнику уже годик, и он самое сладкое, что было у меня в жизни. Позже, может, сделаю подборку его фоток, он правда вам понравится.

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

Главное в моей сфере деятельности — отдых. Многие с этим готовы поспорить, но мне пофиг на их мнение. Я своё навоевал, заработав очень неприятные последствия, с которыми до сих пор разбираюсь. Так что моё спасение — сон, мероприятия, концерты и игры.

Маленькое обращение

Дорогая команда Яндекса, я знаю, что вы это читаете. Дайте ответ на заявку мне и @ArtyDM. Нужно же понимать, чем нам заниматься этим вечером, чтобы строить планы.

Кто считает это наглостью — я просто пользуюсь медийностью, хоть чем-то канал мне помог (помимо благотворительности).

🔵 Глава 2. Развитие

Ну, тут тоже не так густо. Я подал заявку на участие в PHDAYS, надеюсь, получится рассказать немного про наш DAST. Над названием я долго думал, но остановился на «Оркестрация тестирования в стиле DASTоевского». Считаю себя креативным ибэшником 🤣.

Также начал изучать ML-ки: как это работает, как разворачивать, защищать и атаковать 😪. Это достаточно интересно, но требует очень много времени, которого постоянно не хватает. Пока на этапе MlOps, но до Sec уже не так далеко 🙂

🔵 Глава 3. Работа

Ух, я бы тут разгулялся, но чувствую вину перед вами за отсутствие постов про наши достижения и начинания. Не побоюсь назвать это первым открытым процессом, который тоже протух, ведь мало кому было интересно это читать. Я его возобновлю, даю слово, но мне нужна от вас обратная связь, как это улучшить и сделать «лучшим повествованием». Просто аналогов я так и не увидел за эти полгода — у вас были все шансы занять моё место.

Наш DAST в финальной форме, сейчас работаю над развёрткой и управлением. Оказалось, инфраструктура крупной компании накладывает много ограничений. Но с другой стороны, это правильно — больше безопасности.

Работа с нашими коллегами из SecurityGate перешла на этап, когда мы уже внесли вклад в продукт. Я этим горжусь, хоть сам наделал много косяков, которые теперь стали именем нарицательным.

Заключение

Меня отговорили от удаления канала, поэтому я начну потихоньку писать про лёгкие темы, а дальше видно будет...

#бредни_автора

🔹VK Security Confab #3: всё о Bug Bounty

27 февраля в московском офисе 💙 встречаемся на митапе VK Security Confab. В этот раз обсудим секреты и подводные камни Bug Bounty, техники поиска, инструменты и найденные уязвимости.

Программа митапа уже на сайте, а вот небольшой спойлер:

🔵Петр Уваров поделится планами VK Bug Bounty в 2025 году.

🔵Алексей Лямкин расскажет, как устроен триаж изнутри.

🔵Анна Куренова (SavAnna) поделится мнением, почему дубликат — это не проклятие, а ценный урок.

🔵Юрий Ряднина (circuit) покажет дисклозы нескольких уязвимостей ВКонтакте.

🔵Алексей Жучков (zerodivisi0n) продемонстрирует реальные кейсы, которые могут привести к удаленному исполнению кода.

И конечно, афтепати! 🔹
Обсудим доклады, обменяемся идеями и классно проведем время.

🔹 Скорее регистрируйтесь!
Встреча пройдет только офлайн, онлайн-трансляции и записи не будет.

🔹 Сбор гостей в 18:30, начало — в 19:00.

VK Security

#митап #confab #bugbounty

Новые CVE: что можно найти в Next.js

Разбираем вместе с Андреем Матвеенко из команды AppSec (ВКонтакте) и автором канала Blue (h/c)at Café нашумевшую и легкоэксплуатируемую уязвимость в Next.js.

Недавно в команде мы столкнулись с интересной ситуацией, связанной с неожиданным поведением механизма кеширования в Next.js. Это натолкнуло на мысль, что при определённых условиях можно добиться некорректной обработки пользовательских данных, что открывает путь для нестандартных атак — отравление кеша или внедрение нежелательного содержимого. Мы начали изучать материалы из открытых источников, а также проверять все наши внутренние сервисы на наличие проблемы. Рассказываю здесь, что мы нашли, как это можно проэксплуатировать и как защититься.

Next.js использует два механизма для работы с данными: SSG (Static Site Generation) и SSR (Server-Side Rendering). SSG генерирует страницы на этапе сборки, которые потом кешируются CDN с использованием заголовков вроде Cache-Control: s-maxage=31536000, stale-while-revalidate.

В отличие от SSG, SSR динамически создает контент на основе запроса пользователя и предполагает строгий контроль за кешированием ( Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate ).

🔹 Proof of Concept (PoC)

Уязвимость позволяет обмануть сервер, заставив его воспринимать SSR-запросы как SSG. Это достигается путем добавления параметра __nextDataReq и заголовка x-now-route-matches. Например, следующий запрос к уязвимому серверу изменяет правила кеширования:

GET /poc?__nextDataReq=1 HTTP/1.1
Host: localhost:8080
x-now-route-matches: 1
Cache-Control: s-maxage=1, stale-while-revalidate


После этого сервер начинает кешировать динамические данные, которые изначально не предназначались для кеша. Это может привести к отравлению кеша, когда пользователи начинают получать неверные данные. Более того, если сервер отражает данные из запроса, это открывает возможности для Stored XSS. Условный злоумышленник может отправить запрос с вредоносным кодом в заголовке, например:

GET /poc?__nextDataReq=1 HTTP/1.1
Host: localhost:8080
User-Agent:
x-now-route-matches: 1

После выполнения такого запроса вредоносный код будет сохранен в кеше и сработает при каждом посещении страницы.
Ссылка на PoC — тут.

Последствия эксплуатации:

🔹 DoS (Denial of Service)
🔹 Stored XSS
🔹 Утечка данных

Рекомендации по защите

1️⃣ Обновление Next.js до версии ≥ 14.2.10* (UPD)

2️⃣ На уровне приложения или CDN удаляйте все заголовки, которые не были указаны в спеке:

delete req.headers['x-now-route-matches'];


3️⃣ Убедитесь, что сервер использует строгие правила кеширования для SSR:

res.setHeader('Cache-Control', 'private, no-cache, no-store, max-age=0, must-revalidate');

VK Security

#appsec #эксперты #cve #разбор

Новые CVE: что можно найти в Next.js

Разбираем вместе с Андреем Матвеенко из команды AppSec (ВКонтакте) и автором канала Blue (h/c)at Café нашумевшую и легкоэксплуатируемую уязвимость в Next.js.

Недавно в команде мы столкнулись с интересной ситуацией, связанной с неожиданным поведением механизма кеширования в Next.js. Это натолкнуло на мысль, что при определённых условиях можно добиться некорректной обработки пользовательских данных, что открывает путь для нестандартных атак — отравление кеша или внедрение нежелательного содержимого. Мы начали изучать материалы из открытых источников, а также проверять все наши внутренние сервисы на наличие проблемы. Рассказываю здесь, что мы нашли, как это можно проэксплуатировать и как защититься.

Next.js использует два механизма для работы с данными: SSG (Static Site Generation) и SSR (Server-Side Rendering). SSG генерирует страницы на этапе сборки, которые потом кешируются CDN с использованием заголовков вроде Cache-Control: s-maxage=31536000, stale-while-revalidate.

В отличие от SSG, SSR динамически создает контент на основе запроса пользователя и предполагает строгий контроль за кешированием ( Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate ).

🔹 Proof of Concept (PoC)

Уязвимость позволяет обмануть сервер, заставив его воспринимать SSR-запросы как SSG. Это достигается путем добавления параметра __nextDataReq и заголовка x-now-route-matches. Например, следующий запрос к уязвимому серверу изменяет правила кеширования:

GET /poc?__nextDataReq=1 HTTP/1.1
Host: localhost:8080
x-now-route-matches: 1
Cache-Control: s-maxage=1, stale-while-revalidate


После этого сервер начинает кешировать динамические данные, которые изначально не предназначались для кеша. Это может привести к отравлению кеша, когда пользователи начинают получать неверные данные. Более того, если сервер отражает данные из запроса, это открывает возможности для Stored XSS. Условный злоумышленник может отправить запрос с вредоносным кодом в заголовке, например:

GET /poc?__nextDataReq=1 HTTP/1.1
Host: localhost:8080
User-Agent:
x-now-route-matches: 1

После выполнения такого запроса вредоносный код будет сохранен в кеше и сработает при каждом посещении страницы.
Ссылка на PoC — тут.

Последствия эксплуатации:

🔹 DoS (Denial of Service)
🔹 Stored XSS
🔹 Утечка данных

Рекомендации по защите

1️⃣ Обновление Next.js до версии ≥ 14.2.9

2️⃣ На уровне приложения или CDN удаляйте все заголовки, которые не были указаны в спеке:

delete req.headers['x-now-route-matches'];


3️⃣ Убедитесь, что сервер использует строгие правила кеширования для SSR:

res.setHeader('Cache-Control', 'private, no-cache, no-store, max-age=0, must-revalidate');

VK Security

#appsec #эксперты #cve #разбор

В этом посте я рассказал про уязвимость в Next.js, которая на первый взгляд выглядит как небольшой баг в кешировании, но на деле может превратиться в серьезную проблему, способную привести к неожиданным последствиям 😏.

Тут могла бы быть интересная история, но это останется секретом)

Суть в том, что можно обмануть сервер и заставить его кешировать динамические страницы так, будто это статический контент. Если злоумышленник подменит данные, они останутся в кеше и будут раздаваться пользователям. Это открывает путь для Stored XSS, DoS и утечки данных. Мы привыкли считать кеш полезным инструментом для ускорения работы сайта, но если его неправильно настроить, он превращается в оружие.

Если у вас в проектах используется Next.js — советую проверить, не уязвим ли ваш сервис для этого я приложил PoC.

Источники для изучения
https://security.snyk.io/vuln/SNYK-JS-NEXT-8025427
https://github.com/advisories/GHSA-gp8f-8m3g-qvj9
https://github.com/vercel/next.js/security/advisories/GHSA-gp8f-8m3g-qvj9
https://zhero-web-sec.github.io/research-and-things/nextjs-cache-and-chains-the-stale-elixir
https://vulert.com/vuln-db/CVE-2024-46982

#meme