Есть такая штука nextjs, несколько месяцев назад они добавили новую "фишку" распределение нагрузки - под капотом поднимается несколько микросервисов. Каждый из которых занимается своей частью обработки запроса. Работает все примерно так-же как и обычный прокси сервер, запрос приходит, обрабатывается, и через стороннюю библиотеку проксируется на другой порт.
Собственно именно это место нас и интересует.

В HTTP есть такой метод PRI (используются, если мне не изменяет память, чтобы проверить возможность HTTP/2 подключения). Нас интересует что запросы этого метода имеют cимвол * в пути, вместо привычного /.

PRI * HTTP/1.1.

Далее, все http-парcеры работают по разному, у nodejs он немного особенный, и url вида https://example.com:3456*@127.0.0.1:8080 будет разобран как:

hostname: 127.0.0.1, 
port: 8080, 
auth: example.com:3456*,

А самое важное тут то, что http-парсер nodejs считает валидными запросы вида:

GET *@127.0.0.1/ HTTP/1.1
Host: somehost

А знаете кто еще так делает - haproxy!

Ну и последнее: код который формирует url для проксирования внутрь nextjs выглядит так:

const targetUrl = `https://${
  targetHost === 'localhost' ? '127.0.0.1' : targetHost
}:${routerPort}${pathname}`

Собственно, т.к. мы контролируем pathname - мы можем отправить запрос вида:

GET *@127.0.0.1:11211 HTTP/1.1
Host: some

и запрос уйдет напрямую в memcached, получаем SSRF.
Но что более важное - это SSRF с возможностью чтения ответа: если внутри, в инфре, есть приватная веб-морда, мы можем спокойно обращаться к ней, как будь то бы она торчит наружу.

Уязвимые версии:
>= 13.3.0 | <=13.4.12
фича проксирования включена по умолчанию, она так же включается если установлен флаг appDir: true в конфигурации experimental.


Из интересного: vercel отказал в CVE, так как не считает что это уязвимость (на момент репорта уязвимость воспроизводилась в последних версиях). Однако с версии 13.4.13 изменили код. Теперь в части внутренних запросов используется fetch. Что дает некоторую защиту, т.к. fetch не принимает запросы содержащие авторизацию.

>

Доступ в двойную кавычку
Подключи подписку - и получи доступ к контенту раньше, чем будет его публикация, к щепотке уникального контента и чату без цензуры.
Твой вклад помогает развивать этот канал и делать его лучше 💣

#OpenAPI #Swagger

Короч, в extentions для burp suite есть OpenAPI Parser, это штука, которая позволяет брать всякие swagger.json, превращать их в запросы, сканить и вот это все.
Какая с ним проблема. Он не умеет работать с третьей спекой. Валится и все тут.

Выход - сконвертировать в OAS 2.0
У меня был огромный swagger и классический editor.swagger.io не смог его прожувать и вкладка зависала.
Но есть замечательный API Spec Converter, суем в него спеку 3 версии, конвертим в 2, загружаем в burp.

Единственное, в json надо добавить

  "host": "api.someshit.io",
  "basePath": "/",
  "schemes": [
    "https",
    "http"
  ],

после info в файле, и спарсится все отлично.

>

#firebase

Короч. Встречали firebase на страницах? Обычно это подключение js-ника и конфиг вида

firebase.initializeApp({
  apiKey: "VHkgcGlkb3IpMDAwKSkpKSkpKSk=",
  authDomain: "blablabla"
  ...
});

Иногда это используется для заявок, фидбэков и вот этого всего. И если его неправильно готовят, то на нем можно зарегистрироваться через signupNewUser (тыц) и получить доступ к данным, которые собирали сотрудники (в моем случае это было через Firestore).

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

Еще надо попробовать pyfireconnect и python-firebase

Savik поресерчил эту тему и сделал скрипт, который проверяет что доступно по данным Firebase.
Если есть api_key и project_id, то уже можно тыкаться по Realtime Database, Firestore, Storage.

>

Короч, чтоб тебя всякие shodan, censys и прочие умники не сканировали, а еще и не попадать под их поисковую выдачу, рекомендую такой дефолтный конфиг для nginx:

server {
listen 80 default_server;
listen 443 ssl http2 default_server;

# Если есть IPv6
listen [::]:80 default_server;
listen [::]:443 ssl http2 default_server;

ssl_reject_handshake on;

server_name _;

location / {
return 444;
}
}


Че тут делаем?
Слушаем 80 и 443 на ipv4 и ipv6.
Для 443 откланяем все операции SSL handshake, если имя сервера отлично от тех, что есть в других конфигах.
И если соединение установить удалось (и для 80 порта) - рвем его (ответ 444 обладает такой фичей).

>

В дискуссии спросили, ну чего опасного в том, что есть XSS на поддомене без юзеров. Допустим, есть у нас site.kek, а ты нашел уязвимость на subdomain.site.kek

Что может дать XSS на поддомене, где обычный одностраничный лэндинг, нет никаких данных пользователя?

Штош, импакт такой:

- Не только лишь все знают, что поддомен может ставить куки, в том числе на главный сайт (а точнее на весь скоуп, включая другие поддомены), а это может помочь при эксплуатировании других атак, например фиксацию сессии. Или вспомнить про отказ в обслуживании aka cookie bomb

- CORS на других сайтах компании, в том числе сам site.kek может принимать Origin: subdomain.site.kek, а это значит можно выполнять действия от лица пользователя.

- В дополнение к предыдущему - обходится механизм SameSite

- Старый добрый фишинг, если нет дизайна для регистрации или входа - ее можно нарисовать.

Может что-то еще?

>

#OSINT #SSH

Вспомнил тут про старый трюк, можно тестануть:

ssh whoami.filippo.io

Короч, когда ты подключаешься по ssh, твой ssh-agent перебирает всеми ключами, которые у тебя в него подключены.
Это может привести к прикольной деанонимизации, если на стороне сервера включено логирование ssh ключей, которыми пытались подключиться.

Ключики можно собирать как на гитхабе:
https://github.com/Oleg.keys

Так и на гитлабе:
https://gitlab.com/Nikita.keys

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

[1], [2], [3]

>

#owncloud

Для owncloud была классная CVE-2023-49105

Сплоет реализован в качестве прокси, которая подписывает запросы и можно через нее ходить на dav://, используя клиент Filezilla, Cyberduck, короч кто-что юзает.

Сначала ставим ten, запускаем проксю, но не наслаждаемся.

Потому что из коробки сплоет у меня не завелся, клиенты, видимо, не могут корректно распарсить ответ.
А я просто вывел ответ от прокси через print(response.text), и собрал список файлов. Сами файлы можно получать уже через curl/wget/браузер, так как для скачивания файлов достаточно GET запроса.

Типа wget localhost:8800/remote.php/dav/files/admin/Report.7z

Быстро чекнуть уязвимый ли owncloud можно через другую CVE-2023-49103:
/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php/webpwn.css

Если открылся phpinfo() - то, скорее всего, систему не обновляли, а эти CVE'шки вышли рядом.

>

Что опасного в публичном отображении phpinfo?

Сдаешь такой в багбаунти, а тебе говорят, ну где импакт, CVSS 2.6?

А ты такой, ну смотри какой импакт:
- Дает узнать о конфигурации PHP, в том числе о версии, установленных модулях, путях к файлам и т.д. Что поможет эксплуатировать другие уязвимости.
- Раскрывается информация о реальном расположении серверов (если они скрыты за anti-DDOS или CDN)
- Отдельно стоит отметить, что в эпоху этих ваших docker-compose, иногда в нем раскрывается чувствительная информация в переменных окружения (рили видел креды от базы в ENV)
- Помогает эксплуатировать всякие LFI 2 RCE
- Секция с Cookie раскрывает ВСЕ ПЕЧЕНЬЯ, поэтому позволит украсть их, даже если они HTTPOnly

Я что-то забыл?

>