PostgreSQL、MySQL 数据库被入侵究竟有多么普遍？有人做了一项实验

整理 | 苏宓

出品 | CSDN（ID：CSDNnews）

软件安全无小事。几天前，Twitter 上一位用户 fasterthanlime 发帖表示：“新年伊始，我意外地在 Hetzner（德国一家数据中心运营商）主机 5432 上不小心暴露了一个 Postgres 服务器，并立即遭到勒索。(如果你想知道的话，”docker run -p“暴露的是 0.0.0.0）。值得庆幸的是，里面没有敏感数据，而且我有备份。”

好在没有带来什么损失，不过这个帖子一经发布，有不少网友在评论区称，自己也有同样的遭遇。

这种情况引起了安全专家的注意，还有一家专注于基础设施平台建设的安全公司 Border0 决定做一个实验，详细了解活跃且应用广泛的 PostgreSQL 和 MySQL 数据库泄露情况。基于此，他们在 DigitalOcean VM 上运行一个简单的 PostgreSQL 服务器，看看会发生什么！

几个小时攻破 PostgreSQL 数据库

令 Border0 安全团队惊讶的是，这个数据库只在几个小时后就被攻破了。

事实上，他们重新做了几次实验，每天都能重现几次攻破的过程。“外面的世界真可怕！”，Border0 安全团队说道。

数据库受损

在所有情况下，数据库都被清除了（删除数据库）。有趣的是，攻击者在新创建的名为 readme_to_recover 的数据库中留下了一张纸条，说明了如何取回数据...

这让安全团队很好奇：到底发生了什么，这种情况有多常见？

到底发生了什么？

为了更好地了解在这些事件中到底发生了什么，Border0 安全团队把 PostgreSQL 数据库放在一个简单的自定义 PostgreSQL 代理后面。这样可以对用户进行身份验证并记录所有查询。这样做可以让大家更好地了解参与攻击的机器人到底执行了哪些查询。

在本实验中，Border0 安全团队让互联网上的任何地方都能访问其测试 PostgreSQL 数据库，用户名：postgres，密码：password。它有一个名为 books 的示例数据库，其中有几个表和一些假数据。

有了这样的设置，我们就能更多地了解到底发生了什么。没等多久，在启动新设置后不久，勒索机器人又来敲门了！

第一行日志显示了攻击的来源：

2024/01/11 19:02:10 New connection accepted from 94.156.71.8:58212

这是一个来自荷兰主机提供商 AS394711 的 IP，也称为 Limenet。该用户以用户：postgres 和密码：password 身份验证。

通过轻量级代理，该安全团队现在可以清楚地看到正在执行的查询。他们看到的前几个查询旨在探索数据库中的内容。

SELECT datname FROM pg_database;

这有助于机器人识别 PostgreSQL 服务器中所有可用的数据库。

既然机器人知道有哪些数据库可用，接下来它就会尝试确定每个数据库有哪些表可用，以及这些表的外观如何。然后，它会先给数据库中的每个表拍一张快照，然后再删除表和数据库。

这些是该安全团队记录的确切查询，全部包含在每个表的事务中。Books 数据库中的所有表都重复了这一操作。

BEGIN
SELECT pg_database_size('books')
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public'
AND table_type = 'BASE TABLE' AND table_catalog = 'books';
SELECT column_name FROM information_schema.columns WHERE table_schema = 'public'
AND table_name = 'authors';
SELECT * FROM authors LIMIT 20;
DROP TABLE IF EXISTS authors CASCADE;
COMMIT

处理完所有表格后，它会像这样丢弃数据库：

DROP DATABASE books;

在继续之前，它还执行了这一查询：

SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE
pg_stat_activity.datname <> 'postgres' AND pid <> pg_backend_pid();


该查询会终止除“postgres”数据库外所有连接到其他数据库的后端进程，但不包括运行查询的进程本身。它可能是用来终止与数据库的其他活动连接。可能是为了防止管理员或自动系统中断攻击。

留下字条 - 索要赎金

作为最后一步，攻击者在新创建的名为 readme_too_recover 的数据库中给 Border0 安全团队留下了一张纸条。

CREATE DATABASE readme_to_recover TEMPLATE template0;


然后使用这个新数据库添加自述，如下所示

BEGIN
CREATE TABLE readme (text_field VARCHAR(255));
INSERT INTO readme (text_field) VALUES
('All your data is backed up. You must pay 0.007 BTC to 164hyKPAoC5ecqkJ2ygeGoGFRcauWRLujV In 48 hours, your data will be publicly disclosed
and deleted. (more information: go to http://iplis.ru/data3)');

INSERT INTO readme (text_field) VALUES ('After paying send mail to us:
rambler+3uzdl@onionmail.org and we will provide a link for you to download your data.
Your DBCODE is: 3UZDL');
COMMIT

因此，select text_field from readme 向该团队展示了如何恢复数据，即：

您的所有数据都已备份。您必须在 48 小时内支付 0.007 BTC 到 164hyKPAoC5ecqkJ2ygeGoGFRcauWRLujV，否则您的数据将被公开并删除。(更多信息：请访问 http://iplis.ru/data3After，向我们发送邮件：rambler+3uzdl@onionmail.org，我们将为您提供下载数据的链接。您的 DBCODE 是：3UZDL

它很方便地告诉该安全团队，他们可以以 0.007 BTC（约为 327 美元）的价格拿回一份数据副本。如果他们不付钱，数据就会被公开和删除！

不过，Border0 安全团队进一步发现，这是个谎言：“我们知道机器人并没有拿走我们所有的数据！查询日志清楚地显示，虽然它对每个表都进行了 select * 操作，但也包含了 LIMIT 20，这意味着机器人只为每个表选择了 20 条记录。因此，尽管它声称备份了所有数据，但事实显然并非如此。它也不可能公开所有数据，因为它只选取了每个表的前 20 行。这也意味着，支付 0.007 BTC 的赎金将毫无用处。”

攻击勒索机器人执行的查询

赚了多少钱？

仔细查看一下赎金说明中指定的比特币地址，就会发现其中的活动。

该安全团队发现，在过去的几天里，这个地址一共进行了五笔独立的交易，总收入超过 2400 美元。

值得注意的是，每次向该地址转账后，资金都会被迅速转移到另一个钱包。不幸的是，这些受害者再也收不回他们的数据了。

https://bitinfocharts.com/bitcoin/address/164hyKPAoC5ecqkJ2ygeGoGFRcauWRLujV

同一个机器人正在攻击 MySQL 数据库

在 Border0 安全团队的调查过程中，他们还发现了一个涉及 MySQL 数据库的相似情况。同一个僵尸程序攻击 MySQL 数据库，并来自同一 /24 范围内的不同 IP 地址。不过，它们的方法有细微差别。

值得注意的是，在对数据进行筛选时，机器人施加了 10 行的限制，再次停止了完整的数据提取。随后，它系统地删除了所有表格和数据库。在复制 PostgreSQL 策略的过程中，它建立了一个名为 RECOVER_YOUR_DATA 的新数据库，其中有一个同名的表 RECOVER_YOUR_DATA。该表包含 Border0 安全团队之前观察到的相同勒索信息，包括相同的比特币钱包地址。

但奇怪的是，MySQL 数据库的赎金价格是 0.017 BTC（732 美元），大约是 PostgreSQL 价格的两倍。

作为最后一步，该机器人试图使用“SHUTDOWN”命令让 MySQL 服务器停止运行——这清楚地表明了它蓄谋已久的破坏意图，无疑会引起你的注意。

意外暴露数据库比你想象的更容易

也许很多人会想，谁会这样把自己的数据库暴露在互联网上，如果因为暴露了而被攻击，似乎也是应得的。

确实如此，如果一不小心将数据库公开暴露在互联网上是自找麻烦，所以平时一定要注意，至少设置一个强大的密码。

通过在搜索引擎 Shodan.io 上进行的快速搜索显示，安全团队发现全球有 849,653 台可公开访问的 PostgreSQL 服务器。

同时还有超过 320 万个 MySQL 数据库！

这些可公开访问的数据库都极有可能成为黑客的潜在目标。其中大部分运行在 AWS、GCP、DigitalOcean 等公共云提供商中。

在公共云中看到许多开放数据库服务并不奇怪。如果你在 DigitalOcean 或 AWS 上运行数据库，那么这些云提供商并不总是能让你轻松地从桌面访问数据库，甚至是在不同地区或提供商上运行的工作负载。除了从任何地方打开数据库，你可能别无选择。因此，虽然这种做法不好，但有这么多开放式数据库并不奇怪。

此外，对于 Docker 用户来说，使用 docker run -p 发布容器的端口会改变基于 DNAT 的端口转发的 iptables 规则，这一点很重要。这项 Docker 功能可以管理容器的外部通信，覆盖 iptables INPUT 表中的任何默认拒绝设置，从而使端口可以公开访问。所以面对数据库安全，日常也不能掉以轻心。