Artifactory 身份验证绕过遭在野利用：先隔离入口，再排查管理员持久化

2026-09-29 30 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

多项 Artifactory 漏洞正在被主动利用。对于直接暴露在互联网的自托管实例，攻击者可能绕过身份验证，并在不到五分钟内建立持久化管理员访问。风险并不止于“多出一个管理员账号”：后续还可能发生凭据与密钥窃取、任意代码执行、持久化驻留以及清除痕迹。

这类事件不能只按常规补丁工单处理。更稳妥的顺序是：立即收缩网络暴露，确认并升级受影响版本，轮换可能泄露的秘密，然后从可信日志中调查是否已经失陷。

为什么制品仓库失陷尤其危险

Artifactory 往往位于软件供应链的中心。CI/CD 系统向它上传构件，构建节点从中下载依赖，管理员还可能在系统中配置云凭据、签名材料、访问令牌或远程仓库账号。

一旦攻击者取得管理员权限，影响可能沿多个方向扩散：

  • 读取或替换内部构件，把恶意内容带入后续构建与发布流程；
  • 窃取访问令牌、API 密钥、SSH 密钥及远程仓库凭据；
  • 借助服务进程或插件能力执行代码；
  • 创建新用户、令牌或其他持久化入口；
  • 删除、篡改或停止日志，增加取证难度。

“不到五分钟”意味着人工审批和日常变更窗口通常来不及阻止首次入侵。只要实例仍可从公网访问，临时隔离就应当先于完整根因分析。

应急动作：隔离、升级与秘密轮换要并行推进

来源摘要没有给出具体漏洞编号、受影响版本或修复版本，因此不要凭经验猜测。应从供应商安全公告和当前部署清单中确认准确的升级目标。与此同时，可以立即执行以下操作：

  1. 从负载均衡器、安全组、防火墙或反向代理上取消公网访问；
  2. 仅允许企业 VPN、堡垒机和必要的 CI/CD 网段连接；
  3. 保存节点、容器、数据库和日志快照，再开展会改变现场的操作；
  4. 升级到供应商确认已修复的版本，并检查集群中是否存在遗漏节点；
  5. 轮换 Artifactory 管理员凭据、访问令牌、仓库凭据和签名密钥；
  6. 更新所有使用旧秘密的流水线，并显式吊销旧令牌；
  7. 审查新增管理员、权限组、令牌、插件、计划任务和启动项。

仅仅修改管理员密码并不充分。已经生成的长期令牌、被复制的私钥或操作系统级持久化机制不会因密码变化自动失效。

可直接改造的暴露面与日志排查脚本

下面的 Bash 脚本用于完成两项初筛：检查指定 Artifactory 地址是否仍可从当前网络访问，并在日志目录中搜索高风险事件。运行前将 ARTIFACTORY_URL 改成实际地址，将 LOG_DIR 指向保存下来的 Artifactory 或反向代理日志目录。

#!/usr/bin/env bash
set -euo pipefail

ARTIFACTORY_URL="${ARTIFACTORY_URL:-https://artifactory.example.com}"
LOG_DIR="${LOG_DIR:-/var/opt/jfrog/artifactory/log}"
OUT_DIR="${OUT_DIR:-./artifactory-triage-$(date -u +%Y%m%dT%H%M%SZ)}"

mkdir -p "$OUT_DIR"

echo "[1/3] Testing reachability from this host"
curl --connect-timeout 5 --max-time 15 \
  -sS -D "$OUT_DIR/response-headers.txt" \
  -o /dev/null "$ARTIFACTORY_URL/" || true

if [[ -d "$LOG_DIR" ]]; then
  echo "[2/3] Copying metadata and calculating hashes"
  find "$LOG_DIR" -type f -printf '%TY-%Tm-%TdT%TH:%TM:%TS %s %p\n' \
    | sort > "$OUT_DIR/log-inventory.txt"
  find "$LOG_DIR" -type f -print0 \
    | sort -z \
    | xargs -0 -r sha256sum > "$OUT_DIR/log-sha256.txt"

  echo "[3/3] Searching for security-relevant events"
  grep -RniE \
    'admin|user.*(create|add|update)|token|api[ _-]?key|permission|login|authentication|authorization|plugin|delete|truncate|failed' \
    "$LOG_DIR" > "$OUT_DIR/suspicious-events.txt" || true
else
  echo "Log directory not found: $LOG_DIR" >&2
fi

echo "Results written to: $OUT_DIR"

运行方式：

chmod +x triage-artifactory.sh
ARTIFACTORY_URL="https://repo.example.internal" \
LOG_DIR="/var/opt/jfrog/artifactory/log" \
./triage-artifactory.sh

这个脚本只是初筛工具，不会判断实例是否安全。关键字命中可能是正常管理活动，也可能遗漏经过混淆或已被删除的记录。应把结果与身份提供商、反向代理、负载均衡器、数据库审计、主机 EDR 和云平台日志交叉验证。

用反向代理快速收缩入口

如果暂时无法停机，可在升级前通过 Nginx 只允许受控网段访问。下面是假设 Artifactory 监听在 127.0.0.1:8082 的示例；需要替换域名、证书路径和允许的 CIDR，并确认后端端口符合实际部署。

server {
    listen 443 ssl;
    server_name repo.example.com;

    ssl_certificate     /etc/nginx/tls/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/privkey.pem;

    # 企业 VPN、堡垒机和 CI/CD 出口网段
    allow 10.20.0.0/16;
    allow 192.0.2.40/32;
    deny all;

    access_log /var/log/nginx/artifactory_access.log combined;
    error_log  /var/log/nginx/artifactory_error.log warn;

    location / {
        proxy_pass http://127.0.0.1:8082;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

应用前先检查配置，再平滑加载：

sudo nginx -t
sudo systemctl reload nginx

这种限制只能降低攻击面，不能修复漏洞，也不能驱逐已经取得访问权限的攻击者。若实例此前暴露在公网，应默认存在失陷可能，直到调查能够证明相反结论。

调查时不要只查看管理员列表

攻击者可能使用更隐蔽的方式维持访问。调查范围至少应覆盖：

  • 最近创建或修改的用户、组、权限目标与访问令牌；
  • 非预期的管理员授权，以及服务账号权限突然扩大；
  • 配置文件、插件目录、启动脚本和系统服务的变更；
  • 异常子进程、外联连接、临时目录文件与计划任务；
  • 构件被覆盖、重新上传或校验值发生变化的记录；
  • 日志缺口、时间戳异常、审计配置关闭和文件被截断；
  • Artifactory 节点与数据库中不一致的账户或令牌状态。

如果发现任意代码执行迹象，仅在原主机上“清理文件”风险很高。更可靠的做法通常是从可信镜像重建节点、恢复经过验证的数据、重新签发所有秘密，并对受影响时间段内发布的构件重新校验或重新构建。

上线前后的核对清单

  • [ ] 已确认所有节点的实际版本，并升级到供应商确认修复的版本；
  • [ ] Artifactory 不再直接暴露于互联网；
  • [ ] 管理入口仅允许 VPN、堡垒机或专用管理网络访问；
  • [ ] 管理员密码、访问令牌、API 密钥、SSH 密钥和远程仓库凭据均已轮换；
  • [ ] 旧令牌已被显式吊销，而不只是停止使用；
  • [ ] 已审计近期账号、权限、插件、配置和构件变化；
  • [ ] 日志已复制到不可由 Artifactory 管理员删除的外部存储；
  • [ ] 已检查 CI/CD 系统和构建节点是否受到横向影响；
  • [ ] 已验证关键构件的签名、摘要或可重复构建结果；
  • [ ] 已建立异常管理员变更、令牌创建和日志中断告警。

对于供应链核心系统，补丁只是恢复工作的起点。真正关闭事件，需要同时处理网络暴露、身份凭据、主机持久化、构件完整性以及日志可信度。

# InfoQ # 全栈

相关推荐