Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о учетных данных по умолчанию.

 

Предыдущие статьи
  1. Тестирование: введение и задачи
  2. Сбор информации с помощью поисковых систем
  3. Определение веб-сервера
  4. Поиск информации в метафайлах веб-сервера
  5. Определение веб-приложений на сервере
  6. Поиск утечек информации в комментариях и метаданных
  7. Определение точек входа веб-приложения
  8. Составление карты веб-приложения
  9. Определение фреймворка веб-приложения
  10. Определение веб-приложения
  11. Составление карты архитектуры веб-приложения
  12. Тестирование конфигурации инфраструктуры веб-приложения
  13. Изучение расширений файлов
  14. Поиск страрых версий веб-приложения, скрытых файлов и резервных копий
  15. Поиск административных интерфейсов
  16. Тестирование HTTP методов
  17. Тестирование HSTS
  18. Тестирование кросс-доменной политики
  19. Изучение ролей пользователей
  20. Тестирование процесса регистрации
  21. Предоставление учетных записей
  22. Определение имен пользователей
  23. Определение правил генерации имен пользователей
  24. Изучение передачи пользовательских данных


Резюме

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

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

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

Основными причинами данной проблемы являются:

  • Неопытный технический персонал, непонимающий важности изменения учетных данных по умолчанию и оставлюющий их для простоты обслуживания

  • Программисты, забывающие удалить бекдоры, созданные ими для простоты доступа и тестирования веб-приложения

  • Приложения с неудаляемыми встроенными учетными данными, с предопределенным именем пользователя и паролем

  • Приложения, не заставляющие пользователей сменить пароли по умолчанию после первой авторизации

Как тестировать
Тестирование учетных данных по умолчанию распостраненных веб-приложений

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

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

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

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

Так как учетные данные по умолчанию часто используются административными аккаунтами вы можете действовать следующим образом:

  • Попробуйте следующие имена пользователей — «admin», «administrator», «root», «system», «guest», «operator» или «super». Они популярны среди системных администраторов и часто используются. Дополнительно вы можете попробовать «qa», «test», «test1», «testing» и схожие имена пользователей. Попробуйте любые комбинации из преведенных выше в обоих полях: имя пользователя, пароль. Если веб-приложение позволяет определять имена пользователей, то попробуйте пароли в схожей манере. Кроме того, попробуйте пустой пароль или один из следующих «password», «pass123», «password123», «admin», or «guest» с приведенными выше именами пользователей или любыми другими обнаруженными. В дальнейшем можно попробовать и другие вариации. Если эти пароли не подошли, то стоит воспользоваться словарями с наиболее популярными именами пользователей и паролями.

  • Административные пользователи часто создаются исходя из названия веб-приложения или организации. Это значит, что если вы тестируете веб-приложение, названное «Obscurity», то попробуйте obscurity/obscurity или любые другие схожие комбинации.

  • Проводя пентест клиента можно попробовать в качестве логина использовать информацию, указанную в контактактах. Электронные адреса клиентов могут раскрыть правила формирования имен пользователей: если у сотрудника John Doe электронный адрес jdoe@example.com, то вы видите как можно преобразовать имена и фамилии сотрудников (в том числе администраторов) в имена пользователей. В дальнейшем можно попробовать подобрать к ним пароли.

  • Попробуйте пустой пароль со всеми рассмотренными ранее именами пользователей.

  • Изучите JavaScript с помощью перехватывающего прокси или просто в браузере. Ищите любые упоминания имен пользователей или паролей в исходном коде. Например, «если username=’admin’ тогда starturl=’/admin.asp’, в противном случае ‘/index.asp'» (реакция не успешную и неуспешную авторизацию). Также если вам предоставили аккаунт для тестов, то изучите как происходит успешная авторизация, появляются ли дополнительные скрытые параметры, интересные GET запросы (login=yes) и т.д.

  • Ищите имена пользователей и пароли в комментариях к исходному коду. Также поищите исходный код в директориях для резервных копий (или резервные копии исходного кода).

Тестирование паролей по умолчанию для новых аккаунтов

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

Данный ранее совет о блокировке аккаунтов и информативных сообщениях об ошибках также применим и к тестированию паролей по умолчанию.

Следующие шаги можно предпринять при тестировании паролей по умолчанию:

  • Страница регистрации может помочь определить ожидаемый формат и минимум или максимум имен пользователей и паролей. Если страница регистрации не существует — узнайте применяет ли организация определенные правила при создании имен пользователей, как это сделать рассматривалось ранее.

  • Попробуйте определить как веб-приложение генерирует имена пользователей. Например, может ли пользователь сам выбрать его/ее имя пользователя или же система генерирует имя для пользователя, используя персональные данные, или используя определенную последовательность такие как user7811, попробуйте профаззить все возможные аккаунты рекурсивно. В случае если возможно определить реакцию веб-приложения на правильный логин и неправильный пароль — можно провести брутфорс существующих аккаунтов (или быстро попробовать часто популярные пароли с известными именами пользователей).

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

  • Если вы определили правила создания имен пользователей — попробуйте подобрать к ним пароли, используя расспространенные последовательности, например, день рожденья.

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

Тестирование по методу серого ящика

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

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

  • Спросите технический персонал — изменены или деактивированы учетные записи по умолчанию.

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

  • Поищите прописанные имена пользователей и пароли в исходном коде.

  • Проверьте конфигурационные файлы, содержащие имена пользователей и пароли.

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

Инструменты

Рекомендации
Информационные бюллетени