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

[@skimmer]

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

[@CRImier]

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

[@Anisotropic]

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

[@akamajoris]

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

[@Anisotropic]

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

[@vstaf]

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

[@Anisotropic]

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

[@BeLove]

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

[@HeadFore]

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

[@la0]

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

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

[@BeLove]

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

[@la0]

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

[@hMartin]

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

[@BeLove]

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

[@hMartin]

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

[@AmdY]

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

[@kovshenin]

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

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

[@BeLove]

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

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

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

[@zorgrhrd]

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

[@dark_k3y]

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

[@zorgrhrd]

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

[@anephew]

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

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

[@VolCh]

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

[@zorgrhrd]

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

[@VolCh]

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

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

[@zorgrhrd]

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

[@zorgrhrd]

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

[@zviryatko]

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

[@kovshenin]

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

[@BOOMik]

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

[@kovshenin]

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

define( 'DISALLOW_UNFILTERED_HTML', true );

[@ruskella]

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

[@kovshenin]

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

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

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