HTML injection in mails sent from Google Scholar

As you might know, Google is running a vulnerability reward program, where they award researchers monetary awards or a place in their Hall of Fame when they responsibly disclose vulnerabilities. With this in mind, I was scooping around on several Google services, including Google Scholar. As I recently started a PhD at K.U. Leuven, I wanted to change my Google Scholar email address, which was my student’s address before. A few seconds later I received the following email:

Nothing wrong with this apparently. Now, as Mathias Bynens and I had discovered an HTML-injection vulnerability in emails sent from Instagram not too long ago, I thought: let’s see what we get if my name were Tom Van Goethem<!--:

Now as you can see, the bottom part has suddenly disappeared. So this could mean that the HTML comment was not escaped properly and thus rendered in the email. This is confirmed by looking at the source of the email:

<a href="http://scholar.google.be/cita=
tions?user=3D7QYR1UoAAAAJ&hl=en">Tom Van Goethem<!--</a>

So this means that an attacker can inject arbitrary HTML content into emails that are sent by Google Scholar. This means that the attacker is also able to inject stylesheets into the email, allowing him to make the email look like whatever he wants. He could then use this to send out spam, promoting his viagra pills, or phishing emails, asking the user to confirm his address at “Google Scholar”.

Here’s an example of what an email from someone named </a><a id=a href=http://goo.gl/CQtK5F><link rel=stylesheet href="http://tomvglabs.be/css.php"> might look like:

As you might have guessed, clicking that URL won’t refer you to the real Google Scholar, but to http://goo.gl/CQtK5F instead, which redirects to http://google-scholar.org (available for registration).

###Google’s response

Trying to participate in the Google’s vulnerability reward program, I privately disclosed this vulnerability to Google, trying to be as clear as possible showing them the potential dangers.

One day later I received the following email:

Hi Tom Van Goethem,

Nice catch! I’ve filed a bug and will update you once we’ve got more information.

Regards, Aleksandr Dobkin, Google Security Team

One week later:

Hey,

Thanks for submitting this report, unfortunately we can’t include it in the program as we do not believe that there is a security sensitive change that needs to be done here.

Regards, Kevin

Hmmm, not security sensitive? Maybe I was not clear enough in my original report, so I sent another email pointing out that it is in fact security sensitive as it allows attackers to easily send out thousands of phishing mails to people with an academic email address. To make matters worse, the emails contain a DKIM signature from the google.com domain, letting Google take responsibility for the message. Even if this vulnerability doesn’t qualify for a reward, I strongly believe that it should be fixed promptly to protect end users.

This was the Google Security Team’s reply to my clarifying email:

I do fully realize that this exploits the DKIM signature however we still do not feel this warrants an award as almost no one actually checks DKIM, and the few that do, almost never take their signature verification out of TEST mode anyway. Additionally, as you said you can register google-scholar.com and phish from there as well.

Still no luck! At this point Google even would not make a change to their code, leaving it vulnerable, until I sent following email:

Having read your stance on coordinated disclosure, I feel that it might be better for me to publicly disclose this vulnerability, as I feel that there is a severe security impact (while you clearly have a different opinion on this). By publicly disclosing this vulnerability, you will be forced to fix this vulnerability, making the web a safer place for academic people.

I will however give you a reasonable amount of time to fix this vulnerability before I disclose the full details. As the fix of this vulnerability just takes about 3 command (adding htmlentities to all user input), I feel that 2 weeks is a very reasonable amount of time.

Approximately 12 hours later I received following email:

I have some interesting news. We have decided to fix this issue, so you will receive credit at the very least. More interestingly while fixing this we discovered another issue that may be worth a monetary award. If you can hold off on publishing we will make that decision next week and let you know.

And that was last week. Unfortunately, this bug did not meet the threshold for a reward (while Facebook rewarded me and Mathias a generous amount for a very similar vulnerability we reported in Instagram). I did end up in the Honorable Mention section of the Hall of Fame though.

###Conclusion

So why should you not trust emails sent from Google? As I’ve mentioned, the Google Security Team initially stated that injecting arbitrary HTML content in emails is not security sensitive. Not until they were pressurized by the possibility of a public disclosure, did they have the intent to fix this vulnerability promptly. Given this information, I assume that it is unlikely they will fix similar vulnerabilities found in the future (unless the reporter keeps persisting on fixing the vulnerability). This means that when you receive your next email from Google, asking to confirm something by clicking a link, please be very cautious on what you click on, and make sure not to enter any credentials, even when it all looks legit.

Comments are welcome: Hacker News, Twitter