Уязвимость WordPress позволяющая внедрить произвольный контент на страницу.

В контексте данной уязвимости нaс интересует роут /wp­json/wp/v2/posts.

Так как я только что установил WordPress 4.7.1, то в блоге один­единственный пост — «Hello World!». Давай попробуем его изменить и посмотрим ближе на причины уязвимости.

Вот класс, который отвечает за обработку запросов к posts.

wp­includes/rest­api/endpoints/class­wp­rest­posts­controller.php:

Регулярка проверяет, чтобы в качестве ID поста передавалось только числовое значение. Однако при детальном рассмотрении того, как WP обрабатывает пользовательские данные, ты увидишь, что параметры, которые юзер передал через $_POST и $_GET, приоритетнее тех, что генерирует регулярное выражение. Это нетрудно выяснить опытным путем. Для демонстрации я создал еще одну запись в блoге (ID=4) и теперь обращусь к API с таким запросом: /wp­json/wp/v2/posts/1?id=4.

Ага! Прочлась запись с ID=4 «Sample post for priority check», а не «Hello World!», как предполагалось. Теперь регулярка не сможет ограничить нас только числами, и можно передать что­то вроде 4qwe в качестве ID. API вернет нам ту же самую запиcь, значит, где­то в коде используется приведение типов. Запомним этот момент и двинемся дальше — к возможности редактирования постов.

[ad name=»Responbl»]

Как ты, наверное, знаешь, изменять данные в REST API можно с помощью POST­зaпросов. В нашем случае, чтобы отредактировать запись с id=, я должен отправить запрос на /wp­ json/wp/v2/posts/1. Разумеется, если я попробую это сделать, то получу от ворот поворот в виде ошибки «Sorry, you are not allowed to edit this post».

097:  array(
098:   'methods'             => WP_REST_Server::EDITABLE,
099:   'callback'            => array( $this, 'update_item' ),
100:   'permission_callback' => array( $this, 'update_item_permissions_che
101:   'args'                => $this­>get_endpoint_args_for_item_schema(
102:  ),
    

За проверку прав отвечает метод update_item_permissions_check.

wp­includes/rest­api/endpoints/class­wp­rest­posts­controller.php:

593: public function update_item_permissions_check( $request ) {
594:
595:  $post = get_post( $request['id'] );
596:  $post_type = get_post_type_object( $this­>post_type );

    

Функция get_post принимает значение id прямиком из запроcа, никак его не фильтруя. Если запись не была найдена, возвращается null.

wp­includes/post.php:

515: function get_post( $post = null, $output = OBJECT, $filter = 'raw' ) {
...
519: if ( $post instanceof WP_Post ) {
520:    $_post = $post;
521: } elseif ( is_object( $post ) ) {
...
530: }else{
531: $_post = WP_Post::get_instance( $post );
532: }
533:
534: if(!$_post) 
535:   return null;

Все последующие проверки внутри метода проверки прав идут лесом, в результате чего он возвращает true. Дальше управление передается в функцию update_item.

wp­includes/rest­api/endpoints/class­wp­rest­posts­controller.php:

626: public function update_item( $request ) {
...
627:    $id   = (int) $request['id'];
628:    $post = get_post( $id );

А вот здесь, перед тем как передать ID поста в функцию get_post, оно приводится к целому (строка 627). В этой логике и заключается проблема. Мы можем передать невалидный id=1qwe, который успешно пройдет проверку на редактирование. Дальше update_item сделает из него валидный id=1 и выполнит обновление записи с этим ID. Подробнее узнать про такое поведение PHP в процессе приведения строк к числам можно в мaнуале.

Теперь соберем всё, что накопали, и проверим работоспoсобность. Попробуем изменить тестовую запись в блоге с id=1 под названиeм «Hello World!». Для этого отправляем POST­ запрос:

POST /wp­json/wp/v2/posts/1337?id=1qwe HTTP/1.1
Host: wp.local
Content­Type: application/x­www­form­urlencoded
content=Changed+successfully

Пост успешно обновлен, без авторизации и СМС.

Существует несколько эксплоитов, которые автоматизируют процесс. Один из них ты можешь найти на сайте Exploit Database.

При наличии на сайте определенных тем и плагинов баг может превратиться в полнoценную XSS и даже RCE. Многие плагины добавляют кастомные шорт­коды — небольшие макросы, которые можно использовать в тексте записей.

В общем, если у тебя есть блог на WordPress, не медли с обновлением движка до последней версии.

TARGETS

WordPress >= 4.7 < 4.7.2.

SOLUTION

[ad name=»Responbl»]

Уязвимость исправлена в WordPress версии 4.7.2. Если же тебе совсем не нужен REST API, можешь отключить его при помощи плагина Disable REST API.