BeLove Sep 18 2013 at 15:23

WordPress: небезопасен из коробки — получаем RCE с правами редактора. И еще о Google, стартапе и 1 миллиарде долларов

3 min

31K

Information Security*WordPress*

+62

Comments 33

skimmer Sep 18 2013 at 15:50

Как — то руки сразу зачесались и сами в google полезли сайты на WordPress искать :)
Но мы же порядочные все люди :)

CRImier Sep 18 2013 at 16:00

Все гениальное просто.
Эх, нужно было подождать ещё пару месяцев =D

Anisotropic Sep 18 2013 at 16:03

Вы ещё напишите чем именно брутили пароль, и возможно толпа скрипт-киддисов пробежится по wordpress-сайтам)

akamajoris Sep 18 2013 at 16:07

Мои блоги и так каждый день фиксируют по несколько тысяч подборов, так что вряди-ли что что-то изменится. habrahabr.ru/post/188932/

Anisotropic Sep 18 2013 at 16:27

Опа, на мои оказывается тоже. Надо что-то делать))

vstaf Sep 20 2013 at 13:52

Когда эта история началась мне заботливый хостер прислал рекомендацию запаролить wp-login.php =)

Anisotropic Sep 20 2013 at 15:14

Я сам себе хостер, сервачок стоит на шкафу :)
Надо плагин найти, который ограничивает попытки логина. Пока времени нет этим заняться.

BeLove Sep 18 2013 at 16:09

wpscan.org/
Если-скрипт кидди сможет корректно развернуть окружение для него :)

HeadFore Sep 18 2013 at 19:41

>WPScan comes pre-installed on the following Linux distributions:
А уж систему установить все смогут.

la0 Sep 18 2013 at 16:13

защита от подобного брутфорса уровня хостинга: habrahabr.ru/post/190112/

А вообще, если вы получили доступ к шаблону, вы можете выполнять даже php в шаблонах. Ничего не мешает логировать POST на форме логина, например.

BeLove Sep 18 2013 at 16:14

В статье как раз рассматривается пример внедрения PHP кода в шабон.

la0 Sep 18 2013 at 16:27

Я понимаю. Я просто к тому, что не только в WP такое возможно.

hMartin Sep 18 2013 at 16:25

1. Сбрутил редактора.
2. Проводим XSS(условно говоря) и получилаем шелл/права админа.
В чем «небезопасность» из коробки, честно говоря, я не понял. Другие движки не брутятся? Брутятся. На других движках нельзя провести подобную атаку? Да на многих можно, зависит от того, как распределяются права и на что.
Для того, что бы защитить свой сайт от подобного — есть куча решений.
Редактора того гуглосервиса еще и с работы пнут за словарный пароль.
Это не камень в ваш огород, просто непонятен заголовок

+10

BeLove Sep 18 2013 at 16:32

Мое мнение, что не должно быть права исполнения js от редактора (только администраторам). В примере в статье показано, как редактор (возможно, законный) может заполучить RCE. Почему администратор должен этого опасаться? Почему оставлена такая возможность пользователю, на уровень ниже? Открытые вопросы.

-2

hMartin Sep 18 2013 at 16:35

Опенсурс бесплатный движок. В чистом виде его юзают под бложики, обычно, для более крупных проектов меняют под свои нужды, это не так уж и сложно. Не вижу ничего плохого в js для редактора, если у редактора есть голова, хороший пасс или авторизация по каким-нибудь vk api. Для пользователей, да, он не нужен, но админ сам решает кому что и как, тем более в таких дорогих проектах :)
Я, например, никогда не надеюсь на движок, всегда урезаю все права до минимума, который позволит выполнять свои функции.
Разрабам можно только посоветовать сделать более широкую кастомизацию через админку.

AmdY Sep 18 2013 at 16:32

Вставка Javasript через редактор — это серьёзная дыра.

kovshenin Sep 19 2013 at 14:28

+1. Глупо обвинять WordPress если человек сам не прав. Нужно понимать, что именно редактор это основная роль в WordPress, а роль администратора должна использоваться только для административных задач — работа с плагинами, темами и т.д. А редактор должен иметь права на вставку всяких js, иначе как же AdSense, баннерные сети, твиттер виджеты, подписки на рассылки и всё остальное?

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

BeLove Sep 19 2013 at 14:38

Здесь действительно разные взгляды на ситуацию, в статье рассматривается именно со стороны «безопасника».

Ваши доводы верны в плане функциональности и юзабилити, но мы же рассматриваем ситуацию с другой стороны (стороны безопасности). Когда даны определенные права человеку и он не должен иметь скрытой технической возможности их повысить (privilege escalation). Здесь же такая возможность имеется.

Другое дело, если бы он имел выполнить JS только на главной странице, и не имел доступа в админ панель.

zorgrhrd Sep 18 2013 at 17:29

Странно, мне это всегда казалось нормальным поведением.
Ты дал права на редактор человеку, если он безответственный (слабый пароль) или просто негодяй (внедрит код), это твои проблемы, а не редактора.
Если дать ключи незнакомцу и вас ограбят, разве это проблема слабого замка?

dark_k3y Sep 18 2013 at 17:57

Если дать ключи знакомому от сарая/веранды — то это ваша проблема. Если через сарай/веранду попасть в дом очень легко — то, ИМХО, это проблема архитектуры дома.

zorgrhrd Sep 19 2013 at 08:48

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

anephew Sep 18 2013 at 23:12

Именно поэтому когда я даю доступ редактору (или сдаем сайт заказчику) — генерирую сложный пароль и сообщаю о важности его не менять или как минимум учесть сложность пароли при его изменении. Все-таки ответственность на главном админе будет всегда за весь ресурс.

Проблема: Неопытные админы и редакторы — получаем RCE с правами редактора. И еще о Google, стартапе и 1 миллиарде долларов

VolCh Sep 19 2013 at 01:02

Нормальным поведением казалось, что пользователь может получить админские права?

zorgrhrd Sep 19 2013 at 08:44

Да, ведь если вы дали ему ключи от дома, он может зайти, взять ваше ружье и пристрелить вас.

VolCh Sep 19 2013 at 10:49

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

Вообще как-то считал, что возможность эскалации привилегий одна из серьезнейших уязвимостей.

zorgrhrd Sep 19 2013 at 16:29

Согласен, отчасти.

zorgrhrd Sep 19 2013 at 16:38

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

zviryatko Sep 19 2013 at 06:57

Это же и исправить довольно легко, вешаешь esc_js на фильтр контента поста и все, вопрос в том почему это еще не сделано по умолчанию…

kovshenin Sep 19 2013 at 14:32

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

BOOMik Sep 19 2013 at 14:03

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

kovshenin Sep 19 2013 at 14:11

Уязвимость тут не в WordPress, а здесь: «Администраторы блогов выдают права редакторов своим PR-службам…» — они бы им ещё сразу SSH давали. А если и давать права администратора или редактора посторонним лицам, то нужно просто отключить нефильтрованный HTML для всех, как это сделано на WordPress.com и во многих других сетях:

define( 'DISALLOW_UNFILTERED_HTML', true );

ruskella Sep 19 2013 at 17:36

Что это за «нефильтрованный HTML»?

kovshenin Sep 19 2013 at 17:45

В WordPress используется KSES для обработки содержимого записей, страниц, виджетов и прочее: codex.wordpress.org/Function_Reference/wp_kses

Это позволяет указывать какими именно тегами и аттрибутами HTML можно пользоваться, а какие должны вырезаться при сохранении контента — это и есть фильтрация HTML и для некоторых ролей (администратору и редактору по умолчанию) подобная фильтрация отключена, чтобы пользователи могли вставлять свои js снипеты, iframe'ы и прочее.

Директивой DISALLOW_UNFILTERED_HTML в файле конфигурации wp-config.php можно включить фильтрацию HTML для всех ролей.

Show the best of all time