实战 | 从源码隐藏入口到数据库备份泄露的后台沦陷

免责声明

本公众号“猎洞时刻”旨在分享网络安全领域的相关知识，仅限于学习和研究之用。本公众号并不鼓励或支持任何非法活动。本公众号中提供的所有内容都是基于作者的经验和知识，并仅代表作者个人的观点和意见。这些观点和意见仅供参考，不构成任何形式的承诺或保证。本公众号不对任何人因使用或依赖本公众号提供的信息、工具或技术所造成的任何损失或伤害负责。本公众号提供的技术和工具仅限于学习和研究之用，不得用于非法活动。任何非法活动均与本公众号的立场和政策相违背，并将依法承担法律责任。本公众号不对使用本公众号提供的工具和技术所造成的任何直接或间接损失负责。使用者必须自行承担使用风险，同时对自己的行为负全部责任。本公众号保留随时修改或补充免责声明的权利，而不需事先通知。

前言

在日常挖掘 EDU 小程序时，我照例抓包测试了它的后端 api.example.net。

这个地址对应一个登录界面，我尝试了多种方法，但都没有找到突破口。

随后我查询该域名的归属，发现它属于某某学校，在 EDUSRC 收录范围内。

接着我枚举子域名，发现了主站 www.example.net。主站 UI 非常老旧，感觉有希望。结果后面果然发现了不少漏洞，过程非常精彩。

漏洞挖掘

打开小程序后，我发现它的 UI 很像 AI 会使用的，于是决定深入挖掘。

该小程序的后端为 api.example.net，页面 UI 和小程序一致。常规挖掘中，我从前端 JS 里找 API 接口，发现接口都返回 401（未授权），弱口令爆破也失败了。

后来用 FOFA 找到主站 www.example.net，发现主页 UI 非常老，于是把深入挖掘目标换成了主站。

主站右下角有一个“教师登录”。这里本来可以尝试弱口令，但我没有试，而是直接按 Ctrl+U 查看网页源代码。

结果意外发现了admin管理员登录页面。这个路径名称看起来是随机字符串，推测是为了防止攻击者猜测，但它却被直接写在了网页源代码里。

注意：这个页面只能通过查看源代码发现，主页面上没有可点击的入口，所以属于“隐藏入口”, 目录dirsearch 扫描也不行，路径是乱码无序的。

进入后，标题显示“管理员登录”，登录框如下。

这个登录页面的文件是 adminlogin.php。没有在源码中发现登录成功后的页面路径，于是用 AI 生成常见后台文件名列表进行枚举，其中有index.php 等等一堆，最终发现 top.php 存在，并且返回了它的页面内容。

按 top 这个名字，它应该是一种布局，用于显示顶部数据。

但这个top.php页面暴露了存在 right.php。访问 right.php 页面后有信息，但没有暴露新的 PHP 文件。

因为 right 是“右边”的意思，我合理猜测会不会有“左边”，也就是 left.php。

结果 left.php 直接造成关键泄露，里面有一堆后台管理员操作的 PHP 页面。

如下图都是left.php里面泄露的其他文件名称（由于太多了，加上很多并没有用到，所以只展示了部分后面用到的）

访问adminlist.php文件，直接暴露了下面两个管理员账号名称。

访问 webconfig.php，暴露了认证码88888（上面登录需要用到）。

注意：关键转折点！

访问 data.backup.php，发现页面可以生成数据库备份文件并下载到本地。根据页面返回的值，我让 AI 帮助构造了备份请求，成功在本地下载了数据库文件，是一个SQL文件，里面全部是建表和插入记录的 SQL 语句，足足有 20MB 多。

不过很可惜，里面没有泄露身份证信息，但有 MD5 密码哈希。爆破出管理员 qXXX的密码为 QXXX@2020。

随后，我用获取到的管理员名称 qXXX(在adminlist.php文件泄露)、管理员密码 QXXX@2020、认证码 88888（在webconfig.php文件泄露），成功登录后台页面。

这也验证了之前 top.php、right.php、left.php 的作用。top.php 对应图片右上角的三个按钮，其中一个按钮是后台首页，也就是 right.php，即图片里默认显示的右侧页面，而 left.php 是左侧可以选择的功能。

同时根据后续测试，这个网站后台基本没有做有效鉴权。只要访问到 right.php，里面暴露的一堆 PHP 文件，再根据页面提示构造请求，就可以调用任何管理员功能，并且可以未授权添加新的管理员。

这里有一个很值得关注的点。

当没有管理员 Cookie 时，访问 top.php、right.php、left.php 等页面，会返回 Location: adminlogin.php 响应头，浏览器会跳转到管理员登录页。但与此同时，响应正文里仍然返回了页面内容。

这是一个造成信息泄露的逻辑漏洞，按理说没有 Cookie 不应该返回页面正文。这也为后续的未授权提供了决定性信息。

top.php

right.php

left.php

这个时候就要发散思维了。这个站点很老旧，说明开发人员或开发团队当时的安全意识非常薄弱，只为了完成功能，没有考虑安全问题。那么大概率还会存在其他漏洞。

后面尝试了很多，结果没想到主站主页还有 SQL 报错注入，如下。就是很常规的 payload：

1' and extractvalue(1,concat(0x7e,@@secure_file_priv)) and '1'='1

结果没想到还有规则把 updatexml 函数拦截了，但是 extractvalue 没拦截。

直接报错注入拿下，

总结

1. 小程序没突破口，就查归属、枚举子域名，找可能薄弱的站点。  

2. 看源码找隐藏入口，按命名规律猜后台文件，AI 可辅助生成字典。  

3. 302 跳转不代表安全，响应正文可能仍泄露敏感内容。  

4. 后台鉴权、备份、恢复等功能要重点测未授权，泄露信息要串联利用。  

5. AI 主要帮忙枚举、构造和分析，省时间。关键还是换目标、看源码、发散思路。

以上漏洞均已经提交和修复，请勿二次复现！

网安交流学习欢迎加群！