1

我正在浏览 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 中找不到任何关于此漏洞的信息

一些技术/软背景：

  • 虚拟主机
  • 1xCentOS 5 / 1xDebian（均为 x64）
  • Plesk 面板 v. 10.4.4

如果有人可以确认他们确实遇到了该问题/攻击，并且可能有某种解决方案如何防止攻击者，我会非常高兴 - 他最终可能会猜到登录名，但他还没有得到它。

升级到第 11 版暂时不讨论 - VPS 提供商说他还不能这样做，我不能将项目转移到其他 VPS，或者至少不能这么快

提前致谢和问候，亚当

4

2 回答 2

0

大约一年前， Plesk 的安全性引起了轰动，但 Plesk 10.4 一直被报告为安全的。

对于以明文形式存储密码的系统，通过 SQL 查询检索密码是正常的。由于查询看起来不像 SQL 注入，它很可能是 Plesk 本身的活动，但该活动确实可以由攻击者发起。

攻击者实际上并不需要在 Plesk 中有任何特殊的非安全脚本来尝试字典登录。他们总是可以获取您的登录页面并尝试字典登录/密码的不同组合，直到匹配为止。我猜可能存在从被利用的不同系统获得的登录/密码对池。由于人们经常会重复使用登录名和密码 - 如果尝试许多服务器，攻击者将有机会。也许您的服务器是他们正在扫描的其他 1000 台服务器之一。

如果你真的被扫描了，你应该在 MySQL 日志中看到很多这样的查询，并且你应该在访问日志中看到多次尝试访问你的控制面板。要阻止这种情况，您需要通过防火墙（或通过访问限制）阻止除受信任 IP 列表之外的所有人访问您的 Plesk。

于 2013-01-23T12:49:10.393 回答
0

在 Plesk 12.5 安装中，我们发现当尝试使用 ssh 登录时，这些查询会显示在日志中。这可以通过关联 mysql.log 与 auth.log 来验证。

当存在针对 ssh 的字典攻击时，您可以在日志中看到大量此类查询。

如果您可以将 ssh 端口更改为不常见的端口（1337？），您通常会避免成为脚本攻击的目标。

于 2020-01-25T23:38:13.200 回答