weblogic漏洞,apache common collection 3.2.2修复方案
weblogic漏洞,apache common collection 3.2.2修复方案详细介绍
本文目录一览： weblogic漏洞系列-后台上传文件getshell
往后每周会坚持做漏洞复现，环境采取P神的vulhub。
测试环境：
WebLogic Server 版本: 10.3.6.0 （11g）
jdk版本：1.6
测试步骤：
1、通过弱口令进后台，本测试环境弱口令为：
weblogic 常用弱口令可以参考： https://cirt.net/passwords?criteria=weblogic
2、weblogic后台访问地址为： http://ip:7001/console/login/LoginForm.jsp (默认端口是7001，要根据实际开放端口进行访问)
3、输入账号名、密码登录之后进入后台管理界面-【部署】-【安装】
4、在安装页面点击上载文件。
5、然后选择制作好的 war包，点击下一步。
6、war包制作方法：
7、一直下一步，这里注意点击的是上边的下一步，不要点错了。
8、然后点击完成-保存。
9、访问大马文件
weblogic的反序列化漏洞必须开7001端口吗
out.println(path);
%>
使用浏览器访问上述jsp文件，可以看到对应的类所在的jar包的完整路径。
通过上述方法查找“org.apache.commons.collections.map.TransformedMap”所在的jar包，示例如下。
不同版本的weblogic对Apache Commons Collections组件的使用
“org.apache.commons.collections.map.TransformedMap”所在的weblogic的jar包信息如下。
weblogic版本
TransformedMap类所在jar包路径
9.2
无
10.2.1(weblogic 10g)、10.3.4(weblogic 11g)
weblogic安装目录的modules/com.bea.core.apache.commons.collections_3.2.0.jar
12.1.3(weblogic 12c)
weblogic安装目录的wlserver/modules/features/weblogic.server.merged.jar
由于weblogic 9.2未包含TransformedMap类，因此无法触发反序列化漏洞，weblogic 10g、weblogic 11g、weblogic 12c均包含TransformedMap类，因此会触发反序列化漏洞。
0x04 漏洞修复
漏洞修复思路
weblogic的默认服务端口为7001，该端口提供了对HTTP(S)、SNMP、T3等协议的服务。由于weblogic的不同协议均使用一个端口，因此无法通过防火墙限制端口访问的方式防护JAVA反序列化漏洞。
在绝大多数应用的使用场景中，用户只需要在公网能够使用HTTP(S)协议访问web应用服务器即可。对于weblogic服务器，在绝大多数情况下，只需要能够在公网访问weblogic提供的HTTP(S)协议的服务即可，并不需要访问T3协议。
少数情况下，运维人员需要使用weblogic的T3协议：
在weblogic服务器本机执行weblogic的停止脚本；
通过WLST对weblogic进行脚本化配置；
编写使用T3协议通信的程序对weblogic进行状态监控及其他管理功能。
T3协议与HTTP协议均基于TCP协议，T3协议以"t3"开头，HTTP协议以“GET”、“POST”等开头，两者有明显的区别。
因此可以限定只允许特定服务器访问weblogic服务器的T3协议，能够修复weblogic的JAVA反序列化漏洞。即使今后发现了weblogic的其他类存在JAVA反序列化漏洞，也能够防护。
若将weblogic修复为发送T3协议时要求发送weblogic的用户名与密码，也能够修复weblogic的反序列化问题，但会带来密码如何在weblogic客户端存储的问题。
无效的漏洞修复方法
首先尝试将应用部署到非管理Server中，判断其服务端口是否也提供T3协议的服务。
AdminServer是weblogic默认的管理Server，添加一个名为“Server-test”的非管理Server后，weblogic的服务器信息如下。管理Server与非管理Server使用不同的监听端口，可将j2ee应用部署在非管理Server中，这样可以使weblogic控制台与应用使用不同的端口提供服务。
经测试，新增的非管理Server的监听端口也提供了T3协议的服务，也存在JAVA反序列化漏洞。因此这种修复方式对于JAVA反序列化漏洞无效，但可将weblogic控制台端口与应用端口分离，可以使用防火墙禁止通过公网访问weblogic的控制台。
websphere的服务端口
我们来看另一款使用广泛的企业级JAVA中间件：websphere的服务端口情况。从下图可以看到，websphere的应用默认HTTP服务端口为9080，应用默认HTTPS服务端口为9443，控制台默认HTTP服务端口为9060，控制台默认HTTPS服务端口为9043，接收JAVA序列化数据的端口为8880。因此只要通过防火墙使公网无法访问websphere服务器的8880端口，就可以防止通过公网利用websphere的JAVA反序列化漏洞。
网络设备对数据包的影响
对安全有一定要求的公司，在部署需要向公网用户提供服务的weblogic服务器时，可能选择下图的部署架构(内网中不同网络区域间的防火墙已省略)。
上述网络设备对数据包的影响如下。
IPS
IPS可以更新防护规则，可能有厂家的IPS已经设置了对JAVA反序列化漏洞的防护规则，会阻断恶意的JAVA序列化数据包。
防火墙
这里的防火墙指传统防火墙，不是指下一代防火墙，仅关心IP与端口，不关心数据包内容，无法阻断恶意的JAVA序列化数据包。
WAF
与IPS一样，能否阻断恶意的JAVA序列化数据包决定于防护规则。
web代理
仅对HTTP协议进行代理转发，不会对T3协议进行代理转发。
负载均衡
可以指定需要进行负载均衡的协议类型，安全起见应选择HTTP协议而不是TCP协议，只对HTTP协议进行转发，不对T3协议进行转发。
根据以上分析可以看出，web代理和负载均衡能够稳定保证只转发HTTP协议的数据，不会转发T3协议的数据，因此能够防护JAVA反序列化漏洞。
如果在公网访问weblogic服务器的路径中原本就部署了web代理或负载均衡，就能够防护从公网发起的JAVA反序列化漏洞攻击。这也是为什么较少发现大型公司的weblogic反序列化漏洞的原因，其网络架构决定了weblogic的JAVA反序列化漏洞无法在公网利用。
可行的漏洞修复方法
部署负载均衡设备
在weblogic服务器外层部署负载均衡设备，可以修复JAVA反序列化漏洞。
优点
缺点
对系统影响小，不需测试对现有系统功能的影响
需要购买设备；无法防护从内网发起的JAVA反序列化漏洞攻击
部署单独的web代理
在weblogic服务器外层部署单独的web代理，可以修复JAVA反序列化漏洞。
优点
缺点
同上
同上
在weblogic服务器部署web代理
apache common collection 3.2.2修复方案
修复weblogic反序列化漏洞，修复方法为：替换原来的common-collections组件，建议：原来是3.2.d就替换为3.2.2，原来是4.x,就替换为4.4.1，如果出现不兼容，则替换一个版本试试。
1.先停止weblogic
2.替换oracle\modules目录里com.bean.core.apache.commons.collections_x.x.x.jar
3.启动weblogic
weblogic 10.3.5 java 反序列化漏洞 影响吗
收到影响的，建议修补。
以下版本的weblogic收到此漏洞影响:
- 9.2.3.0
- 9.2.4.0
- 10.0.0.0
- 10.0.1.0
- 10.0.2.0
- 10.2.6.0
- 10.3.0.0
- 10.3.1.0
- 10.3.2.0
- 10.3.4.0
- 10.3.5.0
- 12.1.1.0
CVE-2018-6485漏洞怎么修复
WLS12.1.3、WLS12.2.1.2、WLS12.2.1.3版本的WLS都使用Opatch安装补丁，所以仅以WLS12.2.1.3为例介绍补丁安装，并展示攻击结果，不再截图。
1、使用安装中间件服务器的用户登陆中间件服务器所在机器。
2、停止该机器上所有的WLS中间件的Java进程，（如果在Windows机器上则需要注意停止WLS注册的服务，否则会因为权限问题导致补丁升级时报Java.IO的错误）。
3、检查如下环境变量，确保Opatch正确执行：
JDK环境变量，确保你使用的JDK就是你之前安装的JDK；
ORACLE_HOME，确保你补丁最终安装的位置，也就是你WebLogicServer所在位置。
4、解压补丁包：
p27342434_122130_Generic.zip
5、进入解压后的目录，通过命令
Windows下：%ORACLE_HOME%/OPatch/opatch apply
类Unix下：$ORACLE_HOME/OPatch/opatch apply
6、尝试攻击，还是成功了
可以安装一个电脑管家在电脑上
然后打开工具箱，在里面找到修复漏洞功能
使用这个功能，去修复电脑所有检测出的高危漏洞即可
java反序列漏洞，涉及到哪些中间件
目前oracle还没有在公开途径发布weblogic的JAVA反序列化漏洞的官方补丁，目前看到的修复方法无非两条：
使用SerialKiller替换进行序列化操作的ObjectInputStream类;
在不影响业务的情况下，临时删除掉项目里的 "org/apache/commons/collections/functors/InvokerTransformer.class"文件。
ObjectInputStream类为JRE的原生类，InvokerTransformer.class为weblogic基础包中的类，对上述两个类进行修改或删除，实在无法保证对业务没有影响。如果使用上述的修复方式，需要大量的测试工作。且仅仅删除InvokerTransformer.class文件，无法保证以后不会发现其他的类存在反序列化漏洞。
Linux系统下通过WebLogic发布程序，如何防范内部IP地址漏洞的泄露。
#include "stdio.h"
main()
{
int i;
int fact();
for(i=0;i<5;i++)
printf("\40:%d!=%d\n",i,fact(i));
}
int fact(j)
int j;
{
int sum;
if(j==0)
sum=1;
else
sum=j*fact(j-1);
return sum;
}
weblogichost头攻击配置
1. HTTP Host头攻击
从HTTP / 1.1开始，HTTP Host标头是必需的请求标头。它指定客户端要访问的域名。例如，当用户访问https://example.net/web-security时，其浏览器将组成一个包含Host标头的请求，如下所示：
GET /web-security HTTP/1.1
Host: example.net
HTTP Host头的目的是帮助识别客户端要与之通信的后端组件。如果请求不包含Host头或者格式不正确，则在将传入请求的应用程序时可能会导致问题。
从历史上看，这种漏洞并不存在太大问题，因为每个IP地址只会被用于单个域的内容。如今，很大程度上是由于同一个IP上存在多个Web应用程序（不同端口，不同域名解析等），通常可以在同一IP地址访问多个网站和应用程序。这种方法的普及也部分是由于IPv4地址耗尽所致。
当可以通过同一IP地址访问多个应用程序时，最常见的原因是以下情况之一：
虚拟主机
单个Web服务器托管多个网站或应用程序。这可能是具有单个所有者的多个网站，但是也可能是不同所有者的网站托管在同一个共享平台上。它们都与服务器共享一个公共IP地址。
通过代理路由流量
网站托管在不同的后端服务器上，但是客户端和服务器之间的所有流量都通过代理系统进行路由。这可能是一个简单的负载平衡设备或某种反向代理服务器。在客户通过内容分发网络（CDN）访问网站的情况下，这种设置尤其普遍。
在上面两种种情况下，即使网站托管在单独的后端服务器上，它们的所有域名也都解析为中间组件的单个IP地址。这带来了与虚拟主机相同的问题，因为反向代理或负载平衡需要知道每个请求到的哪个后端上。
HTTP Host头的作用就在于，指定请求应该发送到那个应用程序的后端服务器上。打个比方，一封信需要送到居住在公寓楼中的某人手中，整个公寓有许多房间，每个房间都可以接受信件，通过指定房间号和收件人（也就是HTTP Host头）来将信封送到指定的人手中。
3. 什么是HTTP Host头攻击
一些网站以不安全的方式处理Host头的值。如果服务器直接信任Host头，未校验它的合法性，则攻击者可能能够使用此可控变量来注入Host，以操纵服务器端的行为。
现成的Web应用程序通常不知道将它们部署在哪个域上，除非在安装过程中在配置文件中手动指定了该域。例如，当他们需要知道当前域以生成电子邮件中包含的绝对URL时，他们可能依赖于Host头中的值：
Host头值还可以用于不同网站系统之间的各种交互。
由于Host头实际上是用户可控制的，因此这种做法可能导致许多问题。如果未校验或者直接使用Host头，则Host头可以与一系列其他漏洞“组合拳”攻击，比如：
缓存投毒
特殊业务功能的逻辑漏洞
基于路由的SSRF
经典服务端漏洞，如SQL注入（当Host被用于SQL语句时）等
4. 如何发掘HTTP Host头攻击
首先要判断服务端是否检测Host头？检测完了是否还使用Host头的值？
通过修改Host的值，如果服务端返回错误信息：
30b04453d11b44a56c903cc387f17296.png
则说明服务端检测了Host的内容。至于有没有使用Host头的值，有以下几种方法去发掘：
修改Host值
简单的来说，可以修改HTTP头中的Host值，如果观察到响应包中含有修改后的值，说明存在漏洞。
但有时候篡改Host头的值会导致无法访问Web应用程序，从而导致“无效主机头”的错误信息，特别是通过CDN访问目标时会发生这种情况。
添加重复的Host头
添加重复的Host头，通常两个Host头之中有一个是有效的，可以理解为一个是确保请求正确地发送到目标服务器上；另一个则是传递payload到后端服务器中。
GET /example HTTP/1.1
Host: vulnerable-website.com
Host: attackd-stuff
使用绝对路径的URL
尽管许多请求通常在请求域上使用相对路径，但是也同时配置了绝对URL的请求。
GET https://vulnerable-website.com/ HTTP/1.1
Host: attack-stuff
有时候也可以尝试不同的协议，如HTTP或HTTPS。
添加缩进或换行
当一些站点block带有多个Host头的请求时，可以通过添加缩进字符的HTTP头来绕过：
GET /example HTTP/1.1
Host: attack-stuff
Host: vulnerable-website.com
注入覆盖Host头的字段
与Host头功能相近的字段，如X-Forwarded-Host、X-Forwarded-For等，这些有时候是默认开启的。
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attack-stuff
诸如此类，还有其他的字段：
X-Host
X-Forwarded-Server
X-HTTP-Host-Override
Forwarded
忽略端口仅校验域名
当修改、添加重复Host头被拦截的时候，可以尝试了解Web应用程序是怎样解析Host头的。
比如，一些解析算法会忽略Host头中的端口值，仅仅校验域名。这时候可以将Host修改为如下形式：
GET /example HTTP/1.1
Host: vulnerable-website.com:attack-stuff
保持域名不变，修改端口值为非端口号的其他值（非数字）， 将Host头攻击的payload放在端口值处，同样能进行Host头攻击。
5. HTTP Host头攻击漏洞示例
5.1 密码重置中毒
根据HTTP Host头攻击的攻击特点，它被广泛应用于密码重置中毒：攻击者可以操纵网站在重置密码情况下生成的密码重置链接，使其发送攻击者指定的域下，利用此来窃取重置任意用户密码的令牌。
1c2aa7d6f7e77ca7c2bd09feee527087.png
一个重设密码（忘记密码）功能的大致流程如下：
用户输入其用户名或电子邮件地址，然后提交密码重置请求。
该网站检查该用户是否存在，然后生成一个临时的、唯一的、复杂的令牌，该令牌与后端的用户帐户相关联。
该网站向用户发送一封电子邮件，其中包含用于重置其密码的链接。重置令牌的参数包含在相应的URL中：
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
4. 当用户访问此URL时，网站将检查提供的令牌是否有效，并使用它来确定要重置哪个帐户。如果一切都符合，则可以进入用户重置密码步骤。最后，令牌被销毁。
以上步骤的安全性依赖于：只有目标用户才能访问其电子邮件，从而可以访问其唯一的令牌。
密码重置中毒是窃取此令牌以更改另一个用户密码的一种漏洞。
如果网站重置密码的流程完全依赖用户的可控输入（如HTTP Host头），这可能导致密码重置中毒：
1. 攻击者获取受害者的用户名或者电子邮件，作为提交重置密码的请求，攻击者会拦截请求并修改HTTP Host头为其指定的域，如evil-user.net
2. 受害者会收到一封重置密码的邮件，但由于攻击者修改了Host头，而web程序生成重置链接又完全依赖于Host头，导致生成以下URL：
https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
3. 如果受害者点击了该链接，重置密码的令牌就会发送到攻击者的服务器 evil-user.net 上
4. 当攻击者获取到虫子密码的令牌之后，就会进行相应的构造访问真实重置密码的URL进行密码重置。
5.1.1 密码重置中毒—基础
详细了解了上面的密码重置中毒的流程和原理之后，这里通过HTTP Host头攻击导致的基础的密码重置中毒来演示。
首先输入用户名或者用户的电子邮箱来重置指定用户的密码：
534a1d062ccc3813b6596fdec0bb475b.png
提交之后，会发送一封重置密码的电子邮件到wiener用户的邮箱中（数据包如右图）：
7c47a2e653a4fcbbaeae1687f914d093.png
注意重置密码的链接，可能是受Host头的值的影响？
我们来验证一下是否存在HTTP Host头攻击，修改Host头的值为 baidu.com：
8901c053cc8c3e6f0383f5f61b14d549.png
发现请求是可以被后端服务器接收的，所以是存在HTTP Host头攻击的。
这里就输入受害用户carlos进行重置密码，然后抓包将Host头的值改为我们自己的服务器：
ec1f439fbc6013f1b4f71011a2885947.png
然后在我们自己的服务器上就可以通过访问日志看到被窃取的重置密码Token：
c3b81283ee2a440dcf205a1ab344ab32.png
然后根据已知链接规律，构造重置密码的链接：
https://ac651f551e5317b8800207bd008f000f.web-security-academy.net/forgot-password?temp-forgot-password-token=00YIexUDyNLEJkaBXDoCILWtZAGaxgi7
1a4ba4a58416c68b3f513ba1239f76d9.png
随即进入输入新密码的界面，密码重置中毒成功。
5.1.2 密码重置中毒—注入覆盖Host头的字段
有时候直接修改Host头、添加重复Host头的值以及混淆Host头都不行：
3ca0c53bfef0d9b47a9f788eb484f40f.png
可以尝试使用与Host头功能相同的HTTP字段，如X-Forwarded-Host、X-Forwarded-For等，可以进行Fuzz：
cbb645bac4d5b28e8b91c39b174a0767.png
实际上他能够被 X-Forwarded-Host 字段影响，导致Host头攻击，当同时添加多个字段使请求被拦截时，可以尝试类似排除法、二分法来排查哪个字段有效。
对受害用户carlos进行密码重置投毒：
53fd95a8a051dd84951094b4e3e79502.png
然后构造链接即可：
https://acf11f4e1f164378800b165b00bb007d.web-security-academy.net/forgot-password?temp-forgot-password-token=o8gD3Le1K0YQcb2AaASgiI8F2eVI5m3h
efb5ab58ec4a711faa6f4dac736e069a.png
5.1.3 重置密码中毒—Dangling Markup技术
首先简单介绍一下 Dangling Markup技术：
Dangling markup技术
Dangling markup技术, 是一种无需脚本即可窃取页面内容的技术，它使用图像等资源(结合CSP运行的策略)将数据发送到攻击者控制的远程位置。当反射型XSS不工作或被内容安全策略（CSP）阻止时，它非常有用。其思想是插入一些未完成状态的部分HTML，例如图像标记的src属性，页面上的其余标记关闭该属性，但同时将两者之间的数据(包含窃取页面的内容)发送到远程服务器。
例如，我们在反射型XSS注入点上注入这样一个img标签：
JavaRMI服务远程方法调用漏洞如何修复lin
可以安装一个电脑管家在电脑上
然后打开工具箱，在里面找到修复漏洞功能
使用这个功能，去修复电脑所有检测出的高危漏洞即可
Linux的Apache或WebLogic应用被检测出这个漏洞，NSFOCUS(绿盟)给出的解决办法是：
临时解决方法：【限制访问或删除类文件】
如果您不能立刻安装补丁或者升级，建议您采取以下措施以降低威胁：
* 使用防火墙规则及文件系统访问限制
* 使用 SerialKiller 替换进行序列化操作的 ObjectInputStream 类
* 删除掉项目里的“commons-collections-3.2.jar///org/apache/commons/collections/functors/InvokerTransformer.class” 文件，删除后项目可能会在某些功能下报错。
安装厂商补丁：【下载3.2.2以上版本commons-collections补丁】
目前厂商已经发布了升级补丁ACC 3.2.2 以修复这个安全问题，请到厂商的主页下载：
Download Commons Collections
http://svn.apache.org/viewvc?view=revision&revision=1713307
https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
如何控制开放HTTPS服务的weblogic服务器
使用SSL网关提供HTTPS服务
当使用SSL网关提供HTTPS服务时，网络架构如下图所示（无关的设备已省略，下同）。
SSL网关只会向后转发HTTP协议的数据，不会将T3协议数据转发至weblogic服务器，因此在该场景中，无法通过公网利用weblogic的JAVA反序列化漏洞。
使用负载均衡提供HTTPS服务
当使用负载均衡提供HTTPS服务时，网络架构如下图所示。
安全起见，负载均衡应选择转发HTTP协议而不是TCP协议，因此在该场景中，也无法通过公网利用weblogic的JAVA反序列化漏洞。
使用web代理提供HTTPS服务
当使用web代理（如apache、nginx等）提供HTTPS服务时，网络架构如下图所示。
web代理只会向后转发HTTP协议的数据，因此在该场景中，也无法通过公网利用weblogic的JAVA反序列化漏洞。
使用weblogic提供HTTPS服务
当使用weblogic提供HTTPS服务时，网络架构如下图所示。
weblogic能够接收到利用SSL加密后的T3协议数据，因此在该场景中，通过公网能够利用weblogic的JAVA反序列化漏洞。
根据上述分析，仅当HTTPS服务由weblogic提供时，才能够利用其JAVA反序列化漏洞。
0x02 weblogic开放SSL服务时的T3协议格式分析
利用weblogic的JAVA反序列化漏洞时，必须向weblogic发送T3协议头。为了能够利用提供SSL服务的weblogic的JAVA反序列化漏洞，需要首先分析当weblogic提供SSL服务时的T3协议格式。
SSL数据包为加密的形式，无法直接进行分析，需要进行解密。当已知SSL私钥时，可以利用Wireshark对SSL通信数据进行解密。
weblogic可以使用演示SSL证书提供SSL服务，也可以使用指定SSL证书提供SSL服务。
可以使用两种方法进行分析，一是使用weblogic提供的演示SSL证书进行分析，二是使用自己生成的SSL证书进行分析。
使用weblogic演示证书进行分析(方法一)
使用weblogic演示证书开放SSL服务
登录weblogic控制台，将AdminServer的“启用SSL监听端口”钩选，并填入SSL监听端口号。
查看AdminServer的密钥库配置，确认为“演示标识和演示信任”（Demo Identity and Demo Trust），可以看到演示密钥库的文件名为“DemoIdentity.jks”，演示信任密钥库文件名为“DemoTrust.jks”。
查看AdminServer的SSL配置，可以看到演示密钥库的私钥别名为“DemoIdentity”。
使用HTTPS方式登录weblogic控制台，确认可以正常登录。