看我如何发现微软Microsoft Translator Hub服务高危漏洞
因为微软公司部署有很多在线网站和服务，对漏洞挖掘者来说具备较广的攻击测试面，发现漏洞入选微软致谢榜的难度相对不大，所以我就把大把时间耗在了微软漏洞发现上。在我分析微软在线应用服务过程中，微软的机器翻译服务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账号，以该账号用其它浏览器登录之后，在其中创建了两个我自己的翻译项目。
因为微软公司部署有很多在线网站和服务，对漏洞挖掘者来说具备较广的攻击测试面，发现漏洞入选微软致谢榜的难度相对不大，所以我就把大把时间耗在了微软漏洞发现上。在我分析微软在线应用服务过程中，微软的机器翻译服务Microsoft Translator Hub引起了我的注意，最终我发现Microsoft Translator Hub存在一个不安全的间接对象引用漏洞，利用该漏洞可以删除用户创建的多达13000多个翻译项目。
Microsoft Translator Hub ：微软机器翻译服务的延伸，它是充分集成在文本翻译API 并和 Collaborative Translation Framework (CTF)的配合使用。使用建立在Hub上的自定义翻译系统，可以安全使用你的组织工作流，通过微软翻译API，可实现跨越任意数量的产品和服务：从微软、第三方或你自己的自定义开发。微软构建该平台的原因出于2010 年海地地震时救援人员遇到的语言障碍，当时没有一款机器翻译支持海地当地语言。Microsoft Translator Hub重要的是能够构建、训练独特的机器翻译系统，甚至能保护濒临灭绝的小语种。
copyright 无奈人生
漏洞细节
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账号，以该账号用其它浏览器登录之后，在其中创建了两个我自己的翻译项目。
无奈人生安全网