SSRF+CRLF漏洞组合利用分析
SSRF漏洞是服务端请求伪造攻击,这个漏洞基于http协议,不论是GET或者是POST方法,都是为了达到一个目的,就是让服务端帮我们来执行请求。
那么就引出两个问题:
- 为什么要让服务端来帮我们请求?
- 服务端可以帮我们进行什么样的请求?
CRLF漏洞是一个过滤不严格导致的可以输入%0D%0A这两个字符制造换行效果的漏洞,这个漏洞看起来很小,但是在组合漏洞攻击链中也是属于必不可少的组成部分,因为它是非常好的粘合剂。
单独这个漏洞很难造成较大的危害,但是就像python一样,本身能力一般,不过它最大的能力是把两个本来没关系的混蛋联合在一起,变成“大混蛋”,哈哈!
那么就引出问题来了:
- 我们要粘合什么样的漏洞、攻击或者服务?
- 怎么利用CRLF漏洞来做这样的粘合呢?
SSRF在组合利用中起到如下作用:
- 服务器端请求伪造
- 绕过防火墙,到达内网
- 攻击内部服务,比如:Struts2、Redis、Elastic
SSRF可以伪造的请求包括两种类型的协议:
- HTTP 类型协议,比如:Elastic, CouchDB, Mongodb, Docker
- 文本类型协议,比如: FTP, SMTP, Redis, Memcached
充分利用SSRF,我们可以到达的空间超乎你的想象,不管在互联网服务攻击,或者集团内网渗透都有着重要的发挥空间。
这里要注意,如果没有CRLF漏洞,SSRF在漏洞利用中会失色不少,上面提到的伪造协议的很多种都是需要换行符作为命令结束符号的,所以善于利用CRLF漏洞非常重要。
不过需要提出的是,大部分产品对于CRLF漏洞并不是特别注意,还是有很多大的公司或者通用性很强的产品仍然在使用有问题的组件。这里要说的是毕竟CRLF漏洞单独行动的话,没有什么特别大的意义,而CVE记录的漏洞很少会有对多种产品的不同类型的漏洞组合利用的记录。这也是造成CRLF漏洞还可以找到的原因,这不是普通小白帽愿意花时间去琢磨的东西。
下面附图一张,可能有问题的组件:
参考链接:
- A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!
- http://blog.chinaunix.net/uid-28924599-id-4290910.html
- https://blog.****.net/zhouwei1221q/article/details/47399691
- https://www.secpulse.com/archives/40977.html?from=groupmessage
- https://blog.****.net/tangcc110/article/details/79803463
- http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html
- https://blog.****.net/zxcxq/article/details/76938386