Advisory: Insufficient Parameter Sanitization in login.live.com

Overview

Web widgets hosted by Microsoft’s online login portal, login.live.com, do not perform sufficient parameter sanitization allowing an attacker to inject arbitrary text.

Background

Microsoft offers several legacy Javascript widgets that are used to display and customize sign-in link and buttons using Windows Live ID. They are hosted on login.live.com at the following URLs:

https://login.live.com/controls/WebAuth.htm
https://login.live.com/controls/WebAuthButton.htm
https://login.live.com/controls/WebAuthLogo.htm

They are documented by Microsoft here and accept several parameters that are used to customize the resulting widget.

Details

One of the parameters, style, is used to pass in CSS styling commands for the Javascript widgets described above. However, this parameter is not sanitized, and reflects back the information passed to to it via Javascript’s alert() method. It can be coerced to reflect arbitrary text of the attacker’s choosing, making it seemingly appear on a legit Microsoft website. While this does not result in script execution, it can be used as part of a social engineering campaign to attack users.

Example URL with malicious content:

https://login.live.com/controls/WebAuth.htm?appid=test&style=Please_call_Microsoft_Support_at_1-800-BAD-GUYS_and_provide_your_username_and_password:t

Screenshot

(note the SSL icon in the browser)

msft

References

MSRC Case # 30838 / TRK # 0189016
Microsoft Sign-in Link API: https://msdn.microsoft.com/en-us/library/bb676638.aspx

Microsoft Security Researcher Acknowledgements (September 2015): https://technet.microsoft.com/en-us/security/cc308575

Credits

Thank you to Grier Forensics for providing advice. Discovered by Yakov Shafranovich in collaboration with the Shaftek Enterprises Security Research Team.

Bounty Information

This discovery qualified for a security bounty under the terms of Microsoft’s Online Services Bug Bounty program.

Timeline

2015–08–06: Vendor notified
2015–08–06: Initial vendor response
2015–08–11: Vendor replicated the issue
2015–08–31: Fix deployed by vendor
2015–09–17: Bounty received
2015–09–21: Public disclosure

2016–03–15: Updated

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.