PRELOADER

当前文章 : 《对WOT服务中逻辑缺陷漏洞的分析》

12/2/2019 —— 

对WOT服务中逻辑缺陷漏洞的分析

原文链接:https://edoverflow.com/2018/logic-flaws-in-wot-services/

摘要

网络信任服务(WOT)如Keybase,Onename和Blockstack承诺验证个人在网络上的身份。由于Web上的许多应用程序不一致,

因此通常会导致意外行为,从而导致网络信任服务中的安全漏洞。这篇文章分析了我在研究WOT服务安全性时偶然发现的三种攻击方式。

WOT服务背后的技术

WOT服务允许用户创建tokens并将其放置在他们的个人页面上(例如GitHub配置文件)。然后,服务将使用爬虫查找令牌,如果令牌有效,

则显示用户确实拥有该外部页面。这种方法背后的想法是,用户可以显示网络上的哪些页面属于他们,然后将他们的WOT帐户绑定到所有

这些外部服务。最重要的是,由于验证令牌需要公开访问,因此其他用户可以通过访问包含令牌的页面来验证是否合法。

用户TomNomNom以加密方式验证其在Keybase上的在线身份

攻击方法一 —— 时间线上的内容分布

在网络上,许多基于配置文件的应用程序允许通过在您的个人账户上共享其他人发送的帖子来重新分发内容。例如: 在Twitter上用户可以转发

内容,在GitHub上人们可以分叉项目。由于一些WOT服务使用公共信息或帖子来验证用户的身份,我想是否可以通过让他们共享发布到

攻击者时间线上的令牌来声明对他人帐户的所有权。一个特殊的服务对我来说很突出,GitHub,其中WOT应用程序(如Keybase)要求用户

将验证令牌放入GitHub gist文件中。我在GitHub中注意到的有趣行为是:当用户forks这个gist文件时,这个gist不仅会显示在用户的

时间轴上,而且用共享者的用户名替换原作者的用户名。

分叉的GitHub forked - 原作者是EdOverflow,forked是由bayotop分叉

一个易受攻击的服务是Keybase,如果攻击者可以说服受害者分叉他们的GitHub要点,攻击者将能够声称拥有受害者的GitHub用户名。

最重要的是,Keybase允许修改验证代码段,允许攻击者在HTML注释中隐藏令牌。

针对Keybase使用此技术的示例攻击可以展开如下:

1. 该攻击者请求从验证令牌Keybase对受害人的 GitHub的用户名;
1. Keybase会提示攻击者将验证令牌放入keybase.md要点;
1. 该攻击者创建一个keybase.md要点躲在HTML注释验证令牌;
1. 该受害者叉的攻击者的 GitHub的依据;
1. 该攻击者指示Keybase验证/ 受害者 /keybase.md。

因此,攻击者的Keybase帐户声明他们拥有受害者的帐户。更糟糕的是,Keybase有一个浏览器扩展,允许用户浏览某些应用程序

(例如GitHub,Twitter,黑客新闻等),并通过个人资料页面在Keybase上向用户发送消息 - 该扩展程序在其上添加了一个消息窗口。

用户的个人资料。邮件将发送到已验证帐户所有权的Keybase帐户。这意味着扩展将欺骗用户认为他们正在向预期收件人发送消息,

但所有消息都落在攻击者的收件箱中,因为他们控制了受害者的用户名。

在Keybase浏览器扩展中查看了被劫持的GitHub用户名(@ jackds1986)。所有消息都发送给Keybase上名为“totallynotjackds”的用户。

Blockstackfireblock.io也容易受到攻击媒介的攻击。在大多数情况下,修复包括使用GitHub的gist API简单地验证GitHub gist是否是一个fork。

攻击方法二 —— 命名空间攻击

某些WoT服务需要将验证令牌放在特定文件名中。例如,如上一节所述,Keybase需要将GitHub验证令牌放在名为keybase.md的 GitHub中。

在Web资产上,Keybase要求将文件命名为keybase.txt,并将其放在顶级目录或.well-known路径下。在RFC5785中,

放在well-known目录下背后的原因,是为了防止文件名冲突和堵塞根目录。前者在WOT服务方面特别有趣,因为如果攻击者可以控制网站上的文件名,他们可能会声称拥有该域名。

liberapay.com和Keybase就发生了这种情况。Liberapay是一个开源捐赠平台,并没有限制用户名中包含的点数;

因此可以创建包含文件扩展名的用户名。当我为security.txt项目(https://liberapay.com/security.txt)设置个人资料页面时,就发现了这个问题。

我创建了一个名为keybase.txt的用户并在配置文件的说明中嵌入了Keybase验证代码段。这让我可以声称liberapay.com的所有权。

Keybase没有验证keybase.txt文件的内容类型,甚至没有确保令牌有没有嵌入到页面中。

通过创建名为“keybase.txt”的用户并将验证片段嵌入到配置文件的描述中来声明liberapay.com的所有权

攻击方法三 —— 重定向

在声称拥有liberapay.com之后,我注意到liberapay.org重定向到liberapay.com。下一次攻击包括使用为liberapay.com嵌入的

liberapay.org生成的验证令牌来声明liberapay.org的所有权。Keybase的爬虫会盲目跟随重定向,而不是验证最终端点以确保它与

目标主机匹配。Keybase会请求liberapay.org /keybase.txt,它会重定向到liberapay.com /keybase.txt,其中有一个有效的
keybase.txt文件。

通过liberapay.com的keybase.txt文件声明liberapay.org的所有权。

我能提出的一个特别合理的攻击场景是使用这种技术声称品牌的URL缩短器。

结论

受这些攻击方法影响的所有服务都得到通知,并迅速解决了大多数报告的问题。Keybase仍然容易受到攻击媒介2和3的影响 - 据我所知,

他们并不打算解决这些问题。所有受影响的各方的回应时间给我留下了深刻的印象,我期待着将来再次与他们合作。作为这项研究的结果,

我已经沉迷于寻找逻辑漏洞。

更新(2018年2月16日,星期五):@ LewisBugBounty证明了我可以声称对URL缩短器的所有权如上所述:Tweet