CTFHub默认口令题实战复盘：我是如何绕过亿邮网关验证码拿到Flag的-平芜编程栈

CTFHub默认口令题实战复盘：从验证码封锁到Flag获取的完整路径

那天下午，我正对着CTFHub的一道默认口令题目发呆。登录页面简洁得令人不安——只有一个用户名输入框、密码输入框、验证码区域，以及那个刺眼的"亿邮网关"logo。作为参加过几十场CTF的老兵，我清楚这种表面简单的登录框往往暗藏杀机。

1. 初探目标：信息收集的艺术

面对任何Web安全挑战，我的第一反应永远是尽可能收集目标信息。按下F12打开开发者工具，我注意到几个有趣的现象：

页面源代码中隐藏着一段被注释掉的文字：" "
网络请求中有一个向/captcha.php的调用，返回的是四位纯数字验证码
Cookie中没有明显的会话标识符，但有一个名为security_level的参数被设为"medium"

关键发现：在查看页面引用的JavaScript文件时，我找到了一个名为eyou.js的文件，里面包含验证码验证逻辑：

function validateCaptcha(input) { return input === document.getElementById('captcha').value; }

这个客户端验证明显存在逻辑漏洞——它只是简单比较输入值与页面显示的验证码是否一致，完全没有服务端二次验证。这意味着如果我能阻止验证码刷新，就可以固定使用同一个验证码无限尝试。

2. 突破验证码：前端漏洞的利用

基于这个发现，我立即采取了以下步骤：

拦截验证码请求：使用Burp Suite的Proxy功能拦截对/captcha.php的请求
禁用验证码刷新：通过浏览器控制台执行clearInterval(captchaInterval)停止验证码自动刷新
暴力破解防护：编写Python脚本自动化尝试常见默认凭证组合：

import requests session = requests.Session() captcha = "1234" # 固定的验证码 url = "http://target.com/login" with open("top_default_passwords.txt") as f: for password in f: data = { "username": "admin", "password": password.strip(), "captcha": captcha } resp = session.post(url, data=data) if "Login failed" not in resp.text: print(f"Success! Password: {password}") break

意外受阻：脚本运行了几分钟后，我意识到问题没那么简单——即使使用固定验证码，服务器似乎还有某种频率限制。每次连续尝试约20次后，连接就会被重置。

3. 深入挖掘：产品手册带来的转机

这时我决定换个思路，转而研究"亿邮网关"这个产品。通过搜索引擎，我找到了该网关的官方技术文档，其中几个关键信息引起了我的注意：

默认管理员账户：admin@eyou.net
初始密码可能是安装日期，格式为YYYYMMDD
旧版本存在密码哈希泄露漏洞

我立即更新了攻击策略：

尝试文档中的默认凭证：admin@eyou.net/admin组合失败
搜集目标环境线索：在页面底部发现版权信息"© 2018-2020"
生成日期密码字典：用Crunch工具生成2018-2020期间所有可能的日期组合

crunch 8 8 -t 20%%%%%% -o dates.txt -s 20180101 -e 20201231

这次尝试很快有了结果——密码20200401（可能是COVID-19疫情期间的安装）成功通过了验证！

4. 权限提升与Flag获取

登录后的界面是一个简化的管理控制台，但Flag并不在可见位置。通过查看页面源代码，我发现了一个隐藏的API端点：

<!-- 调试接口：/api/debug?action=view&file=../../flag.txt -->

这明显是一个路径遍历漏洞。我直接访问该URL，却收到403 Forbidden响应。看来需要管理员权限。

通过查阅亿邮网关的API文档，我构造了以下请求成功获取了Flag：

POST /api/admin/debug HTTP/1.1 Host: target.com Content-Type: application/json Cookie: session=valid_session_id { "action": "read", "file": "../../flag.txt" }

5. 防御措施与经验总结

这次挑战让我深刻认识到默认凭证在安全体系中的危险性。以下是几点关键经验：

永远修改默认凭证：这是最基本却最常被忽视的安全措施
客户端验证不可信：所有关键验证必须在服务端完成
信息泄露链：产品文档、注释、错误信息都可能成为突破口
纵深防御：单一防护措施（如验证码）很容易被绕过

对于防御者而言，我建议采取以下措施：

风险点	防御方案	实施难度
默认凭证	首次登录强制修改密码	低
验证码漏洞	服务端会话绑定验证码	中
路径遍历	文件访问白名单机制	高
API权限	严格的RBAC控制	中