Плагин Portable phpMyAdmin опасен для сообщества WordPress

В июне 2011 года была открыта уязвимость в плагине phpMyAdmin, в результате которой плагин был удален из хранилища WordPress, и многим пользователям рекомендовалось отказаться от него ввиду существующих рисков.

Сегодня был найден еще один опасный плагин, присутствующий в хранилище WordPress — Portable phpMyAdmin. Если на вашем сайте установлен этот плагин, то обязательно деактивируйте его и удалите. Как вообще работает этот плагин? Для чего он предназначается? Плагин Portable phpMyAdmin функционирует довольно просто (в чем, собственно, и состоит корень проблемы). Как только вы заходите в панель администратора вашего сайта, вы можете получить доступ к основной базе данных, перейдя к меню Portable PMA. Как только вы сделаете это, вы сможете открыть phpMyAdmin внутри панели администратора WordPress. Неплохо, верно? Конечно, если вы являетесь администратором, а значит, должны обладать средствами для работы с базой данных.

Итак, в чем проблема?

Если администратор может получить доступ к указанной информации, то в чем же состоит проблема? Хорошо, поставьте временную сборку WordPress на тестовом домене и создайте любой аккаунт с ролью «Подписчик». Этот аккаунт должен обладать минимальными привилегиями в WordPress. Выйдите из аккаунта администратора и зайдите в аккаунт с ролью Подписчика. Вы увидите следующий Профиль Подписчика:

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

Наберите следующий адрес:

Home

в адресной строке браузера (измените yourdomain.com на реальное доменное имя и нажмите Enter).

Что мы видим?

Скорее всего, вы увидите phpMyAdmin и стандартные таблицы вашего сайта, как показано на скриншоте:

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

В зависимости от настроек вашего сервера и БД, пользователь может уничтожить данные, удалить базы данных, создать новые базы данных, ну и напоследок нарушить функционирование всего сайта в целом. Если все базы данных являются общими друг для друга, то пользователь получит доступ не только к базе данных для одного сайта, но и ко всем базам данных в кластере.

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

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

Из выпадающего списка с левой стороны выберите базу данных, которую вы хотите изменить (подсказка: это не information_schema). Как только будет отображен список таблиц, выберите wp_users (для отдельных сайтов) или wpmain_users (для мультисайтов).

Скорее всего, вкладка Structure будет активной. Щелкаем по вкладке Browse, чтобы увидеть данные, хранящиеся в таблицах базы данных в нижней половине экрана. Щелкаем по полю возле любого имени пользователя и нажимаем на значок карандаша ниже контента таблицы. Примечание: не используйте значок карандаша для списка записей, поскольку это, скорее всего, приведет к появлению ошибки 404.

Как только откроется новый экран, вы можете изменить имя пользователя и адрес электронной почты, связанный с ним, в результате чего вы получите контроль над веб-сайтом. Не пытайтесь изменить пароль, поскольку он зашифрован. Просто используйте функцию «Восстановить пароль», чтобы задать новый.

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

Что еще можно сделать?

Как я отметил ранее, все зависит от настроек вашего сервера и БД. Мой сервер не позволяет создавать новые базы данных, но не все серверы настроены точно так же. Если это не запрещено, то взломщик может создать новые БД, изменить что-то в существующих БД, удалить ваши БД и т.д. Потенциальных проблем очень много.

Этот плагин все еще находится на вашем сайте? Удаляйте его тут же! И никогда больше не возвращайтесь к нему!

Разве разработчик плагина не должен заботиться об этом?

Разработчики плагина – и некоторые другие люди – работали над проблемой. Касперский написал 14 декабря 2012 года о том, что существующее решение заключается в обновлении плагина до версии 1.3.1. Как видите, ничего не поменялось, потому что все описанные в статье действия совершались с версией плагина 1.3.1. Брешь в системе безопасности по-прежнему существует. Попробуйте сами и сверьте результаты.

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

Какие замены плагина существуют?

• phpMyAdmin
• Adminer
• Navicat
• SequelPro
• SQLWave
• SQLyog
• SQLBuddy
• DBDesigner4
• SQLGate
• HeidiSQL
• MyWebSQL
• DbNinja

Первое решение, phpMyAdmin, вызывает у меня некоторые опасения в связи с тем, что уже происходило в прошлом, поэтому я сам лично пользуюсь инструментом Navicat. В нем есть все, что душе угодно. С другими решениями не работал.

Источник: wpmu.org