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. 突破验证码：前端漏洞的利用

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

1. 拦截验证码请求：使用Burp Suite的Proxy功能拦截对/captcha.php的请求
2. 禁用验证码刷新：通过浏览器控制台执行clearInterval(captchaInterval)停止验证码自动刷新
3. 暴力破解防护：编写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
• 旧版本存在密码哈希泄露漏洞

我立即更新了攻击策略：

1. 尝试文档中的默认凭证：admin@eyou.net/admin组合失败
2. 搜集目标环境线索：在页面底部发现版权信息"© 2018-2020"
3. 生成日期密码字典：用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. 防御措施与经验总结

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

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

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

这次CTF挑战最宝贵的收获是认识到：真正的安全不在于复杂的防护，而在于每个基础环节的严格执行。那些被标记为"测试环境勿动"的默认设置，往往就是整个防御体系中最脆弱的环节。