Сбор разведданных с открытым исходным кодом 101
Тест на проникновение почти всегда должен начинаться с этапа сбора обширной информации. В этом посте рассказывается о том, как можно использовать открытые источники информации в Интернете для создания профиля цели. Собранные данные могут использоваться для идентификации серверов, доменов, номеров версий, уязвимостей, неправильных конфигураций, используемых конечных точек и утечек конфиденциальной информации. Читайте дальше!
Существует множество данных, которые можно обнаружить с помощью методов сбора разведывательных данных с открытым исходным кодом, особенно для компаний, которые широко представлены в Интернете. Всегда есть небольшой фрагмент кода, вопрос на техническом форуме с подробными деталями, поддомен, о котором давно забыли, или даже PDF-файл, содержащий маркетинговые материалы с метаданными, которые можно использовать против целевого сайта. Даже простой поиск в Google обычно дает интересные результаты. Вот некоторые действия, которые мы делаем, когда у нас есть имя клиента (домена) (в произвольном порядке):
1.Что нужно искать, чтобы найти контактную информацию администратора и другие адреса электронной почты. Эти адреса электронной почты очень часто существуют как действительные пользователи в приложении. Адреса электронной почты можно искать через утечки базы данных или через службу поиска, такую как HaveIBeenPwned, которая сообщает вам, была ли ваша электронная почта обнаружена как часть взлома.
Помимо адресов электронной почты, запросы whois могут возвращать информацию об истории IP-адресов, даты истечения срока действия домена и даже номера телефонов, которые могут использоваться в атаках социальной инженерии.
2. Расширенный поиск Google с использованием оператора site для ограничения целевым доменом, чтобы найти php (или любой тип файла сценария на стороне сервера), текстовые файлы или файлы журнала.
site:*.example.org ext:php | ext:txt | ext:log
В нескольких случаях мы определяли интересные файлы (например, файлы журналов), которые содержат конфиденциальную информацию и полный системный путь к приложению, используя подобные поисковые запросы. Вы можете связать этот запрос с оператором «минус», чтобы исключить определенные результаты поиска.
3. Выполните поиск в домене (и поддоменах) старых добрых документов. Типы файлов включают в себя, прежде всего, PDF, Excel, Word и PowerPoint. Эти документы могут содержать информацию, которую вы можете использовать для других атак. Часто метаданные документа (имя автора и т. Д.), Содержащиеся в свойствах файла, могут использоваться в качестве действительного имени пользователя в самом приложении.
site:*.example.org ext:pdf | ext:doc| ext:docx | ext:ppt | ext:pptx | ext:xls | ext:xlsx | ext:csv
Вы можете загрузить эти файлы локально и запустить их с помощью средства извлечения метаданных документа или просмотреть свойства каждого файла, чтобы узнать, какая информация просочилась.
Чтобы увидеть все параметры, которые можно использовать для поиска данных, перейдите на страницу https://www.google.co.in/advanced_search. Кроме того, База данных взлома Google (теперь называется exploit-db) позволяет использовать предварительно созданные запросы для поиска конкретных и интересных вещей в Интернете.
4. Проверьте файл robots.txt на наличие скрытых интересных каталогов. Большинство тележек для покупок, фреймворков и систем управления контентом имеют четко определенные структуры каталогов. Таким образом, каталог администратора находится на расстоянии запроса / admin или / administrator. В противном случае robots.txt, скорее всего, будет содержать искомое имя каталога.
5. Просмотрите исходный код HTML, чтобы определить тележки / CMS / фреймворки и т. Д. Определение типа приложения помогает сосредоточить атаку на областях приложения, которые имеют уязвимые компоненты (например, плагины и темы). Например, если вы посмотрите на источник страницы и увидите wp-content, тогда вы можете быть уверены, что смотрите на сайт WordPress.
Многие общедоступные надстройки браузера также могут использоваться для идентификации фреймворков веб-сайтов. Wappalyzer в Firefox довольно хорошо справляется с определением нескольких различных типов серверов, серверных и клиентских фреймворков и сторонних плагинов на сайте.
6. Чаще всего, если сайт, который вы просматриваете, был создан сторонним поставщиком, то вы, скорее всего, увидите вариант «Powered by Third-Party-Developer-Company» где-то внизу дома. страница.
Использование этого для отслеживания сбора информации на сайте подрядчика также может стать невероятно полезным. Просматривая его, можно выявить типы фреймворков и номера версий, на которых они построены. Также весьма вероятно, что у подрядчика есть тестовая / административная учетная запись на сайте вашего клиента в рамках своего плана развития.
По моему опыту, многие администраторы / разработчики сайтов часто используют пароли, которые являются вариацией названия компании (компания клиента или компания подрядчика) и некоторых цифр со специальными символами в конце или без них. Например, если компания-подрядчик называлась «Разработчики примеров», то 001Example, Example001, 00example, example00 и т. Д. Являются хорошими кандидатами на пароли, которые можно попробовать на панели входа на веб-сайт вашего клиента.
(Следите за нашей следующей публикацией о том, как мы использовали эту технику для взлома и получения доступа к клиентскому серверу и выполнения на нем команд оболочки.)
7. Просмотрите профиль компании в LinkedIn, чтобы найти руководителей высшего звена, директоров и нетехнический персонал. Очень часто самые ненадежные пароли принадлежат нетехническому руководству многих компаний. Поиск на странице «О нас» на веб-сайте компании также может привести к обнаружению слабых целей.
На основе обнаружения пары электронных писем можно получить стандартный формат имен пользователей. Как только формат имени пользователя будет понят, можно создать список адресов электронной почты и эквивалентных имен пользователей, которые затем можно будет использовать для выполнения других атак, включая грубую силу страниц входа в систему или даже использование слабой функции сброса пароля. (Не раз мы сочли полезным искать адреса электронной почты и возможные имена пользователей, что приводило к полной компрометации приложения и сервера из-за использования слабых паролей.)
8. Выполните проверки, связанные с IP-адресом. Очень часто приложения могут быть скомпрометированы из-за другого, более слабого приложения, размещенного на том же IP (общий хостинг). Используя обратный поиск IP-адресов, вы можете определить дополнительные цели, которые нужно обойти. У Bing отличный поиск с использованием IP-адреса.
Люди в пунктах вы получаете сигнал и IP-адрес также предоставляют возможность обратного поиска.
В рамках проверки IP-адресов важно также отметить записи A и PTR домена. Иногда из-за неправильной конфигурации другой сайт может быть доступен при использовании PTR или записи A сайта. Эту информацию можно получить с помощью команды nslookup или dig.
dig -x 8.8.8.8 nslookup 8.8.8.8
9. Перечислите субдомены, чтобы найти низко висящие плоды и более слабые точки входа в инфраструктуру хостинга клиента. Перечисление субдоменов - один из самых важных шагов в оценке и обнаружении активов, которые клиент выставил в сети; либо намеренно в рамках их бизнеса, либо случайно из-за неправильной конфигурации.
Перечисление субдоменов можно выполнить с помощью различных инструментов, таких как dnsrecon, subbrute, knock.py, с помощью оператора site Google или таких сайтов, как dnsdumpster и даже virustotal.com. В большинстве этих инструментов используется большой словарь общих описательных слов, таких как admin, pages, people, hr, downloads, blog, dev, staging и т. Д. Эти слова добавляются к основному домену - example.org, для создания списка возможных имен субдоменов, таких как admin.example.org, pages.example.org, people.example.org и т. д. Затем каждое из этих имен можно проверить на DNS-сервере, чтобы проверить, существует ли запись.
10. Ищите коды состояния HTTP и заголовки ответов для различных типов запросов ресурсов. Для действующей страницы, для несуществующей страницы, для страницы с перенаправлением, для имени каталога и т. Д. Обратите внимание на тонкие опечатки, лишние пробелы и избыточные значения в заголовках ответов.
Также обратите внимание на заголовки CSP. Они содержат доменные имена и источники, из которых может быть разрешена загрузка скриптов. Иногда опечатка в доменном имени, указанном в заголовке CSP, или небезопасный CDN с размещением на JavaScript может быть вашим единственным способом выполнить полезную нагрузку XSS :)
11. Выполните поиск доменного имени клиента через Shodan и Censys, чтобы найти файлы, IP-адреса, открытые службы и сообщения об ошибках. Хорошие люди из Shodan и censys кропотливо просканировали порты в Интернете, составили список служб и категоризировали свои результаты, сделав их доступными для поиска с помощью простых ключевых слов. Оба эти сервиса можно использовать для поиска множества интересных вещей, включая открытые камеры, устройства Cisco, серверы управления больничными учреждениями, слабо настроенные сервисы telnet и snmp и системы SCADA. В прошлом Censys использовалась для поиска интересных конечных точек, на которых размещался исходный код и целые образы докеров полных приложений.
12. Найдите клиента в сервисах хостинга кода, таких как github, gitlab, bitbucket и т. Д. В коде, размещенном в Интернете через доступные для поиска репозитории, можно найти всевозможные интересные вещи, включая веб-уязвимости, 0 дней в веб-приложениях, проблемы с конфигурацией, AWS и другие. секретные ключи .
Разработчики часто фиксируют код с производственными паролями или ключами доступа к API только для того, чтобы позже понять и удалить конфиденциальную информацию и сделать дополнительные коммиты. Однако, используя журналы фиксации и проверяя определенные фиксации, можно получить эти конфиденциальные данные, которые затем можно использовать для запуска полной атаки на размещенную инфраструктуру клиента.
Такие инструменты, как Gitrob, можно использовать для запроса Github и поиска конфиденциальных файлов из самой командной строки для конкретных организаций.
13. Просмотрите исходный HTML-код сайта, чтобы определить, размещает ли клиент статический контент в облаке. Контент, например изображения, файлы js и css, может размещаться в корзинах s3, принадлежащих клиенту. Это также может быть возможно при выполнении стандартной разведки, чтобы определить, использует ли клиент облачную инфраструктуру для размещения статического / динамического контента. В таких случаях поиск сегментов, которые использует клиент, может быть действительно полезным, если у клиента неправильно настроены разрешения для сегментов. В публичных ведрах можно найти массу интересной информации.
Такие инструменты, как DigiNinja’s Bucket Finder, можно использовать для автоматизации процесса поиска путем подбора имен корзин. Для работы этого инструмента требуется тщательно подобранный список имен сегментов и потенциальных полных URL-адресов.
OSINT - это постоянно развивающаяся и постоянно расширяющаяся область исследования. Используя перечисленные выше и другие методы, можно построить профиль цели и выявить несколько слабых мест, иногда даже не отправляя им ни одного пакета из вашей системы.
На этом мы подошли к концу этого поста. Если есть методы, которые вы часто используете и которые принесли вам интересные результаты, и если вы хотите ими поделиться, пожалуйста, оставьте комментарий.
До следующего раза, удачного взлома !!
Спасибо, что прочитали эту статью. Если вам понравилось, дайте нам знать, щелкнув значок сердечка ниже.
В Appsecco мы консультируем, тестируем, обучаем и анализируем вопросы безопасности программного обеспечения и веб-сайтов, особенно всего, что находится в сети, и соответствующей инфраструктуры хостинга - веб-сайтов, сайтов электронной коммерции, онлайн-платформ, мобильных технологий, веб-сервисов. и т. д.
Если что-то доступно из Интернета или с компьютера человека, мы можем помочь убедиться, что это безопасно и надежно.
