Статья - Мыслите вне рамок OWASP TOP-10/SANS TOP-25/Bug Bounty | Форум информационной безопасности

Статья является переводом. Оригинал вот

Ссылка скрыта от гостей

TL;DR:

"Мыслите вне рамок

Ссылка скрыта от гостей

". В этой статье мы обсудим несколько примеров, чтобы донести главную идею о том, что если вы думаете ограниченно, то вы и будете ограниченными. Использование Bug bounty ухудшило качество тестирования на проникновение, как для клиентов, так и для специалистов. Клиенту трудно отличить хороший пентест от быстрого и грязного, при использовании топ-10/топ-25 будь то SANS или OWASP .

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

Внимание: Эта статья может изменить и изменит взгляд, мышление и привычку типичного пентестера. Будьте осторожны. Это может причинить серьезную боль вашим чувствам!

1. Введение

કેમ છો? મજામાં. Я - Равикумар Пагдал, в настоящее время работаю старшим менеджером в компании

Ссылка скрыта от гостей

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

"Самое распространенное - это хорошо известные уязвимости".

Да, я говорю о SQL инъекциях, XSS, CSRF, IDOR, отсутствующих заголовках безопасности и т.д.

Шокирует то, что по данным опроса, проведенного HackerOne в 2019 году "

Ссылка скрыта от гостей

" (стр. 39), более 50% BugBounty охотников ориентируются только на XSS и SQLi.

ВСЕ БОЛЬШЕ И БОЛЬШЕ ХАКЕРОВ НАЗЫВАЮТ XSS СВОИМ ЛЮБИМЫМ ВЕКТОРОМ АТАКИ.

На вопрос о любимом векторе или методике атаки, более 38% опрошенных хакеров ответили, что предпочитают поиск уязвимостей межсайтового скриптинга (XSS). Это больше, чем в прошлом году, когда их было всего 28%, и, тем самым, размещает XSS значительно выше всех остальных векторов атак. SQL-инъекция заняла второе место - 13,5%, а fuzzing, business logic и information gathering поместили в первую пятерку. В 2017 году ни business logic, ни сбор информации не попали в десятку лучших за прошлый год.- "
Ссылка скрыта от гостей
" (стр. 38).

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

"Потому что аналитик безопасности или пентестер фокусируется только на известных уязвимостях".

По своему опыту могу сказать, что это

Ссылка скрыта от гостей

. Это то, что я наблюдал в большинстве пентестов. По отношению к тестированию, основной стратегией является перехват HTTP-запроса и ввод одинарных ('), двойных кавычек ("), знак больше, чем (>) и знак меньше, чем (<) для выявления уязвимостей. При инъекции этих специальных символов, аналитик рассуждает только в этом спектре, и в конечном итоге, это приводит к поиску XSS и SQLi уязвимостей

Меня всегда интересовала эта стратегия, но почему они тогда не использует такие символы, как

Ссылка скрыта от гостей

(`),

Ссылка скрыта от гостей

(|),

Ссылка скрыта от гостей

(%00),

Ссылка скрыта от гостей

(N̯̱̣͇̖̦̦̣ͥͮͩͪ̐͑͂̈̅ͦ͋̔͆̀̚̚̕ ),

Ссылка скрыта от гостей

(﷽, 𒐫),

Ссылка скрыта от гостей

(ASCII 13, \r),

Ссылка скрыта от гостей

(ASCII 10, \n) или другие символы, почему?

Давайте разберемся с концепцией модели практики самым простым способом.

Вспомните тот день, когда вы начали с первого своего пентеста веб-приложения, или к примеру, вспомните тот начальный этап обучения, когда за это время у вас была практика поиска распространенных ошибок, таких как SQL Injection, XSS, CSRF и др. Но сейчас мы выросли, и на рынке появилось много новых ошибок (по данным Common Weakness Enumeration (Перечня Общих Слабых Точек) (

Ссылка скрыта от гостей

) общее количество слабых мест в программном обеспечении составляет

Ссылка скрыта от гостей

), так почему же мы фокусируемся только на общих уязвимостях?

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

Возьмем один HTTP-запрос, который содержит два параметра uid и pass.

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

Какая часть запроса является уязвимой?
Какая уязвимость повлияет на приложение и на какую часть?

Наиболее распространенным ответом будет два параметра uid и pass, или в дальнейшем кто-нибудь также ответит, включая параметры cookie _a, _b и _c. Правильно ?!

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

2. Тематические исследования

В приведенных ниже первых пяти примерах , B - это компания, предоставляющая банковские и финансовые услуги. Для аутентификации они используют веб-сервер W, сервер приложений A, базу данных SQL S, базу данных NoSQL N, файловый сервер F, серверы журналов регистрации L1 (БД на базе Oracle) и L2 (машина linux) и сервер контроллера домена AD.

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

2.1 Пример с типичной архитектурой веб-приложений

Нам была предоставлена одна страница для выполнения тестирования black box на банковском приложении B. После того, как мы введем userid и password, эти два параметра 'uid' и 'pass' перейдут на веб-сервер W, а W, в свою очередь, будет создавать динамические SQL запросы для получения подробной информации о пользователе из базы данных MySQL S.

Шаги:

Браузер отправит два параметра uid и pass на веб-сервер W.
Веб-сервер W получит параметры и построит динамические SQL запросы.
SQL Query сработает на сервере БД S и обеспечит желаемый вывод на веб-сервер W.

Наш первый запрос с uid и pass пройдет тем же путем и построит динамический SQL запрос. Итак, на нашу страницу входа повлияла какая-то уязвимость? SQL иньекция, правильно?!

2.2 Пример с файловым сервером с поддержкой WebDAV

Как и ранее, у нас есть одна страница входа для тестирования, но сервер базы данных не реализован на стороне сервера. Все данные хранятся в файловом формате на файловом сервере F. Как только параметры будут получены веб-сервером W, веб-сервер подключится к файловому серверу с помощью методов

Ссылка скрыта от гостей

(

Ссылка скрыта от гостей

и т.д.) и эти методы будут обновлять данные пользователя. Таким образом, в данном случае параметры являются теми самыми uid и pass, но уязвимость будет отличаться.

Шаги:

Браузер отправит два параметра uid и pass на веб-сервер W.
Web-сервер W подключится с файловым сервером F с помощью
Ссылка скрыта от гостей
-методов.
Файловый сервер F выполнит файловую операцию на основе полученного
Ссылка скрыта от гостей
метода.

В этом примере, вы не имеете никакого контроля над вызовами межсервных взаимодействий или их методами, поэтому

Ссылка скрыта от гостей

- мимо. У вас будет контроль только над двумя параметрами uid и pass, поэтому нужно сразу продумать, что можно сделать с этими двумя параметрами, и какую уязвимость можно обнаружить и в дальнейшем эксплуатировать.

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

uid=.../.../.../.../.../.../.../.../.../.../.../.../etc/passwd&pass=xyz

Да, вы на правильном пути... есть вероятность уязвимости

Ссылка скрыта от гостей

.

2.3 Пример с базой данных NoSQL и процессингом XML

У нас одна и та же страница входа, но на этот раз архитектура сервера другая, и в этой архитектуре веб-сервер отвечает за получение параметров, их преобразование в формат XML и переадресацию на сервер приложений A.

Сервер приложений А может понимать только XML или JSON запрос. Если сервер приложений А получит какой-либо запрос от веб-сервера W, то он разберет его в XML запрос, а если запрос получен от Android-приложения AN, то он разберет запрос в JSON.

Вкратце вся бизнес-логика, написана на сервере приложений A и сервере БД N, основана на mongoDB . Как только сервер приложений получает запрос на вход, то он будет обрабатывать его и строить динамические запросы и передавать его на сервер БД N. Если сервер приложений получает правильный ответ от сервера БД N, то он передаст ответ веб-серверу W, который будет затем «строить» HTML-страницу.

Шаги, связанные с этим:

Браузер отправит два параметра uid и pass на веб-сервер W, если используется мобильное приложение AN, то он отправит JSON запрос {uid:"<userid>", pass:"<password>"} на сервер приложений A.
Веб-сервер W получит параметр; преобразует их в XML-формат и перешлет на сервер приложений A.
Сервер приложений A разберет запрос и выполнит вход на сервер Mongo DB N.

В этом случае значение нашего параметра будет преобразовано в XML запрос. Таким образом, вы можете вставить XML пейлоад в параметры uid и pass, а затем он будет проанализирован на сервере приложений A. Таким образом, атакующий может выполнить все возможные XML атаки:

Ссылка скрыта от гостей

, XInclude,

Ссылка скрыта от гостей

[если XPath запросы используются в этом процессе].

Другое наблюдение заключается в том, что mongoDB не принимает никаких SQL выражений. Таким образом, вы должны внедрить инъекцию NoSQL заявлений, а uid является уязвимым для

Ссылка скрыта от гостей

.

2.4 Пример и эксплуатация log server based уязвимости.

Опять же, у нас одна и та же страница входа с двумя параметрами uid и pass, а также у нас та же архитектура, что и в примере 2.3, но к тому же, у нас еще есть два лог сервера.

Один лог сервер L1 размещен на ORACLE DB, а L2 на базе командной строки linux. Каждый запрос, полученный сервером приложений A, будет скопирован и отправлен на оба лог-сервера (L1, L2) , после чего сервер приложений A обработает запрос.

Шаги:

1. Браузер отправляет два параметра uid и pass на веб-сервер W, а если с мобильного приложения AN, то браузер отправит JSON запрос {uid:"<userid>", pass:"<password>"} на сервер приложений A.

2. Веб-сервер W получит параметры; преобразует их в XML-формат и перешлет на сервер приложений A.

3. Каждый запрос, полученный сервером приложений А, будет скопирован и отправлен на оба лог-сервера L1,L2. Если сервер приложений А получит JSON запрос, т.е. {uid: "ravi",pass: "P@ssw0rd"}, то сервер приложений все равно отправит этот запрос на лог-сервера.

На лог-сервере L1 запрос будет сгенерирован в виде следующего SQL-запроса:

SQL:

INSERT INTO LOG_2019 VALUES('{uid:"ravi",pass:"P@ssw0rd"}');
INSERT INTO LOG_2019 VALUES('{uid:"ravi",pass:"Wr0ng_P@55w0rd"}');
INSERT INTO LOG_2019 VALUES('{uid:"admin",pass:"admin"}');
INSERT INTO LOG_2019 VALUES('{uid:"test",pass:"test@123"}');

На L2 запрос будет сгенерирован для добавления запроса в лог-файл, и в следующей форме:

Bash:

echo '{uid:"ravi",pass:"P@ssw0rd"}' >> LOG_2019.log
echo '{uid:"ravi",pass:"Wr0ng_P@55w0rd"}' >> LOG_2019.log
echo '{uid:"admin",pass:"admin"}' >> LOG_2019.log
echo '{uid:"test",pass:"test@123"}' >> LOG_2019.log

4. Сервер приложений A спарсит запрос и выполнит вход на сервер Mongo DB N.

В данном случае все возможные уязвимости можно увидеть в примере 2.3, кроме того, значения наших параметров напрямую вызываются в запросе лог-сервера, чтобы злоумышленник мог произвести инъекцию пейлоада в процесс логироания. Таким образом, лог-сервер L1 уязвим к

Ссылка скрыта от гостей

, а сервер L2 уязвим к

Ссылка скрыта от гостей

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

И еще, если внимательно присмотреться к архитектуре, то все соединения между межсерверным взаимодействием - двунаправленные, но только вызовы L1/L2 лог-сервера идут в одном/единственном направлении. Поэтому, если вы хотите выявить эту слепую инъекцию, вам нужно знать технологию out-of-band, и как она работает. Также, вам нужно узнать о

Ссылка скрыта от гостей

, чтобы обнаружить этот вид скрытых уязвимостей [скрытых, потому что вы не сможете пронаблюдать никаких ошибок или задержек во времени ответа; поэтому вы должны использовать эту уязвимость, только с OOB-технологией ].

2.5 Пример с протоколом LDAP и JSON Web Token

И снова у нас одна и та же страница входа с двумя параметрами uid и pass, и у нас та же архитектура, что и в случае 2.4, но теперь у нас еще есть один процесс аутентификации, использующий

Ссылка скрыта от гостей

, для проверки пользователя.

Как только сервер приложения A получит запрос на вход, он перенаправит запрос в активную директорию или в контроллер домена AD для проверки запроса пользователя, основанный на аутентификации windows; и этот процесс реализуется с помощью динамических LDAP строк. Если пользователь и пароль - действительны, то AD сервера будут выдавать

Ссылка скрыта от гостей

, и в дальнейшем, вся аутентификация будет происходить с помощью верифицирующего JWT токена.

Шаги:

Браузер отправляет два параметра uid и pass на веб-сервер W, а если используется мобильное приложение AN, то он отправит JSON запрос {uid:"<userid>", pass:"<password>"} на сервер приложений A.
Веб-сервер W получает параметры.
W преобразовывает их в XML-формат и перенаправляет на сервер приложений A.
Каждый запрос, полученный сервером приложений А, будет скопирован и отправлен на оба лог-сервера L1,L2.
Сервер приложений A будет создавать динамический LDAP запрос для проверки идентификатора пользователя и пароля и пересылать запрос в активную директорию или контроллер домена AD для проверки пользователя.
Если пользователь ввел валидные данные, то AD-сервер выдаст
Ссылка скрыта от гостей
.
Если запрос пользователя имеет JWT-токен, то прикладной сервер A разберет запрос и начнет обработку данных на сервере Mongo DB N.

Все возможные атаки для этого случая аналогичны атакам для случая 2.4, в дополнение к

Ссылка скрыта от гостей

и возможности

Ссылка скрыта от гостей

, связанные с проблемами.

2.6 Не доверяйте заголовкам HTTP; пример с CVE-2019-5418.

В этом примере, мы рассмотрим некоторые уязвимости, обнаруженные в заголовках HTTP.

CVE-2019-5418 : File Content Disclosure на Rails, найденное
Ссылка скрыта от гостей
.

В этом случае заголовок Accept HTTP уязвим к File Content Disclosure (раскрытию содержимого файлов).

На изображениях ниже показан заголовок Referer HTTP, который уязвим для SQL инъекции.

Итак, мой вопрос для всех пентестеров: "Как часто вы проверяете различные уязвимости в таких HTTP заголовках?".

2.7 Тестирование Out of the Box или странное тестинг - пример с CVE-2018-4124

Ссылка скрыта от гостей
జ్ఞాЭтот символ Telugu вызывает сбой в работе Apple iPhone (Обновление: Исправлена ошибка в iOS 11.2.6).

Кто-то заметил, что отображение строки, написанной на индийском языке Telugu (జ్ఞా), приводило к аварийному завершению работы многих приложений на iOS и MacOS.

Apple стало известно об этой проблеме после того, как новости об ошибке начали распространяться в социальных сетях, а тролли начали её эксплуатировать. Один человек, по-видимому, показал, как он может крах приложения Uber на телефонах водителей, установив его имя в проблемной строке, а затем попросить подвезти.

Хотя первоначально только определенная Telugu строка работала, кто-то позже заметил, что конкретная строка с использованием символов бенгальского языка также вызвало крах приложений на iOS и MacOS. Существует несколько теорий о том, что может стать причиной сбоя, в том числе от инженера-исследователя Mozilla Маниша Горегаокара и Филиппа Верди из консорциума Unicode.

Компания исправила этот недостаток, выпустив дополнение к обновлению macOS High Sierra 10.13.3, iOS 11.2.6, WatchOS 4.2.3 и tvOS 11.2.6.

Другой случай является

Ссылка скрыта от гостей

от

Ссылка скрыта от гостей

	CVE
Spring Framework	CVE-2018-1271
Spark Framework	CVE-2018-9159
Jenkins	CVE-2018-1999002
Mojarra	CVE-2018-14371
Ruby on Rails	CVE-2018-3760
Sinatra	CVE-2018-7212
Next.js	CVE-2018-6184
resolve-path	CVE-2018-3732

Итак, после одной длинной и одной короткой истории!!!

Что мы узнали как пентестер на примере тестирования 2.7 Out of the Box или странного тестинга?

Не верьте ни на один символ юникода, вам нужно проверить ваш веб-сервер со всеми возможными символами юникода. Правильно ???

Вы не знаете, какой именно юникод приведет к краху вашего сервера.

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

Ссылка скрыта от гостей

от

Ссылка скрыта от гостей

.

Эта тема всегда будет обсуждаемой: Почему Джонни не может провести пентест: Анализ Black-box веб-уязвимостей и автоматическое и ручное тестирование. Сканер сделает то же самое, установит все точки и графики инъекции, а также профазит предопределенной пейлоад. На основе ответов сервера сканер будет решать, есть уязвимости или нет.

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

Мы отправляем один запрос ради автоматического сканирования, и во время него сессия может завершиться.
Во время сканирования, сервера может долго отвечать, и поэтому остальная часть теста будет отложена, и сканер обнаружит time based уязвимость, то есть основанную на времени (а это не является правдой).
Сервер может сообщить об ошибке, которой нет в подписи сканера.
Web-страницы содержат те слова, которые перечислены в подписи БД.
Во время сканирования - сервер обновляет токен сеанса.
Новая выявленная уязвимость не является частью сканера !!!
URL-адреса приложений, созданные во время работы, основаны на DOM или JS ...

Заключение

Прежде всего, у 5-ти примеров есть одна общая черта - это одна и та же страница входа с параметром uid и pass.

Как Black Box Tester, мы не знаем об архитектуре и конфигурации серверной стороны. Поэтому при тестировании необходимо следовать двум правилам:

Каждая управляемая пользователем часть HTTP-запроса уязвима ко всем возможным уязвимостям. Поэтому думайте как злоумышленник и тестируйте как злоумышленник.

Злоумышленники не следуют стандартам соответствия и сертификации. -
Ссылка скрыта от гостей

Основываясь на вышеперечисленных 5 примерах, мы пришли к выводу, что нельзя судить об уязвимостях по имени параметра, мы увидели один недостаток с двумя параметрами uid и pass, имеющий возможность использовать несколько уязвимостей (атаки SQLi, RCE, LDAPi, NoSQLi, XML и т.д.) в одном и том же приложении/запросе.

В примере 2.6, в котором четко указано, что не следует игнорировать и заголовки HTTP, они не менее важны, чем параметры.

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

В случае исследования 2.7, мы узнали, что всегда нужно делать out of the box тестирование, чтобы обнаружить больше ненормальных багов(а может и находить, 0-day уязвимость).

Теперь у вас есть такой же HTTP запрос.

и у вас все тот же вопрос.

Какая часть запроса является уязвимой?
Какая уязвимость повлияет на приложение и на какую часть?

И, прочитав статью, у вас есть ответ. Верно?

Каждый уголок запроса включает
Ссылка скрыта от гостей
,
Ссылка скрыта от гостей
и все параметры уязвимы для каждой возможной уязвимости.

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

Самым большим недостатком пентестера является постоянный страх "пропустить уязвимость" и отсутствие энтузиазма найти 0-day или провести странное тестирование в связи с истечением срока. Мы всегда можем подойти к работу с умом, но если мы пропустим 0-day, то это будет нашим самым большим сожалением".

Аппендикс A: Библиография

Программы/Скрипты:

Online Zalgo Text Generator
Ссылка скрыта от гостей
Burp Collaborator
Ссылка скрыта от гостей

Статьи/Посты:

Edge Side Includes abused to enable RCE
Ссылка скрыта от гостей
Apple News
Ссылка скрыта от гостей

Ссылочная документация:

OWASP Top Ten Project
Ссылка скрыта от гостей
CWE/SANS TOP 25 Most Dangerous Software Errors
Ссылка скрыта от гостей
The 2019 Hacker Report
Ссылка скрыта от гостей
Habit, Attitude, and Planned Behaviour
Ссылка скрыта от гостей
CWE List Version 3.4
Ссылка скрыта от гостей
HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Ссылка скрыта от гостей
HTTP PUT request method
Ссылка скрыта от гостей
HTTP PATCH request method
Ссылка скрыта от гостей
JSON Web Token (JWT)
Ссылка скрыта от гостей
JSON Web Token Best Current Practices
Ссылка скрыта от гостей
Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners
Ссылка скрыта от гостей

Експлойты:

File Content Disclosure on Ruby on Rails https://github.com/mpgn/CVE-2019-5418
CVE-2018-4124
Ссылка скрыта от гостей

Презентации с конференции:

Breaking Parser Logic - Take Your Path Normalization Off and Pop 0days Out - Orange Tsai,Blackhat USA 2018
Ссылка скрыта от гостей
Unraveling Unicode: A Bag of Tricks for Bug Hunting - Chris Weber
Ссылка скрыта от гостей
Redefining Defense - Saumil Shah
Ссылка скрыта от гостей

Было упомянуто

Saumil Shah @therealsaumil
Ссылка скрыта от гостей
John Hawthorn @jhawthorn
Ссылка скрыта от гостей
Cheng-Da Tsai @orange_8361
Ссылка скрыта от гостей
Chris Weber @w3be
Ссылка скрыта от гостей
Binni Shah @binitamshah
Ссылка скрыта от гостей
Dafydd Stuttard @dafyddstuttard
Ссылка скрыта от гостей

Отдельная благодарность

Saumil Shah
Hiren Shah
Jigar Soni
Aditya Modha

EOF

Реакции: Alex Trim, VankaIE, John Sportivkin и ещё 27

Нажмите, чтобы раскрыть...

Все сервисы Codeby

Поиск

Поиск

Статья Мыслите вне рамок OWASP TOP-10/SANS TOP-25/Bug Bounty

igor_nikolenko