Hacker News 中文摘要

RSS订阅

Ghrc.io疑似恶意网站 -- Ghrc.io appears to be malicious

文章摘要

文章指出,将ghcr.io误输入为ghrc.io可能会导致恶意行为,窃取GitHub凭证。ghcr.io是GitHub的容器镜像注册表,而ghrc.io表面上是一个默认的Nginx安装,但实际上可能隐藏着恶意目的。

文章总结

标题:ghrc.io 疑似恶意网站

主要内容:

通常,将 ghcr.io 误写为 ghrc.io 只是一个小的拼写错误,用户可能会收到 404 错误,最终发现问题并继续操作。然而,这次拼写错误似乎导致了非常恶意的行为——窃取 GitHub 凭证。

背景介绍:

ghcr.io 是一个符合 OCI 标准的容器镜像和 OCI 工件注册表,被许多项目使用。它是 GitHub 的一部分,是开源项目中非常流行的镜像和工件仓库。

ghrc.io 的初步观察:

乍一看,ghrc.io 只是一个默认的 Nginx 安装,访问时会显示标准的 Nginx 欢迎页面。其他链接也会返回典型的 404 错误。

恶意行为的发现:

问题出现在查看 OCI API 时。这些 API 通常位于 /v2/ 前缀下。当访问 ghrc.io/v2/ 时,它不再像默认的 Nginx 安装那样响应,而是返回 401 状态码和 www-authenticate 头,提示需要身份验证。这种行为与其他注册表(如 ghcr.ioregistry-1.docker.ioquay.io)非常相似。

风险分析:

所有迹象表明,这是一个利用拼写错误进行凭证窃取的攻击。只有在用户存储了 ghrc.io 注册表的凭证时,凭证才会被窃取。以下情况可能导致凭证泄露:

  • 运行 docker login ghrc.io
  • 在 GitHub Action 中使用 docker/login-action 并指定 registry: ghrc.io
  • 在 Kubernetes 中创建 ghrc.io 的注册表凭证,然后尝试从该错误主机拉取镜像。

应对措施:

如果用户曾误登录到错误的服务器,应立即更改密码,撤销使用的任何 PAT(个人访问令牌),并检查 GitHub 账户中是否有任何可疑活动。攻击者可能会利用这些凭证向用户的 ghcr.io 仓库推送恶意镜像,或者直接访问用户的 GitHub 账户。

总结:

ghrc.io 看似无害,但其行为表明它可能是一个恶意网站,专门利用拼写错误窃取用户凭证。用户应提高警惕,避免误操作,并及时采取措施保护账户安全。

评论总结

评论主要围绕域名拼写错误(如“ghrc.io”与“ghcr.io”)带来的安全风险展开,观点分为以下几个方面:

  1. 域名拼写错误的隐蔽性

    • 多位评论者指出,域名中的拼写错误(如“c”和“r”的调换)非常隐蔽,容易被忽视。
    • 引用:“Took the article pointing out that the c and r were transposed for me to even notice there was a problem!”(arjvik)
    • 引用:“Fairly compelling attack vector because it took several readings for me to even see the problem with the domain.”(Atreiden)
  2. 安全威胁的严重性

    • 评论者认为这种拼写错误可能被恶意利用,尤其是在CI/CD环境中,可能导致严重后果。
    • 引用:“Damn, this can pick a typo from a CI job and do mean things.”(a1o)
    • 引用:“GitHub Container registry does not even support fine-grained tokens, instead it uses classic ones, which makes this even more dangerous.”(nicce)
  3. 开源项目的广泛使用

    • 有评论者提到,许多开源项目使用了类似的域名,增加了潜在的风险。
    • 引用:“There are alot of open source projects using this domain.”(aussieguy1234)
  4. 认证机制的安全性

    • 部分评论者讨论了Bearer令牌的安全性问题,质疑OAuth是否会在不同域名间复用令牌。
    • 引用:“Is the danger here token replay? It's using Bearer tokens, so it's not sending a password over.”(engcoach)
    • 引用:“Does OAuth reuse tokens across domains? If not, doesn't this just mean it is requesting an auth token for ghrc (the 'fake' domain) but it can't access any auth tokens for ghcr (the real domain)?”(engcoach)
  5. 域名选择与安全性的权衡

    • 有评论者建议避免使用非主流顶级域名(TLD),认为安全性应优先于域名的“趣味性”。
    • 引用:“Reminder not to use goofy TLDs, being cute is not worth it when compared to security.”(TZubiri)
    • 引用:“I'd rather deal with US verisign rather than the British Indian Ocean territory or colombia or anguila.”(TZubiri)

总结:评论者普遍认为域名拼写错误可能带来严重的安全隐患,尤其是在开源项目和CI/CD环境中。同时,认证机制的安全性以及域名选择也是讨论的焦点。