问答
发起
提问
文章
攻防
活动
Toggle navigation
首页
(current)
问答
商城
实战攻防技术
漏洞分析与复现
NEW
活动
摸鱼办
搜索
登录
注册
记一次前端断点调试到管理员登陆
渗透测试
差点shell，可惜条件不允许。实战总是差点shell的火候，真是令人痛心呐痛心。 发现前端漏洞 This is a 靶标，出于保密原因我就不上图了，长得非常泛微。 一般看到这种一眼通用的系统我都会直接...
差点shell，可惜条件不允许。实战总是差点shell的火候，真是令人痛心呐痛心。 发现前端漏洞 ------ 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可以在这种情况下跑，这里出于研究心态继续了）。 那就又回到断点问题，如何在没有调用的情况下进断点？ 很简单，写一个调用不就行了^ ^。山不就我我来就山嘛。 已知登陆时会调用r\["a"\].rsaEncrypt，那么启用本地替换并在前面补上一行r\["a"\].desEcrypt("a")不就能进入desEncrypt的调用了？  说干就干，右键选择替换内容，然后在encrypt的第一行输入r\["a"\].desEcrypt("a")，下断。  再次登陆，跟随断点直接获取到密钥的值：  再战管理员 ----- ### 解不出一毛 一通瞎跑然后使用经典的用户表查询，也是很快就获取到了一个普通权限的账号密码登陆。本来一切顺风顺水~但突然来了个应急，笔者跟着帽子叔叔出去浪了一天，第二天到公司的时候sqlmap咋跑都跑不动了，低权限账号进去也是啥都没有，有个屁啊！  但是冷静下来想，加密注入怎么可能一天就修了？这又不是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：  意外收获 ---- 既然系统长得像泛微，那我是真得查一查：  简单搜了下pack名，看来真是个小通用思密达~好了收工~
发表于 2024-08-07 09:00:00
阅读 ( 3600 )
分类：
渗透测试
5 推荐
收藏
0 条评论
请先
登录
后评论
阿斯特
AugustTheodor di CatXicure
6 篇文章
×
发送私信
请先
登录
后发送私信
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
