Burpsuite练兵场-如何探查并确认HTTP走私漏洞

zhaorong · 发表于 WEB前端技术 2021-7-6 16:43:28


	0x41 Burpsuite练兵场-如何探查并确认HTTP请求走私漏洞（二）前一章节介绍了HTTP请求走私的基本原理，这一节深入介绍一下在实际的生产环境中如何发现该漏洞的存在来看这样一个场景有一台服务器提供了一个web页面的访问用户可以通过提交POST请求在网页内容中添加评论且由于这一网页内容非常受人欢迎所以访问量很大。站长在这种情况下部署了SDN服务以承载更多的流量。此时有一位攻击者Bob Bob试图使用所学的知识对这一服务器发动HTTP走私攻击那么首先他需要探查这一网络的结构构成了哪种漏洞情形TE.CL/CL.TE 不了解的可以看上一章。而在这一探查的步骤中一个关键点是如何不干扰正常用户的请求而同时测试结果又不会受到其他用户在同一时间发送请求的干扰。首先来讲解一下用于CL.TE的检测报文 POST /about HTTP/1.1 Host: example.com Transfer-Encoding: chunked Content-Length: 4 1 Z Q 复制代码假设网络架构情形为CL.TE 当前端服务器收到这一报文时由于CL字段值为4 所以仅将前一部分的1\r\nZ转发给后端服务器。而后端服务器接收后通过TE字段判断该报文为分块报文但由于并未接收到终止块所以会一直等待下一报文的到来而最终超时那如果这一报文遇到的情境为TE.CL呢前端服务器识别了TE头并开始解析数据块。第一行1为第一块数据的长度而最后一行由于使用了非法的数据块长度值Q 所以这一请求会被拒绝。同样在情境为TE.TE也会直接返回错误而当情境为CL.CL时则会成功接收请求所以当这一检测报文发出后产生了超时结果即可判定这一漏洞情形为CL.TE 下面介绍一下TE.CL的检测报文 POST /about HTTP/1.1 Host: example.com Transfer-Encoding: chunked Content-Length: 6 0 X 复制代码假设网络架构情形为TE.CL情形前端服务器收到请求后解析TE头判断为分块报文由于第一块即为终止块所以前端服务器并不会传输后面的数据内容。而后端服务器在接收到转发后解析CL头判断数据块内容为6字节而由于只收到了部分数据内容所以会一直等待导致超时如果这一报文遇到的情境为CL.TE 前端服务器解析CL头后转发整个报文而后端服务器接收到转发后由于直接接收到了终止块所以会将后续的数据X留存在TCP信道当中导致干扰其他用户的请求所以我们应该在使用上一检测报文后再进行这一检测而当情境为TE.TE时数据X会被丢弃由于攻击者与前端服务器之间一般不会重用信道当情境为CL.CL时服务器正常处理请求注意：在使用包含终止数据块的检测报文中务必确保终止块为0\r\n\r\n 其对应的ASCII Hex码值为300d0a0d0a 不能在0后接空格或其他字符这会导致终止块失效后续实验不再强调。所以使用上面两种报文就可以探查出具体的漏洞情境当然如上一章中所介绍的那样一些服务器可能会受到模糊的请求头的干扰而产生异常而在这种情况下使用自动化检测工具会更加方便这一内容会在文末介绍。实验内容实验一：确认CL.TE情境的HTTP请求走私漏洞实验提示：这个实验涉及到了两台服务器前端服务器不支持分块编码传输即不支持Transfer-Encoding解析实验要求：利用HTTP请求走私漏洞走私数据使得其下一个正常请求会触发404 Not Found相应同样先浏览网页将请求发送到repeater进行操作先将GET改为POST进行尝试成功返回接下来我们使用前文所讲的CL.TE测试报文注意要去除Update Content-Length勾选 Transfer-Encoding: chunked Content-Length: 4 1 Z Q 复制代码发送请求等待了一段时间超时后返回500 Internal Server Error错误因此可以判断存在CL.TE情境下的HTTP请求走私漏洞确认漏洞存在后我们就需要来构造走私数据了经过测试发现只要请求任意不存在的网页路径就会触发404响应，所以可以使用 Transfer-Encoding: chunked Content-Length: 28 0 GET /index HTTP/1.1 复制代码注意在GET /index HTTP/1.1后要有多个换行当然也可以使用实验提供的payload Transfer-Encoding: chunked Content-Length: 26 0 GET /index HTTP/1.1 X-Ignore: X 复制代码发送恶意请求之后我们发送正常报文进行测试这里可以重新发送一个报文流到Repeater方便我们随实切换操作发送正常报文触发404响应完成实验实验二：确认TE.CL情境的HTTP请求走私漏洞实验提示：这个实验涉及到了两台服务器后端服务器不支持分块编码传输即不支持Transfer-Encoding解析实验要求：利用HTTP请求走私漏洞走私数据使得其下一个正常请求会触发404 Not Found相应将报文流发送到Repeater 首先使用CL.TE的检测报文注意不要勾选 Update Content-Length 返回错误并且没有超时说明不符接下来使用TE.CL检测报文 Transfer-Encoding: chunked Content-Length: 6 0 X 复制代码发送请求等待一段时间后超时并返回了错误因此可以判断漏洞情境为TE.CL 开始构造走私报文 Content-Length: 4 Transfer-Encoding: chunked B POST /index HTTP/1.1 x=1 0 复制代码这里的分块长度1B比较难以计算后面会介绍一下工具的使用也可以将POST替换为GET 这里的payload构造并不具备普遍性就是可能在具体的生产环境中是不通用的其基本构造原则就是尽量和正常请求相似这样可以避免前置的分流服务器将两次请求导向到不同的服务器当中更多的还是侧重于原理的理解。 Content-Length: 4 Transfer-Encoding: chunked A GET /index HTTP/1.1 x=1 0 复制代码发送构造的恶意请求再发送正常请求成功触发404错误完成实验自动化检测及利用可以看到手工检测HTTP走私漏洞并进行漏洞验证还是比较繁琐的接下来介绍一下Burp的自动利用插件 HTTP Request Smuggler。具体的安装细节就不讲了直接在BApp中搜索安装就可以了注意：此插件依赖于Turbor Intruder插件没有安装的记得安装。下面以第二个实验TE.CL为例右键点击需要检测的报文流选择Launch Smuggler probe运行弹出了一个扫描配置框一些具体的细节我也还不是很了解相关的帮助文档也很少大家可以结合Logger++插件分析勾选不同配置其所发送的报文有何不同。另外这里还有一个比较尴尬的问题似乎是由于插件本身问题可能会其部分界面超出了屏幕显示范围导致看不到任何按钮。这一界面其实有两个按钮，一个开始一个取消所以直接按Enter即可开始检测，也可以观察Logger++中的日志检查插件是否成功运行。像这样就是已经开始自动检测了检测结果在Target界面如图已经检测到了TE.CL HTTP请求走私漏洞选择右下角的request框选择任意一个请求右键选择执行TE.CL攻击就会弹出Turbor Intruder的配置界面可能有些人没有接触过这一插件简单的讲它就是Intruder的升级版可以快速进行爆破等操作只是需要用脚本进行配置具体这篇文章就不展开讲了仅介绍一下请求走私会涉及到的内容。如果有python基础的话这一脚本应该不难看懂它会发送一个攻击请求和14个原始请求，我们所需要更改的主要就是perfix变量值。该变量的值就是在实验中走私的内容填充所需走私的数据配置完成后点击ATTCK启动 prefix = '''POST /index HTTP/1.1 Host: ac161fbe1ea944fa80c22ff300ef0012.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 4 x=1''' 复制代码成功触发了404响应总结这一漏洞的利用原理还是挺难理解的需要大家在实验中多多体会另外在实验中要注意\r\n的添加以及去除Update Content-Length勾选。

微信扫一扫 分享朋友圈

Burpsuite练兵场-如何探查并确认HTTP走私漏洞

微信扫一扫分享朋友圈