快捷搜索:  网络  CVE  渗透  后门  扫描  木马  黑客  as

挖洞经验 | 看我怎么样发现微软Microsoft Translator Hub服务高危漏洞

timg.jpg

因为微软公司部署有很多在线网站以及服务,对漏洞挖掘者来说具备较广的攻击测试面,发现漏洞入选微软致谢榜的难度相对于不大,所以我就把大把时间耗在了微软漏洞发现上。在我阐发微软在线应用服务过程中,微软的机器翻译服务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” 的翻译项目。01.jpg从上图中可以看到,项目属性中允许 “编辑” 以及 “删除”操作,要是你点击 “删除”按钮,它就会立马删除你创建的项目,别的也没啥新功能。接下来,我就启动了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%2B0L0ppLMAd7kigpYcQ89xhwiDiYN9yNhyVf86EW6KiiOs7FY2PCTFprM/upLYLIhTEYturZ5vOjVPBUP6QqqAtP9rvUCtv9%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”的项目就自然被删除了。

02.jpg

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账号,以该账号用别的阅读器登录以后,在其中创建了两个我本人的翻译项目。

03.jpg接着,我再次启动BurpSuite,希翼对projectID做一些fuzz以及别的操作。在第一次执行的“删除”操作收集要求包中,我把其中的projectID参数值,替代成了我第二个Microsoft Translator Hub账号中创建的项目projectID参数值,以后转发要求并革新页面。竟然发现我第二个Microsoft Translator Hub账号中projectID参数值对应的项目被悄无声息地删除了!

04.jpg

严格意义上来说,这类漏洞应该称为不安全的间接对象引用(Indirect Object Reference),该漏洞的影响也就是说:我近来创建项目的projectID值为12839,要是我把projectID参数进行 0 到 13000的遍历,那么也就能针对微软数据库中,把将近13000多个的Microsoft Translator Hub用户创建项目删除!

简单来说,可用一些简单的检测机制来避免该漏洞,譬如针对项目要求作同一用户检查,或者把用户创建的项目以及用户作关联检查,等等。然则微软却脱漏掉了……

完善结局

我把该漏洞上报给MSRC以后,他们给我的归应以下:

05.jpg以后,微软快速修复了该漏洞,并终极微软把我列入了漏洞致谢榜:06.jpg *参考来源:haiderm,clouds 编译,

您可能还会对下面的文章感兴趣: