某实战项目登录口处的渗透测试

0x01 背景

在测试开始之初，仅提供了目标系统的网址，并未直接给测试账号。这一情况使得我们将初步的测试重点聚焦于系统的 “忘记密码” 功能模块，希望通过此模块的相关测试，为后续进一步深入的渗透测试工作打开局面。

0x02 初识登录口：

问题一：

忘记密码处输入用户账号如user后发送数据包后后端会显示账号带有user的其他用户信息(如显示user1或adminuser)。此处猜测后端对用户输入账号进行了通配符匹配，例如%user%。

问题二：

重置密码时需要输入用户手机号。通过泄露的用户信息，选择一个包含手机号的账号进行随机尝试重置。在此过程中，需要验证手机验证码。修改自己的手机号并尝试无果后，直接将验证码发送到默认绑定的手机上，然后随机填写验证码并发送数据包，虽然重置密码未成功，但返回的内容包含了一个error和999999。根据系统前面验证手机号时返回true和000000的经验，将error和999999修改为true和000000后，成功跳转至重置密码页面。经过测试，发现绕过前端验证后修改密码的页面实际上是未授权的，输入对应用户ID后即可重置该用户密码 。

重置密码后，去登录，结果发现居然无法登录，且提示“用户名和密码错误”。不过，后端明明显示密码已重置成功。经过一番排查，我发现忘记密码接口的子域名和被测系统的子域名并不相同，开始怀疑它们可能并非使用同一数据库。于是询问情况，答复说这个接口并不需要测试，因为它实际上调用的是其他系统中的服务。最终，我只能放弃这一部分的测试（/(ㄒoㄒ)/~~）。

0x03 再遇登录口：

再次回到登录接口后，我首先尝试登录账号并进行抓包，发现即使是相同账号和密码，每次加密内容都不同。我猜测可能加入了时间参数校验机制，但同一数据包多次重放并未有异常情况出现，猜测这里后端并未对时间进行校验。

通过抓包可见携带加密值的参数为identityInstance全局搜索传递加密参数的identityInstance，稍微翻阅了一下代码，发现这里采用了SM4算法对用户名、密码和时间戳进行了加密。

继续通过全局搜索加密函数SM4Encrypt，稍微翻阅了一下代码，便找到了加密密钥。这里简单梳理一下可知，加密过程主要通过调用 “SM4Encrypt” 函数来实现，该函数接“identityInstance” 和 “SM4Data” 作为输入参数，利用预先设定的密钥完成对用户登录信息的加密操作。

这里我们简单介绍一下sm4加密： SM4是一种对称加密算法（与AES类似），即加密和解密使用同一个密钥。对称加密的特点是速度快，适合大数据量加密，但需确保密钥安全传输。

这里我们将已知代码传给deepseek，借助AI生成出加密代码，当然也要引用术语，每次我问它关于渗透的问题时都喜欢在开头告诉这是CTF题目😈。

脚本生成好后，就尝试使用各种弱口令进行的爆破，但均未能成功。回想起之前在忘记密码界面遇到的问题——回显了相关用户信息，我将回显的用户ID全部提取了出来。由于数据库不同，这次依然未能成功突破。

陷入僵局后，于是索要了一个账号，账户命名规则为字母加六位数字。当使用该账号登录时，回显信息为“认证错误”，而之前的账号则返回“用户名或密码错误”。这让我猜测，所有用户账号的命名规则可能都是字母+六位数数字，例如A111111。因此，我直接生成了后四位从0001到9999的范围，也就是A110000到A119999。

通过发包遍历这些账号，我成功测试出数百个用户，并将返回包中不同的用户信息一一保存下来。最终，通过爆破，返回包带有Token的均为弱口令账号。

0x04 总结

AI出来前加密参数需手工编写加密算法耗时费力，需掌握不同加密方法的编写逻辑，且不同网站使用 RSA/AES/SM4 等加密方案均具有差异化。如今分析出网站采用的加密逻辑以及密钥等参数可借助AI直接生成加密代码，事半功倍。