文章总结： 本文记录了针对某在线培训平台的授权渗透测试全过程，攻击者通过端口扫描发现暴露的Vite开发服务器和PostgreSQL数据库，利用默认弱口令postgres/postgres成功登录数据库，窃取用户敏感信息与平台配置（含Proxmox虚拟化平台凭证），进而提升权限至管理员并横向移动至底层虚拟化服务器，最终控制全部虚拟机并获取API密钥等核心资产。文章揭示了默认密码未修改、凭证明文存储、权限提升无二次验证等关键漏洞，并给出了紧急修复建议。 综合评分： 87 文章分类： 渗透测试,漏洞分析,实战经验,安全建设,WEB安全
一条弱口令引发的血案——从Web站打到虚拟化平台覆灭
原创
小金星 小金星
船山信安
2026年5月24日 00:01 广东
在小说阅读器读本章
去阅读
一条弱口令引发的血案——从Web站打到虚拟化平台覆灭
免责声明： 本文所有内容均来自授权测试环境，IP地址、密码、Token等敏感信息已全部脱敏处理。请勿用于非法用途。
一、写在前面
最近做了一次授权渗透测试，目标是一个在线培训与竞赛平台。这类平台一般包含用户管理、题目发布、在线答题等功能，在高校和培训机构中很常见。
说实话，一开始我只是抱着”试试看”的心态，没想到最后一路从Web端打穿到了底层的虚拟化服务器，端掉了整个基础设施。
整个过程大概花了两个半小时，攻击链是这样的：
📄 代码
Web服务器 → 数据库 → 管理后台 → 物理服务器 → 虚拟机集群
下面我就用大白话，把每一步怎么做的、为什么能成功、以及应该怎么修，完整讲一遍。
二、第一步：踩点——先看看目标长什么样
渗透测试的第一步永远是信息收集。就像小偷踩点要先看看门窗在哪、有没有摄像头一样。
2.1 扫端口：发现”门”都开在哪
我用 Nmap 对目标 IP 做了个全端口扫描。你可以把 Nmap 理解成一个”门牌号扫描仪”——它会告诉你目标服务器上开了哪些端口，每个端口跑着什么服务。
结果发现了几个关键端口：
| 端口号 | 跑的服务 | 说明 | | — | — | — | | 22 | SSH | 远程登录服务器的”后门”，一般只有管理员用 | | 80/443 | HTTP/HTTPS | 网站服务 | | 5173 | Vite 开发服务器 | ⚠️ 不对劲，这个不应该出现在生产环境 | | 5432 | PostgreSQL 数据库 | ⚠️ 数据库直接暴露在外网，很危险 | | 8000 | Go API | 平台的后端接口 |
看到 5173 和 5432 这两个端口的时候，我已经感觉到——这个系统的问题可能比想象中要严重。
2.2 意外之喜：Vite 开发服务器在裸奔
Vite 是一个前端构建工具，它自带的开发服务器（dev server）本来是给程序员在本地写代码时用的，结果居然直接跑在了生产服务器上，而且没有任何访问限制。
我打开浏览器访问了一下 http://目标IP:5173/，好家伙——
整个前端源码全部暴露了。
这意味着什么？就像你去一家公司面试，前台直接把公司的员工手册、内部通讯录、组织架构图全给你了。
我能看到的东西包括：
●所有页面路由（管理员后台路径一目了然）
●所有 API 接口的调用方式
●认证和登录的逻辑
●前端代码里有没有硬编码的密钥或后门
2.3 /metrics 端点：又一份”内部资料”
在 8000 端口上，我发现了一个叫 /metrics 的路径。这原本是给 Prometheus（一个监控系统）抓取指标数据用的，结果也没有加任何保护。
返回的数据有 178KB，里面包含了整个平台 50 多个 API 接口的完整路径。
现在我不需要猜了，直接拿到了完整的地图：
📄 代码
/api/auth/register ← 注册接口
/api/auth/login ← 登录接口
/api/admin/users ← 管理员查看用户列表
/api/admin/platform-settings ← 管理员查看平台配置
/api/admin/rbac/users/... ← 管理员修改用户权限
...共 50+ 个接口
小白理解： 这就像你玩游戏时，直接把地图迷雾全开了，所有 BOSS 位置、隐藏宝箱在哪一目了然。
2.4 注册个账号试试
既然有注册接口，我直接发了个请求注册了一个账号。虽然需要填写”邀请码”参数，但测试发现服务器根本没校验这个参数，任何人都能注册。
注册成功后我有了一个普通用户账号，但状态是”待审批”（pending），什么事都干不了。需要管理员审批通过才能用。
到这里信息收集阶段结束，总结一下发现了什么：
📄 代码
✅ 前端源码全部泄露（Vite dev server）
✅ 全部 API 接口路径泄露（/metrics）
✅ 可以注册账号
✅ 知道数据库端口对外（5432）
⚠️ 还没有拿到任何权限
三、第二步：突破——一条密码打开了整个系统
3.1 试试”默认密码”
前面扫描发现 PostgreSQL 数据库跑在 5432 端口上。PostgreSQL 是一个开源的关系型数据库，很多 Web 应用用它存数据。
我试了一个最简单粗暴的组合——
用户名：postgres
密码：postgres
这是 PostgreSQL 安装时的超级管理员默认账号密码。
结果——
登录成功。
这一刻我愣了一下。这是一个网络安全培训平台啊，是教人防黑客的地方。结果它自己的数据库用的是默认密码？这就像健身教练自己从不锻炼一样离谱。
3.2 数据库里有什么
连接上数据库之后，我看到了这个平台的”大本营”——一个叫 blackrange 的数据库，大小 13MB。
里面有很多表，最关键的几张：
| 表名 | 中文说明 | 数据量 |
| — | — | — |
| users | 用户表 | 97 条记录 |
| sessions | 会话表（谁在登录状态） | 363 条记录 |
| challenges | 挑战题表 | 若干 |
| instances | 容器实例表 | 若干 |
| platform_config | 平台配置表 ⚠️ | 若干 |
| audit_logs | 审计日志 | 1727 条 |
3.3 用户数据全裸了
我执行了一条 SQL 查询语句（你可以理解为”查看所有用户信息”的命令），结果拿到了所有 97 个用户的完整信息：
| 数据字段 | 敏感程度 | | — | — | | 邮箱地址 | ⚠️ 个人身份信息 | | 姓名 | ⚠️ 个人身份信息 | | 学号 | ⚠️ 个人身份信息 | | 手机号 | ⚠️ 高度敏感 | | 密码哈希 | ⚠️ 虽然加密过，但存在被破解的风险 |
小白理解： 这就等于有人拿到了你家小区的业主名单，上面有每个人的姓名、电话、门牌号。
3.4 最值钱的一张表：platform_config
在所有表里，有一张叫 platform_config（平台配置）的表引起了我的注意。
里面存的是什么？这台系统所有的核心配置信息。
就像管理员把所有密码贴在了冰箱上：
📄 代码
Proxmox 服务器地址: XXX.XXX.XXX.XXX
SSH 用户名: root
SSH 密码: xxxxx
Proxmox API 地址: ...
VPN 服务器地址: ...
3.5 给自己升个级
在拿到这些数据之前，我的账号是一个”待审批的普通学生”。正常人会等管理员审批，而黑客会——
自己动手。
我执行了一条 SQL 语句：
📄 sql
UPDATE users SET role = 'admin', status = 'approved' WHERE email = '我的邮箱';
翻译成人话就是：把我的角色改成管理员，审批状态改成已通过。
没有告警，没有短信验证，没有二次确认。
就这样，我拿到了整个平台的管理员权限。
四、第三步：管理员视角——看看后台长什么样
4.1 登录管理后台
用前面注册的邮箱（现在已经是管理员了）登录系统后，我获得了完整的后台访问权限。
管理员能做什么？
●查看所有用户信息 —— 97 人，包括姓名、邮箱、手机号、学号
●修改用户权限 —— 可以把任意人的角色改成 admin
●查看审计日志 —— 1727 条操作记录
●读取 RBAC 权限矩阵 —— 整个平台的权限控制体系
●读取平台配置 —— 各种敏感配置信息
4.2 权限矩阵长什么样
我拿到了平台的权限控制表（RBAC，即 Role-Based Access Control，基于角色的访问控制）：
📄 代码
权限 | 管理员 | 老师 | 学生
----------------------------|--------|------|------
注册/登录 | ✅ | ✅ | ✅
创建题目 | ✅ | ✅ | ❌
删除题目 | ✅ | ❌ | ❌
管理用户 | ✅ | ❌ | ❌
管理权限 | ✅ | ❌ | ❌
查看平台配置 | ✅ | ❌ | ❌
查看审计日志 | ✅ | ❌ | ❌
这个权限划分本身是合理的。问题在于——谁能成为管理员这件事，太容易篡改了。
五、第四步：从一台服务器跳到另一台——横向移动
5.1 什么是横向移动？
网络安全里有个概念叫”横向移动”（Lateral Movement）。意思是黑客攻破一台机器之后，不满足于此，而是利用这台机器做跳板，去攻击同一内网的其他机器。
前面从配置表里拿到了 Proxmox 服务器的 SSH 登录信息。Proxmox 是一个虚拟化平台，类似于 VMware vSphere 或 Hyper-V——它负责管理虚拟机。
5.2 SSH 登录成功
SSH 是一种远程登录 Linux 服务器的协议，一般管理员用来在命令行操作服务器。
我执行：
📄 代码
ssh root@服务器地址
输入密码: xxxxx
登录成功。
现在我不只是一台 Web 服务器的管理员了——我是整个虚拟化平台的 root（超级管理员）。
5.3 看看能控制什么
登录后我看了一下这台服务器上跑着什么：
📄 代码
这台物理服务器的配置：
- 操作系统: Debian 12 + Proxmox VE 9.1.1
- CPU: 20 个虚拟核心
- 内存: 33 GB
- 运行时间: 46 天没关机
管理的虚拟机：
VM 100 | 状态: 关机
VM 101 | 状态: 关机
VM 102 | 状态: 关机
VM 103 | 状态: **开机运行中**
4 台虚拟机，其中一台正在运行。我能对它们做什么？
●开机/关机/重启
●查看和修改配置
●挂载磁盘读取所有数据
●克隆或删除整台虚拟机
5.4 又挖出了什么
在 Proxmox 的文件系统里，我又找到了几样”好东西”：
1. Proxmox API Token
API Token 相当于一把”钥匙”——不需要再输入密码，直接用这把钥匙就能访问 Proxmox 的所有功能。
📄 代码
Token ID: root@pam!blackrange
Secret: 9212f469-...（一串长字符串）
2. OpenAI API Key
📄 代码
sk-170cb9bd...（同样是一长串）
OpenAI API Key 是用来调用 ChatGPT 等 AI 服务的凭证。用别人的 Key 调用 AI 服务，费用是别人付。 如果你的 API Key 泄露了，可能一觉醒来账单上多了几万块。
3. root 用户的 SSH 私钥
SSH 私钥相当于”永不过期的身份证”。有了它，即使对方改了密码，我仍然可以用这把钥匙登录。这是黑客最喜欢的持久化后门。
六、”攻击链”到底是什么
攻击链（Kill Chain）是网络安全中用来描述一次完整攻击过程的模型。上面说了那么多，其实可以用这张图来概括：
📄 代码
外部踩点（端口扫描 + 源码泄露 + API 信息收集）
↓
找到突破口（PostgreSQL 弱口令）
↓
数据窃取（用户数据 + 平台配置 + 会话信息）
↓
权限提升（普通用户 → 管理员）
↓
横向移动（Web 服务器 → Proxmox 虚拟化服务器）
↓
目标达成（控制全部虚拟机 + 获取 API Key + SSH 私钥）
整个过程中，每一个步骤都依赖于上一步的成果。只要任何一个环节有防御机制，攻击链就可能被切断。
七、为什么会这样？——根本原因分析
很多人可能会想：这系统怎么这么脆弱？其实这不是个例，这是很多内部系统的通病。我总结了几条根本原因：
7.1 默认密码不换（最致命的问题）
PostgreSQL 安装后有一个默认超级管理员账号 postgres，密码也是 postgres。正确的做法是安装后立刻改成一个强密码。
但这里不仅没改，还把 5432 端口直接暴露在了公网上——等于你家门没锁，还把地址贴在了大街上。
7.2 基础设施凭证明文存储（第二大问题）
Proxmox 的 SSH 密码、API Token 等核心基础设施凭证，直接以明文形式存在数据库的 platform_config 表里。
这就像你把家里的保险柜密码写在了一张便利贴上，然后贴在了冰箱门上。
正确做法：使用专业密钥管理工具（如 HashiCorp Vault），即使数据库被攻破，也拿不到基础设施凭证。
7.3 密码复用
一台 Web 服务器的数据库密码和一个虚拟化平台的 SSH 密码——这两个本该完全不相关的凭证——居然存在同一条数据库记录里。
不同系统之间应该使用完全独立的凭证，一个被攻破不会牵连另一个。
7.4 开发环境跑在了生产环境
Vite 开发服务器本来是用来在本机写代码的，不应该出现在用户能访问的生产服务器上。这种情况通常是由于运维不规范或者赶工期导致的。
7.5 管理操作没有二次确认
修改用户角色这个操作——从普通用户变成管理员——居然不需要任何额外的验证。没有短信验证码，没有管理员审批，甚至连个弹窗确认都没有。
八、应该怎么修？——给开发者的防御建议
我按紧急程度把修复建议排了个序：
🔴 立刻要修的（P0级）
| 问题 | 怎么修 |
| — | — |
| PostgreSQL 弱口令 | 改密码为 24 位随机密码，pg_hba.conf 限制仅本地可连接，防火墙封锁 5432 端口 |
| Proxmox 密码泄漏 | 改密码、轮换 API Token、检查有没有被留后门 |
| OpenAI Key 泄漏 | 去 OpenAI 官网吊销旧 Key，生成新 Key |
| Vite 开发服务器 | 立刻停掉，改用 npm run build 正式构建部署 |
🟡 尽快要修的（P1级）
| 问题 | 怎么修 | | — | — | | /metrics 不加防护 | 添加登录认证或 IP 白名单 | | 注册不需要邀请码 | 服务端校验邀请码，注册必须填写有效码 | | 权限变更太随意 | 敏感操作加二次确认（如短信验证） | | 密码复用 | 不同服务器用不同密码 |
🟢 长期改善的（P2级）
●最小权限原则：PostgreSQL 不要用超级用户连接应用，建一个只读/只写特定表的专用账号
●密钥管理：上 Vault 或类似的密钥管理系统
●网络隔离：VLAN 隔离数据库、管理口、业务口
●日志告警：角色变更、密码重置等敏感操作实时告警
九、写在最后
9.1 这次测试教会了我们什么
1.弱口令仍然是最大的安全威胁。不管系统架构多复杂、代码写得多好，如果密码是 “postgres:postgres”，一切防御都等于零。
2.不要相信”内网就安全”。很多人觉得服务器放在内网就没事，实际上内网被攻破的案例比比皆是。
3.密钥必须分开存。数据库密码、SSH 密码、API Token、OpenAI Key——这些东西要分开管理，不能放在同一个地方。
4.开发环境和生产环境必须隔离。Vite dev server、Swagger UI、调试接口——这些都是好东西，但只能留在开发者的电脑上，不能出现在用户面前。
9.2 攻击者视角 vs 防御者视角
这次测试我是以攻击者的视角去做的。但我经历过后的真实感受是：做攻击者容易，做防御者难。
攻击者只需要找到一个漏洞就能突破防线，而防御者需要在所有环节都做到位才能防住攻击。
所以写这篇文章的目的不是”炫技”，而是希望让更多的开发者和运维人员看到——那些你习以为常的”小问题”，在攻击者眼里就是通往服务器的一扇大门。
希望这篇文章对你有帮助。如果你觉得有用，欢迎点赞转发，让更多人看到安全的重要性。
本文所有测试内容均来自授权环境，IP、密码、Token 等敏感信息已全部脱敏。请勿将本文技术用于非法用途。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：船山信安 小金星 小金星《一条弱口令引发的血案——从Web站打到虚拟化平台覆灭》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论