2021年12月9日，一次媲美永恒之蓝的危机爆发了java代码，Log4j2曝出了应用难度系数非常低的JNDI注入漏洞，其漏洞检测难度系数之低让人赞叹不已，大部分可以并列S2。
而和S2不一样的是，因为Log4j2做为日志记录基本第三方平台库，被好多java代码架构及APP应用，要是使用Log4j2开展日志输出且日志信息能被网络攻击者局部可以控制，即也许会遭受漏洞攻击危害。因而，该漏洞也与此同时危害全世界好多常用APP及组件，比如：ApacheStruts2,ApacheSolr,ApacheDruid,ApacheFlink,ApacheFlume,ApacheDubbo,ApacheKafka,Spring-boot-starter-log4j2,ElasticSearch,drds,Logstash.
下边咱们来一块儿看一下漏洞机理
漏洞分析,构建环境.这儿采用log4j-core2.14.1版本号，容易构造1个环境spring-boot须要把原先的log关闭，添加log4j(这是一个常见使用)执行就可以开启.
漏洞形成原因,这儿咱们常规跟error下来,最先能够看见这儿通过了isEnabled的认证，这也是好多朋友info变量值没法开启的缘故，假如不符合配置，则log并不会被记录。这儿一路上跟着MessagePatternConverter的parse变量值,能够看见此次漏洞的通道，假如源代码中存有${则会进到额外解决。再次跟下来到StrSubstitutor的substitute函数.这儿便是漏洞产生的具体局部了，大部分是递归法解决里边的语法信息，也是有某些内嵌的语法prefixMatcher是${suffixMatcher是}仅有搜索到这两局部才会进到语法解决.引号正中间的信息被传入varname并开展2个内嵌的语法，当中假如匹配到这两个语法，则varname会被更改为相匹配语法的相匹配局部（关键绕开）通过解决的变量值，会在531行进到resolveVariable函数而resolveVariable这儿则立即依据不一样的协议进到相对应的lookup，当中jndi.lookup便会造成漏洞.
假如执行lookup有返回，则会进到423行的递归法解决下层,而lookup适用的协议也是有很多种多样包含{stamp,java,marker,ctX,lower,upper,jndi,set,jvmrunargs,system,ENVI,log4j}假如能成功的从这一流程走下来，就不会太难发觉全部流程的逻辑问题实际上有很多。
还没有评论，来说两句吧...