ИСТИННЫЙ ПОТЕНЦИАЛ RACE CONDITION
Долгое время мы думали о гонках как об ошибках, таких как многократное использование промо-кода или что-то, связанное с функциональностью оформления заказа. Тестируя любой веб-сайт с покупками, мы пробуем подобные уязвимости, но, честно говоря, это работает довольно редко. Я думаю, что единственным правильным состоянием гонки, которое я видел, было RCE, когда цель распаковывала zip-архив и только затем проверяла его содержимое.
Но исследование Джеймса Кеттла в этом году проливает новый свет на этот класс ошибок. Он также поставляется с новыми инструментами и сценариями атак . Вы можете посмотреть его выступление здесь.
ReCAPTCHA
Одно из существующих условий гонки, которое может быть полезным для некоторых атак и которое не будет исправлено - это повторное использование решений Google reCAPTCHA в коротком временном окне. Джеймс обнаружил эту проблему и сообщил о ней в Google, но ему ответили, что не будут ее исправлять.
Может быть полезно для некоторых атак злоумышленников.
LIMIT-OVERRUN RACE CONDITIONS
Race condition в reCAPTCHA является примером условия гонки с превышением лимита. Это означает, что условие гонки позволяет использовать что-то более одного раза. Точнее, больше своего предела. Например, промокод, который должен быть использован 10 раз, но при быстрой отправке 11 запросов удается выйти за пределы лимита.
Это типичные примеры и здесь мы о них говорить не будем.
В качестве примера можно привести ссылку, которая была разослана некоторым пользователям Facebook.
confirmemail[.]php?e=user@gmail.com&c=13475&code=84751
Это пример состояния гонки, но два кода OTP в одной ссылке не являются ошибкой типа превышения лимита.
Именно с этим связан новый тип условий гонки
ПОДСОСТОЯНИЯ
В одном приложении после входа в систему сайт перенаправлялся на, GET /role а затем отправлялся файл POST /role. Оказалось, что после входа в систему приложение назначало роль администратора кому угодно и GET /role меняло ее на pending. Это простой обход логики – после входа в систему вы не следуете перенаправлению, а сразу отправляете POST /role и становитесь администратором.
Где состояние гонки? Теперь представьте ту же ситуацию, за исключением того, что посередине нет GET /role. Приложение назначает роль администратора кому угодно, но всего через 3 строки исходного кода оно меняет роль на pending. Теперь, если вы сможете нажать POST /role в пределах этих трех строк, вы все равно сможете стать администратором. В этих трех строках наша учетная запись находится в подсостоянии , и это окно гонки, в которое мы хотим попасть.
Проблема здесь может заключаться в сетевой задержке - запросы идут медленно, и попасть в это маленькое окно будет крайне сложно. Это, как и многие другие условия гонки, кажется необнаружимым из-за сетевой
задержки. В реальных условиях вам будет очень трудно добиться обработки двух запросов в течение миллисекунд. Однако Джеймс добавил в Burp то, что называется однопакетной атакой. Для нас полезным является
то, что с помощью однопакетных атак мы можем тестировать удаленные приложения практически так же, как и локальные.
При тестировании он сделал 20 запросов на 17 тыс. км, и они были обработаны с медианным разбросом в 1 мс.
Это в 4-10 раз эффективнее, чем предыдущая лучшая техника гонки - синхронизация последнего байта. В Burp он интегрирован как в Turbo Intruder, так и в Repeater, и это будет наиболее распространенным вариантом
его использования.
Чтобы отправить запросы с помощью этой техники, добавьте их в одну группу в Repeater, а затем из выпадающего списка выберите "Send group in parallel (last-byte sync)". В нем вместо однопакетной атаки говорится о last-byte, но для HTTP/2+ будет использоваться однопакетная атака, а для HTTP/1 - last-byte. Это означает, что у вас гораздо больше шансов получить гонку, если ваша цель
использует HTTP/2 или выше.
МЕТОДОЛОГИЯ
По сути тут все разбивается на три этапа.
Прогнозирование:
Теоретически любой запрос может оказаться уязвимым. На практике мы хотим сосредоточиться на наиболее уязвимых функциях, таких как управление пользователями, заказами или сессиями. Хотя Джеймс упомянул, что
обнаружить подобную ошибку при простом просмотре исходного кода довольно сложно, есть некоторые моменты, на которые следует обратить внимание. Рассмотрим на примере функциональности подтверждения электронной почты. Вы отправляете запрос на (1) отправку письма с подтверждением, затем вы
(2) меняете электронную почту, а затем (3) снова отправляете первый запрос. Если в пункте (3) приложение просто создает новый токен подтверждения электронной почты и добавляет его в базу данных, то это не представляет особой
опасности. Однако опасно, если и (1), и (3) работают с одной и той же записью в базе данных. Честно говоря, это выглядит как нечто чрезвычайно сложное для обнаружения с помощью просмотра кода, поэтому проще выявить подобное на практике.
Выбрав функциональность для аудита, проверьте ее нормальное поведение. Отправьте несколько обычных запросов и только затем отправьте последовательность запросов состояния гонки и посмотрите, не изменилось ли что-нибудь.
Для сравнения Джеймс отправил 6 запросов с приглашениями, получил 6 успешных ответов и одно письмо. Затем он отправил их с помощью однопакетной атаки, получил 1 успешный ответ, 5 ответов об ошибках и 2 электронных письма.
Именно разница между поведением эталона и поведением состояния гонки указывает на наличие состояния гонки. Последний шаг - доказать это, добившись реального эффекта.
Воспользовавшись этой техникой, он смог получить токен подтверждения для электронной почты, которой не владел. В GitLab это довольно серьезное воздействие, потому что он мог перехватить приглашения, предназначенные для других пользователей.
Обратите внимание, что ему пришлось задержать второй запрос, потому что отправка письма занимала много времени, и второй запрос должен был прийти позже. Чтобы сделать это без учета сетевых колебаний, все равно используйте атаку с одним пакетом, но отправьте несколько случайных запросов между двумя важными, чтобы задержать обработку второго.
Какой код стоит за этой ошибкой?
Причина в том, что функция send_devise_notification вызывается с неподтвержденным адресом электронной почты в качестве аргумента. Проблемы бы не было, если бы эта функция взяла бы этот аргумент и поместила бы его как в адрес отправителя, так и в тело электронного письма, вместе с соответствующим токеном подтверждения. Но проблема в том, что, хотя адрес отправителя был взят из аргумента, тело электронного письма было заполнено данными пользователя из базы данных. Данные из базы данных могли измениться между вызовом этой функции и выполнением этой строки, электронная почта в базе данных могла быть другой. Таким образом, GitLab мог отправить токен подтверждения электронной почты на неправильный адрес.
Это ошибка в Devise – самой популярной системе аутентификации для Rails. Джеймс нашел еще несколько примеров сайтов, подверженных этой уязвимости. На момент презентации она не была исправлена, поэтому вы должны проверить любое приложение Rails на наличие этой ошибки. Я также быстро просмотрел репозиторий и не нашел ни одного коммита, который бы исправил это.
Вот еще несколько примеров уязвимого кода. Обратите внимание, что они будут работать в одних фреймворках и не будут работать в других – все зависит от того, как фреймворк управления сессиями блокирует сессию при ее изменении.
В заключение, совет от Джеймса заключался в том, что некоторые условия гонки не имеют смысла, и поиски логики здесь могут на самом деле мешать вам. Лучше иметь эксплойт, чем логику.
БУДУ ЛИ Я ИСКАТЬ ЭТУ ОШИБКУ?
Единственное, что немного беспокоит меня, это то, как мало реальных примеров было в презентации Джеймса. С одной стороны, количество полученных вознаграждений не является определяющим фактором хорошего исследования, но с другой стороны, мы действительно оцениваем это так, и Джеймс, безусловно, знает об этом. Так что если бы нахождение условий гонки было бы легким, я думаю, у него было бы больше примеров. Тем не менее, я думаю, что в этом классе ошибок есть потенциал.
Презентация: https://web.archive.org/web/20230924200655/https://media.defcon.org/DEF CON 31/DEF CON 31 presentations/James 'albinowax' Kettle – Smashing the state machine the true potential of web race conditions.pdf
Доклад: https://www.youtube.com/watch?v=tKJzsaB1ZvI
Статья: https://portswigger.net/research/smashing-the-state-machine