Архив метки: Wordpress

Бесплатный хостинг с ISP manager

Меня тут частенько спрашивают, а где взять бесплатный хостинг?




Так вот, ловите: https://bill.aquinas.su/



2019-05-12T02:44:43
wordpress

Удаленное выполнение кода в WordPress 5.0.0

В этом блоге рассказывается, как сочетание уязвимости обхода пути и включения локального файла приводит к удаленному выполнению кода в ядре WordPress. Уязвимость оставалась открытой в ядре WordPress более 6 лет.

 

Влияние

Злоумышленник, получивший доступ к учетной записи с как минимум привилегиями author на целевом сайте WordPress, может выполнить произвольный код PHP на базовом сервере, что приведет к полной удаленной передаче.

 

На кого это влияет?

Уязвимость, описанная в этом посте, стала неиспользуемой другим исправлением безопасности в версиях 4.9.9 и 5.0.1. Однако обход пути все еще возможен и в настоящее время не исправлен. Любой сайт WordPress с установленным плагином, который неправильно обрабатывает записи Post Meta, может сделать использование еще доступным.

Согласно странице загрузки WordPress, Разработанные сайты на вордпресс используется более чем 33% на всех веб-сайтов в Интернете. Принимая во внимание, что плагины могут вновь вызвать проблему и принимая во внимание такие факторы, как устаревшие сайты, количество уязвимых установок по-прежнему исчисляется миллионами.

 

Фон — Управление изображениями в WordPress

Когда изображение загружается на сайт WordPress, оно сначала перемещается в каталог загрузки ( wp-content/uploads). WordPress также создаст внутреннюю ссылку на изображение в базе данных, чтобы отслеживать метаинформацию, такую как владелец изображения или время загрузки.

Эта мета-информация хранится в базе данных Post Meta. Каждая из этих записей является парой ключ/значение, назначенной определенному идентификатору.

 

Пример публикации мета-ссылки на загруженное изображение ‘evil.jpg’

MariaDB [wordpress]> SELECT * FROM wp_postmeta WHERE post_ID = 50;

+---------+-------------------------+----------------------------+

| post_id |        meta_key         |         meta_value         |

+---------+-------------------------+----------------------------+

|   50    |    _wp_attached_file    |          evil.jpg          |

|   50    | _wp_attachment_metadata | a:5:{s:5:"width";i:450 ... |

...

+---------+-------------------------+----------------------------+

В этом примере изображению было присвоено значение post_ID50. Если в будущем пользователь захочет использовать или отредактировать изображение с указанным идентификатором, WordPress будет искать соответствующую мета-запись _wp_attached_file и использовать ее значение, чтобы найти файл в каталоге wp-content/uploads.

 

Основная проблема — записи мета-записей могут быть перезаписаны

Проблема с этими записями Post Meta до WordPress 4.9.9 и 5.0.1 заключается в том, что можно было изменять любые записи и устанавливать для них произвольные значения.

Когда изображение обновляется (например, изменяется его описание), вызывается функция edit_post(). Эта функция напрямую воздействует на массив $_POST.

 

Произвольные мета значения Post могут быть обновлены.

function edit_post( $post_data = null ) {



if ( empty($postarr) )

$postarr = &$_POST;

⋮

if ( ! empty( $postarr['meta_input'] ) ) {

foreach ( $postarr['meta_input'] as $field => $value ) {

update_post_meta( $post_ID, $field, $value );

}

}

 

Как видно, можно вводить произвольные записи мета- постов. Поскольку не проверяется, какие записи изменены, злоумышленник может обновить мета-запись _wp_attached_file и установить для нее любое значение. Это никоим образом не переименовывает файл, оно просто изменяет файл, который будет искать WordPress при попытке отредактировать изображение. Это приведет к обходу пути позже.

 

Обход пути через модифицированную мета-запись

Обход пути происходит в функции wp_crop_image(), которая вызывается, когда пользователь обрезает изображение.

Функция берет идентификатор изображения для crop ( $attachment_id) и извлекает соответствующую запись _wp_attached_file мета-поста из базы данных.

Помните , что из — за дефекта в edit_post(), $src_file может быть установлен на что-нибудь.

 

Упрощенная функция wp_crop_image(). Фактический код находится в wp-admin/includes/image.php

function wp_crop_image( $attachment_id, $src_x, ...) {



$src_file = $file = get_post_meta( $attachment_id, '_wp_attached_file' );

⋮

На следующем шаге WordPress должен убедиться, что изображение действительно существует, и загрузит его. WordPress имеет два способа загрузки данного изображения. Первый — просто найти имя файла, предоставленное записью _wp_attached_file Meta Post в каталоге wp-content/uploads (строка 2 следующего фрагмента кода).

В случае сбоя этого метода WordPress попытается загрузить изображение со своего собственного сервера в качестве запасного варианта. Для этого будет сгенерирован URL-адрес для загрузки, состоящий из URL-адреса каталога wp-content/uploads и имени файла, хранящегося в записи _wp_attached_file мета-поста (строка 6).

Чтобы привести конкретный пример: если значение, сохраненное в записи _wp_attached_file Post Meta, было evil.jpg, то WordPress сначала попытается проверить, существует ли файл wp-content/uploads/evil.jpg. Если нет, то он будет пытаться загрузить файл со следующего URL: https://targetserver.com/wp-content/uploads/evil.jpg.

Причиной попытки загрузить изображение вместо локального его поиска является случай, когда какой-то плагин генерирует изображение на лету при посещении URL.

Обратите внимание, что здесь не проводится никакой дезинфекции. WordPress просто объединит каталог загрузки и URL с пользовательским вводом $src_file.

Как только WordPress успешно загрузит правильное изображение через wp_get_image_editor(), он будет обрезать изображение.

⋮

if ( ! file_exists( "wp-content/uploads/" . $src_file ) ) { // If the file doesn't exist, attempt a URL fopen on the src link.

// This can occur with certain file replication plugins.

$uploads = wp_get_upload_dir();

$src = $uploads['baseurl'] . "/" . $src_file; } else {

$src = "wp-content/uploads/" . $src_file;

}



$editor = wp_get_image_editor( $src );

⋮

Обрезанное изображение затем сохраняется обратно в файловую систему (независимо от того, было ли оно загружено или нет). Полученное имя файла $src_file будет возвращено пользователем get_post_meta(), который находится под контролем злоумышленника. Единственное изменение, внесенное в результирующую строку имени файла, заключается в том, что к базовому имени файла добавляется cropped-(строка 4 следующего фрагмента кода). Чтобы следовать примеру evil.jpg, результирующее имя файла будет cropped-evil.jpg.

WordPress затем создает любые каталоги в результирующем пути, которые еще не существуют через wp_mkdir_p() (строка 6).

Затем он наконец записывается в файловую систему с использованием save()метода объекта редактора изображений. Метод save() также не выполняет Path Traversal проверки по данному имени файла.

⋮

$src = $editor->crop( $src_x, $src_y, $src_w, $src_h, $dst_w, $dst_h, $src_abs );



$dst_file = str_replace( basename( $src_file ), 'cropped-' . basename( $src_file ), $src_file );



wp_mkdir_p( dirname( $dst_file ) );



$result = $editor->save( $dst_file );

 

Идея

До сих пор мы обсуждали, что можно определить, какой файл загружается в редактор изображений, поскольку никакие проверки очистки не выполняются. Однако редактор изображений выдает исключение, если файл не является допустимым изображением. Первое предположение может заключаться в том, что тогда можно обрезать изображения только вне каталога загрузки.

Однако тот факт, что WordPress пытается загрузить изображение, если оно не найдено, приводит к уязвимости удаленного выполнения кода.









Локальный файлСкачать HTTP
Загруженный файлevil.jpgevil.jpg
_wp_attached_fileevil.jpg? shell.phpevil.jpg? shell.php
Результирующий файл, который будет загруженWP-содержание / добавления / evil.jpg? shell.phphttps://targetserver.com/wp-content/uploads/evil.jpg?shell.php
Фактическое местоположениеWP-содержание / добавления / evil.jpghttps://targetserver.com/wp-content/uploads/evil.jpg
Результирующее имя файлаНет — загрузка изображения не удаласьevil.jpg? обрезаны-shell.php

 

Идея заключается в том, чтобы установить _wp_attached_fileв evil.jpg?shell.php, что привело бы к запросу HTTP Делаем по следующему адресу: https://targetserver.com/wp-content/uploads/evil.jpg?shell.php. Этот запрос вернул бы действительный файл изображения, так как все, что после, ? игнорируется в этом контексте. Полученное имя файла будет evil.jpg?shell.php.

Однако, хотя метод save() редактора изображений не проверяет атаки Path Traversal, он добавляет расширение типа mime изображения, загружаемого к результирующему имени файла. В этом случае результирующее имя файла будет evil.jpg?cropped-shell.php.jpg. Это делает вновь созданный файл безвредным снова.

Тем не менее, все еще возможно поместить полученное изображение в любой каталог, используя полезную нагрузку, такую ​​как evil.jpg?/../../evil.jpg.

 

Использование обхода пути — LFI в каталоге тем

Каждая тема WordPress представляет собой просто каталог, расположенный в каталоге wp-content/themes в WordPress, и предоставляет файлы шаблонов для разных случаев. Например, если посетитель блога хочет просмотреть сообщение в блоге, WordPress ищет файл post.php в каталоге текущей активной темы. Если он найдет шаблон, он сделает include().

Чтобы добавить дополнительный уровень настройки, можно выбрать собственный шаблон для определенных сообщений. Для этого пользователь должен установить запись _wp_page_template Post Meta в базе данных с таким пользовательским именем файла. Единственным ограничением здесь является то, что редактируемый файл include() должен находиться в каталоге текущей активной темы.

Обычно к этому каталогу нельзя получить доступ, и никакие файлы не могут быть загружены. Однако, злоупотребляя вышеописанным обходом пути, можно внедрить вредоносное изображение в каталог используемой в настоящее время темы. Затем злоумышленник может создать новую запись и использовать ту же ошибку, которая позволила ему обновить запись _wp_attached_file мета-поста в соответствии include() с изображением. Внедрив PHP-код в изображение, злоумышленник получает произвольное удаленное выполнение кода.

 

Создание вредоносного образа — GD vs Imagick

WordPress поддерживает два расширения для редактирования изображений для PHP: GD и Imagick. Разница между ними заключается в том, что Imagick вовсе не разделяет метаданных изображения EXIF, в котором PHP код может быть сохранен. GD сжимает каждое редактируемое изображение и удаляет все метаданные exif. Это результат того, как GD обрабатывает изображения.

Тем не менее, эксплуатация все еще возможна, если создать изображение, содержащее созданные пиксели, которые будут перевернуты таким образом, что это приведет к выполнению PHP-кода после того, как GD завершит обрезку изображения.

 

Резюме

В этом посте подробно рассказывается об удаленном выполнении кода в ядре WordPress, которое присутствовало более 6 лет. Оно стало непригодным для использования с патчем для другой уязвимости, о которой сообщает RIPS в версиях 5.0.1 и 4.9.9. Однако обход пути все еще возможен и может использоваться, если установлен плагин, который все еще позволяет перезаписывать произвольные данные поста.

Мы хотели бы поблагодарить добровольцев из команды безопасности WordPress, которые были очень дружелюбны и действовали профессионально, работая с нами над этой проблемой.



2019-05-11T06:34:57
Лучшие учебники по Wodpress

Защита сайтов на WordPress с помощью Fail2Ban

Ваши сайты на WordPress пытаются ломать?

Мой VDS находится под мониторингом Zabbix’а. Вчера я стал активно получать на почту сообщения о большой загрузке сервера.

Я не выдержал и зашел на Zabbix посмотреть графики загрузки.

CPU Utilization

Читать →

Нагрузочное тестирование сайта

Есть прекрасный сервис https://tools.pingdom.com/… Когда-нибудь я напишу по нему подробный обзор




Тестирование утилитой ab (Apache Benchmark)




ab -c 8 -n 10000 http://mail.ru/




8 потоков, 10000 запросов 




Server Software:        nginx/1.15.2
Server Hostname:        mail.ru
Server Port:            80

Document Path:          /
Document Length:        53960 bytes

Concurrency Level:      8
Time taken for tests:   186.452 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      542200000 bytes
HTML transferred:       539600000 bytes
Requests per second:    53.63 [#/sec] (mean)
Time per request:       149.161 [ms] (mean)
Time per request:       18.645 [ms] (mean, across all concurrent requests)
Transfer rate:          2839.83 [Kbytes/sec] received




Результат теста: 53.63 страниц в секунду, на тестирование затрачено 186.452 секунд.




loader.io:




loader.io-load-testing-application




https://loader.io



2019-05-06T07:40:37
wordpress

Как использовать Google invisible reCAPTCHA v3

Тут можно добавить ваш сайт и получить для него ключи: https://www.google.com/recaptcha/admin




когда-нибуь я напишу нормальную инструкцию на основе этого поста:




Новая reCAPTCHA от Google 3 версии: возможности и установка на сайт