本文讲述了关于微软在线调查创建应用Microsoft forms的一个漏洞,通过其中的数据分享机制,作者可以藉机获取到参与调查用户的邮箱信息,漏洞最终收获了$2k的奖励。微软的Office365有很多服务,其中的Microsoft Forms以OData数据协议方式实现在线的调查测验创建,并能把相关调查结果数据分享给其他用户。

OData协议介绍

开放数据协议(Open Data Protocol,简称OData)是一种描述如何创建和访问Restful服务的OASIS标准。该标准由微软发起 ,前三个版本1.0、2.0、3.0都是微软开放标准,遵循微软开放规范承诺书(Microsoft Open Specification Promise)。第四个版本4.0于2014年3月17日在OASIS投票通过成为开放行业标准。OData协议是一种通过Restful交互的应用层数据协议,它支持数据模型的描述、编辑和请求,其基于SQL理念,不管客户端和数据源的具体类型,都能按照客户端请求响应返回相关数据。OData的数据交互模型如下:

简单来说,OData元数据是系统(如关系数据库中的information_schema)的数据模型之一,对每一个元数据来说都具备相关的实体(类似于数据库中的表)和属性(类似于数据库中的列),以及不同实体类型之间的关系。每种实体类型都有一个实体键,它类似于关系数据库中的键。假设我们有一个名为Customers(顾客)的实体类型,它包括三个属性。此实体类型有以下记录:

在上述例子中,ID是其中一个实体键。以下请求会返回ID为2的一条顾客记录:

customerApi/Customers(2)

即该请求会返回ID=2的顾客信息。OData和SQL相同的是,我们能以请求方式来获取其中的相关数据。OData支持好几种数据请求方式,例如可以使用以下$select语法去请求受限的实体属性,它会去获取ID=2的顾客email信息:

customerApi/Customers(2)?$select=email

在SQL语法中,其查询样式为:

SELECT email FROM Customers WHERE ID=2;

以上只是为了方便大家了解OData协议举的例子。当然除了$select外,还可以使用其它的查询语法,如JSON或XML格式的数据导出$format等。

漏洞发现

我的漏洞测试思路是:首先需要对目标系统有一个整体的了解认识,然后再去一一测试其中的每个功能属性。在Microsoft Forms这里,我首先测试的是其中的OData元数据,为此,我必须对其元数据格式进行一个深入的了解。这里,我可以请求微软官方的metadata接口来看看:
http://forms.office.com/formapi/api/$metadata

在上述微软的XML元数据结构中,并没有多少有意义的线索。接着,我又从网站https://pragmatiqa.com/xodata/的OData结构描述中来了解不同OData实体类型的关系:

一番学习之后,我尝试着去发现包含敏感信息的实体类型。正巧就发现一个名为forms的实体,其中包含了email在内的用户生成相关数据:

这里的这个email线索让我有了去探寻其他人邮箱的思路。这里,用IDOR和CORS肯定是行不通的。几经测试,我发现了一种可以访问获取到他人email信息的方法,但前提是,我的这种方法需要受害者执行访问某个恶意网站的交互动作。这种受害者交互的限制条件大大降低了漏洞危害性,最终我把漏洞上报后只获得了微软方面的简单致谢。

深入构造-未授权的OData实体访问

为了去除受害者交互这个前提动作,我重新进行了测试构造。我想Microsoft Forms用户可以把他的调查数据分享给别人进行帮忙调查,那么我是否可以从这个方面来考虑考虑呢。用户A需要把他的调查数据分享给用户B,那么需要做到以下几步:

1、用户A选择需要分享的表单form,微软服务端自动为用户A生成一个分享链接;
2、用户A把该分享链接发送给用户B;
3、用户B打开该链接,并往里面填写提交调查数据时,就会向微软服务端有一个请求动作,而此时用户A可以在他的账户环境中看到用户B的提交数据。

在以上第3步的用户B提交数据过程,会有以下提交请求:

可以注意到其中包含了以下关键字段:

formapi/api/<ownerTenantID>/users/<ownerID>/forms(<formID>)/responses

用户B提交表单数据时,这里请求内容中的ownerTenantID, ownerID, formID与他相关,因此,我就想利用这些参数能否查看到用户B的相关信息,比如邮箱email呢?于是,我就用$select语法构造了以下查询请求:

但请求发出后,服务端却返回了404的状态。也即服务端不允许我访问createdBy属性或是其他用户的表单邮箱信息。但我又想到了另外一种方法:"是否有另一个实体有createdBy属性?并且还具有与forms表单实体相同的实体键(formID)?这又引发了我的想像,假设我们要找的实体为X,什么情况下实体键应该与forms表单实体键相同?

实体X具备createdBy属性,而我们的点在于需要通过该属性访问到其中的用户邮箱email。另外,假设X有一个名为accountID的实体键,为了访问其中的email,我们需要向其发送以下请求:

formapi/api/<ownerTenantID>/users/<ownerID>/X(<accountID>)$select=createdBy

这里的关键是accountID,因为我们并不知晓其中包含了什么东西,但从前面的步骤来看,我们可以通过用户B提交的表单看到其中的formID。之后,经过几种实体类型的比对,我又发现了另一个名为runtimeForms并包含createdBy属性的实体,且其与forms表单具备相同的实体键!这样,就完全满足了我前述想像的漏洞利用条件了:

接下来,我把请求中的forms用runtimeForms代替,并用$select语法去请求受害者的邮箱email。请求发出后,终于成功获取到了受害者的邮箱信息:

据此,我就能无交互地实现受害者邮箱信息获取了,当然最终也收获了微软官方奖励的$2k奖励。

参考来源:medium

本文作者:clouds, 转自FreeBuf