Command Injections Ч.1

Введение

Уязвимость Command injection (В дальнейшем CMDi) относится к наиболее критическим типам уязвимостей. Она позволяет нам выполнять системные команды непосредственно на внутреннем сервере хостинга, что может привести к плачевным последствиям. Если веб-приложение использует управляемый пользователем ввод для выполнения системной команды на внутреннем сервере, мы можем внедрить вредоносную полезную нагрузку, чтобы выполнять наши команды.

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

Что такое инъекции?

Уязвимости, связанные с инъекциями, считаются риском номер 3 в OWASP top 10. Внедрение происходит, когда вводимые пользователем данные неверно интерпретируются как часть веб-запроса или исполняемого кода, что может привести к изменению предполагаемого результата запроса на другой результат, полезный для злоумышленника.

В веб-приложениях существует множество типов инъекций, в зависимости от типа выполняемого веб-запроса. Ниже приведены некоторые из наиболее распространенных типов инъекций:

Существует много других типов инъекций, кроме указанных выше, таких как инъекция LDAP, инъекция NoSQL, инъекция заголовка HTTP, инъекция XPath, инъекция IMAP, инъекция ORM и другие. Всякий раз, когда пользовательский ввод используется в запросе без надлежащей очистки, возможно выйти за границы обычного пользователя, на которые рассчитывал разработчик. Вот почему по мере того, как все больше веб-технологий будет внедряться в веб-приложения, мы увидим новые типы инъекций, представленные в веб-приложениях.

Command injection

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

Пример PHP

Например, веб-приложение, написанное на PHP, может использовать функции exec, system, shell_exec, passthru, popen и т.д. для выполнения команд непосредственно на сервере, каждая из которых имеет несколько разные варианты использования. Следующий код является примером кода PHP, уязвимого для внедрения команд:

<?php
if (isset($_GET['filename'])) {
    system("touch /tmp/" . $_GET['filename'] . ".pdf");
}
?>

Данное веб-приложение имеет функцию, позволяющую пользователям создавать новый документ .pdf, который создается в каталоге /tmp с именем файла, предоставленным пользователем, и затем может использоваться веб-приложением для обработки документов. Однако, поскольку пользовательский ввод из параметра имени файла в запросе GET используется непосредственно с командой touch (без предварительной очистки или экранирования), веб-приложение становится уязвимым для CMDi. Эту уязвимость можно использовать для выполнения произвольных системных команд на внутреннем сервере.

Пример NodeJS

Это не уникально для PHP, но может произойти в любой среде или языке веб-разработки. Например, если веб-приложение разработано в NodeJS, разработчик может использовать для той же цели child_process.exec или child_process.spawn. Следующий пример выполняет функции, аналогичные тем, которые мы обсуждали выше:

app.get("/createfile", function(req, res){
    child_process.exec(`touch /tmp/${req.query.filename}.txt`);
})

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

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

Обноружение

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

В данном веб-приложении мы видим утилиту Host Checker, которая запрашивает у нас IP-адрес, чтобы проверить, активен он или нет:

Мы можем попробовать ввести IP-адрес локального хоста 127.0.0.1, чтобы проверить функциональность, и, как и ожидалось, он возвращает вывод команды ping, говорящий нам, что локальный хост действительно активен:

Хотя у нас нет доступа к исходному коду веб-приложения, мы можем предположить, что введенный нами IP-адрес входит в команду ping, поскольку полученные нами выходные данные дико намекают на это. Поскольку результат показывает один пакет, переданный в команде ping, используемая команда может быть следующей:

ping -c 1 IP_INPUT

Если наш ввод не фильтруется до того, как он будет использован с командой ping, мы можем ввести другую произвольную команду. Итак, давайте попробуем выяснить, уязвимо ли веб-приложение для CMDi.

Способы осуществления CMDi

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

Мы можем использовать любой из этих операторов для ввода другой команды, чтобы выполнялись обе или одна из команд. Мы запишем ожидаемый ввод (например, IP), затем используем любой из вышеперечисленных операторов, а затем напишем нашу новую команду: 127.0.0.1;whoami.

Воспользуемся BurpSuite для удобства и кодировки URL.

Итак, мы видим, что сервер нам отвечает, что пользователь, от лица которого выполняется команда www-data. Есть выполнение произвольных команд!

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