主页 / server / 问题 / 1086065
Accepted
Uri
Asked: 2021-12-12 20:52:16 +0800 CST

如何检查我的服务器上是否安装了 Log4j？

  • 772

我已经阅读了与 Log4j 相关的安全漏洞。

如何检查我的服务器上是否安装了 Log4j？我的特定服务器使用Ubuntu 18.04.6 LTS.

我已经安装了许多第三方软件包，其中一些可能包含它。

是否有命令在我的服务器上运行以检查是否安装了 Log4j？

ubuntu security log4j

11 个回答

  1. Best Answer

    试试这个脚本以获得提示：

    echo "checking for log4j vulnerability..."
OUTPUT="$(locate log4j|grep -v log4js)"
if [ "$OUTPUT" ]; then
  echo "[WARNING] maybe vulnerable, those files contain the name:"
  echo "$OUTPUT"
fi
OUTPUT="$(dpkg -l|grep log4j|grep -v log4js)"
if [ "$OUTPUT" ]; then
  echo "[WARNING] maybe vulnerable, dpkg installed packages:"
  echo "$OUTPUT"
fi
if [ "$(command -v java)" ]; then
  echo "java is installed, so note that Java applications often bundle their libraries inside jar/war/ear files, so there still could be log4j in such applications."
fi
echo "If you see no output above this line, you are safe. Otherwise check the listed files and packages."

    确保您的定位数据库是最新的updatedb。

    或者更好地检查并运行来自 GitHub 的增强脚本，该脚本还可以在打包的 Java 文件中进行搜索。在一行中运行

    wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash

    我不确定是否可以在没有安装 java 的情况下在服务器上运行已编译的 Java 程序？

    或者甚至是在打包档案中找不到源文件的编译版本？

    GitHub 上也有很多开发，在这里你可以找到攻击和对策。

    这对我来说需要很多时间。我正在寻找可以转让 GitHub 上存储库所有权的人

    • 48

  2. 没有任何命令可以肯定地告诉你这一点。有些应用程序将它们直接使用的库作为 jar 文件提供，有些应用程序会将它们包含在存档中。

    即便如此，您也不知道发布了哪个版本以及如何使用它。确保缓解 CVE 的唯一方法是阅读应用程序的安全公告和发行说明并遵循他们的建议。

    • 26

  3. 试试这个命令：

    • dpkg -l | grep liblog4j

    • dpkg -l | grep log4

    • find / -name log4j-core-*.jar

    • locate log4j | grep -v log4js

    • 10

  4. 我编写了这个 Python 脚本来在您的系统上查找易受攻击的 Log4j2 版本：https ://github.com/fox-it/log4j-finder

    它通过递归扫描磁盘和内部 Java Archive 文件并查找已知的坏文件来工作。

    • 5

  5. log4jsscanner

    由 Google 在 Apache-2.0 许可下发布，log4jscanner 是一个 log4j 漏洞文件系统扫描器和用于分析 JAR 文件的 Go 包。

    • 4

  6. 为引用外部材料道歉，我希望这在目前的情况下是可以容忍的。

    Lunasec.io 发布的有关易受攻击的二进制 Java .class 文件的哈希的信息：

    https://github.com/lunasec-io/lunasec/blob/master/tools/log4shell/constants/vulnerablehashes.go

    另请参阅他们的博客： https ://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/

    如果您在文件中订购了可疑类的哈希（每行一个），hashes并且有一个 jar 文件subject.jar并有unzip,find和sha256sum命令，那么您可以与已知的哈希进行比较：

    JARFILE=subject.jar; DIROUT=$(mktemp -d); unzip -qq -DD "$JARFILE" '*.class' -d "$DIROUT" && find "$DIROUT" -type f -not -name "*"$'\n'"*" -name '*.class' -exec sha256sum "{}" \; | cut -d" " -f1 | sort | uniq > "$JARFILE"-hashes; rm -rf -- "$DIROUT"

comm -12 hashes subject.jar-hashes

    如果comm有输出，那么就有一个匹配的哈希。

    • 3

  7. 尝试syft。它创建了一个软件材料清单 (SBOM)，然后您可以搜索旧的 log4j 版本（甚至可以使用 docker 图像）。

    类似于syft dir:/opt/foo-application | grep log4j传统部署中的搜索。syft dir:/ | grep log4j应该适用于您的整个服务器。

    传递您的 docker 图像也可以：

    # syft -q jacobalberty/unifi:5.13.29 | grep log4j
log4j-api                                 2.12.1                               java-archive
log4j-core                                2.12.1                               java-archive
log4j-slf4j-impl                          2.12.1                               java-archive
tomcat-embed-logging-log4j                8.5.2                                java-archive

    创建一个将所有 docker 映像传递给 syft 的脚本应该不会太难，但您可能会在我的这些脚本中找到一些灵感：https ://github.com/debuglevel/syft-grype-utils

    • 3

  8. John Hammond 与其他一些人一起发布了托管 LDAP 重定向服务，因此您可以跳过所有的恶作剧。https://log4shell.huntress.com/

    方向很简单 - 它为您生成一个客户端 ID（它在 URL 中，以及注入字符串的一部分），您可以将其发布到任何表单/请求/或 Web 请求的派生项。

    通常，如果您正在运行“因为它是本地访问而无法使用”的任何东西，那么无论如何您都可以，因为无法通过基于 Java 的应用程序进行转发。

    值得注意的是——我认为大多数关注点应该放在 L2/L3 网络管理硬件上；特别是如果您正在与 ISP 打交道，或者您的内容是通过托管服务提供的。

    • 2

  9. 检查已安装的软件包是不够的，因为log4j可以由其他一些应用程序手动安装。

    对于 Linux 服务器，我使用以下内容：find / -iname "*log4j*.jar"

    对于 Windows 服务器，可以使用类似的东西：（dir C:\*log4j*.jar /s更改C:为D:等其他磁盘）。

    文件名通常会显示库版本，但要仔细检查，您可以打开清单文件并阅读版本/实现字段。

    请注意，以上内容不足以捕获嵌入log4j（例如：在其他 jar 文件中）。对于这些，必须 grep 相关的字符串，但这会耗费大量时间和资源，因此我建议将文件搜索作为第一步（但不完整）。

    • 1

  10. 这里所有解决 log4j 漏洞的尝试都失败了。您不能依赖该locate命令，因为它只查看一组配置的路径（/etc/updatedb.conf在 Debian 上）。

    软件可以自行安装在未配置的位置，updatedb.conf并且会被更新定位数据库的 cron 作业完全遗漏。

    此外，还发现软件供应商（如Elastic）已将易受攻击的 JndiLookup.class（例如：）重新打包到elasticsearch-sql-cli-7.16.1.jar以前不知道的地方，这使得围绕已知文件哈希、名称或路径构建的解决方案不完整。

    @shodanshok 在这里是正确的，但不是显式搜索 log4j，而是需要查看系统上的每个“.jar”。

    这个比较完整，需要zip包。以及 shodanshok 答案的延伸。这只会显示JndiLookup.class找到代码的位置。可以添加另一行来消除这些漏洞，但我宁愿让管理员自行决定。上面的 Elastic 链接显示了如何：

    for jar in $(find / -name '*.jar'); do
   unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
done

    例子：

    # for jar in $(find / -name '*.jar'); do
>    unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
> done
Found vulnerability in /usr/lib/unifi/lib/log4j-core-2.13.3.jar
Found vulnerability in /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.2-SNAPSHOT/minecraft-server-1.15.2-SNAPSHOT.jar
Found vulnerability in /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.1-SNAPSHOT/minecraft-server-1.15.1-SNAPSHOT.jar
...

    在安装了网络文件系统的系统上运行此程序时要小心，因为性能可能会受到影响。在这些情况下，您需要在文件服务器本身上运行命令。

    • 1

相关问题