• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

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

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

1585656217753.png


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).
1585656426540.png


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

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

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

Меня всегда интересовала эта стратегия, но почему они тогда не использует такие символы, как (`), (|), (%00), (N̯̱̣͇̖̦̦̣ͥͮͩͪ̐͑͂̈̅ͦ͋̔͆̀̚̚̕ ), (, 𒐫), (ASCII 13, \r), (ASCII 10, \n) или другие символы, почему?

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

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

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

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

1585660343758.png


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

Наиболее распространенным ответом будет два параметра 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.

1585660586725.png


Шаги:
  • Браузер отправит два параметра 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-страницу.

1585661007466.png


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

  • Браузер отправит два параметра 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 токена.

1585663429949.png


Шаги:
  1. Браузер отправляет два параметра uid и pass на веб-сервер W, а если используется мобильное приложение AN, то он отправит JSON запрос {uid:"<userid>", pass:"<password>"} на сервер приложений A.
  2. Веб-сервер W получает параметры.
  3. W преобразовывает их в XML-формат и перенаправляет на сервер приложений A.
  4. Каждый запрос, полученный сервером приложений А, будет скопирован и отправлен на оба лог-сервера L1,L2.
  5. Сервер приложений A будет создавать динамический LDAP запрос для проверки идентификатора пользователя и пароля и пересылать запрос в активную директорию или контроллер домена AD для проверки пользователя.
  6. Если пользователь ввел валидные данные, то AD-сервер выдаст .
  7. Если запрос пользователя имеет 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 (раскрытию содержимого файлов).

1585663708734.png


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

1585663722750.png


Итак, мой вопрос для всех пентестеров: "Как часто вы проверяете различные уязвимости в таких 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 запрос.

1585664101046.png


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

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

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

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


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

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

Программы/Скрипты:
  1. Online Zalgo Text Generator
  2. Burp Collaborator
Статьи/Посты:
  1. Edge Side Includes abused to enable RCE
  2. 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
Експлойты:
  1. File Content Disclosure on Ruby on Rails https://github.com/mpgn/CVE-2019-5418
  2. CVE-2018-4124
Презентации с конференции:
  1. Breaking Parser Logic - Take Your Path Normalization Off and Pop 0days Out - Orange Tsai,Blackhat USA 2018
  2. Unraveling Unicode: A Bag of Tricks for Bug Hunting - Chris Weber
  3. Redefining Defense - Saumil Shah
Было упомянуто
  1. Saumil Shah @therealsaumil
  2. John Hawthorn @jhawthorn
  3. Cheng-Da Tsai @orange_8361
  4. Chris Weber @w3be
  5. Binni Shah @binitamshah
  6. Dafydd Stuttard @dafyddstuttard
Отдельная благодарность
  • Saumil Shah
  • Hiren Shah
  • Jigar Soni
  • Aditya Modha
EOF
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!