有一天,当我在浏览Twitter上的信息时,我发现了一篇非常有趣的文章,Wesley Wineberg在微软OAuth 认证接口发现的一个CSRF漏洞。这篇文章让我好奇的同时也激起了我能在这个地方再找到一个漏洞的信心(作者谜一样的自信),因此我打算深入分析一下这个认证接口。
首先,要在我们的测试app上使用OAuth认证,我们需要先注册一个app。经过搜索,我发现了一个链接,点击后会来到”微软开发者中心”,我发现在这里注册app的话会要求我填写“应用名”和“语言”。
任何允许用户输入的地方都有可能是触发xss的入口点,所以我插入了xss攻击向量:’”>。很不幸的是,这个应用拒绝了我提交的向量,并且返回了一个有趣的错误提示:
 

从这个错误信息中我们能够发现我的攻击向量中的 ‘’被拦截了,但是’(单引号) 或 “(双引号)并没有被过滤。因此我做出了如下猜想:如果我能找到其他页面将我上面输入的内容放在标签属性中或者script标签中,但是却没有进行编码的话,我就能注入JavaScript代码。我尝试输入攻击向量 “onload=”alert(1),希望我的攻击向量能够被添加到支持onload事件的HTML标签中。
在填写完OAuth认证要返回的地址redirect_uri后,我完成了注册,然后得到了用于在我注册的app上进行OAuth验证的链接(关于Microsoft的OAuth2认证,你能在 这里找到更多的内容)。
打开该链接,我惊喜的发现我的猜想是正确的,这个认证接口存在xss漏洞
 

在页面的源代码中,我们能更好的理解应用是如何解析我提交的数据的,如下图
 

在第212行,我的攻击向量没有被编码,而是被放在了alt这个属性中(默认alt中的数据到app注册时间(20151227161905)),src的值为默认值(app如果没有上传图标,则默认使用此链接的图标),因为这个图片是一定会存在的,所以我们的onload事件一定会被执行,导致xss。
扩大战果
虽然现在我已经有了能够证明漏洞存在的证据,但是我想多花点时间来研究一下这个漏洞究竟能造成多大的影响,利用xss来“盗取cookie”或者“钓鱼”对我来说简直太无趣了(微笑脸)!所以我又做了如下猜想:既然这个漏洞存在于用户认证页面,用户可以基于他们的判断来选择接受(点击”Yes”按钮)或者拒绝(点击”No”按钮)此应用,如果我能插入JavaScript代码使得自动执行点击”Yes”按钮,我就能神不知鬼不觉的的获取到访问用户资源的权限。
所以我创建了一个新的app,并且填入了能够实现我猜想的攻击向量: “onload=”document.getElementById(‘idBtn_Accept’).click()” param=”,这个向量在onload事件触发会自动模拟点击提交”Yes”,给app授权访问用户的私人资源。
黑客能从受害者获取到的最有用的资源是什么?
一旦攻击者获取到用户的授权token后,他就能获取到该用户的资源,黑客能获取到的致命的数据包括如下:
[1]读取Outlook账户上的所有邮件(通过IMAP),或者以用户的身份发送新邮件(通过SMTP)
[2]读取保存在OneDrive上的所有文件
[3]读取用户的所有图片、视频、音频等
这里有一个poc视频:
如果快速传播此漏洞?
考虑到这是个存储型xss,并且不需要用户交互,所以可以说只要用户一访问链接就能触发xss,将该链接放到社交应用(Facebook, Twitter等)上,并且赋以有趣的故事说明,相信很多人都会中招的!
不过需要说明的是要触发该xss,需要用户已经登录过Microsoft,不过这应该不是什么难事吧?
修复
Microsoft已经修复了此漏洞,现在所有的字符都会被编码成HTML实体。