вольтаж

SSH RCE via Race Condition (CVE-2024-6387)

2024-08-06T14:43:18.297Z

1 июля, исследователи Qualys обнаружили как добиться удаленного исполнения кода в SSH 8.5p1 через состояние гонки в обработчике сигнала SIGALRM.

Состояние гонки - когда несколько частей программы могут одновременно изменять один и тот же ресурс, без какой-либо синхронизации в формате "сначала меняю значение Я, а потом ТЫ"

Что интересно, эта уязвимость уже была в 2006, получив CVE-2006-5051 и будучи исправленной патчем 4.4p1

deja vu i've been in this place before

но потом "случайно" вернулась в прод, от чего Qualys прозвали уязвимость regreSSHion.

Опасный обработчик сигнала

В конфиге для sshd есть опция LoginGraceTime, описывающая за сколько секунд пользователь должен успеть аутентифицироваться перед его отключением от сервера. По умолчанию, за 120 секунд.

Если пользователь аутентифицируется больше 120 секунд, то асинхронно вызывается SIGALRM обработчик для прерывания соединения.

Однако, этот обработчки также прерывает синхронные функции, небезопасные для асинхронных сигналов (non-async-signal-safe), такие как syslog()

В Qualys обнаружили, что во время состояния гонки возможно добиться повреждения кучи с FILE структурой и перенаправить исполнения программы.

как себя ощущает syslog() при каждой попытке эксплуатации

Повреждение кучи

В управлении памятью есть два основных концепта

стек, с упорядоченной памятью
куча (heap), когда информация хранится как попало

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

В итоговой куче должен быть свободный кусок памяти в 8КБ и после свободный мелкий кусок в 320байт, разделенные "чанк барьерами" (barrier chunk), что позволяют создать отдельные свободные куски памяти

Прыгаем на подключение к серверу.

атакующий превышает время для аутентификации во время подключения, указанное в LoginGraceTime
вызывается асинхронный SIGALRM обработчик, что вызывает синхронный syslog()

Здесь атакующий встречается с новым испытанием, ведь теперь ему надо попасть в исполнение malloc() внутри syslog(), между 4327 и 4339 строкой, когда malloc() аллоцировал память, но не успел сдвинуть её.

Что приводит к делению доступного нам куска памяти в 8КБ на 2 чанка по 4КБ. В одном аллоцированная память, а другой становится "свободным остатком"

И тут происходит странная ситуация. Прервав исполнение malloc(), "свободный чанк" привязывается к списку "свободной для перезаписи памяти", в то время как атакующий всё ещё имеет доступ к этой области памяти.

Зная, что эта память перезапишется, атакующий искусственно увеличивает размер "свободного для перезаписи" чанка, чтобы тот захватывал мелкий кусок свободной памяти в 320бит, который был подготовлен ещё в начале атаки.

Думаешь хватит сложностей для атаки? Не тут то было

Эти все операции должны произойти перед тем, как асинхронный обработчик SIGALRM вызовет небезопасные для асинхронного вызова - синхронные функции __tzfile_read() и fopen()

Если всё сошлось, то

fopen() аллоцирует свою FILE структуру в наш мелкий кусок памяти на 320бит
__fread_unlocked() перезапишет "свободный кусок памяти" с 4КБ буфером на чтение, затрагивая часть FILE структуры от fopen()

3. атакующий, имея доступ к буферу, перезаписывает часть FILE структуры и дальше, ещё более душно, перенаправляет flow исполнение программы куда ему нужно для исполнения кода

Вот и всё. Всего-то пару операций, туда-сюда и ты исполнился от рута!

Ладно, давай откроем форточку и суммируем атаку по картинке ниже

Так ли страшно?

Кроме того, что на системе должен быть glibc, большую роль играет архитектура процессора.

Для 32-битных систем

3-4 часа для победы в гонке за ~10 000 попыток, при 100 соединений в окне 120 секунд
6-8 часов чтобы найти нужный адрес и 1 раз исполнится от рута

спасибо ASLR, за рандомизацию стека, кучи, кода библиотек и программы, усложняя атакующем находить их в памяти

Для 64-битных систем

Нет подтверждения, что оно возможно
Адресов больше (32бит = 2^32 < 64бит = 2^48)
_

Теперь точно всё. Если твой голод подобных разборов не утолился, то прочитай мой более простой разбор нашумевшего бэкдора в библиотеке xz

Появились вопросы по уязвимости? Читай разбор от Qualys

Появились вопросы не по уязвимости? Пиши @w0ltage

Все совершают ошибки, или как я сдал 0 багов на хаксе

2023-12-10T14:39:39.137Z

literally standoff hacks experience

В потоке эфемерных советов, крутых инструментов и историй успеха, соскучился по историям не_успеха, тупым ситуациям и мыслям об этом.

Проанализировал свои действия на хаксе, собрал мысли в пункты и по каждому расписал как попал в ситуацию из названия + как мог избежать + что понял.

В единую миску текста, перемешал следующие мюсли ::

Как не утонуть в бесконечном реконе и фаззинге

Решая десятки, а то и сотни CTF тасков + написывая отчёты по ним, я неосознанно вбивал в голову паттерн

быстро пройтись по приложению -> найти выбивающийся функционал -> найти аномалию -> раскрутить -> сдать флаг

Что же происходило при подходе к живой цели?

Внутренняя похекерская ящерица видела over 9000 паттернов выбивающегося функционала, призывала СТФерскую интуицию и вместе они сходила с ума, перегружая мозг бесконечным реконом и фаззингом, в надежде поймать low-hanging fruit.

Почему это происходило?

Потому что CTF развивает навыки вширь, поддаваясь и расширяя кругозор, в то время как багбаунти тянет в глубь, позиционируя себя неприступной стена, но у которой пару кирпичей в фундаменте сделаны из пенопласта.

Веду к тому, что в CTF возможно забрать флаг без углублений в работу приложения, а зная множество техник и выкрутасов. В багбаунти же надо разбираться как работает приложение, чтобы его поломать.

Как остановить ящерный мозг?

Во-первых, чеклисты, чеклисты и даже mindmap чеклисты.

Стоило обозначить шаги для первичного анализа приложения и оглушив внутреннего ящера битой, со словами : :

Твои low-hanging fruits спрятались чуть глубже в приложении.
Разберись как работает приложение и закончи чеклист.

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

Начал понимать как работает приложение, как взаимодействуют компоненты и где могут быть уязвимости. Это и позволило найти первый баг, но об этом позже.

Чеклисты разделил на два типа

перечень шагов, приводящих к единому или набору результатов. пишу в обычном markdown. каждый шаг - чекбокс с описанием
карта действий, с прикрепленными результатами

Второй вариант легче показать, чем объяснить.

карта действий по первичному анализу приложения

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

Сами "карты" создаю в Obsidian Canvas. Это кибер-полотно, с возможностью расставлять блоки с текстом, вставлять заметки из хранилище, связывать их линиями и вставлять preview веб-страниц!

Как говорят в легендарном подкасте про багхантинг critical thinking:

You need to get "intimate" with a web application to find a juicy bugs

Во-вторых, делай перерывы. Всякий раз, ловя себя на "распылении", это были моменты усталости и не понимания что делать.

Надо было остановиться, встать из-за стола и сходить прогуляться. Дав себе отдохнуть, переключить и позволить взглянуть на приложение "со стороны".

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

Сколько и когда отдыхать? С этим придётся экспериментировать.

Я обычно работаю 2ч и отдыхаю 20мин, однако, если вхожу в поток, то могу работать часами напролет без отдыха. В такие моменты наиболее велика вероятность распыления, но и продуктивность тоже невероятна высока.

Потребление контента и overthinking

Готовясь к хаксу, стал загружать в голову подкасты critical thinking + darknet diaries, паттерны с райтапов решенных лаб, багбаунти отчётов (спасибо BBRE), кучу сообщений вебпвнчата и конечно же, сохранил "очень важные" посты в saved messages.

Это конечно круто, что я теперь, как попугай, могу повторять термины жестких веберов, и даже иногда в тему, но какой смысл, если не получается находить баги?

А смысла нет, ведь это всё - симптомы overthinking (надумывания), когда пытаешься предугадать все исходы и подготовиться к каждому из них. Пока я тратил 100 единиц усилий на "подготовку", другие проёбывались и получали опыт, тратя лишь 1 единицу усилий

Если тебе знакомо это ощущение, то настоятельно рекомендую прочитать эту статью про Overthinking, от легендарного UX-спеца.

Как перестать думать и начать прогрессировать?

Помогло перечитать модуль Learning Process от HackTheBox Academy, с мыслью

Фокусируйся на практике, с небольшим теоритическим перекусом, чтобы после обратно нырять в практику

Если ещё не читал этот модуль про самообучение, то давай, открывай новую вкладку, регистрируй аккаунт на HTB Academy, открывай модуль и возвращайся сюда. Прочитаешь после моих пластов текста.

Надо ли полностью отказываться от внешнего контента?

Не знаю. Думаю, надо оставлять место для вдохновения и мыслей, расширяющих понимание возможного, но не позволять теории превышать практику.

Эти люди существуют!

Побывав на Standoff Talks и Hacks, понял, что крутые безопасники - не фантастические существа из интернета, а реальные люди, не сильно отличающиеся от меня.

Причём, мне необязательно быть крутейшим хакером в комнате, чтобы приятно пообщаться с триажерами VK, Тинькофф, Standoff365, авторами крутейших каналов по безопасности и продукт овнерами багбаунти платформ BI.ZONE и Standoff365

В голове произошел окончательный ментальный сдвиг : :

Если они смогли, то и я смогу. Если у них получается, значит я что-то делаю не так и надо продолжать пытаться.

Тоже самое относится и к тебе. У тебя тоже получится.

Зачем сдавать информативы?

За весь хакс, нашёл лишь один жидкий-low баг, позволяющий включить администратору функционал (старые версии API), недоступные через UI.

По итогу, не смог раскрутить до "импакта" и не сдал, ибо "нет же импакта, да и в описании программы сказано, что не принимают возможность сделать действие, недоступное через UI без выявленных рисков безопасности"

ОДНАКО! Позже спросил у триажеров про этот "баг", на что получил:

- Знаем такой, его уже сдали. Тоже бы мог сдать и получить дубликат.

- В описании программы, в пункте про "действия не через UI", подразумевались только unreleased features, найденные в где-то в коде фронтенда.

Казалось бы, только я потерял баг, но нет, это повторилось у нескольких других хакеров с хакса. До сих пор очётливо помню, как автор самого пивного канала по безопасности, сказала : :

Если бы я сдала тот информатив, то мне бы заплатили 150к...

Выводы? Точно ли надо сдавать информативы?

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

кстати, триажеры VK попробуют помочь раскрутить баг, даже если тот информатив, но подаёт надежды выше информатива

БОНУСНЫЕ ЭПИЗОДЫ

Про синдром самозванца

До и во время хакса, во мне впервые разыгрался синдром самозванца. Он постоянно напирал : :

УУУ, я не найду багов и они узнают, что я не такой крутой багхантер и тогда будет плохо, УУУ

Когда же всё закончилось, всем было плевать. Мой мир не схлопнулся и отношение ко мне не изменилось, когда я не сдал багов. В этот самый момент, синдром самозванца исчез и пообещал не возвращаться.

Как я 90 минут подключал ноут к VPN в финале хакса

Считаю это апогеем тупых ситуаций со мной, но от того не менее смешной и интересной одновременно. Назвал бы его "хакатон костылей".

В тексте всё просто и прозаично, но за кадром я успел сгореть, уйти в депрессию, восстать из пепла, снова сгореть и собрать один большой костыль из маленьких (лего) костылей.

Ближе к делу. Больше года я работал на стареньком Thinkpad T420 с Arch Linux без всяких проблем. Получалось даже запускать EVE-NG с 5 виртуалками одновременно!

Впрочем, на финальный день хакса, решил сменить слабенький Thinkpad T420 на рабочий ноутбук, обосновывая "тот мощнее + там лицензионный бурп и WSL с настроенными инструментами".

Принёс, подключил, и стал ждать, пока Толя поведает нам секретный скоуп финального дня хакса. Спустя пару десятков минут, Толя поднимается на сцену и говорит : :

Cегодня будем ломать настолько секретный скоуп, что вам понадобится OpenVPN! Ещё, в удаленной сети нет DNS, поэтому вам придётся добавить хосты в hosts

Казалось бы, надо просто поставить OpenVPN, добавить хосты в файл и подключиться... и тут до меня доходит, что на тот момент, мне ещё не выдали права локального администратора, нужные для установки OpenVPN и редактирования hosts файла

Пришлось выкручиваться. Задача стояла следующая : :

Предоставить ноутбуку доступ к хостам в удаленной сети, без установки OpenVPN (для установки нужны права админа) и настроить обращение к виртуальным хостам сервера через /etc/hosts

На опыте предыдущих ~~проёбов~~ stupid situations (расскажу в другой раз), я знал, что "предоставить ноутбук доступ к хостам в удаленной сети без установки VPN клиента" возможно через подключение телефона к VPN и раздачи точки доступа через VPN tethering. При таком сетапе, все подключенные устройства будут иметь доступ к удаленной сети VPN'a.

По памяти быстренько скачал приложение VPN Hotspot, раздал точку доступа и подключил к ней ноутбук. Пропинговал хост в скоупе, на что пришёл ответ.

Первая часть проблемы решена!

Далее, нужно придумать как закинуть хосты файл c:\windows\system32\drivers\etc\hosts + настроить проксирования траффика браузера через бурп.

Сначала посетила мысль

Точно есть расширение браузера, имитирующие hosts файл.

Перепробовал несколько расширений Chrome браузера для имитации изменения файла hosts, но все они не работали как надо.

Следующей идеей было

Что если отредактировать /etc/hosts на виртуалке и поднять прокси сервер (mitmproxy) на той же виртуалке, чтобы виртуалка была выходным узлом для траффика и применяла на него свой локальный /etc/hosts

Окей, а как впихнуть сюда бурп?

Учитывая, что бурп - тот же прокси сервер, то как и в других прокси-серверах, в них возможно настроить перенаправление траффика на другой прокси сервер!

В бурпе это тоже возможно. За это отвечает функционал Upstream Proxy, в разделе настроек Proxy, заставляющий бурп - отправлять все запросы через указанный прокси.

Открыл настройки, перешёл к Upstream Proxy и настроил отправку запросов через прокси на виртуалке, с отредактированным /etc/hosts.

Осталось проверить.
Вбиваю домен в адресную строку,
жму enter и ОНО РАБОТАЕТ!

Итоговое решение выглядит так

average windows enjoyer

И да, виртуалка заменилась на WSL, ибо виртуалка в VMware почему-то зависала каждые 10 минут.

Итого, чтобы вставить кавычку на сайте, кавычке приходилось проходить путь "хром -> бурп -> виртуалка -> хост в удалённой сети, будучи подключенным к точке доступа телефона, раздающей VPN соединение" и обратно.

Сколько времени ушло на это? От объявления скоупа и до получения доступа с ноутбука к доменам скоупа прошло 1 час и 26 минут из доступных 4ч похека + 80% ментальных сил.

Следующие 3ч34мин прошли в режиме "распыление", где на оставшиеся 20% ментальных сил, я пытался ухватиться за low-hanging fruits.

Что дальше?

Остаётся написать на бумаге I have failed, but I will try again tomorrowи не сдаваться. Ты тоже не сдавайся. Все совершают ошибки, все проебываются и попадают в тупые ситуации, но лишь некоторые учаться на них, становясь лучше.

Надеюсь какие-то из этих мыслей и ситуаций помогут в нужный момент, или уже помогли и ты зарядился энергией делать то, что к чему постоянно готовился.

Как появятся вопросы, предложения, мемы или захочешь что-нибудь обсудить, смело пиши мне на @tokiakasus + подписывайся на @hackthishit, чтобы видеть БОЛЬШЕ контента по безопасности веба, инфры и головы.