PIDRILA: практическое применение

PIDRILA: практическое применение

BrightSearch


«Сколько нужно нетсталкеров чтобы вкрутить лампочку?»‎

Всем привет!

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

Работающая PIDRILA

Если в двух словах, PIDRILA сейчас представляет собой асинхронную версию Dirbuster с конфигурационным файлом и хорошо документированными параметрами командной строки. Архитектура веб-сканера позволяет не только надежно и быстро работать с множеством целей, но и сканировать сайты в Tor и I2P-сетях через socks-прокси, что очень важно для этичных исследований нашей группы.

Сегодня мы расскажем, как PIDRILA можно применить для быстрого анализа сотен тысяч ссылок с платформы iplogger.org

Несколько слов о нашем сообществе

BrightSearch – это сообщество, основанное на идеях Комитета по Этике Нетсталкинга – чистом исследовании сетей без нарушения целостности чужого частного инфопространства. Мы исследуем только те места, чьи хозяева так или иначе согласны на их посещение; исследование сетевых ресурсов уровня "не для общего пользования" мы считаем неприемлемым и неэтичным.

В Сети есть множество "светлых" узлов, владельцы которых будут только рады, если к ним придут посетители, но, к сожалению, эти ресурсы зачастую остаются неизвестными. Мы это исправим! 

Многие другие сообщества погрязли в использовании blackhat инструментов для перебора паролей, мы призываем не присоединяться к ним и не использовать это ПО, так как считаем такие действия крайне неэтичными. В сети очень много "светлых" источников, каждому хватит и ещё останется. Ищите и обрящете!

Как нетсталкерская PIDRILA хитрого iplogger-а кравлила

Однажды дождливым осенним вечером внимание одного из исследователей BrightSearch привлекла ссылка на iplogger в профиле одного из зашедших в Safespace осинтеров. Сама ссылка перенаправляла пользователей на типичный чат-молчат с автомутом для новичков, не представлявший особого интереса. Исследователь подумал, что часть из подобных ссылок может вести в куда более загадочные и привлекательные для нетсталкеров места, а значит неплохо было бы понять, как именно они генерируются и какими свойствами обладают.

Индексы и кодировки

Для начала анализа исследователь решил просто зайти на сайт и создать несколько перенаправлений, чтобы понять, как будет вести себя их идентификатор.

Пример перенаправления

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

Запрос
Ответ

Исследователь сделал несколько запросов подряд и, после минутной паузы, ещё парочку. Результаты были довольно показательными: индекс оставался тем же, а часть ссылки менялась так, как если бы она являлись перевернутым числом в системе счисления, основанием которой является 56. Числа кодировались набором из десятичных цифр, маленькими и большими буквами латинского алфавита. При этом в адресе исключалось использование цифр 0 и 1, а также литер "l", "o", "O", "I". Все указывало на применение редкой кодировки base56.

Индексы, ссылки и их номера

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

Кравлинг отдельного индекса

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

Генерация словаря для индекса "2u"

Перенаправив вывод Python в pathlist.txt исследователь начал продумывать подходящие опции. Для этичного перебора ссылок необходимо было ограничить количество одновременных подключений к сайту, сохранив при этом достаточно хорошую скорость отправки запросов чтобы кравлинг не занял слишком много времени. Для этого было выбрано использование метода HEAD и 16 одновременных подключений с включенным по-умолчанию Keep-Alive.

Оптимальная конфигурация PIDRILA

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

Анализ и обработка полученных данных

После того как PIDRILA завершил работу исследователь приступил к анализу лога из 721335 ссылок. Базовый анализ с помощью grep показал что большая часть ссылок в индексе пуста, 174к ведут на различные URL сразу, и ещё 32к - через страницу про COVID. И лишь одна уникальная ссылка https://iplogger.org/2uphp вела на 403, что явно связано с используемыми сайтом защитными механизмами.

Результат работы PIDRILA

После этого весь полученный датасет был выложен в канал группы BrightSearch в виде zip-архива.

Вывод

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

Где такое может быть нужно? 

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

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

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

Там, где требуется реализация собственной логики для работы с веб-сервером (например, анализ robots.txt на всех популярных сайтах или поиск всех серверов, возвращающих "Index of"), но где не хочется создавать инструмент для их быстрого сканирования с нуля: любая логика может быть реализована в виде модуля, а затем просто добавлена в PIDRILA через расширение класса ScanManager.

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

Кто знает, может быть перед вами прямо сейчас стоит такая задача? Просто напишите об этом в Точке Сбора или в чате обсуждения PIDRILA, будет очень полезно.

Report Page