用户
搜索
  • TA的每日心情
    开心
    2021-5-27 08:23
  • 签到天数: 179 天

    连续签到: 1 天

    [LV.7]常住居民III

    i春秋作家

    Rank: 7Rank: 7Rank: 7

    13

    主题

    41

    帖子

    1955

    魔法币
    收听
    0
    粉丝
    4
    注册时间
    2018-6-2

    i春秋签约作者

    发表于 2020-12-3 22:26:41 320139
    本帖最后由 dll_s 于 2020-12-3 22:32 编辑

    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

    网络架构情境 表现
    CL.TE 超时
    TE.CL 出现错误
    TE.TE 出现错误
    CL.CL 正常处理

    下面介绍一下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时,服务器正常处理请求

    网络架构情境 表现
    TE.CL 超时
    CL.TE 干扰其他用户请求
    TE.TE 部分数据被丢弃
    CL.CL 正常处理

    注意:在使用包含终止数据块的检测报文中,务必确保终止块为0\r\n\r\n,其对应的ASCII Hex码值为300d0a0d0a,不能在0后接空格或其他字符,这会导致终止块失效(后续实验不再强调)

    所以使用上面两种报文就可以探查出具体的漏洞情境,当然如上一章中所介绍的那样,一些服务器可能会受到模糊的请求头的干扰而产生异常,而在这种情况下使用自动化检测工具会更加方便,这一内容会在文末介绍

    实验内容

    实验一:确认CL.TE情境的HTTP请求走私漏洞

    实验提示:这个实验涉及到了两台服务器,前端服务器不支持分块编码传输(即不支持Transfer-Encoding解析)

    实验要求:利用HTTP请求走私漏洞走私数据,使得其下一个正常请求会触发404 Not Found相应

    img

    同样先浏览网页,将请求发送到repeater进行操作,先将GET改为POST进行尝试

    img

    成功返回,接下来我们使用前文所讲的CL.TE测试报文,注意要去除Update Content-Length勾选

    Transfer-Encoding: chunked
    Content-Length: 4
    
    1
    Z
    Q

    发送请求等待了一段时间(超时)后返回500 Internal Server Error错误,因此可以判断存在CL.TE情境下的HTTP请求走私漏洞

    img

    确认漏洞存在后,我们就需要来构造走私数据了,经过测试发现只要请求任意不存在的网页路径就会触发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

    发送恶意请求

    img

    之后我们发送正常报文进行测试,这里可以重新发送一个报文流到Repeater方便我们随实切换操作

    发送正常报文,触发404响应完成实验

    img

    实验二:确认TE.CL情境的HTTP请求走私漏洞

    实验提示:这个实验涉及到了两台服务器,后端服务器不支持分块编码传输(即不支持Transfer-Encoding解析)

    实验要求:利用HTTP请求走私漏洞走私数据,使得其下一个正常请求会触发404 Not Found相应

    img

    将报文流发送到Repeater,首先使用CL.TE的检测报文,注意不要勾选Update Content-Length

    img

    返回错误并且没有超时,说明不符

    接下来使用TE.CL检测报文

    Transfer-Encoding: chunked
    Content-Length: 6
    
    0
    
    X

    发送请求,等待一段时间后超时并返回了错误

    img

    因此可以判断漏洞情境为TE.CL,开始构造走私报文

    Content-Length: 4
    Transfer-Encoding: chunked
    
    1B
    POST /index HTTP/1.1
    
    x=1
    0
    

    这里的分块长度1B比较难以计算,后面会介绍一下工具的使用,也可以将POST替换为GET(这里的payload构造并不具备普遍性,就是可能在具体的生产环境中是不通用的,其基本构造原则就是尽量和正常请求相似,这样可以避免前置的分流服务器将两次请求导向到不同的服务器当中,更多的还是侧重于原理的理解)

    Content-Length: 4
    Transfer-Encoding: chunked
    
    1A
    GET /index HTTP/1.1
    
    x=1
    0
    

    发送构造的恶意请求

    img

    再发送正常请求,成功触发404错误 完成实验

    img

    自动化检测及利用


    可以看到手工检测HTTP走私漏洞,并进行漏洞验证还是比较繁琐的,接下来介绍一下Burp的自动利用插件HTTP Request Smuggler。具体的安装细节就不讲了,直接在BApp中搜索安装就可以了,注意:此插件依赖于Turbor Intruder插件,没有安装的记得安装。

    下面以第二个实验TE.CL为例,右键点击需要检测的报文流,选择Launch Smuggler probe运行

    img

    弹出了一个扫描配置框,一些具体的细节我也还不是很了解,相关的帮助文档也很少,大家可以结合Logger++插件分析勾选不同配置其所发送的报文有何不同。另外,这里还有一个比较尴尬的问题,似乎是由于插件本身问题,可能会其部分界面超出了屏幕显示范围,导致看不到任何按钮。这一界面其实有两个按钮,一个开始一个取消,所以直接按Enter即可开始检测,也可以观察Logger++中的日志检查插件是否成功运行。

    img

    像这样就是已经开始自动检测了

    img

    检测结果在Target界面,如图已经检测到了TE.CL HTTP请求走私漏洞

    img

    选择右下角的request框,选择任意一个请求右键选择执行TE.CL攻击,就会弹出Turbor Intruder的配置界面

    img

    可能有些人没有接触过这一插件,简单的讲它就是Intruder的升级版,可以快速进行爆破等操作,只是需要用脚本进行配置,具体这篇文章就不展开讲了,仅介绍一下请求走私会涉及到的内容。如果有python基础的话,这一脚本应该不难看懂,它会发送一个攻击请求和14个原始请求,我们所需要更改的主要就是perfix变量值

    img

    该变量的值就是在实验中走私的内容,填充所需走私的数据,配置完成后点击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响应

    img

    总结

    这一漏洞的利用原理还是挺难理解的,需要大家在实验中多多体会,另外在实验中要注意\r\n的添加以及去除Update Content-Length勾选,更多原理及细节参考:

    本帖被以下淘专辑推荐:

    感谢分享!
    使用道具 举报 回复
    发表于 2020-12-11 13:38:33
    本帖最后由 dll_s 于 2020-12-11 13:42 编辑

    注意文中的两个报文应该是



    疑似是论坛的编辑器渲染有问题,导致1A和1B中的1丢失了
    使用道具 举报 回复
    学习了,多谢楼主分享。
    使用道具 举报 回复
    发新帖
    您需要登录后才可以回帖 登录 | 立即注册