中间件常见漏洞总结
下面分三种常见的中间件来总结:IIS、apache、nginx,本文参考别人写的中间件漏洞总结,链接放在下面
链接: Web中间件常见漏洞总结.pdf_免费高速下载|百度网盘-分享无限制 (baidu.com)
提取码: vbey 复制这段内容后打开百度网盘手机App,操作更方便哦
IIS
IIS是Internet Information Services的缩写,意为互联网信息服务,是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。 IIS目前只适用于Windows系统,不适用于其他操作系统。
解析漏洞
IIS 6.x
基于文件名,该版本 默认会将 *.asp;.jpg 此种格式的文件名,当成Asp解析。
原理是 :
服务器默认不解析;号及其后面的内容,相当于截断。
基于文件夹名,该版本 默认会将 *.asp/目录下的所有文件当成Asp解析。
另外,IIS6.x除了会将扩展名为.asp的文件解析为asp之外,还默认会将扩展名为.asa,.cdx,.cer解析为asp
从网站属性->主目录->配置 可以看出,他们都是调用了asp.dll进行的解析。
修复建议
由于微软并不认为这是一个漏洞,也没有推出IIS 6.0的补丁,因此漏洞需要自己修复 。
1. 限制上传目录执行权限,不允许执行脚本。
2. 不允许新建目录。
3. 上传的文件需经过重命名(时间戳+随机数+.jpg等)
IIS 7.x
IIS7.x版本 在Fast-CGI运行模式下,在任意文件,例:test.jpg后面加上/.php,会将test.jpg 解析为php文件。
修复建议
配置cgi.fix_pathinfo(php.ini中)为0并重启php-cgi程序
PHP CGI 中 fix_pathinfo 引起的安全隐患 - buffer的blogs - 博客园
Nginx + PHP CGI的一个可能的安全漏洞 - 风雪之隅
结果如下:
PUT任意文件写入
IIS Server 在 Web 服务扩展中开启了 WebDAV之后,支持多种请求,配合写入权限,可造成任意文件写入 。
修复建议
关闭WebDAV 和 写权限
IIS短文件漏洞
一、漏洞描述
Internet Information Services(IIS,互联网信息服务)是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。
Microsoft IIS在实现上存在文件枚举漏洞,攻击者可利用此漏洞枚举网络服务器根目录中的文件。
危害:攻击者可以利用“~”字符猜解或遍历服务器中的文件名,或对IIS服务器中的.Net Framework进行拒绝服务攻击。
二、漏洞成因
为了兼容16位MS-DOS程序,Windows为文件名较长的文件(和文件夹)生成了对应的windows 8.3 短文件名。
在Windows下查看对应的短文件名,可以使用命令 dir /x
如上图,Downloads对应的短文件名为DOWNLO~1。根据此特性,我们能够通过访问短文件名间接访问它对应的文件。
由于短文件名的长度固定(xxxxxx~xxxx),因此黑客可直接对短文件名进行暴力破解,从而访问对应的文件。
举个例子,有一个数据库备份文件 backup_www.abc.com_20190101.sql,它对应的短文件名是 backup~1.sql 。因此黑客只要暴力破解出 backup~1.sql 即可下载该文件,而无需破解完整的文件名。
短文件名有以下特征:
1) 只有前六位字符直接显示,后续字符用~1指代。其中数字1还可以递增,如果存在多个文件名类似的文件(名称前6位必须相同,且后缀名前3位必须相同)。 2) 后缀名最长只有3位,多余的被截断。 3) 访问构造的某个存在的短文件名,会返回404 4) 访问构造的某个不存在的短文件名,会返回400
三、 漏洞的利用
漏洞的利用,需要使用到通配符。在windows中,可以匹配n个字符,n可以为0.判断某站点是否存在IIS短文件名暴力破解,构造payload,分别访问如下两个URL:
1. http://www.xxx.com/*~1****/a.aspx 2. http://www.xxx.com/1234*~1****/a.aspx
这里使用了4个星号,主要是为了程序自动化猜解,逐个猜解后缀名中的3个字符,实际上,一个星号与4个星号没有任何区别(上面已经提到,*号可以匹配空)。
如果访问第一个URL,返回404,
而访问第二个URL,返回400,
则目标站点存在漏洞,判断漏洞存在后,继续猜解目录下是否存在一个a开头的文件或文件夹,访问:
http://www.xxx.com/a*~1****/a.aspx
如果存在,将返回404。如此反复,不断向下猜解完所有的6个字符。猜解完之后,得到的序列应该类似:
http://www.xxx.com/abcdef*~1****/a.aspx
到了这一步,需要考虑两种情况,如果以abcdef开头的是一个文件夹,则
http://www.xxx.com/abcdef*~1/a.aspx
将返回404.
如果abcdef开头的是一个文件,则自动提交
http://www.xxx.com/abcdef*~1*g**/a.aspx
用a-z的26个字母替换上述g的位置,应该能得到多个404页面。(记住一点,404代表的是存在。)如果下面的地址返回404,
http://www.xxx.com/abcde*~1*g**/a.aspx
则代表扩展名中肯定存在g。
按照上面的思路,继续猜解g后面的字符,直到后缀名中的3个字符都猜解完,就可以了。
以上介绍了怎么手工猜解,这个漏洞的意义何在:
1) 猜解后台地址 2) 猜解敏感文件,例如备份的rar、zip、.bak、.SQL文件等。 3) 在某些情形下,甚至可以通过短文件名web直接下载对应的文件。比如下载备份SQL文件。
四、 漏洞的局限性
1) 只能猜解前六位,以及扩展名的前3位。
2) 名称较短的文件是没有相应的短文件名的。
3) 需要IIS和.net两个条件都满足
4) 如果文件名前6位带空格,8.3格式的短文件名会补进,和真实文件名不匹配;
5 ) 如果文件夹名前6位字符带点".",扫描程序会认为是文件而不是文件夹,最终出现误报;
6) 不支持中文文件名,包括中文文件和中文文件夹。一个中文相当于两个英文字符,故超过4个中文字会产生短文件名,但是IIS不支持中文猜测。
五、 解决方法
1)从CMD命令关闭NTFS 8.3文件格式的支持
Windows Server 2003: (1代表关闭,0代表开启)
关闭该功能:fsutil behavior set disable8dot3 1
Windows Server 2008 R2:
查询是否开启短文件名功能:fsutil 8dot3name query 关闭该功能:fsutil 8dot3name set 1
不同系统关闭命令稍有区别,该功能默认是开启的.
2)或从修改注册表关闭NTFS 8.3文件格式的支持
快捷键Win+R打开命令窗口,输入regedit打开注册表窗口
找到路径:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem,将其中的 NtfsDisable8dot3NameCreation这一项的值设为 1,1代表不创建短文件 名格式
以上两种方式修改完成后,均需要重启系统生效。
Note:此方法只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除,需要重新复制才会消失。 例:将web文件夹的内容拷贝到另一个位置,如c:\www到c:\ww,然后删除原文件夹,再重命名c:\ww到c:\www。
参考文章
IIS短文件名泄露漏洞修复_bylfsj的博客-CSDN博客_iis短文件名漏洞
HTTP.SYS远程代码执行 (MS15-034)
影响范围
Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2
漏洞危害
利用HTTP.sys的安全漏洞,攻击者只需要发送恶意的http请求数据包,就可能远程读取IIS服务器的内存数据,或使服务器系统蓝屏崩溃。
复现
在Windows7上 安装IIS7.5。
编辑请求头,增加Range: bytes=0-18446744073709551615字段,若返回码状态为416 Requested Range Not Satisfiable,则存在HTTP.SYS远程代码执 行漏洞
利用看下面的文章
HTTP.sys远程执行代码漏洞验证及复现——CVE-2015-1635、MS15-034_7Riven的博客-CSDN博客_cve-2015-1635验证
修复建议
安装修复补丁(KB3042553)
RCE-CVE-2017-7269
CVE-2017-7269-iis远程溢出漏洞复现 - PANDA墨森 - 博客园
修复建议
关闭 WebDAV
Apache
Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是最流行的Web服务 器端软件之一。它快速、可靠并且可通过简单的API扩充,将Perl/Python等解释器编译到服务器中。
解析漏洞
未知扩展名解析漏洞
影响范围
Apache 1.x、2.x
漏洞原理
未知扩展名解析漏洞依赖于apache解析的一个特性:apache读取文件判断文件类型时会读取最后一个后缀,如果该后缀无法识别(不在mime.types文件内),则会继续向左读取文件后缀,直到识别到合法的后缀后再进行解析。
漏洞复现
创建一个11.php.shtmlljjb,内容如下
<?php phpinfo();?>
在浏览器打开,发现执行成功了
修复建议
1、在Apache/conf/extra/下有一个httpd-php.conf文件修改为
<FilesMatch \.php$> SetHandler application/x-httpd-php </FilesMatch>
这一段的意思是,对文件进行正则匹配(FilesMatch),如果文件后缀以.php结尾,才会认为是php文件,再进行解析(SetHandler)。
2、升级到最新版本
3、或将上传的文件重命名为为时间戳+随机数+.jpg的格式并禁用上传文件目录执行脚本权限。
AddHandler导致的解析漏洞
如果运维人员给.php后缀增加了处理器:
AddHandler application/x-httpd-php .php
那么,在有多个后缀的情况下,只要一个文件名中含有.php后缀,即被识别成PHP文件,没必要是最后一个后缀。 利用这个特性,将会造成一个可以绕过上传白名单的解析漏洞。
复现
只要文件名中出现.php,就直接被解析为php。
Apache HTTPD 换行解析漏洞(CVE-2017-15715)
影响范围
2.4.0~2.4.29版本
漏洞原理
此漏洞形成的根本原因,在于$。 正则表达式中$不仅匹配字符串结尾位置,也可以匹配\n 或 \r
在解析PHP时,1.php\x0A将被按照PHP后缀进行解析,导致绕过一些服务器的安全策略。
<FilesMatch \.php$> SetHandler application/x-httpd-php </FilesMatch>
测试代码:
<html> <body> <form action="" method="post" enctype="multipart/form-data"> <input type="file" name="file" /> <input type="text" name="name" /> <input type="submit" value="上传文件" /> </form> </body> </html> <?php if(isset($_FILES['file'])) { $name = basename($_POST['name']); $ext = pathinfo($name,PATHINFO_EXTENSION); if(in_array($ext, ['php', 'php3', 'php4', 'php5', 'phtml', 'pht'])) { exit('bad file'); } echo "ok"; move_uploaded_file($_FILES['file']['tmp_name'], './' . $name); } ?>
相同代码在Linux下进行测试,可以正常写入。
访问,执行成功
限制:获取文件名时不能用$_FILES['file']['name'],因为它会自动把换行去掉。
修复建议
1. 升级到最新版本
2. 或将上传的文件重命名为为时间戳+随机数+.jpg的格式并禁用上传文件目录执行脚本权限。
Nginx
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like 协议下发行。其特点是占有内存少,并发能力强,事 实上nginx的并发能力确实在同类型的网页服务器中表现较好。
Nginx配置文件错误导致的解析漏洞
对于任意文件名,在后面添加/xxx.php(xxx为任意字符)后,即可将文件作为php解析。 例:info.jpg后面加上/xxx.php,会将info.jpg 以php解析。
漏洞成因
该漏洞是Nginx配置所导致,与Nginx版本无关,下面是常见的漏洞配置。
server { location ~ \.php$ { root /work/www/test; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_pass unix:/tmp/php-fpm.sock; } }
当攻击者访问/info.jpg/xxx.php时, Nginx将查看URL,看到它以.php结尾,并将路径传递给PHP fastcgi处理程序。
Nginx传给php的路径为c:/WWW/info.jpg/xxx.php, 在phpinfo中可以查看_SERVER["ORIG_SCRIPT_FILENAME"]得到。
PHP根据URL映射,在服务器上寻找xxx.php文件,但是xxx.php不存在,又由于cgi.fix_pathinfo默认是开启的,因此PHP 会继续检查路径中存在的文件,并将多余的部分当作 PATH_INFO。接着PHP在文件系统中找到.jpg文件,而后以PHP的形式执行.jpg的内容,并将/xxx.php存储在 PATH_INFO 后丢弃,因此我们 在phpinfo中的$_SERVER['PATH_INFO']看的到值为空。
Note:
php的一个选项:cgi.fix_pathinfo,该选项默认开启,值为1,用于修理路径, 例如:当php遇到文件路径"/info.jpg/xxx.php/lxh.sec"时,若"/info.jpg/xxx.php/lxh.sec"不存在,则会去掉最后的"/lxh.sec",然后判断"/info.jpg/xxx.php"是否存 在, 若存在则将/info.jpg/xxx.php当作文件/info.jpg/xxx.php/lxh.sec,若/info.jpg/xxx.php仍不存在,则继续去掉xxx.php,依此类推。
修复建议
1.配置cgi.fix_pathinfo(php.ini中)为0并重启php-cgi程序
2.或如果需要使用到cgi.fix_pathinfo这个特性(例如:Wordpress),那么可以禁止上传目录的执行脚本权限。 或将上传存储的内容与网站分离,即站库分离。
3.或高版本PHP提供了security.limit_extensions这个配置参数,设置security.limit_extensions = .php
Nginx 空字节任意代码执行漏洞
影响版本
Nginx 0.5*, 0.6*,0.7 <= 0.7.65,0.8 <= 0.8.37
漏洞成因
Ngnix在遇到%00空字节时与后端FastCGI处理不一致,导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码
大致是1.jpg%00.php能被Nginx匹配到.php结尾的请求,就发送给fastcgi进行解析,然后%00截断了后面的.php,fastcgi就以php形式解析了1.jpg里面的内容。
漏洞复现
这里提供个打包好的Windows环境 Nginx 0.7.65+php 5.3.2
链接:https://pan.baidu.com/s/1FUVJv9iFCcX9Qp5D5AMxKw 提取码:imdm
解压后,在Nginx目录下执行startup.bat 然后在nginx-0.7.65/html/目录下创建info.jpg,内容为,
<?php phpinfo();?>
访问info.jpg,并抓包,修改为info.jpg..php,在Hex选修卡中将jpg后面的.,更改为00.
Note:该漏洞不受cgi.fix_pathinfo影响,当其为0时,依旧解析。
修复建议
升级Nginx版本
Nginx 文件名逻辑漏洞(CVE-2013-4547)
影响版本
Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
漏洞原理
这一漏洞的原理是非法字符空格和截止符(\0)会导致Nginx解析URI时的有限状态机混乱,危害是允许攻击者通过一个非编码空格绕过后缀名限制。
举个例子,比如,Nginx匹配到.php结尾的请求,就发送给fastcgi进行解析,常见的写法如下:
location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT /var/www/html; }
正常情况下(关闭pathinfo的情况下),只有.php后缀的文件才会被发送给fastcgi解析。而存在
CVE-2013-4547的情况下,我们请求 1.gif[0x20][0x00].php ,这个URI可以匹配上正则 \.php$,可以进入这个Location块;
进入之后,经过%00的截断,Nginx错误地认为请求的文件的1.gif[0x20],就设置其为SCRIPT_FILENAME的值发送给fastcgi。
fastcgi根据SCRIPT_FILENAME的值进行解析,最后造成了解析漏洞。重点是在CVE-2013-4547的情况下,1.gif[0x20][0x00].php可以匹配上正则 \.php$,具体为什么能匹配上,我也不清楚。
绕过黑名单执行php代码
访问http://your-ip:8080/info.jpg
问http://your-ip:8080/uploadfiles/info.jpg, 并抓包,修改为info.jpg...php, 在Hex选修卡中将jpg后面的两个点2e改成20,00 点击Go,如下。
绕过访问限制
CVE-2013-4547还可以用于绕过访问限制,虽然和文件解析漏洞无关,但也记录在这里。比如很多网站限制了允许访问后台的IP:
location /admin/ { allow 127.0.0.1; deny all; }
我们可以请求如下URI:/test[0x20]/../admin/index.php,这个URI不会匹配上location后面的/admin/,也就绕过了其中的IP验证。但最后请求的是/test[0x20]/../admin/index.php文件,也就是/admin/index.php,成功访问到后台。(这个前提是需要有一个目录test,这是Linux系统的特点,如果有一个不存在的目录,则即使跳转到上一层,也会爆文件不存在的错误,Windows下没有这个限制)
复现过程
首先在网站根目录下新建一个目录,命名为protected,在目录protected中新建文件s.html,内容随意。然后在Nginx的配置文件中写上:
location /protected/ { deny all; }
以禁止该目录的访问。接着在网站根目录下新建一个目录,名为“test ”,目录名的最后一个字符是空格,该目录用于触发漏洞。最后来进行验证,直接访问:
http://127.0.0.1/protected/s.html
返回“403 Forbidden”。利用漏洞访问:
http://127.0.0.1/protected/s.html
成功访问到文件s.html。注意上示URL中的空格,不要将空格编码。
修复建议
升级版本
参考文章
14.Nginx 文件名逻辑漏洞(CVE-2013-4547) - bmjoker - 博客园
vulhub/nginx/CVE-2013-4547 at master · vulhub/vulhub · GitHub
Nginx配置错误导致的安全漏洞
一、CRLF注入
查看Nginx文档,可以发现有三个表示uri的变量:
1.$uri 2.$document_uri 3.$request_uri
1和2表示的是解码以后的请求路径,不带参数,3表示的是完整的URI(没有解码)
Nginx会将1,2进行解码,导致传入%0a%0d即可引入换行符,造成CRLF注入漏洞。
错误的配置文件原本的目的是为了让http的请求跳转到https上的,意思就是配置实现了强制跳转的功能,当用户访问nginx服务器时,由于此配置的存在会被强制跳转到以https协议访问之前访问的链接
配置中的 $url 是我们可以控制的,这样我们就可以在 $url 处填入CRLF ,然后对服务器进行访问实现头部注入。
漏洞危害:
劫持合法用户会话,利用管理员身份进行恶意操作,篡改页面内容、进一步渗透网站
利用CRLF injection设置一个 SESSION ,造成一个 "会话固定漏洞"
漏洞原理:
CRLF是“回车 + 换行”(\r\n)的简称。在HTTP协议中,HTTP Header与HTTP Body是用两个CRLF分隔的,浏览器就是根据这两个CRLF(使用payload %0a%0d%0a%0d进行测试)来取出HTTP内容并显示出来。
所以,一旦我们能够控制HTTP消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie
(http://www.xx.com%0a%0d%0a%0dSet-cookie:JSPSESSID%3Dxxx) 或者HTML代码 (http://www.xx.com/?url=%0a%0d%0a%0d<img src=1 οnerrοr=alert("xss")>)
Nginx会将$uri进行解码,导致传入%0a%0d即科引入换行符,造成CRLF注入漏洞
$uri跳转HTTPS,$uri就会产生%0a%0d换行符,换行符就一定存在CRLF注入漏洞
漏洞复现:
[http://127.0.0.1/%0ASet-cookie:JSPSESSID%3D36](http://127.0.0.1/ Set-cookie:JSPSESSID%3D36)
CRLF + XSS 配合
%0D%0A%0D%0A%3Cimg%20src=1%20οnerrοr=alert(/xss/)%3E
二、CRLF深入
攻击者操作:
- 攻击者打开一个网站,然后服务器会回复他一个session id。比如SID=abcdefg。Attack把这个id记下了
- Attack给被攻击者发送一个电子邮件,他假装抽奖或者推销,诱导攻击者点击链接:http://unsafe/?SID=abcdefg,SID后面是Attack自己的session id
- 被攻击者被吸引后,点击了http://unsafe/?SID=abcdefg,像往常一样,输入了自己的账号和口令从而登录到银行网站
- 因为服务器的session id不改变,现在被攻击者点击后,他就拥有了被攻击者的身份,就可以为所欲为了
三、目录遍历
Nginx在配置别名(Alias)的时候,如果忘记加/,将造成一个目录穿越漏洞。假设静态文件存储在/home/目录下,而该目录在url中名字为files,那么就需要用alias设置目录的别名:
location /files { alias /home/; }
此时,访问http://example.com/files/readme.txt,就可以获取/home/readme.txt文件。
但我们注意到,url上/files没有加后缀/,而alias设置的/home/是有后缀/的,这个/就导致我们可以从/home/目录穿越到他的上层目录:
修改请求为http://example.com/files../,可以成功跳转到上一层目录下。如下图所示
进而我们获得了一个任意文件下载漏洞。
如何解决这个漏洞?只需要保证location和alias的值都有后缀/或都没有这个后缀。
四、add_header被覆盖
Nginx的配置文件分为Server、Location等一些配置块,并且存在包含关系,子块会继承父块的一些选项,比如add_header。 如下配置中,整站(父块中)添加了CSP头
正常情况下访问:
当访问 /test2时,XSS被触发。因/test2的location中添加了X-Content-Type-Options头,导致父块中的add_header全部失效
参考文章
红蓝对抗之服务攻防:Nginx中间件渗透总结 - FreeBuf网络安全行业门户
nginx配置错误导致的漏洞_yumengzth的博客-CSDN博客_nginx 配置错误
Nginx漏洞复现与总结 - FreeBuf网络安全行业门户