Небольшой трюк при эксплуатации SQLi в PostgreSQL. Когда необходимо узнать имена колонок в таблице можно использовать функции для работы с JSON, а именно to_jsonb и use jsonb_object_keys. Пример запроса:
select to_jsonb(u.*) from users u;В результате получим подобную структуру:
{"id":0, "name": "John", "password":"xxx"}
Взято отсюда.Нашел интересный проект, который посвящен замене символьного пароля на графический. В основе секрета лежит рисунок, который умещается на карте 7x7 клеток. При создании "пароля" можно использовать разные цвета (8). Рисунок можно конвертировать в строку и использовать в менеджерах паролей. Всё это обёрнуто в расширение для браузера. В общем, попытка перетащить функционал локскрина в телефонах на сайты. Идея интересная, но не за 10$ ;)
#wehatepasswords
#wehatepasswords
Когда есть необходимость получить reverse shell, но под рукой нет сервера, можно воспользоваться современными технологиями, а именно:
* ngrok - можно проксировать http/tcp на свой хост (даже за NAT). После запуска локального агента вам будет выдан случайный порт на внешке
* telebit - после подтверждения email можно пользоваться пробросом:
* localtunnel - не пользовался. Поддерживает только http. Есть клиенты на JS/GO/C#/.NET
* hypertunnel - расширенная версия localtunnel с поддержкой tcp. Клиент на js.
* webhookrelay - в бесплатной версии только http/https. Есть докер образ для быстрого старта.
Можно еще упомянуть лямбды у облаков, но это уже в другой раз.
* ngrok - можно проксировать http/tcp на свой хост (даже за NAT). После запуска локального агента вам будет выдан случайный порт на внешке
* telebit - после подтверждения email можно пользоваться пробросом:
$ ~/telebit tcp 9000* localhost.run - для работы с сервисом нужен только ssh клиент с пробросом портов. Не пользовался. Генерируете пару ключей и пробрасываете:
> Forwarding jondoe.telebit.io -p 5050 => localhost:9000
ssh -R 80:localhost:3000 localhost.run
* localtunnel - не пользовался. Поддерживает только http. Есть клиенты на JS/GO/C#/.NET
* hypertunnel - расширенная версия localtunnel с поддержкой tcp. Клиент на js.
* webhookrelay - в бесплатной версии только http/https. Есть докер образ для быстрого старта.
Можно еще упомянуть лямбды у облаков, но это уже в другой раз.
Один из индусских CTFеров посмотрел на патчи, которые были влиты в кодовую базу V8 после Pwn2Own (за находку и боевой вариант чувакам с павна дали $100к, между прочим) и накидал эксплоит (PoC), который всё еще пробивает необновлённые версии EDGE, Opera и всю остальную шелуху, которая использует сhromium'ную базу. Возможно, стоит посмотреть на десктопные приложения, которые используют веб интерфейсы? 🤔
В Chrome Canary и Firefox Nightly уже подвезли HTML Sanitizer API. Это что-то вроде DOMPurify, который теперь стандартизирован и доступен без подключения сторонних скриптов. Основное предназначение - защита от XSS и HTML-инъекций. Плэйграунд, чтобы посмотерь как этот работает. XSS-ки скоро кончатся?
Пример атаки 51% в действии. Все манипуляции производились в cheapETH. Это небольшая сеть, созданная Джорджом Хоцом (GeoHot). В распоряжении хакера оказался пул, который по мощности превосходил в несколько раз (1.39GH/s) актуальную мощность сети (527MH/s). Имея такие вычислительные ресурсы хакер обогнал сеть на несколько блоков, после чего подключился к основной сети. Это привело к тому, что легитимная сеть подтянула блоки из пула. Стоит отметить, что это лишь демонстрация без двойного расходования, поскольку цель была именно показать то, насколько просто маленькие сети подвержены влиянию мощных пулов. В реальном мире было несколько громких случаев с 51%.
В 2014 году майнинговый пул ghash.io получил 51% мощности хэширования в сети биткойна, но после добровольно снизил мощность.
В 2018 году таким образом у Bitcoin Gold утекло $18.000.000.
В 2014 году майнинговый пул ghash.io получил 51% мощности хэширования в сети биткойна, но после добровольно снизил мощность.
В 2018 году таким образом у Bitcoin Gold утекло $18.000.000.
Современные браузеры это уже давно не только рендеры HTML. Часто натыкался на рекламу очередного браузера, но с чем-то новым в виде отдельного компонента. Это может быть VPN, плеер, месенджеры, встроенная нода Tor (и я сейчас не про ТОР браузер), криптокошелек.
Представьте, что каждый из этих компонентов теперь потенциальный вектор атаки. За примером далеко ходить не нужно.
В Opera многие из этих пунктов уже есть. А еще там есть Web Flow. Это некий аналог мессенджера между вашими мобильными и штатными девайсами, на который стоит браузер Opera. Основной функцией является синхронизация текcтов и файлов.
Сегодня в блоге оперы появился пост про уязвимость, которая приводит к RCE через Web Flow.
Еще вы узнаете, что в браузерах иногда бывают скрытые расширения, а также что .batники еще живы :)
Представьте, что каждый из этих компонентов теперь потенциальный вектор атаки. За примером далеко ходить не нужно.
В Opera многие из этих пунктов уже есть. А еще там есть Web Flow. Это некий аналог мессенджера между вашими мобильными и штатными девайсами, на который стоит браузер Opera. Основной функцией является синхронизация текcтов и файлов.
Сегодня в блоге оперы появился пост про уязвимость, которая приводит к RCE через Web Flow.
Еще вы узнаете, что в браузерах иногда бывают скрытые расширения, а также что .batники еще живы :)
Переполнение буффера в 2023 году
В сети появился PoC для эксплуатации CVE-2023-4911 (Looney Tunables). Уязвимный код находится в динамическом загрузчике glibc, поэтому возможна эксплуатация на большом количестве систем. В основе атаки лежит манипуляция переменной окружения GLIBC_TUNABLES. Детали можно почитать здесь.
Повышение привилегий до root было успешно проверено на Fedora {37,38}, Ubuntu {22.04,23.04}, Debian {12,13}.
Быстро чекнуть систему на наличие уязвимости можно так:
Рабочий сплоент https://github.com/leesh3288/CVE-2023-4911
В сети появился PoC для эксплуатации CVE-2023-4911 (Looney Tunables). Уязвимный код находится в динамическом загрузчике glibc, поэтому возможна эксплуатация на большом количестве систем. В основе атаки лежит манипуляция переменной окружения GLIBC_TUNABLES. Детали можно почитать здесь.
Повышение привилегий до root было успешно проверено на Fedora {37,38}, Ubuntu {22.04,23.04}, Debian {12,13}.
Быстро чекнуть систему на наличие уязвимости можно так:
env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --helpЕсли видно Segmentation fault (core dumped), то 🙈.
Рабочий сплоент https://github.com/leesh3288/CVE-2023-4911
🌭2👍1
Несколько раз встречал в сети dashboard traefik, в котором можно найти информацию в том, что крутится в контейнерах, а иногда и креды от сервисов.
Дорк, чтобы посмотреть в живую:
Телега без премиума не даёт писать много текста, поэтому чуть больше деталей тут.
Дорк, чтобы посмотреть в живую:
intitle:traefik inurl:dashboardТелега без премиума не даёт писать много текста, поэтому чуть больше деталей тут.
👍1🌭1
Приветствую, уважаемые папищики.
Надеюсь, я не утомил вас слишком частым постингом в этом канале. Постараюсь делать это реже, чтобы не надоедать 👌
Октябрь продуктивный месяц. Сегодня выложу из загашника подготовленный в прошлом году пост.
Надеюсь, я не утомил вас слишком частым постингом в этом канале. Постараюсь делать это реже, чтобы не надоедать 👌
Октябрь продуктивный месяц. Сегодня выложу из загашника подготовленный в прошлом году пост.
Buffer overflow + request smuggling = ?
Возможно, данная техника прошла мимо вас, но она (как по мне) носит долгоиграющие последствия. Речь пойдет про request smuggling, который обычно упоминается с сочетании с HTTP протоколом. Но не простой смаглинг, а на уровне транспорта и клиентов. Наиболее полго раскрыл тему Paul Gerste на прошлогоднем Defcon.
Для работы с внешними сервисами в различных языках программирования есть так называемые "драйвера". Это некоторая реализация общения между вашим кодом и внешней системой, например - СУБД. Канал данных между ними может быть любой. Чаще всего используется UNIX-сокет, в современных микросервисных архитектурах чаще всего TCP, но обдолбанные могут юзать и UDP :)
Суть уязвимости
Для общения по этим транспортным протоколам нужен общий язык. Как раз драйвер и описывает порядок, как маркируются сообщения, какая длина, тип и т.д. В MySQL под длину отведено 3 байта, затем порядковый номер пакета и сами данные, в PostgreSQL первый байт - это тип сообщения, затем 4 байта длина и сами данные.
Вроде бы всё хорошо, только вот что будет, если передать данные большего размера, чем максимальная длина, которую можно уместить в 4 байта? Всё будет по-разному. Во-первых, некоторые системы усекают максимальный размер до определенного числа.
Если используется знаковое число - 2147483647 (2^31 - 1), если беззнаковое - 4294967295 (2^32 - 1). В современном мире это не такой уж и большой объем данных.
Улавливаете мысль?
Драйвер сообщает во внешнюю систему, что длина пакета N, а по факту передает данные большей длины. Это вполне реалистичная ситуация. Предположим, что есть некоторый POST параметр, который пришел от пользователя. Его длина 4294967100, т.е. превышает допустимую вместимость uint32.
Получается, что мы можем сконструировать фейковый пакет данных для нужного драйвера, расчитать нужную длину и выполнить произвольное действие на внешней системе, в СУБД, например, выполнить произвольный запрос. Т.е. на выходе получается что-то вроде SQL Injection, основанной на Protocol manipulation + Request smuggling.
Несмотря на некоторые ограничения (понятно, что может существовать настройка, которая валидирует длину входящих данных на том же веб сервере, либо валидация входящих символом на алфавит и т.д.) были найдены в дикой природе уязвимые компоненты. Поль раскрыл детали про pgx, pgdriver, pq, pg (драйвера для PostgreSQL для golang), Npgsql - .Net компонент.
Потенциально узявимы языки, в которых типы строк (именно тип string чаще всего используется для такого рода хранения) превышают макс. длину uint32, а это Golang, Rust, Python, в других же языках. Есть фишки, которые позволяют обходить это ограничение в других языках, например в JS есть бинарные буфферы, а там своя длина. Т.е. потенциал у баги большой. Думаю, мы еще не раз услышим о подобном способе атаки на систему с помощью данной техники.
Возможно, данная техника прошла мимо вас, но она (как по мне) носит долгоиграющие последствия. Речь пойдет про request smuggling, который обычно упоминается с сочетании с HTTP протоколом. Но не простой смаглинг, а на уровне транспорта и клиентов. Наиболее полго раскрыл тему Paul Gerste на прошлогоднем Defcon.
Для работы с внешними сервисами в различных языках программирования есть так называемые "драйвера". Это некоторая реализация общения между вашим кодом и внешней системой, например - СУБД. Канал данных между ними может быть любой. Чаще всего используется UNIX-сокет, в современных микросервисных архитектурах чаще всего TCP, но обдолбанные могут юзать и UDP :)
Суть уязвимости
Для общения по этим транспортным протоколам нужен общий язык. Как раз драйвер и описывает порядок, как маркируются сообщения, какая длина, тип и т.д. В MySQL под длину отведено 3 байта, затем порядковый номер пакета и сами данные, в PostgreSQL первый байт - это тип сообщения, затем 4 байта длина и сами данные.
Вроде бы всё хорошо, только вот что будет, если передать данные большего размера, чем максимальная длина, которую можно уместить в 4 байта? Всё будет по-разному. Во-первых, некоторые системы усекают максимальный размер до определенного числа.
Если используется знаковое число - 2147483647 (2^31 - 1), если беззнаковое - 4294967295 (2^32 - 1). В современном мире это не такой уж и большой объем данных.
Улавливаете мысль?
Драйвер сообщает во внешнюю систему, что длина пакета N, а по факту передает данные большей длины. Это вполне реалистичная ситуация. Предположим, что есть некоторый POST параметр, который пришел от пользователя. Его длина 4294967100, т.е. превышает допустимую вместимость uint32.
Получается, что мы можем сконструировать фейковый пакет данных для нужного драйвера, расчитать нужную длину и выполнить произвольное действие на внешней системе, в СУБД, например, выполнить произвольный запрос. Т.е. на выходе получается что-то вроде SQL Injection, основанной на Protocol manipulation + Request smuggling.
Несмотря на некоторые ограничения (понятно, что может существовать настройка, которая валидирует длину входящих данных на том же веб сервере, либо валидация входящих символом на алфавит и т.д.) были найдены в дикой природе уязвимые компоненты. Поль раскрыл детали про pgx, pgdriver, pq, pg (драйвера для PostgreSQL для golang), Npgsql - .Net компонент.
Потенциально узявимы языки, в которых типы строк (именно тип string чаще всего используется для такого рода хранения) превышают макс. длину uint32, а это Golang, Rust, Python, в других же языках. Есть фишки, которые позволяют обходить это ограничение в других языках, например в JS есть бинарные буфферы, а там своя длина. Т.е. потенциал у баги большой. Думаю, мы еще не раз услышим о подобном способе атаки на систему с помощью данной техники.
👍4