Plesk 10.4.4 Дыра в безопасности?

Я просматривал журналы mysql-slow-logs, чтобы проверить потенциальную оптимизацию, и заметил в них странную схему (см. ниже):

SELECT password, type FROM accounts AS a  JOIN sys_users AS s ON (a.id = s.account_id) WHERE s.login='**DICTIONARY_USER_NAME_HERE**'  AND (SELECT count(*) FROM hosting   AS h WHERE h.sys_user_id = s.id) = 0  AND (SELECT count(*) FROM web_users AS w WHERE w.sys_user_id = s.id) = 0  AND (SELECT count(*) FROM ftp_users AS f WHERE f.sys_user_id = s.id) = 0;

Что еще более пугает, так это то, что эти запросы выполняются с admin@localhost (который указан пользователем Plesk MySQL)

Я проверил, и кажется, что Plesk хранит некоторые пароли в виде обычного текста, и эти запросы являются очевидным методом словаря для угадывания логина, поэтому mysql ответит паролем в виде обычного текста.

Итак, чтобы подвести итог

  • запросы называются admin@localhost
  • пароли plesks в текстовом виде

Я не уверен, каков вектор атаки, но если мы примем во внимание несколько вещей:

  • злоумышленник теперь не знает пароль администратора, иначе он мог бы выполнить точный запрос вместо словаря
  • злоумышленник явно не выполняет ssh / удаленное выполнение mysql
  • это, вероятно, вина plesk, поскольку я наблюдал это на обоих серверах, которые работают под разными ОС, в разных конфигурациях, и только один из них имеет какой-либо контент (веб-сайт/приложение или что-то еще, что может быть возможным вектором атаки)
  • наиболее вероятным кажется то, что злоумышленник (или бот в данном случае) выполняет запрос через некоторые из незащищенных сценариев Plesk (тех, кто разрешает такой запрос, не требуя от вас входа в систему)

Теперь я могу совершенно ошибаться и неправильно понимать ситуацию, и это какое-то совершенно нормальное действие Plesk (в чем я сомневаюсь), что также странно, так это то, что я не смог найти ничего в Google об этой уязвимости.

Некоторый технический/мягкий фон:

  • VPS
  • 1xCentOS 5 / 1xDebian (оба x64)
  • Панель Plesk v. 10.4.4

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

Обновление до версии 11 пока не обсуждается - провайдер VPS сказал, что пока не может этого сделать, я не могу переносить проекты на другие VPS или, по крайней мере, не так быстро

Заранее спасибо и с уважением, Адам


mysql plesk brute-force
person johhniedoe    schedule 22.01.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Около года назад было большое количество слухов о безопасности Plesk, но Plesk 10.4 всегда упоминался как безопасно.

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

Злоумышленнику не обязательно иметь какой-либо специальный незащищенный скрипт в Plesk, чтобы попытаться войти в систему по словарю. Они всегда могут взять вашу страницу входа и попробовать разные комбинации словарного логина/пароля, пока они не совпадут. Я предполагаю, что могут существовать пулы пар логин/пароль, полученные из разных эксплуатируемых систем. Поскольку люди часто повторно используют логин и пароль, у злоумышленника будет шанс, если он попробует много серверов. Возможно, ваш сервер является одним из 1000 других, которые они сканируют.

Если вас действительно сканируют, вы должны увидеть много таких запросов в журнале MySQL, а также вы должны увидеть несколько попыток доступа к вашей панели управления в журналах доступа. Чтобы остановить это, вам нужно либо заблокировать доступ к вашему Plesk через брандмауэр (или через ограничения доступа) для всех, кроме списка ваших доверенных IP-адресов.

person Sergey L    schedule 23.01.2013

arrow_upward
0
arrow_downward

При установке Plesk 12.5 мы обнаружили, что эти запросы отображаются в журнале при попытке входа в систему с помощью ssh. Это можно проверить, сопоставив mysql.log с auth.log.

Когда происходит атака по словарю против ssh, вы можете увидеть большое количество таких запросов в логе.

Если вы можете изменить порт ssh на что-то необычное (1337?), вы, как правило, избегаете атак по сценарию.

person hennings    schedule 25.01.2020