问答
发起
提问
文章
攻防
活动
Toggle navigation
首页
(current)
问答
商城
实战攻防技术
漏洞分析与复现
NEW
活动
摸鱼办
搜索
登录
注册
记一次前端断点调试到管理员登陆
渗透测试
差点shell,可惜条件不允许。实战总是差点shell的火候,真是令人痛心呐痛心。 发现前端漏洞 This is a 靶标,出于保密原因我就不上图了,长得非常泛微。 一般看到这种一眼通用的系统我都会直接...
差点shell,可惜条件不允许。实战总是差点shell的火候,真是令人痛心呐痛心。 发现前端漏洞 ------ This is a 靶标,出于保密原因我就不上图了,长得非常泛微。 一般看到这种一眼通用的系统我都会直接跑路,但是一开始说了,this is a 靶标,所以还得先看一看。 由于前端一眼打包器,跑一跑URL。一轮下来也是一堆堆401,但有两个带sql的路径居然是200: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1721806609776-73eee3a0-d8be-43e3-92f9-6804ec88da09.png?x-oss-process=image%2Fformat%2Cwebp) 这倒是有意思,直接发到重发器看看返回。 ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1721899178826-5f1880b0-e4f7-4d11-ae07-94313b9a4421.png) 由于不知道参数,直接返回脚本为空。但看返回的意思是可以直接执行sql语句? 于是折回前端看看js,看是否能找到参数。一番查找,很幸运的是路由跟参数表放在一起: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1721900117309-444b84c6-2bd0-434b-9de1-e8d65e50251d.png) sqlpart不出意外就是语句,argspart不知道,就先置为空。那么就代入参数再试一试: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1721987652550-e4630ea2-dab3-4272-b59c-d9f4ffc3bb85.png) 显示解密错误,应该是跟某种加密有关。那么我们返回js再向上看,确实套了一层des加密: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1721899790777-30161828-770e-45cc-a5ea-15cbd99149c1.png) 直接搜索函数的名字: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1721901143600-674cf90e-9423-4583-9b44-545227bffd7e.png) 这里也是个很简单的标准DES,只不过两个参数key和iv不以明文方式出现。函数采用了类似导出的方式,它的上下文不太好找。 不过一般存在加密的网站会对所有请求包进行加密,所以我们可以先登录试试看看能不能直接走到这个函数,然后下断点抓key。函数第一行下断点前端登录查看是否能断下,结果并没有,请求包越过我的断点飞奔而去: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1721988005356-ffc0c0ae-2188-4076-a43d-8db1b31b0f86.png) 看来登陆请求使用的并非这个加密函数。那么我们如何通过断点调试获得key和iv呢?总不能真的手算吧? 创造一个断点调试的环境 ----------- ### 获取一个desEncrypt 在遇到看似误解的难题时,我们通常需要细心观察。在函数所在js文件中上下查找,发现这个文件中存在多个加解密函数: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722221887100-2069ad25-3a88-4f59-94ce-a6f6bd5f51cf.png) 而它们都属于同一个导出。那么假设存在一个调用a.rsaEncrypt,那么这个a是否也有desEncrypt的上下文呢?依照这个思路,我们可以随机找一个使用加密的包然后在调用加密时下断。如果不想找,也可以给所有加密函数下断,然后等待调用。 还是登录包,在函数rsaEncrypt处断下。向前跳一个堆栈,来到encrypt函数处: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722222788816-249030d7-0964-430e-a9ef-19420021028c.png) 此时console会获得当前的上下文(也就是当前作用域下所有变量),我们尝试在console下调用desEncrypt,成功: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722223023187-14e964ec-cd0f-4f93-b5be-e0129a4b39db.png) 然后我们在控制台中将这个函数“导出”,也就是存储为全局变量: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722223456564-fb747ab7-1b16-4e13-ad0e-80cc6b0072e9.png) 然后放开断点,直接调用导出的变量,成功: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722223468352-d89504b3-e8f3-4f8d-a8e7-e6adf95c8e79.png) ### 下断点v2 现在我们获得了一个可以直接调用的加密函数,先试用此函数试试SQL语句是否能够执行,比如加密select 1: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722224581818-e5698dea-8141-45b6-abb5-d7b976559adf.png) ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722224570817-ce72ceb7-0454-4acf-97c6-ac9ddfb3c014.png) 执行成功~这下起码确认漏洞是存在的。但本脚本小子肯定不愿意手动一个个调用desE再复制粘贴,所以需要一个全自动工具帮我跑出库名表名等,比如sqlmap。这就需要我找到真正的key,而不仅仅是在console中获得一个导出(其实笔者写的插件processorRemote可以在这种情况下跑,这里出于研究心态继续了)。 那就又回到断点问题,如何在没有调用的情况下进断点? 很简单,写一个调用不就行了^ ^。山不就我我来就山嘛。 已知登陆时会调用r\["a"\].rsaEncrypt,那么启用本地替换并在前面补上一行r\["a"\].desEcrypt("a")不就能进入desEncrypt的调用了? ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722235923514-ca6e47eb-2f18-4dd4-a996-ece936347119.png) 说干就干,右键选择替换内容,然后在encrypt的第一行输入r\["a"\].desEcrypt("a"),下断。 ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722236197683-c3b3d907-4c67-4f22-a804-3097bdf3776c.png) 再次登陆,跟随断点直接获取到密钥的值: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722236271535-e8be9923-6829-47da-bc3d-8df31630ae3b.png) 再战管理员 ----- ### 解不出一毛 一通瞎跑然后使用经典的用户表查询,也是很快就获取到了一个普通权限的账号密码登陆。本来一切顺风顺水~但突然来了个应急,笔者跟着帽子叔叔出去浪了一天,第二天到公司的时候sqlmap咋跑都跑不动了,低权限账号进去也是啥都没有,有个屁啊! ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722236755186-4e33331f-5787-41e2-9475-c77909ce965e.png) 但是冷静下来想,加密注入怎么可能一天就修了?这又不是GHvv,而且其他路由都没有问题,账号也可以继续登录——这并不像是应急的痕迹。 抛开sqlmap,手动再次访问端点,访问失败。 删除参数中的内容,访问成功。 再次使用select 1测试,成功。 使用select 1',失败。 看来问题不出在web端,也许是蓝队发现数据库错误日志异常增加给数据库加上了什么修改。不过没事,昨天起码跑了一个账号,账号表的位置我还是知道的。 简单select \* from dbs.users where isAdministrator=1找一下管理员账号,有五个: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722239637895-afbdcde9-8e9b-4830-9cc8-6e462b58dc7d.png) 但很可惜,没有一个密码能解,fxxk! ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722239713855-af077f1e-8459-4f4f-b9ac-4155094ca217.png) 真令人仰天锥心而泣血者也......这就像是临门一脚了发现对面用的金库保险门- -。 ### 越权是程序员的原罪 这下又只能继续对后台进行测试了。后台左翻翻右翻翻还是没啥数据,sql注入已经有了,文件上传到了静态目录,RCE又不是一般黑盒能整出来的大活。 功能点看完了返回BP看一看原始包: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722240150688-9c2f7c4e-9f8e-48f1-8bbd-b53ec0dd076b.png) 其它的都无所谓,这个UserId水灵灵得让人发现端倪。一般能够在请求包中出现可枚举的用户ID时,这个系统都存在有用户越权的可能。这里的用户ID虽然不可枚举(这里是UUID)——但我拥有一整个数据库,查查用户ID还是易如反掌。 随便取出一个管理员所属ID,bp开启替换,再次刷新: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722244966772-5f181044-4a28-47b8-8222-73d01c3a3544.png) 喜提高贵的Administrator: ![](https://cdn.nlark.com/yuque/0/2024/png/32358243/1722245210782-ab2bba1a-f232-4197-bb41-3f396bf9cc26.png) 意外收获 ---- 既然系统长得像泛微,那我是真得查一查: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/07/attach-eb9dec56f673d1c8e5b3a9e0af7d7eb59276e9b2.png) 简单搜了下pack名,看来真是个小通用思密达~好了收工~
发表于 2024-08-07 09:00:00
阅读 ( 2321 )
分类:
渗透测试
4 推荐
收藏
0 条评论
请先
登录
后评论
阿斯特
AugustTheodor di CatXicure
6 篇文章
×
发送私信
请先
登录
后发送私信
×
举报此文章
垃圾广告信息:
广告、推广、测试等内容
违规内容:
色情、暴力、血腥、敏感信息等内容
不友善内容:
人身攻击、挑衅辱骂、恶意行为
其他原因:
请补充说明
举报原因:
×
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!