Advisory: Using www.google.com to Host Malicious Mobile Content

Overview

It is possible to use a flaw in Google.com to host malicious content. However, such content is not able to interact with anything on Google.com domain itself.

Details

Google’s main website provides a subsite for displaying mobile-optimized pages published using a special subset of HTML called AMP. The current implementation can display any AMP page on the Internet without checking content. The URL is as follows:

https://www.google.com/amp/XXXX

where XXXX is the URL of the site. This ONLY works on mobile devices and can be simulated using Chrome’s developer tools, but on desktop browsers, it will redirect to the page itself (as described in our earlier post). Here is a real working example:

https://www.google.com/amp/www.usatoday.com/story/life/people/2016/03/31/world-famous-architect-zaha-hadid-dies-age-65/82466082/

amp1.png
Example of AMP site running on Google.com directly

This, however, can be used to display malicious content. Due to the way AMP is designed, AMP pages are not allowed to have Javascript, or “javascript:” URLs. They can, however, have URLs that lead to the Google Play store or iTunes. This can be leveraged to fool users into installing apps they don’t need — all on Google.com. Here is an example screenshot — note the URL and that a valid Google.com certificate is used. The link goes to the Google play store.

amp2.png
Source code - BODY tag only, rest is standard AMP HTML (see here):
<body><amp-img src=”glogo.jpg” alt=”logo” height=”200px” width=”300px”></amp-img> <h3>We have scanned your phone and found it to be infected with a virus. To clean your off, please click on the link below</h3> <p><a href=”https://play.google.com/store/apps/details?id=com.cleanmaster.mguard&hl=en">Clean My Phone</a></p></body>

Taking this a step further, while AMP does not allow forms and Javascript in the main page, it does allow Javascript and forms in an iframe, as long as that iframe is at least 75% down from the top of the page. This can be used to do the following — embedding a malicious login form inside an iframe which then can be used to steal people’s Google account credentials. Example screenshot and source below — this is not styled since it is a POC.

 amp3.png
amp4.png

Main page BODY:

<body>
<amp-img src=”glogo.jpg” alt=”logo” height=”300px” width=”300px”></amp-img>
<amp-img src=”glogo.jpg” alt=”logo” height=”300px” width=”300px”></amp-img>
<h3>You have logged out of your account, please login again below</h3>
<amp-iframe width=”300px” height=”300px”
    sandbox=”allow-scripts allow-forms” layout=”responsive”
    frameborder=”0" src=”iframe.html">
</amp-iframe>
</body>

Iframe Source:

<!doctype html>
<html>
 <head>
 <meta charset=”utf-8">
 <title>Test1</title>
 </head>
 <body>
 <form action=”form.py”>
 Email: <input type=”text” name=”email”/><br/>
 Password: <input type=”password” name=”password”/><br/>
 <input type=”submit”/>
 </form>
 </body>
</html>

Vendor Response

The vendor has communicated that they do not consider this to be a security issue

References

Credits

Researched and written by Yakov Shafranovich.

Timeline

2016–04–12: Vendor notified
2016–04–13: Vendor response
2016–04–13: Public disclosure

Advisory: Content Injection in Google Calendar API (Google)

Overview

Google Calendar embedding API allows injection of arbitrary content.

Background

Google Calendar offers an embedding API, allowing calendars to be embedded in web pages. This API is accessible at the following URL:

https://www.google.com/calendar/embed?src=<url>

Details

In case of an invalid URL, it mirrors back the text of the URL. For example, the following URL:

https://www.google.com/calendar/embed?src=<url>

would show the following message:

Invalid calendar id: <url>

While we have not been able to show script execution, we believe that this can still be used as a vector of attack, especially since this injects content into a page that is SSL secured with a Google certificate. Interestingly, a similar content injection attack was considered to be severe enough by Microsoft to be fixed (as per our earlier blog post).

We would like to present the following attack scenarios:

Scenario #1 — Phishing attack

An attacker can use this to send email to Google Calendar users with the following URL:

https://www.google.com/calendar/embed?src=-We%20are%20having%20a%20problem%20with%20your%20account.%20Please%20call%201-800-BAD-GUYS%20x123%20and%20give%20them%20your%20password

Resulting in the following message:

Invalid calendar id: -We are having a problem with your account. Please call 1–800-BAD-GUYS x123 and give them your password

A sophisticated attack can issue a unique extension for each spammed address, bypassing the requirement for users to provide their email address over the phone. It would also be possible to automate such attack with voice API providers like Twilio, further making users feel at ease, since most phone phishing attempts use humans.

Scenario #2 — Stock manipulation attack

An attacker can use the following URL to show a fake Google Calendar in attempt to manipulate the stock market:

https://www.google.com/calendar/embed?src=-BEGIN%3AVEVENT%0ASUMMARY%3A%20%0AUID%3A12345%0ADESCRIPTION%3BSergey%20Brin%2FElon%20Musk%20to%20announce%20%24GOOG%20acquisition%20of%20%24TSLA%0ALOCATION%3AMountainview%2C%20CA%0ADTSTART%3BTZID%3D%2FUS%2FEastern%3A20151109T100000%0ADTEND%3BTZID%3D%2FUS%2FEastern%3A20151109T113000%0AURL%3Ahttp%3A%2F%2Fintranet.google.com%2Fcalendar%2Fsergerybrin%2Feventid%3D12345%0AEND%3AVEVENT

This would result in the following message:

Invalid calendar id: -BEGIN:VEVENT SUMMARY: UID:12345 DESCRIPTION;Sergey Brin/Elon Musk to announce $GOOG acquisition of $TSLA LOCATION:Mountainview, CA DTSTART;TZID=/US/Eastern:20151109T100000 DTEND;TZID=/US/Eastern:20151109T113000 URL:http://intranet.google.com/calendar/sergerybrin/eventid=12345 END:VEVENT

Seemingly this would indicate a fake calendar event announcing the acquisition of Tesla Motors by Google. HOWEVER, given that the embed API can be used to embed any calendar, it would be trivial to create a real Google calendar with fake info and embed it.

Screenshot

(Please note the SSL icon)

google.png

Vendor Response

Vendor response is as follows:

There is no XSS demonstrated here, just content injection, which has legitimate use and is not a technical security bug for the purposes of our reporting program (phishing generally isn’t a “technical” enough attack scenario). All inputs appear to be properly sanitized, so if you want to demonstrate an actual XSS, you’d need to show proof of script execution

References

Google Security CID: 6–1050000008145
Google Calendar Embed docs: https://support.google.com/calendar/answer/41207?hl=en

Timeline

2015–08–07: Vendor notified
2015–08–07: Vendor response
2015–10–26: Public disclosure

Version Information

Version 1
Last updated on 2015–09–21

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