Кавычка

Многие юзают инфу о выданных сертификатах, чтобы узнать поддомены компании, например в crt.sh Но не только лишь все знают, как узнать другие домены одного владельца в ru зоне. Раньше для этого юзал 1stat.ru, но он уже больше как архив, а сейчас использую backorder.ru Эт такой сервис для киберсквоттеров, который позволяет наблюдать за истекшими доменами и их перехватить. Ну и помимо этой функции, доступен расширенный поиск. Короч, вбиваешь условный vk.ru, тыкаешь в значение поля Org, нажимаешь "Все домены". #Osint >

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

#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'шки вышли рядом. >

#OSINT #SSH Вспомнил тут про старый трюк, можно тестануть: ssh whoami.filippo.io Короч, когда ты подключаешься по ssh, твой ssh-agent перебирает всеми ключами, которые у тебя в него подключены. Это может привести к прикольной деанонимизации, если на стороне сервера включено логирование ssh ключей, которыми пытались подключиться. Ключики можно собирать как на гитхабе: https://github.com/Oleg.keys Так и на гитлабе: https://gitlab.com/Nikita.keys Всякие энтузиасты собирают собственные базы забавы ради, думаю есть и те, которые делают это для расследований инцидентов после компрометации и вот этого всего. [1], [2], [3] >

В дискуссии спросили, ну чего опасного в том, что есть XSS на поддомене без юзеров. Допустим, есть у нас site.kek, а ты нашел уязвимость на subdomain.site.kek Что может дать XSS на поддомене, где обычный одностраничный лэндинг, нет никаких данных пользователя? Штош, импакт такой: - Не только лишь все знают, что поддомен может ставить куки, в том числе на главный сайт (а точнее на весь скоуп, включая другие поддомены), а это может помочь при эксплуатировании других атак, например фиксацию сессии. Или вспомнить про отказ в обслуживании aka cookie bomb - CORS на других сайтах компании, в том числе сам site.kek может принимать Origin: subdomain.site.kek, а это значит можно выполнять действия от лица пользователя. - В дополнение к предыдущему - обходится механизм SameSite - Старый добрый фишинг, если нет дизайна для регистрации или входа - ее можно нарисовать. Может что-то еще? >

Короч, чтоб тебя всякие 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 обладает такой фичей). >

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

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

Иногда это используется для заявок, фидбэков и вот этого всего. И если его неправильно готовят, то на нем можно зарегистрироваться через signupNewUser (тыц) и получить доступ к данным, которые собирали сотрудники (в моем случае это было через Firestore). Только как имя базы узнать я не знаю, в моем случае оно тоже светилось в файлах фронта, но может в комментах подскажут. Еще надо попробовать pyfireconnect и python-firebase Savik поресерчил эту тему и сделал скрипт, который проверяет что доступно по данным Firebase. Если есть api_key и project_id, то уже можно тыкаться по Realtime Database, Firestore, Storage. >

#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 в файле, и спарсится все отлично. >

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

Есть такая штука nextjs, несколько месяцев назад они добавили новую "фишку" распределение нагрузки - под капотом поднимается несколько микросервисов. Каждый из которых занимается своей частью обработки запроса. Работает все примерно так-же как и обычный прокси сервер, запрос приходит, обрабатывается, и через стороннюю библиотеку проксируется на другой порт. Собственно именно это место нас и интересует. В HTTP есть такой метод PRI (используются, если мне не изменяет память, чтобы проверить возможность HTTP/2 подключения). Нас интересует что запросы этого метода имеют cимвол * в пути, вместо привычного /.

PRI * HTTP/1.1.

Далее, все http-парcеры работают по разному, у nodejs он немного особенный, и url вида http://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 = `http://${
  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 не принимает запросы содержащие авторизацию. >