WP-Syntax - это самый популярный плагин для wordpress для подсветки кода. Его используют на многих сайтах, например Стефан Эссер использует его на своем блоге. Для меня этот плагин представлял интерес, так как обнаружил его в блоге довольно крупной фарма-партнерки. Проведя анализ исходного кода, я нашел достаточно необычную уязвимость, поэтому решил создать отдельную тему. Возможно у кого-нибудь возникнут замечания или мысли по поводу более изящного решения.

WP-Syntax использует библиотеку GeSHi, которая и реализует весь функционал по разбору синтаксиса и составления соответствующего для каждого языка html-кода. Разобрав главный скрипт плагина wp-syntax.php, я перешел к папке test, где хранилось 2 скрипта: index.php и code.php. Code.php содержал примеры кода для разных языков, а index.php выводил их с подсветкой для демонстрации возможностей плагина. Index.php инклудит wp-syntax.php, который в свою очередь подключает geshi.php. По замыслу разработчика wp-syntax.php может вызываться только из контекста WP, в то время как test/index.php может запускаться независимо от платформы, при этом автор решил использовать самопальное подобие механизма WP для выполнения callback-функций. Кто знаком с внутренним устройством WP или хотя бы видел часть кода может понять, что я говорю о функциях add_action(), do_action(), apply_filters() и др.

Самореализованная ф-ция apply_filters выглядит следующим образом:

Глобальный массив test_filter нигде ранее не инициализируется, поэтому появляется возможность добавить в него произвольные элементы при register_globals=on и впоследствии выполнить любую функцию с помощью call_user_func_array. В WP есть специальная ф-ция - unregister_globals, защищающая от подобных уязвимостей, но здесь другой случай - скрипт работает вне контекста WP.
apply_filters вызывается в нескольких местах, один их них:

Как видим сложность данного случая заключается в том, что нельзя выполнить функцию с произвольными аргументами - будет передаваться один пустой аргумент с типом string. С первого взгляда мне показалось, что даже банальный phpinfo() выполнить не удастся, так как он принимает аргумент только с типом integer, иначе возникнет ошибка уровня E_WARNING. Однако вникнув в логику ф-ции apply_filters становится ясным, что изменить аргумент для call_user_func_array() можно, так как она выполняется в цикле и присваивает свой результат аргументу для следующей callback-функции. Иначе говоря с помощью специально составленной цепочки функций можно бы было получить -1 и передать это значение в phpinfo (-1 = INFO_ALL). Тут я начал вспоминать все функции PHP, которые могли бы мне помочь в данной ситуации. Как оказалось многие функции, не принимающие аргументов, вызывают ошибку, если предать в них пустое значение. Тем не менее, нужная мне последовательность вызовов функций была найдена:

http://localhost/wp/2.7/wp-content/plugins/wp-syntax/test/index.php?test_filter[wp_head][99][0]=pi&test_filter[wp_head][99][1]=cos&test_filter[wp_head][99][2]=phpinfo

Сперва вызывается функция pi(), возвращающая значение числа pi. Как ни странно, эта функция, несмотря на отсутствие принимаемых аргументов, не вызывает ошибку "Wrong parameter count for". Далее идет вызов функции cos(), в которую передается значение числа pi. Как известно, cos(pi) = -1, поэтому в phpinfo() попадает нужное значение и выводятся все данные.

Казалось большего уже не достичь, но я продолжал поиск способа для выполнения произвольных команд. Необходимо было найти функцию, которая возвращала бы нужные для меня данные. Эти данные можно бы было получить из окружения, но подходящих функций не попадалось. Однако способ все-таки был найден =)
Ф-ция session_id() может как возвращать значение текущего идентификатора сессии, так и устанавливать его, если был передан аргумент. Мне естественно нужно было получить значение, но как быть с пустым параметром, который постоянно передавался? Я решил проверить возвращаемые значения таким скриптом:

Выяснилось, что session_id возвращает значение прошлого идентификатора, несмотря на то, что в функцию был передан параметр. Не знаю баг это или нет, но в доках по этому поводу ничего не сказано. В итоге финальный запрос выглядит следующим образом:

Спасибо за внимание, надеюсь было интересно =)

__________________
<? Raz0r.name — блог о web-безопасности

ну в session_id запихнуть можно только буквы и цифры, поэтому особо раздолья нет, вот помучал немного :
ну и куку PHPSESSID=ZXZhbCgkX0dFVFtxXSk7ICAK

также еще есть в пхп функция get_browser(), но по дефолту ее в php.ini надо настраивать, а так можно былобы через юзер агента текст нужный пихать.

Насчет get_browser() тоже думал, но эта функция действительно мало, гда работает.
Если в PHPSESSID помещать данные в base64, то нужно составлять такие строки, чтобы в них не было символов =.
Функция call_user_func_array() не допускает использование eval() в качестве callback'а, но твой способ обхода этого ограничения с помощью assert() очень порадовал =)

__________________
<? Raz0r.name — блог о web-безопасности

>cкажите имея логин/хеш от версии 2.5 и SECRET_KEY, подставить кукис можно или нет?
перелистай тему, выкладывали тут тулзу для этого.
можно, только если кей из wp-config.php оставлен дефолтным

Attack: Denial Of Service
Required cookies: GLOBALS=<anything>
Triggering file: index.php (just an example, basically any file including the
affected file)
Affected file: wp-settings.php
Effect: no request is processed as it aborts because of the presence of
GLOBALS in $_REQUEST

Attack: Deletion of users
Required cookies: action=dodelete, delete_option=delete, users[]=n (where n is
an integer)
Triggering file: wp-admin/users.php
Affected file: wp-admin/users.php
Note: this doesn't affect etch's version as it correctly uses $_POST

Attack: Denial Of Service
Required cookies: action=logout
Triggering file: wp-login.php
Affected file: wp-login.php
Effect: redirection loop, preventing the user from logging in

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504771
http://trac.wordpress.org/ticket/8814

XSS wp-slimstat 0.92

by Ryat[puretot]
mail: puretot at gmail dot com
team: http://www.80vul.com
date: 2008-12-18
Подробности уязвимости

wp-admin/post.php

Итак, представим, что у нас уже есть доступ к бд и нам необходимо закрепиться на блоге. Для этого создаем нового юзера, даем ему права админа и в бд в таблице wp_usermeta в поле first_name с ИД нашего юзера прописываем:
В итоге, наш админчег не будет виден на странице wp-admin/users.php =)
Для версий 2.5-2.7 могут быть свои вариации.

Wordpress Wp-forum plugin 1.7.8 Sql injection vulnerability
exploit:
источник:http://milw0rm.com/