Пару слов о Content Discovery

Небольшая заметка о таком явлении как content discovery. В очередной раз наткнулся на такую проблему в одном из проектов и решил написать об этом. Пост будет бесполезен тем, кто в курсе как проводится аудит безопасности, но для меня, как для разработчика ПО в свое время эта штука стала откровением.

В информационной безопасности content discovery называют технику поиска скрытых ресурсов, преимущественно в web-приложениях. Впервые я столкнулся с таким явлением несколько лет назад, когда ко мне обратились знакомые и сказали, что у них стали пропадать клиенты. Это была небольшая компания, у них был отдел продаж и маленький одностраничный веб-сайт, где потенциальные клиенты оставляли свой номер телефона. Затем менеджеры отдела продаж перезванивали клиенту и совершали сделку. Так вот, с какого-то момента клиенты, пришедшие на сайт оказывались обработаны конкурентами до того, как им позвонит менеджер. Поначалу подозревали сотрудников, но затем я решил взглянуть на исходный код сайта. Выяснилось, что по урлу /clients (или что-то такое, точно не помню) без всякой аутентификации были доступны клиенты оставившие заявку за несколько часов. Этот урл дергался CRMкой и новые клиенты перекидывались в базу CRM.

На тот момент мне было непонятно, как можно было обнаружить этот путь на сайте, ведь он нигде не фигурировал — ни в sitemap.xml, ни в robots.txt ни где либо ещё. Про content discovery я ничего не знал, поэтому немного подумал и забил(к тому же проблема оказалась решена). Как оказалось есть способы поиска таких скрытых ресурсов. Давайте посмотрим что можно спрятать и как это можно найти.

 

Перебор урлов

Самым простым и распространенным способом является перебор урлов. Для этих целей существуют специальные инструменты (dirs3arch, dirb) и словари. Для примера воспользуемся для этого утилитой dirs3arch.

dirs3arch usage example, directory bruteforce

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

  • Всевозможные «секретные» админки
  • Файлы бекапов
  • Конфигурационные файлы
  • Служебные ресурсы — неоднократно наблюдал различные странички, содержащие отладочную информацию, самопальный мониторинг или даже позволяющие выполнить некоторое действие — очистить очередь, перезапустить задачу и т.д. Однажды даже мне попался целый скриптовый движок, позволяющий добраться до внутренностей приложения и выполнить код. Просто его забыли отключить

Помимо простого доступа к ресурсам, существуют словари, которые содержат урлы, специфичные для определенных продуктов. К примеру, если вы обращаясь к .htaccess получаете 403, то быть может этот сервер крутится на апаче

Поиск поддоменов

Брутфорс

Представим, что нашей компании принадлежит домен company.com. У вас может быть основной сайт на company.com и куча поддоменов, в том числе и непубличных.

Например:

  • test.company.com — для тестирования
  • demo.company.com — для демки
  • stage.company.com — для стейджа и тому подобные

Такие домены легко находятся перебором (опять же вот тут есть немного словарей), а перебрать их можно тулзой под названием dnscan

dnscan usage example, subdomain bruteforce

Certificate transparency

Если в системе используются SSL-сертификаты, то мы также можем посмотреть поддомены, на которые эти сертификаты были выданы, если удостоверяющий центр поддерживает технологию certificate transparency. Для того, чтобы узнать на какие поддомены были выданы сертификаты, мы можем воспользоваться утилитой ctfr:

ctfr usage example, subdomain enumeration

AXFR

Ещё один способ узнать домены — спросить об этом DNS-сервер. Вкратце — DNS-сервера обладают возможностью реплицировать свое содержимое. Для этого существует процедура репликации или трансфера. Чтобы получить данные для реплики нужно отправить DNS-серверу AXFR-запрос и в случае некорректной настройки сервера мы получим полный список доменов. Такая штука может сработать, если компания использует свои сервера имён

dig -t AXFR domain.com @ns.domain.com

Поиск скрытых параметров запроса

Иногда это бывает удобно при разработке — отключить лишнюю проверку для отладки или что-то в этом роде. Такую “отключалку” можно сделать необязательным параметром HTTP-запроса, спрятать в куках, заголовках и так далее

Тем не менее, такие штуки продолжают жить в production среде. В качестве инструмента можно взять Burp Intruder. Пару примеров:

  • Спрятанный параметр — может передаваться как параметр формы, поле json-тела и так далее
//обработка выглядит вот так
if(request.param(isAdmin) == true){
  // можно грабить корован
    sandbox.diasble
}
  • Недокументированные методы API — если у нас есть метод POST http://service/api/update/42, то почему бы не попробовать вместо update подставить delete, даже если это явно не прописано в документации
  • etc

Неуловимый Джо

Предположим, что мы деплоим некий сервис на только нам известный IP-адрес (доступный из интернетов) и нестандартный порт. Доступ к нему только по IP-адресу, никаких привязанных доменов не существует. Кажется что тут всё в порядке, никто не знает про этот сервис, значит никто не придет. Действуем по принципу Неуловимого Джо — вроде как существует, но никто его не видел — потому что нахрен никому не нужен. Но не тут то было. В интернете существуют различные сервисы типа Shodan, которые только и делают, что сканируют весь интернет и собирают баннеры и прочую полезную информацию. Ради примера поставьте обычный apache, повесьте его голым задом в интернеты и увидите много интересного в access-logах. Из личного опыта — один мой коллега развернул линукс-сервер для каких-то своих нужд, перевесил ssh-порт на какой-то нестандартный и оставил вход по паролю, без ssh ключей. Через некоторое время он обнаружил на своем сервере дополнительное ПО в виде майнера криптовалюты. Да и вообще, вы наверное слышали истории как в интернете находили огромные незапароленные базы с персональными данными пользователей фейсбука и прочим добром.

Google Dorks

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

Итого

  • Если какие-то хосты не должны быть видны снаружи — сделайте так, чтобы они были недоступны извне
  • Если у вас есть служебные ресурсы на веб-сервере — закройте их авторизацией или поместите в админку
  • Не делайте скрытых параметров, кук и прочего
  • Помимо перечисленных методов content discovery есть ещё другие возможности поиска скртых ресурсов, поэтому даже не пытайтесь спрятаться — всё равно найдут

 

Оставить комментарий

Ваш адрес email не будет опубликован.