The attack spread incredibly quickly – the first known phishing email was sent at 2:27pm EST<\/a> and about an hour later Google had stopped the attack by revoking the malicious app\u2019s API token. As many as a million accounts<\/a> may have been compromised in that small window.<\/p>\n The attack is being referred to as \u201cdynamite phishing\u201d because of how many users it affected and it’s totally indiscriminate targets. The name also emphasizes the difference in tactics compared to \u201cspearphishing,\u201d an extremely narrow and tailored attack, which has been used in high-profile hacks of political figures.<\/p>\n Now that the dust has settled, there is no indication the attack had malicious intent – code found by researchers suggests the primary purpose was replicating and spreading itself. It is entirely possible that emails and contact lists were downloaded and are being saved for a later use, but we likely won\u2019t know until the next attack is underway.<\/p>\n Harm aside, this incident has raised a lot of questions about the OAuth standard and Google\u2019s implementation of it.<\/p>\n Looking at the attack, it is clear that there were multiple failings in Google\u2019s design of their permission page, as well as bigger picture issues with one-click access to your personal data.<\/p>\n The primary reason this attack was successful was because users were directed to a legitimate Google OAuth page asking them to give permission to \u201cGoogle Docs.\u201d Hiding the app\u2019s author behind a hyperlink didn\u2019t help either.<\/p>\n What everyday user is going to be suspicious of a Google.com page asking \u201cGoogle Docs\u201d to access your Google account?<\/p>\n This was possible because Google does not perform any sort of validation<\/a> of the app name, icon, or URL, allowing anyone to mimic legitimate services. Any popular app or service could be easily spoofed.<\/p>\n Working in the world of URLs, I know how difficult it can be to prevent spoofing<\/a>. But let\u2019s start by blocking literal strings such as \u201cGoogle Docs\u201d – or anything with \u201cGoogle\u201d or any similar spellings. There is no legitimate reason third-party apps need to be using \u201cGoogle\u201d in their name – and this attack has shown just how effective this tactic is.<\/p>\n To add insult to injury, Motherboard has found that this exact attack was reported to Google<\/a> and publicly posted as a concept more than 6 years ago.<\/p>\n Google allows you to manage the apps connected<\/a> to your account through a page that lists each app, the permissions it has, and the date it was first authorized.<\/p>\n What they don\u2019t show you is any clear identification of the app\u2019s author. We know that the malicious \u201cGoogle Docs\u201d app was published by the account \u201ceugene.pupov@gmail.com<\/a>.\u201d But that information is not shown<\/a> on the permissions management page, nor is there any indicator the app is published by a third-party.<\/p>\n Below is a screenshot of my account, where \u201cGoogle Chrome\u201d is listed as a connected app because I have signed into my browser with my account. How do I tell if this is legitimate or another malicious app?<\/p>\n Why is there no way to differentiate between this first-party service provided by Google itself and other apps?<\/p>\nWhy does Google allow apps to give themselves the same name as legitimate Google services?<\/h2>\n
![\"google](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/05\/google-oauth-permissions-1.png\")
<\/p>\nWhy does Google not identify first-party services?<\/h2>\n
![\"google](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/05\/google-oauth-permissions-2.png\")
<\/p>\nWhy are Google OAuth permissions so broad?<\/h2>\n