挖洞经验 | 看我如何发现微软Microsoft Translator Hub服务高危漏洞
source link: http://www.freebuf.com/articles/web/178766.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
因为微软公司部署有很多在线网站和服务,对漏洞挖掘者来说具备较广的攻击测试面,发现漏洞入选微软致谢榜的难度相对不大,所以我就把大把时间耗在了微软漏洞发现上。在我分析微软在线应用服务过程中,微软的机器翻译服务Microsoft Translator Hub引起了我的注意,最终我发现Microsoft Translator Hub存在一个不安全的间接对象引用漏洞,利用该漏洞可以删除用户创建的多达13000多个翻译项目。
Microsoft Translator Hub :微软机器翻译服务的延伸,它是充分集成在文本翻译API 并和 Collaborative Translation Framework (CTF)的配合使用。使用建立在Hub上的自定义翻译系统,可以安全使用你的组织工作流,通过微软翻译API,可实现跨越任意数量的产品和服务:从微软、第三方或你自己的自定义开发。微软构建该平台的原因出于2010 年海地地震时救援人员遇到的语言障碍,当时没有一款机器翻译支持海地当地语言。Microsoft Translator Hub重要的是能够构建、训练独特的机器翻译系统,甚至能保护濒临灭绝的小语种。
漏洞细节
Microsoft Translator Hub在线服务允许用户创建自定义的机器语言翻译项目,为了发现漏洞,尽管没完全了解其中的功能特征,我注册登录后就随手创建了一个名为 “huntingbugs” 的翻译项目。 从上图中可以看到,项目属性中允许 “编辑” 和 “删除”操作,如果你点击 “删除”按钮,它就会立马删除你创建的项目,其它也没啥新功能。接下来,我就启动了BurpSuite准备拦截HTTP请求通信,以下即为“删除”操作的网络请求包:
POST /Projects/RemoveProject?projectId=12839 HTTP/1.1
Host: hub.microsofttranslator.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://hub.microsofttranslator.com/Projects/Index
Cookie: RPSAuth=FABKARSt1lMxfQ39EcbVsLWT8hLbEL12RANmAAAEgAAACI6Hs92zqyRlCAGce1EqwSJmjJe21nXVHarrEJ9ROzjj21XAthl%2BUUjzX3XR5JeCB8WI0oMdmwQhyn30OIiubBYaeLeg21nqXT06UwzczFIDAjoqU%2BQpCg9SWaLSVSC3aKMZPT92NVjgySbIV8YYxPA4XMVMbU04mvNKv8v5vaGVMUNBtjHldxFqKYEWqI5P0UZetmtagzOK%2Bf2CRFbgb3Gak68RN6Mjj/xXt2ovC8pxYn2qb9MqSNxHC4Y3bA8n6vyZoJzM6Uu0zZpTUPIhv5L1PyHOO3FdXFELqttx2Yd2LEJNvxjkmON9KcYXIR%2BlUsHfimE901msD9XWB1SLG3zvm06oacncf1WGrdjEdnA2lOgUALlEhQzxHbGm6TryDMpq%2BbrTU/wG; RPSSecAuth=FABKARSt1lMxfQ39EcbVsLWT8hLbEL12RANmAAAEgAAACKDdutui3VqgCAE5DVaipcaF6WaWT%2B0L0ppLMAd7kigpYcQ89xhwiDiYN9yNhyVf86EW6KiiOs7FY2PCTFH2rM/uH3LYLIhTEYturZ5vOjVPBUP6QqqAtP9rvUCtv9%2Bakv9WNwY4gpZzQ4SXjtVpSMqyrV3RIN/emocWtNDmU5BPrnAZk50oAnoSf6aJX5IjaNcXc61Tv3BSO6m3GKLevxWnpSoyLzIajETwMSBe84fL5fWyUI0r3jXq7rW/rUh/Go/R4OzS2nL1okl512yFcZFZFXdsEq6k5M0lKP0L9ZTVtaW0WiZKXKgY%2B%2BPPtImjI5whKX2U4wbqgPiD1rxXwDogAlcrLKu6YGEHfVg01iG0GQ0UAF%2BhVQ4CptuuRm8tI8XE9zmo3%2Bhr; ANON=A=365DFF2DD45617971705DA33FFFFFFFF&E=1089&W=1; NAP=V=1.9&E=102f&C=h8ZS17Xmf0z4Q2T9Dj26e_Pijaca9G00g1PJCcXaI36L1P7jWHYOFQ&W=1; mstcid=[RemovedEmail]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
可以看到,POST请求包中没有任何内容,而且其URL中涉及的参数“projectid”是不是看着有点异样,貌似是来自数据库中的项目ID号,这里 projectid 为 12839。所以按照数据库思维来说,以上这个POST的删除请求可以转化为以下这样的数据库命令:
Delete project FROM projects WHERE projectid=12839;
转发通过这个POST的HTTP请求之后,我们ID号为“12839”的项目就自然被删除了。
CSRF 攻击可能
在这里,我想可以针对这个请求包做点手脚。很明显,能发现其服务端没有CSRF保护,那么可能会存在CSRF攻击。也就是说,攻击者会利用这种环境下的CSRF漏洞去伪造合法用户身份,执行登录和其它操作。利用情形如下:
合法用户处于登录状态;
攻击者在图片标记、iframe框架等其它属性的网页中嵌入以下删除请求的链接:
http://hub.microsofttranslator.com/Projects/RemoveProject?projectId=12839
作为受害者的合法用户访问到包含以上请求链接的网页后,删除请求便会发出;
唯一需要知道的就是合法用户自己创建的 ProjectID 号;
主要原因在于在服务端没有设置 antiCSRF token手段来防止CSRF攻击;
某些情况下,即使设置有 antiCSRF token手段,也 可能被绕过 。
最严重的后果
我们再看看上面那个项目删除的POST请求,如果我们对 projectID 进行一些 fuzz 操作,更改为其它项目号会如何呢?于是乎,我又另外创建了一个Microsoft Translator Hub账号,以该账号用其它浏览器登录之后,在其中创建了两个我自己的翻译项目。
接着,我再次启动BurpSuite,希望对projectID做一些fuzz和其它操作。在第一次执行的“删除”操作网络请求包中,我把其中的projectID参数值,替换成了我第二个Microsoft Translator Hub账号中创建的项目projectID参数值,之后转发请求并刷新页面。竟然发现我第二个Microsoft Translator Hub账号中projectID参数值对应的项目被悄无声息地删除了!
严格意义上来说,这种漏洞应该称为 不安全的间接对象引用 (Indirect Object Reference),该漏洞的影响也就是说:我最近创建项目的projectID值为12839,如果我把projectID参数进行 0 到 13000的遍历,那么也就能针对微软数据库中,把将近13000多个的Microsoft Translator Hub用户创建项目删除!
简单来说,可用一些简单的检测机制来避免该漏洞,比如针对项目请求作同一用户检查,或者把用户创建的项目和用户作关联检查,等等。但是微软却遗漏掉了……
完美结局
我把该漏洞上报给MSRC之后,他们给我的回应如下:
之后,微软快速修复了该漏洞,并最终微软把我列入了漏洞致谢榜: * 参考来源: haiderm ,clouds 编译,转载请注明来自 FreeBuf.COM
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK