WordPress.org выпустил принудительное обновление безопасности для плагина Loginizer , который активен на более чем 1 миллионе веб-сайтов. Плагин предлагает защиту от перебора в своей бесплатной версии, а также другие функции безопасности, такие как двухфакторная аутентификация, reCAPTCHA и вход без пароля в коммерческом обновлении.
На прошлой неделе исследователь безопасности Славко Михайлоски обнаружил неаутентифицированную уязвимость SQL-инъекции и уязвимость XSS, о которых он сообщил авторам плагина. Версия Loginizer 1.6.4 была выпущена 16 октября 2020 года с исправлениями для двух проблем, которые кратко описаны в блоге плагина:
1) [Исправление безопасности]: правильно созданное имя пользователя, используемое для входа в систему, могло привести к SQL-инъекции. Это было исправлено с помощью функции подготовки в PHP, которая подготавливает SQL-запрос к безопасному выполнению.
2) [Security Fix]: если заголовок IP HTTP был изменен на нулевой байт, это могло привести к сохранению XSS. Это было исправлено путем правильной очистки заголовка IP HTTP перед его использованием.
Loginizer не раскрыл уязвимость до сегодняшнего дня, чтобы дать пользователям время на обновление. Учитывая серьезность уязвимости, команда плагинов на WordPress.org разместила обновление безопасности на всех сайтах, на которых работает Loginizer на WordPress 3.7+.
В июле 2020 года Loginizer был приобретен Softaculous , поэтому компания также могла автоматически обновлять любые установки WordPress с помощью Loginizer, которые были созданы с помощью Softaculous. Эти усилия в сочетании с обновлениями с WordPress.org охватили большую часть пользовательской базы Loginizer.
Автоматическое обновление застало некоторых пользователей плагина врасплох, поскольку они не инициировали его сами и не активировали автоматические обновления для плагинов. После того, как несколько пользователей разместили сообщение на форуме поддержки плагина, член команды плагина Сэмюэл Вуд сказал, что «WordPress.org имеет возможность включать автоматические обновления для проблем безопасности в плагинах» и использовал эту возможность много раз.
Сегодня Михайлоски опубликовал более подробное доказательство концепции в своем блоге. Он также обратил внимание на некоторые проблемы, связанные с системами WordPress, которые позволили этой серьезной уязвимости проскочить через бреши. Он утверждает, что проблема могла быть легко предотвращена группой проверки плагинов, поскольку плагин не использовал функцию подготовки для безопасного выполнения SQL-запросов. Михайлоски также рекомендовал периодически проверять код для плагинов в официальном каталоге.
«Когда плагин попадает в репозиторий, он должен быть проверен, но когда он снова проверяется?» Михайлоски сказал. «Все начинают с 0 активных установок, но что происходит с 1 000, 10 000, 50 000, 100 000, 500 000, 1 миллион + активных установок?»
Михайлоски был озадачен, как такая вопиющая проблема безопасности могла оставаться в коде плагина так долго, учитывая, что это плагин безопасности с активным количеством установок, которое больше, чем у многих известных CMS. Плагин также недавно перешел из рук в руки, когда он был приобретен Softaculus и прошел аудит нескольких организаций безопасности, включая WPSec и Dewhurst Security .
Михайлоски также рекомендует WordPress повысить прозрачность в вопросах безопасности , поскольку некоторым владельцам сайтов и закрытым сообществам может быть неудобно, что их активы управляются неизвестными людьми на WordPress.org.
«WordPress.org в целом прозрачен, но нет никаких заявлений или документов о том, кто, как и когда решает и выполняет автоматические обновления», – сказал Михайлоски. «Это как будто держать все яйца в одной корзине.
«Я думаю, что это ключевые моменты, на которых WP.org следует сосредоточиться, и все будет в короткие сроки: полная техническая документация WordPress для предупреждений безопасности, руководство по раскрытию ошибок (от исследователей, но также от поставщика аспект), а также повторяющиеся проверки кода для популярных плагинов ».
