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

larchik

Red Team
07.06.2019
303
394
Привет, Codeby!

Когда-то давно я начал перевод Owasp Testing Guide тут на форуме, но до сих пор не завершил начатое. "Штош", продолжим )
Это продолжение перевода версии 4.2, которая на данный момент является актуальной.
Версия 5.0 в настоящее время находится в разработке, кому интересно, могут ознакомиться на гитхабе или официальном сайте.
Мой перевод может содержать неточности и быть не полным, поэтому рекомендую почаще обращаться к оригиналу.

Введение в пентест веб-приложений: поиск утечек информации с помощью поисковых систем

Пентест веб-приложений: определение веб-сервера, изучение robots.txt, определение приложений на веб-сервере.

Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.

Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.

Пентест веб-приложений: Тестирование конфигурации инфраструктуры приложения. Расширения файлов.

Пентест веб-приложений: Обнаружение резервных копий, старых и забытых файлов. Поиск административных интерфейсов и подбор паролей к ним.

Пентест веб-приложений: Тестирование HTTP-методов, HSTS, кроссдоменных политик, прав доступа к файлам.

Пентест веб-приложений: Роли пользователей. Процесс регистрации и получения аккаунта. Перечисление аккаунтов.


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


Тестирование передачи учетных данных по зашифрованному каналу

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

Клиент может отправлять или получать данные аутентификации во время следующих взаимодействий:
  • Клиент отправляет на сервер учетные данные для входа в систему;​
  • После успешного логина сервер отправляет клиенту токен сессии;​
  • Аутентифицированный клиент отправляет на сервер токен сессии для получение конфиденциальной информации;​
  • Клиент отправляет секретный код на веб-сайт, если он забыл свой пароль.​
Если эти учетные данные не шифруются при передаче, то злоумышленник с помощью инструментов анализа сетевого трафика сможет их перехватить и использовать для кражи аккаунта клиента. Атакующий для перехвата данных может использовать Wireshark или похожие инструменты либо настроить прокси для перехвата HTTP-запросов.
Тем не менее тот факт, что трафик зашифрован, не означает, что передаваемые данные автоматически находятся в безопасности. Безопасность зависит так же от алгоритма шифрования и от надежности используемых ключей.

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

Как тестировать
Для тестирования передачи учетных данных потребуется перехватить трафик между клиентом и сервером в момент, когда происходит обмен учетными данными. Протестируйте систему в момент логина клиента, а также во время работы аутентифицированного клиента с веб-приложением (во время действующей сессии).

Перед началом тестирования:
  1. Настройте и запустите инструменты для перехвата трафика:
    - можно использовать перехватывающий прокси, такой как OWASP ZAP или Burp Suite
    - либо встроенные средства браузера, такие как Developer tools в Firefox​
  2. Некоторые расширения для браузеров, например HTTPS Everywhere, автоматически заставляют веб-сайт использовать HTTPS вместо HTTP, если сайт его поддерживает. Если в вашем браузере имеются такие функции или плагины, отключите их.
В перехваченном трафике ищите конфиденциальные данные, включая:
  • Пароли (обычно в теле запроса)​
  • Токены (обычно внутри файлов cookie)​
  • Коды для сброса паролей или учетных записей​
Для каждого запроса, который содержит эти данные, убедитесь, что обмен данными произошел с использованием HTTPS, а не HTTP. Ниже приведены несколько примеров тестирования.


Пример 1:

Попробуем войти на Codeby с логином test и паролем test:

example1.png


Для того, чтобы просмотреть отправленный запрос, я буду использовать Developer Tools в браузере Firefox.
После отправки запроса можем убедиться, что пароль и логин были переданы по HTTPS:

example1-2.png



Пример 2:

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

example2-1.png


Убедимся в этом сами. Логин test и пароль test были переданы по незащищенному протоколу HTTP:

example2-2.png



Рекомендации

Используйте HTTPS для всех запросов к веб-сайту. Реализуйте на сайте HSTS ( HTTP Strict Transport Security - механизм, принудительно активирующий защищенное соединение через протокол HTTPS), чтобы любой запрос передавался только через HTTPS. В таком случае сайт получит следующие преимущества:
  • Злоумышленник не сможет изменить взаимодействие клиента с веб-сервером (в том числе путем размещения JavaScript-based malvare на скомпрометированном маршрутизаторе)​
  • Новые браузеры помечают сайты, использующие HTTP, как небезопасные. Использование HTTPS поможет в таком случае избежать потери пользователей сайта.​
  • Использование HTTPS упрощает написание определенных приложений, которые взаимодействуют с сайтом.​
Если на текущий момент перевод всего сайта на HTTPS затруднителен, установите приоритет HTTPS для запросов, содержащих конфиденциальные данные. В среднесрочной перспективе запланируйте полный переход на HTTPS.


Проверка дефолтных учетных данных (учетных данных по умолчанию)

В настоящее время для создания веб-приложений часто используется программное обеспечение (как коммерческое, так и open source), которое требует минимальной настройки перед использованием. Кроме того, некоторое оборудование (к примеру, сетевой маршрутизатор) имеет веб-интерфейсы для настройки и управления.

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

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

Первопричины этой проблемы можно определить так:
  • Неопытный IT-персонал, который не осознает важность изменения учетных данных, предоставленных по умолчанию для новых компонентов инфраструктуры или оставляет дефолтный пароль для своего “удобства”​
  • Разработчики, которые оставляют для себя бэкдоры с целью тестировать свое приложения в ходе разработки, но потом забывают эти бэкдоры удалить​
  • Приложения со встроенным и не удаляемым аккаунтом с предустановленными логином и паролем​
  • Приложения, которые не принуждают пользователя изменять дефолтные учетные данные после первого входа в систему​

Задачи тестирования
  • Выявить в тестируемой системе ПО, которое “из коробки” поставляется с дефолтными учетными записями, а затем проверить, возможен ли вход с дефолтными логином и паролем​
  • Дайте оценку новым учетным записям (создаваемым пользователями). Проверьте, создаются ли они с использованием каких-либо шаблонов или значений по умолчанию​

Как тестировать

Проверка дефолтных учетных данных в распространённых приложениях.

При тестировании методом “Black Box” предполагается, что тестировщик ничего не знает о приложении и его инфраструктуре. В реальности это часто не так и кое-что о приложении все же известно. Предполагается, что с помощью методов из раздела “Сбор информации” тестировщик уже нашел одно или несколько приложений, которые имеют административные интерфейсы и могут поставляться с учетными данными по умолчанию.

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

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

Обратите внимание, что в тестируемом приложении может быть включена защита от перебора паролей. К примеру, если вам известен логин, скажем admin, и вы к этому логину подбираете пароль, учетная запись с именем admin может быть заблокирована после нескольких неудачных попыток входа. Таким образом можно создать проблем администратору приложения (к примеру, если администратор работает удаленно, а для сброса учетной записи требуется физический доступ к устройству).

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

Поскольку учетные данные по умолчанию часто являются учетными данными администратора, можно действовать следующим образом:
  • Попробуйте следующие имена пользователей - “admin”, “administrator”, “root”, “system”, “guest”, “operator”, “super”. Эти имена популярны среди системных администраторов и встречаются часто. Дополнительно можете попробовать “qa”, “test”, “test1” и другие похожие имена. Попробуйте подставлять эти слова как в поле ввода логина, так и в поле для ввода пароля, по-разному комбинируя их. Если вам точно известны имена пользователей в приложении, то подставляйте приведенные выше слова в качестве пароля вместе с известным именем пользователя. Кроме того попробуйте пустой пароль, а так же “password”, “password123”, “pass123”. Если учетные данные не подошли, используйте словари логинов и паролей вместе со специальными утилитами для брутфорса, это может значительно сократить время подбора.​
  • Администратор приложения часто именуется по названию самого приложения или организации, которая его использует. Если вы тестируете приложение, которое называется “Obscurity”, то логично попробовать пару логин/пароль - obscurity/obscurity.​
  • Если ранее в ходе сбора информации о приложении вы обнаружили какие-то контактные данные (например email), попробуйте использовать их в качестве логина. Если вы заметили, что имена электронной почты формируются по какому-то алгоритму (John Doe – [email protected]), вы можете по аналогии предположить существование других email’ов и имен пользователей. Исследовав сайты организации, социальные сети, можно узнать настоящие имена админов приложения и сгенерировать на их основе логины для дальнейшего подбора паролей.​
  • Пробуйте использовать все указанные выше имена с пустым полем для ввода пароля.​
  • Изучите исходный код веб-страниц и файлов javascript на предмет обнаружения там того, что указывало бы на действительные имена пользователей. К примеру, можно обнаружить такой код If username='admin' then starturl=/admin.asp else /index.asp. Если у вас есть действующая учетная запись, то войдите под ней и тоже изучите исходники страниц и js, а также HTTP-запросы и ответы в момент удачного входа в систему и неудачного. Обратите внимание на скрытые параметры в запросах, а также на другие параметры, которые могут быть интересны (например, login=yes)​
  • Имена пользователей и пароли можно обнаружить в комментариях в исходных кодах веб-страниц и в резервных копиях исходников.​

Пример:

В ходе сбора вы обнаружили устройство D-Link:

example3-1.png


Немного погуглив, находим сайт со списком дефолтных пар логин/пароль для разных устройств D-Link:

example3-2.png


Список разных моделей хоть и большой, но вариантов логин/пароль не так уж и много. Пробуем admin/admin:

example3-3.png


И успешно логинимся:

example3-4.png


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


Проверка дефолтных паролей в новых аккаунтах.

Может случиться так, что при создании новой учетной записи ей будет автоматически назначен пароль. Такие пароли могут иметь какие-то стандартные характеристики, которые делают пароль предсказуемым. Если пользователь не изменит этот пароль при первом входе в систему (такое часто бывает, если приложение не заставляет пользователя изменить пароль) или если после создания аккаунта пользователь не выполнит первый вход в систему, угадываемый пароль позволит атакующему получить неавторизованный доступ к приложению.

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

При тестировании такого типа дефолтных учетных данных можно выполнить ряд следующих действий:
  • Внимательно изучите страницу регистрации пользователей. Информация на ней может помочь определить ожидаемый формат, а также минимальную и максимальную длину имени пользователя и пароля. Если страница регистрации отсутствует, определите, использует ли организация какой-нибудь шаблон при создании имен пользователей​
  • Попробуйте определить, как именно генерируются имена пользователей в приложении. Например, может ли пользователь сам придумать имя, или же система генерирует имя на основе некоторой личной информации или предсказуемой последовательности? Если система генерирует имена на основе предсказуемой последовательности (к примеру, user1337), попробуйте рекурсивно фаззить все возможные имена. Если вы получаете разные ответы от приложения при использовании валидного/невалидного логина (и невалидного пароля), вы так же можете методом перебора определить имена существующих пользователей.​
  • Попытайтесь определить, предсказуем ли пароль, сгенерированный системой. Создайте несколько учетных записей одну за другой и сравните сгенерированные пароли, чтобы выявить закономерность. Сопоставьте пароли с именами пользователей или другой личной информацией из созданных учетных записей (например, с датами рождения), возможно при таком сопоставлении вы обнаружите связь между паролем и учетной записью, которая в дальнейшем поможет вам при брутфорсе паролей других аккаунтов.​
  • Всегда пробуйте использовать все обнаруженные имена пользователей с пустыми паролями, а также пробуйте имя пользователя в качестве пароля.​


Тестирование механизма блокировки учетных записей

Механизм блокировки учетной записи позволяет предотвратить брутфорс-атаки. Данным способом можно защититься от:
  • попыток подбора паролей и имен пользователей​
  • попыток подбора секретных кодов (при двухфакторной авторизации) или подбора ответов на секретные вопросы​
Механизм блокировки аккаунта требует баланса между защитой аккаунтов от неавторизованного доступа и защитой пользователей от отказа в авторизованном доступе. Обычно учетные записи блокируются после трех-пяти попыток неудачного входа и разблокируются автоматически через какое-то определенное время, разблокируется пользователем самостоятельно с помощью механизма разблокировки либо блокировку снимает администратор приложения.

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

Задачи тестирования
  • Оцените, снижает ли механизм блокировки аккаунта вероятность подбора пароля методом перебора​
  • Оцените устойчивость механизма разблокировки к несанкционированной разблокировке учетной записи​

Как тестировать

1. Механизм блокировки.

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

Чтобы оценить работоспособность механизма блокировки, попробуйте выполнить вход с неправильным паролем несколько раз. Затем попытайтесь войти с правильным паролем, чтобы убедиться, что учетная запись заблокирована. Пример теста:
  1. Попробуйте выполнить вход с неправильным паролем три раза​
  2. Выполните вход с правильным паролем. Если вход выполнен успешно, то механизм блокировки не сработал.​
  3. Попробуйте тот же порядок действий, но вводите неправильный пароль сначала 4 раза, затем 5 раз. Таким образом вы определите, после скольких попыток ввода неправильного пароля блокируется аккаунт (если вообще блокируется)​
  4. Если аккаунт заблокировался и вход с правильным паролем невозможен, подождите 5, 10, 15 минут, что бы понять, через какое время аккаунт будет разблокирован.​

Пример:

Codeby блокирует пользователя после пяти неудачных попыток входа и разблокирует этого пользователя автоматически через 5 минут:

example4.png


Обратите внимание, что капча (CAPTCHA) может препятствовать брутфорс-атакам, но капча может иметь свои уязвимости и ее можно обойти при неправильной реализации, поэтому этот механизм не должен заменять собой механизм блокировки аккаунтов. Какие могут быть слабые места капчи:
  • легко решаемые математические задачи, ограниченный набор задач​
  • капча проверяет код HTTP-ответа вместо ответа на задачу​
  • логика капчи на стороне сервера по умолчанию предполагает успешное решение задачи​
  • результат капчи никогда не проверяется на стороне сервера​

Чтобы оценить эффективность капчи:
  • оцените предлагаемые задачи и подумайте, можно ли автоматизировать их решение​
  • попробуйте отправить запрос без решения капчи с помощью пользовательского интерфейса веб-приложения​
  • попробуйте отправить запрос с ошибкой в решении капчи​
  • отправьте запрос без решения капчи с помощью перехватывающего прокси (Burp или ZAP)​
  • попробуйте фаззить точки ввода данных капчи с использованием пэйлоадов для инъекций или последовательностей спецсимволов​
  • если в задаче капчи используется изображение, посмотрите alt-текст в тегах <img>, не подходит ли этот текст в качестве решения​
  • решите капчу правильно, а затем попробуйте использовать это решение в повторных запросах​
  • попробуйте очистить cookie перед отправкой запроса (бывает, что капча отображается только после нескольких неудачных попыток входа)​
  • если капча является частью многоэтапного процесса, например является первым шагом входа пользователя в систему, попробуйте обойти этот шаг и сразу перейти к вводу логина и пароля (например, используя перехватывающий прокси)​
  • проверьте альтернативные методы входа в приложение, например используя API​

Пример:

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

example-captcha.png


2. Механизм разблокировки.

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


Рекомендации

Применяйте механизм разблокировки в зависимости от уровня риска. В порядке от наименее безопасного способа к наиболее безопасному:
  1. Разблокировка аккаунта автоматически через определенное время​
  2. Разблокировка аккаунта пользователем самостоятельно​
  3. Разблокировка аккаунта администратором приложения​
  4. Разблокировка аккаунта администратором, который предварительно идентифицирует пользователя​

Факторы, которые следует учитывать при реализации механизма блокировки учетной записи:
  1. Насколько велик риск для приложения при подборе пароля пользователя?​
  2. Можно ли обойтись капчей для снижения этого риска?​
  3. Механизм блокировки срабатывает на стороне клиента? (например, javascript).​
  4. Количество попыток неудачного входа до блокировки должно быть оптимальным. Если порог блокировки слишком низкий, то аккаунты добросовестных пользователей будут блокироваться часто. Если же порог высокий, то у злоумышленника будет выше шанс подобрать пароль. В зависимости от целей приложения, количество попыток ввода пароля обычно составляет от 5 до 10.​
  5. Как будут разблокироваться аккаунты?
    • вручную администратором: это наиболее безопасный способ, но наименее удобный как для пользователей, так и для администратора. Обратите внимание, что у администратора также должен быть способ разблокировать собственный аккаунт в случае блокировки. Если в приложении используется только этот тип разблокировки аккаунтов, злоумышленник может заблокировать большое количество учетных записей, что приведет к атаке «отказ в обслуживании» (denial-of-service, dos).​
    • разблокировка автоматически через определенное время: длительность блокировки от 5 до 30 минут может быть хорошим компромиссом между защитой от брутфорс-атак и созданием неудобств для добросовестных пользователей.​
    • разблокировка пользователем самостоятельно: как говорилось ранее, этот механизм должен быть достаточно безопасным, чтобы злоумышленник не мог разблокировать учетные записи пользователей.​


На этом все, всем пока!
 
Мы в соцсетях: