Web容器安全
简介
- Web中间件
提供系统软件与应用软件之间连接的软件。他处在操作系统和更高一级应用程序之间,他充当的功能是:将应用程序运行环境与操作系统隔离,从而实现应用程序开发者不必为更多系统问题忧虑,而直接关注该应用程序在解决问题上的能力 。
- Web容器
容器是中间件的一种,它给处于其中的应用程序组件提供从一个环境,使应用程序直接与容器中的环境变量进行交互而不必关注其他的系统问题。
- Web服务器
提供 Web 服务器的软件或主机,即 Web 服务器软件或者装有 Web 服务器软件的计算机。
Apache
Apache配置缺陷
AddHandler application/x-httpd-php .php
配置为相应的文件扩展名指定处理程序,表明将扩展名为.php
的文件交给 x-httpd-php 程序处理- Apache识别文件扩展名顺序是从后往前,当遇到无法识别和处理的扩展名,则会接着往前识别,直到遇到第一个可以识别并处理的扩展名
那么在以上两个配置下,可以通过上传xxx.php.png
的文件来绕过文件上传中的白名单机制等等。
复现
-
conf文件配置
-
.htaccess文件配置
- 访问
http://192.168.66.55/phpinfo.php.png
Apache换行解析漏洞
CVE-2017-15715
影响:Apache 2.4.10 - 2.4.29
原理
在解析文件时,遇到.php\x0a
会按照php后缀进行解析,从而绕过一些安全策略限制,比如文件上传中的白名单。
复现
后端使用白名单对后缀进行校验。
在hex中加入0a
尝试绕过:
发现成功上传,访问结果如下:
Nginx
Nginx (engine x) 是一个高性能的HTTP和反向代理Web服务器,同时也提供了IMAP/POP3/SMTP服务。
Nginx配置缺陷
CRLF注入
攻击者向请求行或首部字段注入恶意CRLF和一些响应首部字段或报文主体,且改字段会在响应头中添加,那么在解析时就会误认为在响应头添加了新的首部字段,又称为HTTP响应拆分漏洞。
在Nginx配置中,可以接收URL的变量有:
- $URI:获取解码后的请求路径
- $DOCUMENT_URI:与$URI相同
- $REQUEST_URI:未解码的完整URL
原理:
Nginx中错误的配置:
# 原本是希望http请求跳转到https
location / {
return 302 https://$host$uri;
}
那么在url中引入%0d%0a
和其他内容,则会发生注入。
复现:
目录穿越
Nginx 在配置别名(Alias)的时候,如果忘记加 /
,将造成一个目录穿越漏洞。
错误的配置:
# 原本的目的是为了让用户访问到 /home/ 目录下的文件
location /files {
alias /home/;
}
那么访问http://your-ip:8081/files../
可穿越到根目录:
Nginx 越界读取缓存
CVE-2017-7529
影响版本:Nginx 0.5.6 - 1.13.2
原理
HTTP Range头:
HTTP 的 Range,允许客户端分批次请求资源的部分,如果服务端资源较大,可以通过 Range 来并发下载;如果访问资源时网络中断,可以断点续传。Range 设置在 HTTP 请求头中,它是多个 byte-range-spec(或 suffix-range-byte-spec)的集合。
Range:bytes=0-1024 表示访问第 0 到第 1024 字节
Range:bytes=500-600,601-999,-300 表示分三块访问,分别是 500 到 600 字节,601 到 600 字节,最后的 300 字节
Cache:
Nginx作为反向代理站点的时候,通常会将一些文件进行缓存,特别是静态文件。缓存的部分存储在文件中,每个缓存文件包括文件头+HTTP返回包头+HTTP返回包体
。如果二次请求命中了该缓存文件,则Nginx会直接将该文件中的HTTP返回包体
返回给用户。
如果请求中包含Range头,Nginx将会根据指定的start和end位置,返回指定长度的内容。而如果我构造了两个负的位置,如(-600, -9223372036854774591),将可能读取到负位置的数据。如果这次请求又命中了缓存文件,则可能读取到缓存文件中位于HTTP返回包体
前的文件头、HTTP返回包头
等内容。
复现
成功越界读取文件头、HTTP返回包头
Nginx 文件名逻辑漏洞
CVE-2013-4547
影响版本:Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
危害:绕过文件上传、绕过目录限制
FastCGI
Nginx不支持对外部动态程序的直接调用或者解析,所有的外部程序(包括PHP)必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket(可以是文件socket,也可以是ip socket)。为了调用CGI程序,还需要一个FastCGI的wrapper,这个wrapper绑定在某个固定socket上,如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候,通过FastCGI接口,wrapper接收到请求,然后派生出一个新的线程,这个线程调用解释器或者外部程序处理脚本并读取返回数据;接着,wrapper再将返回的数据通过FastCGI接口,沿着固定的socket传递给Nginx;最后,Nginx将返回的数据发送给客户端,这就是Nginx+FastCGI的整个运作过程。
FastCGI的主要优点是把动态语言和HTTP服务器分离开来,是Nginx专一处理静态请求和向后转发动态请求,而PHP/PHP-FPM服务器专一解析PHP动态请求。
原理
非法字符空格和截止符 \0
会导致 Nginx 解析 URI 时的有限状态机混乱,危害是允许攻击者通过一个非编码空格绕过后缀名限制。
假设服务器上存在文件:file.aaa[空格]
,注意文件名的最后一个字符是空格。则可以通过访问:http://127.0.0.1/file.aaa \0.bbb
,让 Nginx 认为文件 file.aaa
的后缀为 .bbb
。
绕过文件上传-复现
漏洞利用条件:
-
Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
-
php-fpm.conf 中的 security.limit_extensions 为空,也就是说任意后缀名都可以解析为 PHP
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 块;但进入后Nginx 却错误地认为请求的文件是 1.gif[0x20]
,就设置其为 SCRIPT_FILENAME
的值发送给 fastcgi
。
fastcgi 根据 SCRIPT_FILENAME
的值进行解析,最后造成了解析漏洞。
所以,我们只需要上传一个空格结尾的文件,即可使 PHP 解析之。
环境中是黑名单验证,这里借助该漏洞上传phpinfo.png
,让其以PHP进行解析:
绕过目录限制
限制访问后台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 下没有这个限制
Nginx 解析漏洞
该漏洞与Nginx、php版本无关,属于用户配置不当造成的解析漏洞。
原理
-
nginx 把以
.php
结尾的文件交给 fastcgi 处理,为此可以构造http://ip/uploadfiles/test.png/.php
,其中 test.png 是上传的包含 PHP 代码的图片文件。 -
fastcgi 在处理 .php 文件时发现文件并不存在,这时 php.ini 配置文件中
cgi.fix_pathinfo=1
发挥作用,这项配置用于修复路径,如果当前路径不存在则采用上层路径。为此这里交由 fastcgi 处理的文件就变成了/test.png
。 -
最重要的一点是 php-fpm.conf 中的
security.limit_extensions
配置项限制了 fastcgi 解析文件的类型(即指定什么类型的文件当做代码解析),此项设置为空的时候才允许 fastcgi 将 .png 等文件当做代码解析。
复现
访问http://ip/test.png/.php
直接可以php文件解析。
Tomcat
Tomcat 是 Apache 软件基金会的 Jakarta 项目中的一个核心项目,由 Apache、Sun 和其他一些公司及个人共同开发而成。
Tomcat 服务器是一个免费的开放源代码的 Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用。
实际上 Tomcat 是 Apache 服务器的扩展,但运行时它是独立运行的,所以当你运行 Tomcat 时,它实际上作为一个与 Apache 独立的进程单独运行的。
Tomcat 配置缺陷
CVE-2017-12615
影响版本:Apahce Tomcat 7.0.0 - 7.0.79
原理
当 Tomcat 运行在 Windows 主机上,且启用了 HTTP PUT 请求方法,攻击者将有可能可通过精心构造的攻击请求向服务器上传包含任意代码的 JSP 文件。之后,JSP 文件中的代码将能被服务器执行。
Tomcat 配置了可写(readonly=false),导致可以往服务器写文件:
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Tomcat对文件后缀有限制,无法直接写JSP文件,但是可以利用Windows和Linux的一些特性去写,例如:
- Windows:
PUT /test.jsp%20
、PUT /test.jsp::$DATA
、PUT /test.jsp/
- Linux:
PUT /test.jsp/
写入shell后直接连接即可。
Tomcat 弱口令 + war 包部署
Tomcat 支持在后台部署 war 文件,可以直接将 webshell 部署到 web 目录下。但是想要访问后台,需要对应用户有相应权限。
Tomcat 权限
- manager(后台管理)
- manager-gui 拥有 html 页面权限
- manager-status 拥有查看 status 的权限
- manager-script 拥有 text 接口的权限,和 status 权限
- manager-jmx 拥有 jmx 权限,和 status 权限
- host-manager(虚拟主机管理)
- admin-gui 拥有 html 页面权限
- admin-script 拥有 text 接口权限
可以在conf/tomcat-users.xml
中配置用户权限:
<?xml version="1.0" encoding="UTF-8"?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<role rolename="admin-gui"/>
<role rolename="admin-script"/>
<user username="tomcat" password="tomcat" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" />
</tomcat-users>
如若用户采用上述配置,即tomcat
用户拥有所有权限,且密码是弱口令。正常安装的情况下,tomcat8中默认没有任何用户,且manager页面只允许本地IP访问。只有管理员手工修改了这些属性的情况下,才可以进行攻击。
复现
以弱密码进入:
进入后台:
打包war:
jar cvf shell.war ./shell.jsp
上传连接测试:
Jboss
jBoss 是 J2EE 环境中一个流行的 Web 容器,但是 jBoss 在默认安装时提供的一些功能却不 太安全,如果配置不得当,则可能直接造成远程命令执行。
默认端口在8080,常见的Jboss弱口令如下:
admin/admin
jboss/admin
admin/jboss
admin/123456
admin/password
控制台getshell
控制台地址
- Joss4.x及其之前:console 管理路径为
/jmx-console/
和/web-console/
- jboss5.x / 6.x :Jboss5.x开始弃用了 web-console,console 管理路径为
/jmx-console/
和/admin-console/
console的配置文件地址不同网站一般会不同。
利用
Jboss4.x的jmx-console管理后台存在未授权,可以直接访问上传war包getshell
5.x开始只有admin-console才可部署war包,且进入后台需要口令认证
待更
反序列化-CVE-2017-12149
待更
反序列化-CVE-2017-7504
待更
JBoss JMXInvokerServlet 反序列化漏洞
待更