D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Автор: miserylord
Эксклюзивно для форума: xss.is
Ты в системе, игра начинается, на связи miserylord!
Что такое дорки, какие принципы помогают освоить самостоятельное написание дорков, что можно получить с их помощью и как извлечь информацию с найденных сайтов? Эта статья ответит на все эти вопросы.
Этимология слова, насколько я понимаю, происходит от английского "dork", что переводится как что-то грубее, чем "придурок". В контексте Google дорки — это способ обнаружения чувствительной информации с использованием так называемых операторов поиска. Под дорками также подразумеваются администраторы или программисты, которые допустили утечку данных. Удивительно, но, кажется, не существует официальной документации по операторам поиска, однако частично тема раскрыта здесь. В целом, это первая тема, с которым стоит ознакомиться.
На самом деле алгоритм удивительно прост: изучаем существующие дорки, созданные кем-то до нас, анализируем их ценность и информацию, которую они предоставляют, выясняем причины появления уязвимостей, а затем создаём свои дорки, изменяя компоненты или задаваясь вопросом, в каких ситуациях можно получить аналогичные данные. Повторив этот процесс несколько тысяч раз, вы, вероятно, начнёте генерировать уникальные дорки, особенно если глубоко понимать принципы работы и технологии веб-приложений. Это лучший способ, который я нашёл. На этом этапе можно переходить к практике.
Где взять базу существующих дорков? Самая популярная база — это exploit database: Google Hacking Database (GHDB). Также списки можно найти на форумах или в каналах социальных сетей. Например, можно взять список с GitHub: SQL-Injection-Google-Dork-List.
Теперь переходим к практике!
В примере я использовал дорки, нацеленные на SQL-инъекции. Подробнее о том, что такое SQLi, можно узнать в этой статье, но с помощью дорок можно искать практически любую информацию. Например, возьмём уязвимость открытого редиректа. Она возникает, когда приложение не проверяет корректность данных и позволяет перенаправлять пользователей на сторонние URL-адреса без достаточной проверки или фильтрации. Эта уязвимость часто встречается, поскольку даже крупные программы багбаунти не всегда платят за её нахождение. Однажды я читал, что её можно использовать для превращения приложения в бесплатный прокси, но на практике это не работает так, как кажется. Тем не менее, обнаружить её можно с помощью дорок — вот пример Open Redirect Dorks. Таким образом, с дорками можно искать различные типы уязвимостей.
После того как найдена дорка, важно уметь с ней работать и извлекать информацию. Возьмём, к примеру, дорку shop intitle:"index of" docker-compose.yml. Что с ней делать? Во-первых, нужно разобраться, что такое docker-compose.yml. Это конфигурационный файл, который используется для определения и управления многоконтейнерными Docker-приложениями. Изучив его, можно понять, что в нём могут храниться переменные окружения, и если они неправильно настроены (например, не вынесены в файл .env), это может привести к утечке данных, таких как доступ к базе данных.
Теперь вопрос — как подключиться к базе данных? В первую очередь нужно узнать её адрес. Если он уже раскрыт в конфигурационном файле — отлично, но если указан адрес типа 127.0.0.1, придётся искать его. Для этого можно использовать Shodan, вставив туда URL для поиска, и получить нужный адрес (где порт соответствует стандартному порту базы данных; стандартный порт можно узнать с помощью, например, ChatGPT). После этого подключаемся к серверу. Для этого используем, скажем, Visual Studio Code и устанавливаем расширение для подключения к СУБД, например, расширение Database, и подключаемся к базе данных.
Этот процесс можно адаптировать под каждую найденную дорку.
Когда на сервере отсутствует файл index.html или другая страница по умолчанию для отображения содержимого директории, сервер может вернуть страницу с простым списком файлов в этой директории. Это называется "индексирование директории". Запрос "Index of" в Google Dorking используется для нахождения открытых директорий на веб-сайтах, где отображается содержимое серверных папок. Эти страницы могут содержать файлы, которые обычно не должны быть публично доступными, такие как резервные копии, конфиденциальные документы или даже программные скрипты.
Поскольку с помощью дорок можно получить много информации, давайте попробуем найти криптовалютные кошельки. Видоизменим дорку index of из примеров и попробуем найти кошельки: intitle:"index of" .wallet. Насколько я понимаю, такая дорка в основном находит серверы с запущенными нодами блокчейн-сети биткоин, где точка интерпретируется как директория (папка). Убрав точку, можно расширить критерии поиска. Попробуем запрос без точки: intitle:"index of" wallet. После нескольких сайтов мне удалось найти seed-фразу в текстовом файле, но после проверки ещё десятка сайтов ничего подобного больше не обнаружилось. Думаю, что серверов, на которых кто-то додумался сохранить seed-фразу в открытом виде, во всём интернете — считаные десятки. Любую чувствительную информацию нужно тщательно проверять, так что давайте проверим эту seed-фразу. По её виду можно предположить, что она использовалась либо для USDT, либо для блокчейна Tron (или мне так показалось). Проверить seed-фразу можно с помощью чекеров или нескольких приложений, поддерживающих импорт кошельков по seed-фразам. После загрузки нескольких приложений (TronLink, Phantom и другие) выяснилось, что на этих блокчейнах нет ни балансов, ни транзакций.
После этого мне пришла идея проверить файлы с доступами. Возможно, кто-то назовёт файл "доступ.txt". Ведь если люди сохраняют сид-фразы в открытом виде на сервере, то возможно всё. Попробуем дорку intitle:"index of" access.txt. Оказалось, что кто-то придумал эту дорку до меня, так как в выдаче появился линк на exploit database. Однако не всё потеряно, ведь слова в поисковой строке можно комбинировать. После нескольких неудачных попыток с inurl и доменами Google предложил мне запрос: intitle:"index of" inurl:shop access (без .txt на конце). Эта дорка раскрывает директорию плагина Download Monitor для WordPress. Узнав больше о плагине, я нашёл, что для него есть CVE-2021-24786. Внимательно изучив код эксплойта на exploit-db, становится ясно, как он работает: требуется доступ к админке и версия плагина — WordPress Plugin Download Monitor V 4.4.4 - SQL Injection (Authenticated). Версию плагина можно узнать с помощью wpscan командой wpscan --url example.com --enumerate p, либо в корневой директории плагина может быть файл package-lock.json, который также раскроет версию. К сожалению, доступа к админке у меня не было, сервер не позволял прочитать PHP-файлы, а перейти в директорию выше не удалось. Взлому WordPress я планирую посвятить отдельный материал, так что пока отложим эту тему.
Вернёмся к доркам. Их можно модифицировать по-разному. Например, мне пришла идея использовать дорку intitle:"index of" 访问.txt, где "访问" означает "доступ" на китайском. Эта дорка находит определённые сайты, преимущественно тайваньские. Я глубже её не изучал, но это пример того, как можно изменять дорки, даже если они уже известны и описаны.
Если сервер неправильно сконфигурирован, это позволит свободно перемещаться по каталогам. Таким образом, можно, например, найти директорию с сессиями. В файле с сессиями могут содержаться данные, такие как токены. Хотя это не всегда принесёт результаты, можно попробовать использовать эти сессии с помощью расширения StorageAce для Google Chrome, чтобы подменить токены (они могут храниться как в local storage, так и в cookies, а это расширение позволяет заменить данные и там, и там).
Запрос filetype:sql в Google Dorking используется для поиска файлов с расширением .sql. SQL-файлы обычно содержат команды для работы с базами данных, включая создание, модификацию или извлечение данных. Например, давайте возьмём запрос filetype:sql "insert into" (pass|passwd|password) из списка и изменим его на что-то другое, например, filetype:sql "account". Я предполагал, что эту дорку уже нашли до меня, но неожиданно она открыла не SQL-файлы, а публичные GitLab-репозитории. Множество дорок нацелены на GitHub, но, на мой взгляд, искать уязвимости на GitLab интереснее. Главное отличие GitLab от GitHub заключается в том, что GitLab часто используется для приватных репозиториев, и код, обнаруженный там, может быть более ценным. По этому принципу можно протестировать ещё несколько тысяч дорок.
Таким образом, можно менять тип файла в запросе. Например, для поиска баз данных можно использовать запрос inurl:shop index of .db, где .db — это расширение файлов баз данных. Однако все ли базы данных имеют расширение .db? Возьмём, к примеру, базу данных MongoDB. Мне не удалось развить эту гипотезу дальше, и я не видел такой дорки нигде, так что, возможно, она до сих пор не используется. Суть в том, что старые версии MongoDB (с 3.2 до 4.x.x) использовали расширение .wt. .wt — это файлы данных, используемые движком WiredTiger. Дорка intitle:"index of" wt mongo позволяет обнаружить такие серверы.
Мы можем найти инструкцию по открытию этих файлов на Stack Overflow — Restoring MongoDB using only .wt files. Скачиваем MongoDB отсюда: MongoDB Community. Следуя инструкции, я столкнулся с ошибкой, которая указывает на несовместимость версий. Как я понимаю, для открытия таких файлов необходима MongoDB версии 4, которая больше недоступна для скачивания с официального сайта. Сайты с базами данных, найденные по этому запросу, не показались мне особо интересными, так что я отложил эту идею. Однако по такому принципу можно тестировать различные NoSQL СУБД.
Возвращаясь к SQL-доркам, я заметил, что многие из них нацелены на файлы .php (более подробно о точках возникновения я расписывал в предыдущей статье). Однако современные сайты активно используют JavaScript-фреймворки. Чтобы понять, в каких точках могут возникнуть уязвимости, можно изучить репозитории на GitHub и посмотреть, как строятся приложения на тех или иных фреймворках. Либо просто убрать .php из дорки, поскольку расширение .js не будет присутствовать в строке, но логика работы страницы может быть сохранена.
Подводя итоги, дорки — это как лудомания: очень интересная история, полная неожиданных находок и возможностей. Они открывают двери в мир, где можно обнаружить уязвимости и конфиденциальную информацию, а также многое другое. Трям! Пока!
Эксклюзивно для форума: xss.is
Ты в системе, игра начинается, на связи miserylord!
Что такое дорки, какие принципы помогают освоить самостоятельное написание дорков, что можно получить с их помощью и как извлечь информацию с найденных сайтов? Эта статья ответит на все эти вопросы.
Что такое дорки?
Этимология слова, насколько я понимаю, происходит от английского "dork", что переводится как что-то грубее, чем "придурок". В контексте Google дорки — это способ обнаружения чувствительной информации с использованием так называемых операторов поиска. Под дорками также подразумеваются администраторы или программисты, которые допустили утечку данных. Удивительно, но, кажется, не существует официальной документации по операторам поиска, однако частично тема раскрыта здесь. В целом, это первая тема, с которым стоит ознакомиться.
Как написать собственные дорки?
На самом деле алгоритм удивительно прост: изучаем существующие дорки, созданные кем-то до нас, анализируем их ценность и информацию, которую они предоставляют, выясняем причины появления уязвимостей, а затем создаём свои дорки, изменяя компоненты или задаваясь вопросом, в каких ситуациях можно получить аналогичные данные. Повторив этот процесс несколько тысяч раз, вы, вероятно, начнёте генерировать уникальные дорки, особенно если глубоко понимать принципы работы и технологии веб-приложений. Это лучший способ, который я нашёл. На этом этапе можно переходить к практике.
Где взять базу существующих дорков? Самая популярная база — это exploit database: Google Hacking Database (GHDB). Также списки можно найти на форумах или в каналах социальных сетей. Например, можно взять список с GitHub: SQL-Injection-Google-Dork-List.
Теперь переходим к практике!
Область применения
В примере я использовал дорки, нацеленные на SQL-инъекции. Подробнее о том, что такое SQLi, можно узнать в этой статье, но с помощью дорок можно искать практически любую информацию. Например, возьмём уязвимость открытого редиректа. Она возникает, когда приложение не проверяет корректность данных и позволяет перенаправлять пользователей на сторонние URL-адреса без достаточной проверки или фильтрации. Эта уязвимость часто встречается, поскольку даже крупные программы багбаунти не всегда платят за её нахождение. Однажды я читал, что её можно использовать для превращения приложения в бесплатный прокси, но на практике это не работает так, как кажется. Тем не менее, обнаружить её можно с помощью дорок — вот пример Open Redirect Dorks. Таким образом, с дорками можно искать различные типы уязвимостей.
Как работать с дорками?
После того как найдена дорка, важно уметь с ней работать и извлекать информацию. Возьмём, к примеру, дорку shop intitle:"index of" docker-compose.yml. Что с ней делать? Во-первых, нужно разобраться, что такое docker-compose.yml. Это конфигурационный файл, который используется для определения и управления многоконтейнерными Docker-приложениями. Изучив его, можно понять, что в нём могут храниться переменные окружения, и если они неправильно настроены (например, не вынесены в файл .env), это может привести к утечке данных, таких как доступ к базе данных.
Теперь вопрос — как подключиться к базе данных? В первую очередь нужно узнать её адрес. Если он уже раскрыт в конфигурационном файле — отлично, но если указан адрес типа 127.0.0.1, придётся искать его. Для этого можно использовать Shodan, вставив туда URL для поиска, и получить нужный адрес (где порт соответствует стандартному порту базы данных; стандартный порт можно узнать с помощью, например, ChatGPT). После этого подключаемся к серверу. Для этого используем, скажем, Visual Studio Code и устанавливаем расширение для подключения к СУБД, например, расширение Database, и подключаемся к базе данных.
Этот процесс можно адаптировать под каждую найденную дорку.
Великий "Index of"
Когда на сервере отсутствует файл index.html или другая страница по умолчанию для отображения содержимого директории, сервер может вернуть страницу с простым списком файлов в этой директории. Это называется "индексирование директории". Запрос "Index of" в Google Dorking используется для нахождения открытых директорий на веб-сайтах, где отображается содержимое серверных папок. Эти страницы могут содержать файлы, которые обычно не должны быть публично доступными, такие как резервные копии, конфиденциальные документы или даже программные скрипты.
Поскольку с помощью дорок можно получить много информации, давайте попробуем найти криптовалютные кошельки. Видоизменим дорку index of из примеров и попробуем найти кошельки: intitle:"index of" .wallet. Насколько я понимаю, такая дорка в основном находит серверы с запущенными нодами блокчейн-сети биткоин, где точка интерпретируется как директория (папка). Убрав точку, можно расширить критерии поиска. Попробуем запрос без точки: intitle:"index of" wallet. После нескольких сайтов мне удалось найти seed-фразу в текстовом файле, но после проверки ещё десятка сайтов ничего подобного больше не обнаружилось. Думаю, что серверов, на которых кто-то додумался сохранить seed-фразу в открытом виде, во всём интернете — считаные десятки. Любую чувствительную информацию нужно тщательно проверять, так что давайте проверим эту seed-фразу. По её виду можно предположить, что она использовалась либо для USDT, либо для блокчейна Tron (или мне так показалось). Проверить seed-фразу можно с помощью чекеров или нескольких приложений, поддерживающих импорт кошельков по seed-фразам. После загрузки нескольких приложений (TronLink, Phantom и другие) выяснилось, что на этих блокчейнах нет ни балансов, ни транзакций.
После этого мне пришла идея проверить файлы с доступами. Возможно, кто-то назовёт файл "доступ.txt". Ведь если люди сохраняют сид-фразы в открытом виде на сервере, то возможно всё. Попробуем дорку intitle:"index of" access.txt. Оказалось, что кто-то придумал эту дорку до меня, так как в выдаче появился линк на exploit database. Однако не всё потеряно, ведь слова в поисковой строке можно комбинировать. После нескольких неудачных попыток с inurl и доменами Google предложил мне запрос: intitle:"index of" inurl:shop access (без .txt на конце). Эта дорка раскрывает директорию плагина Download Monitor для WordPress. Узнав больше о плагине, я нашёл, что для него есть CVE-2021-24786. Внимательно изучив код эксплойта на exploit-db, становится ясно, как он работает: требуется доступ к админке и версия плагина — WordPress Plugin Download Monitor V 4.4.4 - SQL Injection (Authenticated). Версию плагина можно узнать с помощью wpscan командой wpscan --url example.com --enumerate p, либо в корневой директории плагина может быть файл package-lock.json, который также раскроет версию. К сожалению, доступа к админке у меня не было, сервер не позволял прочитать PHP-файлы, а перейти в директорию выше не удалось. Взлому WordPress я планирую посвятить отдельный материал, так что пока отложим эту тему.
Вернёмся к доркам. Их можно модифицировать по-разному. Например, мне пришла идея использовать дорку intitle:"index of" 访问.txt, где "访问" означает "доступ" на китайском. Эта дорка находит определённые сайты, преимущественно тайваньские. Я глубже её не изучал, но это пример того, как можно изменять дорки, даже если они уже известны и описаны.
Если сервер неправильно сконфигурирован, это позволит свободно перемещаться по каталогам. Таким образом, можно, например, найти директорию с сессиями. В файле с сессиями могут содержаться данные, такие как токены. Хотя это не всегда принесёт результаты, можно попробовать использовать эти сессии с помощью расширения StorageAce для Google Chrome, чтобы подменить токены (они могут храниться как в local storage, так и в cookies, а это расширение позволяет заменить данные и там, и там).
filetype
Запрос filetype:sql в Google Dorking используется для поиска файлов с расширением .sql. SQL-файлы обычно содержат команды для работы с базами данных, включая создание, модификацию или извлечение данных. Например, давайте возьмём запрос filetype:sql "insert into" (pass|passwd|password) из списка и изменим его на что-то другое, например, filetype:sql "account". Я предполагал, что эту дорку уже нашли до меня, но неожиданно она открыла не SQL-файлы, а публичные GitLab-репозитории. Множество дорок нацелены на GitHub, но, на мой взгляд, искать уязвимости на GitLab интереснее. Главное отличие GitLab от GitHub заключается в том, что GitLab часто используется для приватных репозиториев, и код, обнаруженный там, может быть более ценным. По этому принципу можно протестировать ещё несколько тысяч дорок.
Таким образом, можно менять тип файла в запросе. Например, для поиска баз данных можно использовать запрос inurl:shop index of .db, где .db — это расширение файлов баз данных. Однако все ли базы данных имеют расширение .db? Возьмём, к примеру, базу данных MongoDB. Мне не удалось развить эту гипотезу дальше, и я не видел такой дорки нигде, так что, возможно, она до сих пор не используется. Суть в том, что старые версии MongoDB (с 3.2 до 4.x.x) использовали расширение .wt. .wt — это файлы данных, используемые движком WiredTiger. Дорка intitle:"index of" wt mongo позволяет обнаружить такие серверы.
Мы можем найти инструкцию по открытию этих файлов на Stack Overflow — Restoring MongoDB using only .wt files. Скачиваем MongoDB отсюда: MongoDB Community. Следуя инструкции, я столкнулся с ошибкой, которая указывает на несовместимость версий. Как я понимаю, для открытия таких файлов необходима MongoDB версии 4, которая больше недоступна для скачивания с официального сайта. Сайты с базами данных, найденные по этому запросу, не показались мне особо интересными, так что я отложил эту идею. Однако по такому принципу можно тестировать различные NoSQL СУБД.
.php
Возвращаясь к SQL-доркам, я заметил, что многие из них нацелены на файлы .php (более подробно о точках возникновения я расписывал в предыдущей статье). Однако современные сайты активно используют JavaScript-фреймворки. Чтобы понять, в каких точках могут возникнуть уязвимости, можно изучить репозитории на GitHub и посмотреть, как строятся приложения на тех или иных фреймворках. Либо просто убрать .php из дорки, поскольку расширение .js не будет присутствовать в строке, но логика работы страницы может быть сохранена.
Подводя итоги, дорки — это как лудомания: очень интересная история, полная неожиданных находок и возможностей. Они открывают двери в мир, где можно обнаружить уязвимости и конфиденциальную информацию, а также многое другое. Трям! Пока!