Следует ли приостанавливать работу поддерживаемых плагинов в репозитории WordPress при возникновении проблем с безопасностью?
Опубликовано: 2020-03-1227 февраля 2020 года в 21:34 (центрально-европейское время) мы получили электронное письмо с уведомлением о том, что журнал активности нашего плагина WP был « временно удален из каталога плагинов WordPress.org из-за эксплойта» .
Мы представили исправление в пятницу, 28 февраля 2020 г., в 16:08. Нам потребовалось всего 16,5 часов, чтобы выпустить исправление. Мы бы исправили проблему намного раньше, если бы это произошло в наше обычное рабочее время (мы находимся в Европе), потому что у нас очень хорошее время отклика службы поддержки (ссылка).
Наш плагин был восстановлен в понедельник, 2 марта 2020 года, в 13:00. То есть через 69 часов после отправки исправления. Важно отметить, что команде потребовалось так много времени, чтобы восстановить плагин из-за выходных.
Почему я пишу это?
Я хотел бы отметить, что я считаю, что неподдерживаемые плагины, которые имеют проблемы с безопасностью, должны быть приостановлены из репозитория WordPress. Кроме того, я с огромным уважением отношусь к работе, которую выполняют волонтеры из группы проверки плагинов, и я также беру на себя полную ответственность за заявленную проблему безопасности.
Тем не менее, я считаю, что сообщаемые проблемы безопасности в поддерживаемых плагинах могут быть решены лучше. Из-за того, как они обрабатываются в настоящее время, репутация плагина сильно страдает, а его пользователи и их веб-сайты подвергаются риску. Поэтому в конце этого поста я выделяю несколько возможных улучшений, которые могут помочь, и я думаю, что их следует рассмотреть. Идея состоит в том, чтобы всегда подвергать меньшему риску пользователей и уменьшать влияние на плагин и разработчиков.
В этом посте я также задокументирую все детали того, что произошло, и объясню уязвимость с низким уровнем серьезности, обнаруженную в нашем плагине.
Какова процедура сообщения о проблеме с безопасностью плагина WordPress?
Из официальных руководств в Руководстве по плагинам:
Каждая попытка связаться с разработчиком напрямую должна быть предпринята до того, как вы сообщите нам о плагине (хотя мы понимаем, что это может быть сложно — сначала проверьте исходный код плагина, многие разработчики указывают свои адреса электронной почты). Если вы не можете связаться с ними в частном порядке, пожалуйста, свяжитесь с нами напрямую, и мы поможем.
Что произошло в нашем случае?
Мы четко указываем в плагине, кто разрабатывает плагин. Просто взгляните на страницу плагина в репозитории, и вы все поймете! Мы также сделали это очень легко связаться с нами.
Однако никто не сообщал нам о проблеме безопасности до того, как плагин был временно изъят из репозитория плагинов. Итак, кто-то сообщил о проблеме команде проверки плагинов WordPress, и они временно удалили наш плагин из репозитория без предварительного уведомления.
Прежде чем мы углубимся в почему и что, а также что хорошо, что плохо и что можно улучшить, давайте взглянем на уязвимость плагина и кратко объясним, кто мы такие.
В чем заключалась уязвимость плагина?
У нас есть мастер установки в журнале активности WP, который помогает пользователям настроить плагин. Один из параметров мастера позволяет разрешить пользователям без прав администратора читать журналы активности.
Однако мы допустили ошибку; мы не проверяли, аутентифицирован ли пользователь, запускающий мастер. Таким образом, неавторизованные пользователи могут запустить мастер и предоставить другому пользователю или роли доступ к настройкам подключаемого модуля. Тем не менее, это крайний случай низкой серьезности проблемы.
Почему это проблема безопасности с низким уровнем серьезности?
Злоумышленники могут использовать это только в том случае, если:
- мастер установки так и не был завершен установщиком,
- у злоумышленников уже был пользователь/имели доступ к пользователю на сайте,
- Злоумышленники могут получить доступ только к настройкам плагина и журналу активности.
Используя эти проблемы безопасности, злоумышленники не получают доступа к другим привилегиям на веб-сайте WordPress. Таким образом, данный эксплойт не оказывает негативного влияния на поведение и функциональность самого веб-сайта.
Доказательство концепции
POC очень прост. Посетите эту страницу как неавторизованный пользователь:
http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access
Это шаг мастера, который позволяет указать, кто может просматривать журналы. Найдите одноразовый номер «_wpnonce» в исходном коде HTML-страницы, скопируйте и вставьте его в следующую команду curl:
$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access' -d '_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D= подписчик&save_step=Далее'
После того, как вы войдете в систему как подписчик, вы получите полный доступ к настройкам плагина.
Почему мы считаем, что это дело было неправильно рассмотрено?
В письме, которое нам прислали, было следующее:
Мы не закрываем плагины легкомысленно, и когда дело доходит до проблем безопасности, мы пытаемся сбалансировать количество пользователей и историю разработчиков с серьезностью и потенциальным ущербом отчета.
Однако я считаю, что наш плагин был отозван слишком рано. Уже;
- Когда у нас возникали проблемы в прошлом, мы всегда решали их в течение нескольких часов. Мы сделали то же самое в этот раз.
- Мы всегда отвечали вовремя, когда команда проверки плагинов связывалась с нами.
- Проблема безопасности затронула только наш плагин (низкая серьезность), и это был крайний случай.
- Проблема безопасности не может быть использована автоматически.
- Единственный ущерб , который мог нанести злоумышленник, — это изменить настройки плагина, прочитать журналы активности или очистить их.
Что другие разработчики думают о таких ситуациях?
Большинство из нас уже прочитали статью, твит или сообщение в социальных сетях о подобных проблемах. Однако я хотел узнать для себя, что думают по этому поводу другие люди, особенно разработчики. Я думаю, что это важно, потому что могут быть некоторые вещи, которые я не вижу.
Для начала я отправил электронное письмо человеку, который определил проблему, поблагодарив его за ответственное раскрытие. Его ответ был:
«Рад видеть, что вы быстро исправили проблему в плагине. Кстати, я заметил, что люди на wordpress.org закрыли его на несколько дней, это было немного грубо и в действительности не нужно», — Джером Брюанде.
Я также провел небольшой опрос в группе Facebook Selling WordPress Products. Хотя эта группа небольшая, большинство ее участников — разработчики плагинов и тем. Из опроса мы видим, что разработчики единодушно согласны с тем, что в случае проблем с низкой и средней серьезностью следует связаться с разработчиками и дать им возможность предоставить исправление, а не отозвать плагин:
Как можно улучшить эти процедуры?
Насколько мне известно, не существует задокументированных процедур, когда кто-то сообщает о проблеме безопасности в плагине. В этом случае описанные ниже процедуры могут помочь разработчикам, а также подвергнуть меньшему риску людей.
Свяжитесь с разработчиками и согласуйте план действий перед закрытием плагина
Группа проверки подключаемых модулей может попытаться связаться с разработчиками и подтвердить наличие уязвимости перед закрытием подключаемого модуля. Разработчики должны ответить с планом действий, включая разумную дату исправления.
При необходимости группа проверки плагинов может установить крайний срок. Например, у разработчиков должно быть от 12 до 24 часов, чтобы решить проблему. Однако в некоторых случаях им может потребоваться больше времени, в зависимости от часового пояса, в котором они находятся, и т. д. Если разработчики не ответят, плагин следует изъять из репозитория.
Определение серьезности и типа проблемы безопасности
Это может быть открыто для обсуждения. Тем не менее, кто-то с небольшим опытом в области безопасности может легко сказать, может ли обнаруженная проблема безопасности быть использована автоматически, является ли она пограничным случаем или нет, и каково ее влияние на сообщенное доказательство концепции (POC).
Проверить, что разработчики придерживаются плана действий
Должна быть своего рода проверка, подтверждающая, что разработчики вовремя представили исправление и придерживаются любых других задач, включенных в план действий.
Удаление поддерживаемых плагинов из репозитория не помогает
В случае поддерживаемых плагинов удаление их из репозитория приносит больше вреда, чем пользы. Например;
- Вы публично сообщаете, что у плагина есть проблема, скорее всего, проблема с безопасностью. Это вызывает много тревог и привлекает внимание к плагину. Это также похоже на приглашение злоумышленников, говорящих им, что что-то в плагине возможно эксплуатируется.
- Он раскрывает текущую базу пользователей плагинов, потому что их веб-сайты внезапно стали целью. Большинство пользователей понятия не имеют, что им делать, особенно если функциональность плагина является основной для их веб-сайта и бизнеса.
- Вы увеличиваете шансы отсрочить исправление. Обычно это вызвано отсутствием связи или праздниками и выходными.
Кто-то может возразить, что, удаляя плагин из репозитория, вы останавливаете распространение инфекции . Однако, если проблема безопасности незначительна, эксплуатация не может быть автоматизирована, а раскрытие информации является ответственным, то риски отсутствуют или риски чрезвычайно низки.
Отказ от ответственности: это не атака
Я хотел бы отметить, что это не атака на группу проверки плагинов WordPress или кого-либо, кто участвует в этих процессах. Я искренне уважаю их работу и знаю, что они делают добросовестно. Однако, безусловно, есть место для улучшения, как и в любой другой системе и процессе.
Многие, вероятно, скажут мне, что если я хочу перемен, я должен стать добровольцем, а не писать этот пост.
Я пытался присоединиться в течение довольно долгого времени; Я говорил с несколькими людьми на разных WordCamps, чтобы принять участие, и я также отслеживал страницу плагинов Make WordPress для призывов к волонтерам. Однако в последние несколько лет у них не было вакансий. Когда им нужна была помощь, они добавляли новых участников только по приглашению.