<% dim ModuleName,InfoID,ChannelShortName,CorrelativeArticle,InstallDir,ChannelDir,Keyword,PageTitle,ArticleIntro,Articlecontent Keyword=stripHTML("账户身份,身份验证,验证漏洞,漏洞分析") PageTitle=stripHTML("微软最新账户身份验证漏洞分析") ArticleIntro=stripHTML("英国安全顾问Jack Whitton在微软的身份验证系统中发现了一个重要漏洞,攻击者可访问用户的Outlook、Azure和Office账户,为此微软支付了1.3万美元奖金。") Articlecontent=stripHTML("         该漏洞与Wesley Wineberg发现的“OAuth CSRF in Live.com”漏洞类似,唯一的不同在于该漏洞影响的是微软的主身份…") ModuleName = stripHTML("exploits") InfoID = stripHTML("225783") ChannelShortName=stripHTML("漏洞") InstallDir=stripHTML("http://www.77169.com/") ChannelDir=stripHTML("exploits") %> 微软最新账户身份验证漏洞分析 - 华盟网 - http://www.77169.com
您现在的位置: 华盟网 >> 漏洞 >> 最新漏洞 >> win 漏洞 >> 正文

[组图]微软最新账户身份验证漏洞分析

2016/4/7 作者:vul_wish 来源: 网络收集
导读 <% if len(ArticleIntro)<3 then Response.Write Articlecontent 'Response.Write "Articlecontent" else Response.Write ArticleIntro 'Response.Write "ArticleIntro" end if %>

      

  该漏洞与Wesley Wineberg发现的“OAuth CSRF in Live.com”漏洞类似,唯一的不同在于该漏洞影响的是微软的主身份验证系统,而不是OAuth保护机制。

  微软在多个域(*.outlook.com, 、*.live.com等)中提供不同的服务,并且通过向login.live.com、login.microsoftonline.com和login.windows.net发送请求来解决跨服务的身份验证,为用户建立会话。

  outlook.office.com的流程如下:

  1、用户浏览https://outlook.office.com

  2、用户被重定向到https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=4&wreply=https%3a%2f%2foutlook.office.com%2fowa%2f&id=260563

  3、用户登录,POST请求发回给wreply值,其中的t表单字段中包含用户的登录令牌:

      

  4、该服务使用该令牌,用户成功登录。

  当该服务托管在完全独立的域中时,cookie不能使用,那么令牌成为用户登录的唯一凭证。这同OAuth的工作机制类似。

  这意味着,一旦攻击者获取以上代码,并将t值发回其控制的服务器,就可以冒充合法用户。

  研究人员尝试将wreply值更改为非Microsoft域,如example.com,会收到一个错误,并且该请求不会被处理:

 login-3.png

  URL编码和URL解析

  研究人员在多次研究URL编码参数时偶然发现,该方法可以绕过不同的过滤器,而这却是该身份验证漏洞的根源。

  在这种情况下,wreply在域通过检查前是URL解码的,因此,https%3a%2f%2foutlook.office.com%2f等同于https://outlook.office.com/,是有效的,请求通过。

       
   
  有趣的是,当传递https%3a%2f%2foutlook.office.com%252f的值时会抛出错误,因此https://outlook.office.com%2f不是有效的URL。

  但是,如果在URL末尾附加@example.com就不会产生错误,而是显示如下有效的URL:

  

  至于为何上述URL有效,请看URL语法:

  

  由此可以看出服务器端会执行两项验证:

  1、第一个是URL的完整性检查,确定是否有效,也就是说,服务器会默认outlook.office.com%2f为URL的用户名部分;

  2、第二个检查域名是否被允许使用,该检查会失败——example.com不允许使用。

  但是大家都知道,服务器会一直解密wreply,直到其中没有编码的字符,然后再验证该域。这是之前就已经发现过的问题:URLparsing issue #1

  现在我们就可以指定任意URL请求令牌,将重定向设置为https%3a%2f%2foutlook.office.com%252f@poc-ssl.fin1te.net%2fmicrosoft%2f%3f,其结果为:

        login-4.png

  然后简单地重放该令牌:

      

  之后就得到了该用户账户的完全访问权限:

 login-2.png

  注:在该过程中获取的令牌只在其对应的服务中有效,例如,Outlook令牌不能用于Azure服务中。但是,使用该方法就可以轻易地创建多个内联框架,设置指向不同服务的登录URL,获取令牌。

  其实这是一个跨站请求伪造漏洞,尽管有时这类漏洞的利用率并不像其他漏洞那么高,但是在身份验证系统中时影响还是十分广泛的。

  缓解

  wreply中的主机名限制为必须以%2f结尾,也就是解码后的‘/’。这就确保了浏览器只会将请求发送到目标主机。

  时间轴

  2016年1月24日,周日——漏洞发布

  2016年1月24日,周日——漏洞确认并修复

  2016年1月26日,周二——漏洞补丁发布



  • 上一篇漏洞:

  • 下一篇漏洞: 没有了