标签 数据库安全 下的文章

ClickHouse 数据库渗透测试指南

目录

1概述

2信息收集

3权限评估

4文件读取利用

5文件写入利用

6命令执行利用

7SSRF 利用

8云环境利用

9横向移动

10防御绕过

11常见限制与绕过

12工具与脚本

概述

什么是 ClickHouse

ClickHouse 是由 Yandex 开发的开源列式数据库管理系统,专为在线分析处理(OLAP)场景设计。它能够高效处理大规模数据集,支持快速查询和实时数据分析。

默认配置

配置项

默认值

HTTP 端口

8123

TCP 端口

9000

MySQL 协议端口

9004

配置目录

/etc/clickhouse-server/

数据目录

/var/lib/clickhouse/

用户脚本目录

/var/lib/clickhouse/user_scripts/

用户文件目录

/var/lib/clickhouse/user_files/

渗透测试目标

1 信息泄露:获取敏感数据、配置信息

2 文件读取:读取系统敏感文件

3 文件写入:写入 webshell、脚本、配置文件

4 命令执行:实现 RCE(远程代码执行)

5 横向移动:利用 SSRF 或数据库连接攻击内网

信息收集

1. 版本信息

2. 用户与权限

3. 数据库与表

4. 服务器配置

5. 集群信息

6. 查询历史(敏感信息)

7. 可用函数

权限评估

关键权限检查

权限等级

权限级别

可执行操作

只读用户

SELECT 查询

普通用户

SELECT、INSERT、部分表函数

DDL 权限

CREATE、DROP、ALTER

SOURCES 权限

url()、mysql()、postgresql() 等

管理员

全部权限

文件读取利用

1. file() 函数读取

2. 路径穿越(低版本可能有效)

3. 软链接绕过(需要命令执行权限)

如果有命令执行权限,可以创建软链接绕过目录限制:

然后读取:

文件写入利用

1. INTO OUTFILE

2. 写入脚本到 user_scripts 目录

命令执行利用

方法1:UDF 配置文件(需要配置文件写入权限)

步骤1:创建 UDF 配置文件

创建 /etc/clickhouse-server/cmd_function.xml:

关键参数说明:

execute_direct=0:command 通过 sh -c 执行

execute_direct=1:command 在 user_scripts 目录查找脚本

步骤2:确保 config.xml 包含

步骤3:重启服务后执行

方法2:带参数的交互式 Shell

UDF 配置:

执行命令:

方法3:executable() 表函数

方法4:Executable 表引擎

方法5:Executable Dictionary

SSRF 利用

1. url() 表函数

2. 常见内网服务探测

3. 批量内网扫描

4. 其他 SSRF 函数

云环境利用

AWS

阿里云

腾讯云

Google Cloud

横向移动

1. MySQL 连接

2. PostgreSQL 连接

3. remote() 连接其他 ClickHouse

4. JDBC 连接(需要 JDBC Bridge)

防御绕过

1. 编码绕过

2. 字符串拼接

3. 使用变量

常见限制与绕过

托管环境限制

限制

状态

绕过方法

INTO OUTFILE 禁用

常见

无直接绕过,尝试其他写入方式

Executable DDL 禁用

常见

尝试配置文件方式

路径穿越阻止

常见

软链接(需命令执行)

url() 内网限制

少见

DNS 重绑定

配置文件只读

常见

无绕过

工具与脚本

1. 信息收集一键脚本

2. Python SSRF 扫描脚本

3. 批量端口扫描 SQL 模板

漏洞概述 CVE-2026-22687是一个存在于WeKnora Agent服务中的SQL注入漏洞。该漏洞由于后端代码对用户输入的SQL语句校验不严,导致攻击者可以通过精心构造的提示词绕过安全限制,执行任意SQL查询,从而获取数据库服务器中的敏感信息。 影响范围: <0.2.4 所有启用Agent服务的WeKnora实例 漏洞详情 漏洞位置 文件: /internal/agent/tools/database_query.go 函数: validateAndSecureSQL() (第249-373行) API端点: POST /api/v1/agent-chat/{session_id} 漏洞根因 1.后端 安全校验逻辑缺陷 在validateAndSecureSQL函数中,开发者试图通过正则表达式检查SQL语句中涉及的表名,只允许访问预定义的白名单表:

Plain Text

复制代码
allowedTables := []string{
"tenants", "knowledge_bases", "knowledges", "sessions",
"messages", "chunks", "embeddings", "models",
}

// 提取FROM和JOIN子句中的表名
tablePattern := regexp.MustCompile(`(?i)\b(?:from|join)\s+([a-z_]+)(?:\s+as\s+[a-z_]+|\s+[a-z_]+)?`)
matches := tablePattern.FindAllStringSubmatch(lowerSQL, -1)

2. 两处关键绕过点 第一处漏洞:未校验PostgreSQL内置危险函数
代码仅检查表名是否在白名单中,但完全忽略了对数据库函数的校验。攻击者可以利用PostgreSQL内置函数(如pg_ls_dir、pg_read_file等)进行文件系统操作。
第二处漏洞:未考虑SQL注释绕过
正则表达式使用\s+匹配空白字符,但攻击者可以使用/**/等SQL注释代替空格,从而绕过表名检测:

Plain Text

复制代码
-- 原始查询(会被拦截)
SELECT pg_ls_dir('/etc')

-- 绕过后的查询(使用注释代替空格)
SELECT/**/pg_ls_dir('/etc')

代码分析 代码执行流

Plain Text

复制代码
// 漏洞点1:原始SQL执行,无参数化查询
func (t *DatabaseQueryTool) Execute() {
// line 158: 直接执行原始SQL
t.db.WithContext(ctx).Raw(securedSQL).Rows()
}

// 漏洞点2:校验函数存在缺陷
func validateAndSecureSQL(sql string) error {
// 仅检查表名,不检查函数和存储过程
// 使用简单正则,易被注释绕过
}

1 缺少参数化查询:直接拼接用户输入执行SQL 2 函数名白名单缺失:未限制可执行的数据函数 3 SQL解析不完整:依赖简单正则而非完整SQL解析器 4 多层转义缺失:未对用户输入进行适当的转义处理 漏洞复现

新一轮GoBruteforcer攻击瞄准了加密货币和区块链项目的数据库,意图将其纳入一个僵尸网络。该网络能够对Linux服务器上的FTP、MySQL、PostgreSQL和phpMyAdmin等服务进行用户密码暴力破解。

Check Point Research在上周发布的分析报告中指出:"当前这波攻击活动由两个因素驱动:一是AI生成的服务器部署示例被大量复用,传播了常见的用户名和脆弱的默认设置;二是诸如XAMPP等遗留Web栈的持续存在,这些栈暴露了FTP和管理界面,且加固程度极低。"

GoBruteforcer(亦称GoBrut)最初由Palo Alto Networks Unit 42于2023年3月记录。该恶意软件能够针对运行x86、x64和ARM架构的类Unix平台,部署一个互联网中继聊天(IRC)机器人和一个用于远程访问的Web Shell,同时获取一个暴力破解模块以扫描易受攻击的系统并扩大僵尸网络的覆盖范围。

Lumen Technologies的Black Lotus Labs团队在2025年9月的一份后续报告中发现,受另一个名为SystemBC的恶意软件家族控制的一部分受感染机器人,也属于GoBruteforcer僵尸网络的一部分。

Check Point表示,其在2025年中识别出了一个更复杂的Golang恶意软件版本。该版本包含一个用跨平台编程语言重写、经过高度混淆的IRC机器人,并改进了持久化机制、进程伪装技术和动态凭证列表。

凭证列表包含一系列允许远程登录的常见用户名和密码组合(例如:myuser:Abcd@123 或 appeaser:admin123456)。选择这些名称并非偶然,因为它们曾出现在数据库教程和供应商文档中,而这些资料都被用于训练大型语言模型(LLM),导致模型生成的代码片段带有相同的默认用户名。

列表中的其他一些用户名则专注于加密货币领域(例如:cryptouser、appcrypto、crypto_app和crypto)或针对phpMyAdmin面板(例如:root、wordpress和wpuser)。

Check Point称:"攻击者为每次攻击活动复用一个小而稳定的密码池,从中刷新每项任务列表,并每周数次轮换用户名和特定领域的添加项,以追求不同的目标。与其他服务不同,FTP暴力破解使用的是嵌入在暴力破解器二进制文件中的一小部分硬编码凭证。该内置集合指向Web托管栈和默认服务账户。"

进一步分析此次攻击活动发现,其中一台被入侵的主机被用于部署一个模块,该模块会遍历一系列TRON区块链地址,并使用tronscanapi[.]com服务查询余额,以识别资金非零的账户。这表明攻击者正协同努力地针对区块链项目。

"GoBruteforcer例证了一个更广泛且持续存在的问题:暴露的基础设施、脆弱的凭证和日益自动化的工具相结合,"Check Point表示。"虽然该僵尸网络本身在技术上并不复杂,但其操作者受益于大量仍在线的配置不当的服务。"

此次披露之际,GreyNoise揭示威胁行为者正在系统地扫描互联网,寻找可能提供商业LLM服务访问权限的配置不当的代理服务器。

在这两波活动中,其中一波在2025年10月至2026年1月期间,利用了服务器端请求伪造(SSRF)漏洞,针对Ollama的模型拉取功能和Twilio SMS webhook集成。基于对ProjectDiscovery的OAST基础设施的使用,推测该活动可能源自安全研究人员或漏洞赏金猎人。

第二波活动始于2025年12月28日,被评估为一次大规模枚举尝试,旨在识别与阿里巴巴、Anthropic、DeepSeek、Google、Meta、Mistral、OpenAI和xAI相关的暴露或配置不当的LLM端点。扫描源自IP地址45.88.186[.]70和204.76.203[.]125。

这家威胁情报公司表示:"自2025年12月28日起,两个IP地址对超过73个LLM模型端点展开了有方法的探测。在十一天内,它们生成了80,469次会话——这是针对可能泄露商业API访问权限的配置不当代理服务器的系统性侦察。"

觉得这篇文章有趣吗?请关注我们的Google News、Twitter和LinkedIn,阅读我们发布的更多独家内容。

MongoDB 最近修补了CVE-2025-14847,这是一个影响多个支持和遗留 MongoDB 服务器版本的漏洞。根据披露,该漏洞可以被未认证的攻击者以较低的复杂度远程利用,可能导致敏感数据和凭证的外泄。

 

这个漏洞被称为 MongoBleed,以臭名昭著的Heartbleed命名,CVSS 得分为8.7,由对 zlib 压缩网络流量处理不当触发,允许未经身份验证的攻击者泄露未初始化的内存,并可能从受影响的 MongoDB 服务器窃取敏感数据,如凭证或令牌。根据Wiz的安全研究人员,该漏洞正在被广泛利用。

 

正如 MongoDB 的声明所述,MongoDB Atlas 上的托管实例已经被修补,但是如果自托管 MongoDB 不更新,仍然存在风险。强烈建议组织立即应用安全补丁,或禁用压缩并限制网络暴露。Merav Bar、Amitai Cohen、Yaara Shriki 和 Gili Tikochinski 解释:

 

CVE-2025-14847 源于 MongoDB 服务器基于 zlib 的网络消息解压缩逻辑中的一个缺陷,该逻辑在认证之前进行了处理。通过发送畸形的压缩网络数据包,未经身份验证的攻击者可以触发服务器错误处理解压缩的消息长度,导致返回给客户端未初始化堆内存。

 

根据 Wiz 文章,42%的云环境中至少有一个易受攻击的 MongoDB 实例,Censys 报告称全球大约有 87,000 台服务器存在潜在的风险。由于该漏洞可以在没有认证或用户交互的情况下被利用,暴露在互联网上的数据库服务器面临特别高的风险。Wiz 团队补充道:

 

在代码层面,这个漏洞是由 message_compressor_zlib.cpp 中的错误长度处理引起的。受影响的逻辑返回了分配的缓冲区大小(output.length()),而不是实际解压缩数据的长度,从而允许过小或畸形的有效载荷暴露相邻的堆内存。

 

这个漏洞影响了自2017年以来发布的所有 MongoDB 版本。Linkfields Innovations 的软件开发人员 Gourav Boiri评论道

 

MongoBleed 突出了即使是成熟的数据库,当暴露或打补丁时,也可能成为关键的攻击面。预认证内存泄露、主动漏洞攻击和 87K+暴露实例——提醒我们,数据库安全就是基础设施安全。

 

在“简单解释MongoBleed”的文章中,Stanislav Kozlovski解释了这一漏洞的工作原理,并警告说:

 

它非常容易被利用——只需要连接到数据库(不需要认证)。截至撰写本文时,它已经被修复,但一些 EOL 版本(3.6、4.0、4.2)将不会得到修复。

 

InfoSec 创始人和实践者Eric Capuano解释了如何从日志中检测数据库服务器是否被利用。在一个流行的Reddit帖子中,用户 misteryuub 争论道:

 

很多人争论说开源代码比闭源代码更安全,或者安全问题会在开源代码中更快被发现。这种级别的漏洞存在是对这个论点的反驳。

 

Kozlovski 不同意:

 

当人们说开源更安全时,他们通常指的是有活跃社区的开源项目。Mongo 在 2017 年似乎没有这个,因为引入这个漏洞的 PR 没有在公共 GitHub 上被审查。

 

MongoDB补丁版本现在可用于从 4.4 到 8.0 的所有支持版本。像Percona Server for MongoDB这样的分支也受到上游漏洞的影响

 

https://www.infoq.com/news/2026/01/mongodb-mongobleed-vulnerability/