Conti Ransomware malware leak WITH LOCKER
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 

221 lines
9.3 KiB

АДМИНКА И BACKEND ДЛЯ СКАНЕРОВ ПАРОЛЕЙ И УЯЗВИМОСТЕЙ
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
НАЗНАЧЕНИЕ
Система осуществляет две функции:
1) координация и управление распределенной сетью сканеров; распределение задач между ними
2) пользовательский интерфейс для просмотра и выгрузки данных.
ОБЩИЕ СВЕДЕНИЯ
Сканеров много и они организованы в распределенную сеть.
Каждому сканеру нужны две вещи:
- входные данные (источник списка доменов для сканирования; словари для перебора, правила итд)
- куда отправлять результат.
Чтобы КПД сканирования был высоким, деятельность сканеров нужно координировать: выдавать каждому сканеру
оптимальный c т.зрения распределения ресурсов участок сканирования.
Для этого наш бэкенд должен вести учет: что кому выдано, и что кем обработано.
В данной реализации мы будем дробить на участки только список доменов.
Словари не дробим; считается, что модуль должен по каждому домену прогнать полный словарь.
Рассчитывать на то, что типов сканеров есть несколько. Соответственно, каждому типу сканеров
нужен свой раздел - в БД все данные хранятся в разрезе "тип сканера".
Текущие типы сканеров:
- сканер RDP (имя в API: rdp)
- сканер OWA (Outlook Web Access) (имя в API: owa)
- сканер уязвимостей веб-сайтов (SQLScan) (имя в API: sql)
Настройки для всех типов сканеров:
- список доменов (сейчас используется TOP Alexa https://s3.amazonaws.com/alexa-static/top-1m.csv.zip; формат файла и упаковка должны быть такими же)
- размер участка сканирования (выбирается пропорционально размеру сети) - целое неотрицательное число
- время сохранения участка за конкретным сканером - целое неотрицательное число секунд; по умолчанию 4 суток; далее подбираем эмпирически
Настройки для сканера RDP (отдается в ответ на запрос от сканера - приведены имена настроек и значения):
- режим работы: mode (brute|check)
- словарь (словари) паролей: dict (текстовый файл в упаковке gzip)
- частота отправки результатов на сервер: freq (число секунд >= 0; 0 - означает немедленно по готовности следующего пароля;
не 0 - не чаще чем раз в Х секунд ожидаем накопленную пачку)
Настройки для сканера OWA:
- словарь пар "логин:пароль": dict (текстовый файл в упаковке gzip)
Настройки для сканера SQLScan:
- правила: rules (текстовый файл)
Размер чанка (куска общего списка) должен рассчитываться по следующим критериям:
- он должен быть минимально возможным, чтобы при входе новых безработных ботов в сеть им было что выдать
- время обработки чанка одним ботом не должно превышать некой небольшой величины, например одного часа
К примеру, для одного потока RDP наихудшее время одного подбора может занимать 120 секунд. Следовательно,
обработка 500 комбинаций "логин/пароль" займет 500*120=60000 секунд, т.е. почти сутки.
Под размер чанка должна подгоняться настройка "время сохранения участка за конкретным сканером" - она должна быть примерно равна
полуторакратному времени прохода одного чанка одним ботом.
API BACKEND
API выполнить на основе HTTP-сервера.
По умолчанию, на корректные запросы система отвечает HTTP 200 OK,
на некорректные - HTTP 404 Not Found.
В более широком смысле, все что не 200 считается ошибочным состоянием.
Сервер всегда должен отдавать заголовок Content-Length.
Избегать выдачи длины по Content-Disposition: chunked либо по Connection: close.
Все URL API начинаются с группы /group/clientid/
где
group - группа бота
clientid - id бота
Перед ответом на запрос система обязана проверить формальную корректность группы и ИД,
и отвергнуть запрос, если параметры некорректны.
Валидация группы: от 4 до 6 символов; первые 3 символа - латиница в нижнем регистре, последние 1..3 символа - цифры
Валидация ИД: это строка в верхнем регистре, состоящая из двух компонентов, разделённых точкой.
Первая часть имеет формат <name>_XYYYYYYY, где name - это некоторое имя, которое может как-то идентифицировать машину
(имя компьюетра или имя пользователя, в зависимости от типа операционной системы),
X - символ обозначающий тип системы на которой работает клиент (W - windows, L - linux, A - андроид, M - Mac OS),
YYYYYYY - 3-7 цифр содержащих major-version, minor-version и build операционной системы если таковые имеются у системы
(например, длЯ 6.1 build 7600 это будет 617600).
Вторая часть содержит 32 случайных символов 0-9, A-F.
Пример id клиента - QWERTY_W617600.11223344556677889900AABBCCDDEEFF.
GET /group/clientid/scantype/settingname HTTP/1.1
Получить конкретные настройки по имени настройки (settingname) для данного типа сканера.
Тело ответа варьируется в зависимости от настройки
GET /group/clientid/scantype/domains HTTP/1.1
Получить участок доменов для сканирования.
scantype - тип сканера.
Система выбирает следующий участок списка доменов, помечает его как занятый за данным сканером
с отметкой даты-времени.
В ответ отдается список доменов как простой текст; разделитель строк \r\n
Content-Type: text/plain
Если данный участок был занят этим же самым клиентом,
мы вновь отдаем модулю этот участок. Это штатная ситуация, означающая
перезагрузку модуля без сохранения состояния.
Если данный участок уже занят другим сканером того же типа,
смотрим на настройку "время сохранения"; если бывший владелец участка его не освободил за это время,
и от него не было сигналов, участок освобождаем и переназначем.
Если же участок действительно занят, ответ 404 Not Found.
GET /group/clientid/scantype/over HTTP/1.1
Сигнал от сканера, что участок обработан
В ответ всегда отдаем HTTP 200 OK, вне зависимости от ситуации.
Проверяем, действительно ли участок был за этим модулем, если да - помечаем как обработанный.
Если нет - пишем ошибку в лог.
Тело ответа - как на запрос /domains
Выбирается следующий свободный участок, назначается модулю и отдается в ответе.
Если свободных участков нет, отдается код 404.
GET /group/clientid/scantype/dict HTTP/1.1
Запрос словаря для данного типа сканера.
В ответ - словарь в том виде, как он загружен в админку.
Content-Type: text/plain или application/gzip
POST /group/clientid/81 HTTP/1.1
Намайненные сканером данные
Тело запроса - контейнер multipart/form-data со следующими полями:
data - бинарные данные размером до 32к - это собственно данные, которые нужно распарсить
source - UTF-8 строка длиной до 4096 байт - содержит указание на тип сканера (к примеру, "OWA Passwords")
Любые другие поля в посылке игнорируются, но ошибкой не считаются.
По умолчанию, в data приходит текст UTF-8 в следующем формате:
resource|login|password\n
Конец строки может быть как Unix (\n), так и DOS (\r\n)
resource - это место, куда подходит пароль (например URL. Или тип мессенджера. Или IP-адрес хоста. ИТД).
login
password - понятно
В такой записи могут быть доп.поля с разделителем | (вертикальная черта)
В ответ сервер должен выдать
HTTP 200 OK
Content-Type: ...
Content-Length: ...
/1/
ПАНЕЛЬ УПРАВЛЕНИЯ
Панель управления должна содержать следующие разделы:
* dashboard
* настройки сканеров
* данные со сканеров
На dashboard мы видим сводку по работе сканеров с момента последнего обновления списка доменов.
По каждому сканеру следующая инфа:
- круговые диаграмма с процентом "обработано/не обработано"
- размер участка сканирования
- дата-время последнего обновления списка доменов
- всего уникальных ботов работает по данному типу сканирования
- всего логинов/уязвимостей найдено
В настройках сканеров, для каждого типа сканера можно загрузить данные для него:
- список доменов
- словари
- что там еще.
При обновлении списка доменов или словарей очищается состояние выданных участков по данному сканеру,
очищается вся статистика (в dashboard), и выдача участков начинается сначала.
Потому при сохранении учитывать случай отсутствия изменений в конфигурации, чтобы не аннулировать результаты работы сети.
В разделе "данные со сканеров", на каждый тип сканера отдельная вкладка или страница.
На ней мы видим таблицу с полями
- дата-время отстука
- clientid
- group
- IP address
- полученные данные
По полям возможна сортировка и фильтрация.
а также кнопку "скачать дамп".
По кнопке получаем данные за всю историю работы.
***
[10:49:01] <A> Report interval, seconds подсказка The module will report every N seconds about its status
[10:49:35] <A> Fetch request, seconds подсказка The module will upload the vulnerabilities found to the server every N seconds
[10:50:44] <A> Rules переименуй в Scan Rules
[10:51:11] <A> подсказка These are the scan rules for the module. XML format is
[10:52:36] <A> <rules>
<rule>
<name>rule name</name>
<type>time|diff (one of these two options)</type>
<value1>probe value 1</value1>
<value2>probe value 2</value2>
<value3>probe value 3</value3>
</rule>
...
<rule>
...
</rule>
</rules>
[10:52:52] <A> CHANGE IT ONLY WHEN YOU KNOW WHAT YOU ARE DOING!
[10:54:04] <A> Domains подсказка These are the Internet domains to scan
[10:54:22] <A> Format is: plain text file; one domain per line; line separator is \n
[10:54:26] <A> Example:
[10:54:29] <A> www.site.com
[10:54:33] <A> domain.com
[10:54:34] <A> etc
[10:55:16] <A> Thead (1..10) переименуй в Scan threads number (1..10)
[10:56:31] <A> Time threshold (0..40) переименуй в Time threshold for time difference rules, seconds (0..40)
[10:58:35] <A> подсказка Time difference rule finds vulnerability by comparing injected and non-injected page loading time
[10:59:05] <A> Threshold (0..1000) переименуй в Char threshold (0..1000) (number of characters)
[11:01:09] <A> подсказка This value determines injection success for difference rules. When the injected page differs from the non-injected page by this number of characters