嘿大家。我搞砸了Anubis的部分制作方式，因此我已经修复了它，并正在提交此 CVE 来解释出了什么问题以及如何修复它。这是GHSA-56w8-8ppj-2p4f 。
这需要经验丰富的攻击者瞄准运行 Anubis 的服务器。我怀疑这种情况的唯一实例是记者作为概念证明和在我的测试中所做的实例。
漏洞详情
这些详细信息已从GHSA-56w8-8ppj-2p4f复制。
CVSS 分数：2.3（CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA :N)
弱点： CWE-807 ：安全决策中依赖不受信任的输入
易受攻击的版本：任何早于v1.11.0-37-gd98d70a版本
修补版本： v1.11.0-37-gd98d70a及更新版本
语境
Anubis 是一款工具，允许管理员通过机器人检查启发式方法和工作量证明挑战来保护机器人免受 AI 抓取工具的侵害，以阻止从多个 IP 地址进行抓取。有关 Anubis 的更多信息，请参阅Anubis 的 README.md 。
影响
针对使用 Anubis 的网站的老练攻击者（或爬虫者）可以轻松绕过机器人保护机制。
这需要有针对性的攻击。
补丁
拉取最新的 Docker 映像，以确保您已升级到提交e09d0226a628f04b1d80fd83bee777894a45cd02 。
解决方法
目前没有已知的解决方法。用户必须升级才能解决此问题。
细节
Anubis 的工作原理是让客户端请求具有给定难度的挑战值，然后客户端执行工作量证明来创建与该难度匹配的 sha-256 哈希值。在提交e09d0226a628f04b1d80fd83bee777894a45cd02之前，客户端将其使用的难度发送回服务器，服务器使用该不受信任的值做出允许/拒绝决定。
这个问题已通过在做出允许/拒绝决定时使用管理员在 Anubis 配置标志中设置的难度值来解决。
格瑞特兹
感谢 Coral Pink 报告此问题。
Techaro 安全问题报告政策
在Techaro ，我们坚信处理安全问题时应完全诚实。我们尽力不编写易受攻击的代码，但不可避免地我们会搞砸并意外地这样做。当我们这样做时，我们将：透明、诚实、高信号，并像专业成年人一样处理情况。我们会珍惜安全研究人员的时间。
有时，我们会失败。我们真正测量的不是它发生的次数，而是当它发生时我们的反应。这就是我们公开、诚实地报告此问题的原因。
当事情确实失败时，我们将创建回归测试以确保这些失败不会重复发生。 Anubis 的测试目前是私有的，但为了透明起见，这里是我们添加到该存储库中以处理此回归的测试：
func TestFakeChallengeDifficulty ( t * testing . T ) { cli , err := anubis . New ( * testServerURL ) if err != nil { t . Fatal ( err ) } ctx , cancel := context . WithTimeout ( context . Background ( ) , 10 * time . Second ) defer cancel ( ) chall , err := cli . MakeChallenge ( ctx ) if err != nil { t . Fatal ( err ) } nonce := 42069 response , err := sha256sum ( fmt . Sprintf ( "%s%d" , chall . Challenge , nonce ) ) if err != nil { t . Fatal ( err ) } if err := cli . PassChallenge ( ctx , anubis . PassChallengeRequest { Response : response , Nonce : nonce , Redir : "https://xeiaso.net" , ElapsedTime : 420 , Difficulty : 0 , } ) ; err != nil { sce , ok := err . ( * anubis . StatusCodeErr ) if ! ok { t . Fatal ( err ) } if sce . Got != http . StatusForbidden { t . Fatalf ( "wrong status code, should have forbidden auth bypas: want: %d, got: %d" , sce . Want , sce . Got ) } } return }
感谢您关注Anubis的发展。