记一次前端断点调试到管理员登陆

本文又名“小保与SQL注入的一千次相遇”，第四个案例（详情请看文末合集：One Night in SQL Injection）。

感觉这篇有点低技术力，但是投稿到奇安信攻防社区的时候还是过了，真心感谢审核和运营同学的认可。

发现前端漏洞

This is a 靶标，出于保密原因我就不上图了，长得非常泛微。
一般看到这种一眼通用的系统我都会直接跑路，但是一开始说了，this is a 靶标，所以还得先看一看。
由于前端一眼打包器，跑一跑URL。一轮下来也是一堆堆401，但有两个带sql的路径居然是200：

这倒是有意思，直接发到重发器看看返回。

由于不知道参数，直接返回脚本为空。但看返回的意思是可以直接执行sql语句？
于是折回前端看看js，看是否能找到参数。一番查找，很幸运的是路由跟参数表放在一起：

sqlpart不出意外就是语句，argspart不知道，就先置为空。那么就代入参数再试一试：

显示解密错误，应该是跟某种加密有关。那么我们返回js再向上看，确实套了一层des加密：

直接搜索函数的名字：

这里也是个很简单的标准DES，只不过两个参数key和iv不以明文方式出现。函数采用了类似导出的方式，它的上下文不太好找。
不过一般存在加密的网站会对所有请求包进行加密，所以我们可以先登录试试看看能不能直接走到这个函数，然后下断点抓key。函数第一行下断点前端登录查看是否能断下，结果并没有，请求包越过我的断点飞奔而去：

看来登陆请求使用的并非这个加密函数。那么我们如何通过断点调试获得key和iv呢？总不能真的手算吧？

创造一个断点调试的环境

获取一个desEncrypt

在遇到看似无解的难题时，我们通常需要细心观察。在函数所在js文件中上下查找，发现这个文件中存在多个加解密函数：

而它们都属于同一个导出。那么假设存在一个调用a.rsaEncrypt，那么这个a是否也有desEncrypt的上下文呢？依照这个思路，我们可以随机找一个使用加密的包然后在调用加密时下断。如果不想找，也可以给所有加密函数下断，然后等待调用。
还是登录包，在函数rsaEncrypt处断下。向前跳一个堆栈，来到encrypt函数处：

此时console会获得当前的上下文（也就是当前作用域下所有变量），我们尝试在console下调用desEncrypt，成功：

然后我们在控制台中将这个函数“导出”，也就是存储为全局变量：

然后放开断点，直接调用导出的变量，成功：

下断点v2

现在我们获得了一个可以直接调用的加密函数，先试用此函数试试SQL语句是否能够执行，比如加密select 1：

执行成功~这下起码确认漏洞是存在的。但本脚本小子肯定不愿意手动一个个调用desE再复制粘贴，所以需要一个全自动工具帮我跑出库名表名等，比如sqlmap。这就需要我找到真正的key，而不仅仅是在console中获得一个导出（其实笔者写的插件processorRemote可以在这种情况下跑，这里出于研究心态继续了）。

关于processorRemote这个插件可以看我之前写的这篇文章：

那就又回到断点问题，如何在没有调用的情况下进断点？
很简单，写一个调用不就行了^ ^。山不就我我来就山嘛。
已知登陆时会调用r["a"].rsaEncrypt，那么启用本地替换并在前面补上一行r["a"].desEcrypt("a")不就能进入desEncrypt的调用了？

说干就干，右键选择替换内容，然后在encrypt的第一行输入r["a"].desEcrypt("a")，下断。

再次登陆，跟随断点直接获取到密钥的值：

再战管理员

解不出一毛

但是冷静下来想，加密注入怎么可能一天就修了？这又不是GHvv，而且其他路由都没有问题，账号也可以继续登录——这并不像是应急的痕迹。
抛开sqlmap，手动再次访问端点，访问失败。
删除参数中的内容，访问成功。
再次使用select 1测试，成功。
使用select 1'，失败。
看来问题不出在web端，也许是蓝队发现数据库错误日志异常增加给数据库加上了什么修改。不过没事，昨天起码跑了一个账号，账号表的位置我还是知道的。
简单select * from dbs.users where isAdministrator=1找一下管理员账号，有五个：

但很可惜，没有一个密码能解，fxxk！

真令人仰天锥心而泣血者也......这就像是临门一脚了发现对面用的金库保险门- -。

越权是程序员的原罪

这下又只能继续对后台进行测试了。后台左翻翻右翻翻还是没啥数据，sql注入已经有了，文件上传到了静态目录，RCE又不是一般黑盒能整出来的大活。
功能点看完了返回BP看一看原始包：

其它的都无所谓，这个UserId水灵灵得让人发现端倪。一般能够在请求包中出现可枚举的用户ID时，这个系统都存在有用户越权的可能。这里的用户ID虽然不可枚举（这里是UUID）——但我拥有一整个数据库，查查用户ID还是易如反掌。
随便取出一个管理员所属ID，bp开启替换，再次刷新：

喜提高贵的Administrator：

. . . * . * 🌟 * . * . .

原文始发于微信公众号（重生之成为赛博女保安）：记一次前端断点调试到管理员登陆