Про Web-хакинг было рассказано уже столько, что вполне можно начинать составлять целые тома с описанием процессов взлома разных движков CMS, форумов, фреймворков. И может показаться, что взлом Web-ресурсов превратился в некую рутину, в которой нет места творчеству: все те же SQL-инъекции, lfi, rfi и т.п. Но это абсолютно не так! Данная тема настолько обширна и необъятна, что предсказать то, как будет осуществлен конкретный взлом, и какие особенности атакуемой системы будут при этом использованы, заранее невозможно. Сегодня я расскажу тебе о том, каким образом она была использована при реальной атаке сайта и получении доступа к аккаунту на площадке хостера.

 

Первые шаги

Все началось довольно прозаично: читая почту в Gmail, я наткнулся на новостную ссылку с информацией о найденной ошибке в компоненте Joomla jresearch. Более подробная информация говорила о том, что эта ошибка была типа local file including (lfi). Бага заключалась в не обработанной должным образом функции require_once(), которая подгружала исходные тексты дополнительных классов, находящихся во внешних файлах. В общем, все стандартно, но мне захотелось опробовать ошибку в действии. Зарядив в поисковике запрос на поиск в URL jresearch, я стал искать объект для исследования, и мне на глаза попался научно-популярный редиско-сайт rediscoverscience.com. Замечательная кандидатура.

Первое, что полетело в качестве привета на сайт, был модифицированный эксплойт с багтрекера:

http://rediscoverscience.com/component/jresearch/?task=show&view=publication&id=18&controller=../../../../../../../../../../etc/passwd%00

К моему удивлению отобразился достаточно большой список пользователей сервера. Хеши паролей хранились в shadow. Брутить сервисы по найденным логинам мне не хотелось, да и не нужно мне это было :). Моей целью на тот момент была максимальная раскрутка ошибки просто ради спортивного интереса.

Уже с самого начала было понятно, что сайт работает на CMS Joomla, а все самое интересное, как известно, находится в ее конфигурационном файле – configuration.php (в этом файле лежат различные настройки сайта, в том числе пароли к FTP и базе данных). Именно этот файл я выбрал для дальнейшего исследования. Естественно, что его инклуд ничего интересного не дал: PHP просто выкинул пустую страницу (все настройки сайта хранятся в виде PHP-класса). Поэтому мне необходимо было найти возможность выполнения произвольного PHP-кода для того, чтобы прочитать содержимое конфига.

 

В погоне за конфигом

Попытка инклуда логов обломалась из-за установленных квот на потребление памяти интерпретатором. Был еще один путь: проинклудить залитый на сервер графический файл с вставленным в него PHP-кодом, благо форум на сайте был, но это не был путь истинного йога. Поэтому, заново посмотрев эксплойт, который находился в ссылке новости, я обратил внимание, что в нем происходит инклуд файла виртуальной файловой системы proc: /proc/self/environ, который незаслуженно в самом начале был заменен на /etc/passwd. В этом файле находится вся информация о переменных окружения процесса, который обращается к данному файлу. И если посмотреть на то, что выдал мне сервер, после обращения по ссылке:

http://rediscoverscience.com/component/jresearch/?task=show&view=publication&id=18&controller=../../../../../../../../../../../../proc/self/environ%00

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

  • DOCUMENT_ROOT – корень документов сайта;
  • SERVER_ADDR – IP-адрес сервера;
  • SCRIPT_FILENAME – полный путь до index.php;
  • HTTP_USER_AGENT – название агента, с помощью которого юзер браузит по инету;
  • HTTP_COOKIE – содержимое передаваемых кукисов и т.п.

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

Не знаю почему, но мне захотелось сделать инклуд PHP-кода через кукисы. Сначала значение кукиcа "ja_purity_tpl", в котором хранилось имя модификации шаблона CMS, был заменено на <? phpinfo(); ?>. После инклуда /proc/self/environ ничего интересного не произошло. Просмотрев содержимое переменной, я обнаружил, что оно по каким-то причинам обрезалось. Изменение значения переменной "__utma" на <? phpinfo(); ?> также не принесло результатов: содержимое и этой переменной опять было обрезано.

После того, как возня с кукисами прекратилась, в дело пошла модификация заголовка user-agent.

После того, как я заменил значение заголовка на свой любимый <? phpinfo(); ?> и проинклудил переменные окружения PHP, передо мной отобразилось великолепие разных данных по текущим настройкам PHP.

Посмотрев полный путь до папки сайта на сервере и сформировав полный путь до configuration.php, я, недолго думая, заменил user-agent на команду чтения файла, получилось нечто похожее на это:

<? readfile("/home/redisco3/public_html/configuration.php"); ?>

А затем заново проинклудил вывод файла /proc/self/environ. Посмотрев внутрь страницы, я обнаружил виновника всего этого торжества – configuration.php.

 

В дебрях procfs

Лезть в базу и добавлять юзеров для доступа к админке не хотелось. Ибо CMS отображает последних посетителей админки, что могло вызвать подозрение, а удалять эту инфу потом мне просто было бы лениво. Поэтому я полез разбираться дальше. Опять с помощью файлов, находящихся в proc, я нашел очень много полезной информации: инклуд /proc/cpuinfo сообщил, что сервер работал на четырехядерном xeon'e, а /proc/version показал очень интересный результат:

Linux version 2.6.31.9-grsec (root@web55.justhost.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Thu Feb 25 02:14:17 CST 2010

Версия ядра меня не заинтересовала, но заинтересовал хостинг, и мне захотелось проверить аутентификационные данные из файла конфигурации для доступа к cpanel. Перейдя на сайт хостинговой компании, я попробовал залогиниться с логином и паролем от FTP. Логин прошел успешно, и у меня оказался полноценный доступ к панели.

 

Зарабатываем хорошую карму

Закончилось все также прозаично, как и началось: я закрыл брешь на сайте и написал администратору сайта письмо с сообщением об уязвимости и несколькими советами. В общем, даже если кажется, что вам все известно, то не надо останавливаться в своем развитии. Продолжай искать и зарабатывай хорошую карму :).

 

Дополнительная информация про ProcFS

ProcFS (сокращение от process file system) – это виртуальная файловая система, используемая во многих Unix-like операционных системах для получения информации о системных процессах из ядра. Эта файловая система чаще всего монтируется в директорию /proc. И, так как /proc динамически создается, а не хранится, ее размер ограничен только объемом оперативной памяти. ProcFS поддерживается Linux, Solaris, BSD, QNX и другими ОС.

Некоторые файлы и директории из ProcFS:

  • /proc/PID/cmdline – аргументы командной строки (где PID – идентификатор процесса или self);
  • /proc/PID/environ – переменные окружения для данного процесса;
  • /proc/PID/status – статус процесса;
  • /proc/PID/fd – директория, содержащая символьные ссылки на каждый открытый файловый дескриптор;
  • /proc/cpuinfo – информация о процессоре (производитель, модель, поколение и т.п.);
  • /proc/cmdline – параметры, передаваемые ядру при загрузке;
  • /proc/uptime – количество секунд, прошедших с момента загрузки ядра и проведенных в режиме бездействия;
  • /proc/version – содержит информацию о версии ядра, компилятора и другую информацию, связанную с загруженным ядром.
 

Ссылки по теме

 

WARNING

Внимание! Информация представлена исключительно с целью ознакомления. Ни автор, ни редакция за твои действия ответственности не несет.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии