Hacker News new | comments | ask | show | jobs | submit login
Google Phishing Quiz (withgoogle.com)
135 points by technion 25 days ago | hide | past | web | favorite | 97 comments



Seems odd to me that they would encourage allowing 3rd party sites to read all your email, but I guess this is where we're at right now


Yeah, that's the only reason I got a question 'wrong'. Sorry, but no third party app is getting access to my email for obvious security reasons. Doesn't matter how 'legit' the company is or what not.


This sounds conceptually right and I would definitely agree with it... if I haven't given multiple sites access to my email over the years.

Anything that interacts with your email is going to need it, and if you're signing up for that service odds are you know (or at least assume) it'll need some kind of access to your email. For example, I used unroll.me for years, which gives you a singular interface to block spam and fake subscriptions -- for these kinds of emails, there's often no (working) unsubscribe link. Unroll.me works by looking at each incoming email and, if it's from someone you've blocked, automatically deletes the email.

Similarly, it has other services that operate on emails you receive, like bundling up multiple emails into one (which, on the backend, deletes thoseincoming emails and concatenates them into a singular email with them all later).

It's easy to say "i'll never give a third party app access to my email", but for most people it comes down to the age old problem of trading data for services/conveniences that you find valuable.

Side-note: There've been many rumors over the years that Unroll.me sells information about the emails it scans. I think it's even more telling of the "trade data for service" paradigm that people continue to use the service even after finding out.


> There've been many rumors over the years that Unroll.me sells information about the emails it scans.

It's not just rumors, it's stated clearly (if in softened terms) on the site now[1]. Although it wasn't for the first few years, as their original monetization model wasn't based on it.

The big stink about it was that they shifted to that model silently. The original founder only monetized it in a straightforward manner via ads in the app. Then it was sold to Slice/Rakuten, and they silently incorporated it as part of Slice's consumer intelligence data, along with data from other subsidiaries they bought such as Ebates.

Small aside: Rakuten also has a major stake in Acorn[2]. Acorn uses Plaid to verify bank account information for payouts. Plaid[3] is incredibly handy from a consumer experience, but the implications are scary from an "alternative use" perspective. Once connected, there are several handy Plaid products[4] which can make use of that authorization, above and beyond just confirming account ownership. Such as continuously siphoning off transaction level records or keeping tabs on income and employment fluctuations[5].

Not that Rakuten is leveraging their stake in Acorn to access Acorn's bank authorization for those ulterior uses. But it's food for thought on what possibilities exist.

> I think it's even more telling of the "trade data for service" paradigm that people continue to use the service even after finding out

I agree wholeheartedly with this assessment. Although I wonder how much their subscriber growth rate changed after their alternative data use came to light.

[1] https://unroll.me/your-data

[2] https://techcrunch.com/2016/04/21/paypal-invests-30-million-...

[3] https://plaid.com/

[4] https://plaid.com/products/

[5] https://plaid.com/products/income


I've used TripIt. Reading your email is central to their "magic." The idea is that whenever you get any sort of travel confirmation, they automatically ingest it and compile all the info into trips, then handle stuff like reminding you to checkin, auto-filling up your checkin code, suggesting seats, etc.

They also have an alternative for the privacy-minded where you just forward any confirmation emails you want them to know about and the same stuff happens, but for the email address I was using for this, there wasn't anything I was worried about them accessing, and this was easier.


My workaround for this is to set up a dummy email address that I use for all travel. That email address then forwards the emails to both plans@tripit.com and my personal email address.


You could also use gmails + feature. My.name+travel@gmsil.com and have those forward to trip it.


Do you apply that constraint to browser extensions as well? "Access and modify all site data" definitely includes your email, and is required by a fair number of useful extensions including all adblockers that I know of.


Only if you read your email in the browser.


Not that I disagree with you but, do you...

- host your own email...

- on your own hardware...

- with your own software (hopefully doing end to end encryption)

Even then your surely not running your own fiber, though things like STARTTLS help mitigate this vector.

I only mean to say, some level of trust is assumed. But yea, you should aim towards less buggy, evil corporate dependencies.


The inclusion of that one kinda baffled me.

No way for me to tell whether the app that's connecting would be one I'd want reading emails (I wasn't familiar with it) and without an address bar, hard to tell if it's a spoof or the real thing.


Yeah, I mean it doesn't say the context very well, so I assumed it I clicked on a link. Like if it said you signed up for a service and clicked on a link to do something very specific.

If I accidentally clicked on a link in my email and it brought that page up, could you call it phishing?

Also the email from the person with the PDF. Like, why is that phishing? What if I trusted the sender? People send pdfs all the time. are there no secure ways to read pdfs?


I think it was mostly due to the fact that it was from a different TLD.

The TLD of the context was .EDU and the one from the email was a .ORG.


Yeah, anyone asking for that, even if it's not a phishing attempt would never get the OK from me. That's just crazy.


I suppose it might make sense if you were installing a 3rd party gmail application on your desktop.

I'm no oauth expert, but I would imagine an app would go through a flow like this.


I believe you can connect gmail to your local email client using IMAP/POP3, but I don't think that uses the oauth flow to do that (you just type in the password). I've never used any other kind of 3rd party gmail apps though.


Newer email clients do indeed often use Google's OAuth flow for email logins.


Apple Mail uses that dialog.


They should have proposed three answers for this one :-

[_] phishing

[_] legit

[X] legit, but there's no chance I will accept that!


[X] Legit phishing


Amusingly, Google doesn't let its own employees allow TripIt to access corporate email accounts.

(But personal ones? Go for it...)


That's just about compliance. In order to stay hippa compliant they can't let 3rd party read emails. Period.


Yeah, baffled me for a bit but then I remembered that question is whether is phishing attack or not; not if you gonna click "Allow". Then again there is no URL address bar to look for so it _might_ be some sort of phishing attack.


I got that answer wrong too. But I guess they were asking specifically about phishing.

I think the rationale is that the page has to be a real permissions page to give the attacker access to your data. A fake page won't have any power in that regard.

And on a real permissions page, an attacker won't be able to fake the requesting app's link.

So: legit page + legit link = no phishing ... even though it is by no means a safe situation.


The barrier to setting up a "legit" request for permissions for my phishy app is not that high. Yes, you can't phish for Google passwords that way, but you can get access to all other accounts of a person that are not protected by 2FA and can reset passwords via email.


I consider this grooming by google


I wish the quiz had a fake url bar, that one I got right just out of a pure guess. Without the url bar and just assuming the html is legit, theres no way of really knowing.


Could understand if it was a desktop or mobile email app using the API though.


While the domain is a legit Google domain, I find it ironic that it’s hosted on “withgoogle.com”. If my parents followed my anti-phishing tips they would fail by clicking this link.


It's because google.com contains very valuable cookies which could be leaked if there was an XSS or something anywhere on the google.com domain.

Thats why things like this (which are often developed by third party contractors, and might not go through the same level of review), are hosted on another domain.

It's a flaw in the web though. A domain should have the ability to host content without that content gaining full control over the secrets/cookies of the hosting domain.


If they mark the cookies as http only then that wouldn't be a concern though, for xss attacks anyway. Subdomains would also solve that issue.

https://www.owasp.org/index.php/HttpOnly

Personally I think they separate them out for branding. Things that are on google.com are flagship products, and getting your thing under google.com means you and/or you're project has a lot of clot at Google.


Httponly wouldnt solve the issue - the serverside code also shouldn't be trusted with such cookies. Cookies aren't the only permission either - Google wouldn't want webcam or audio recording permission to be given to a 'withgoogle' site without the users consent either.


withgoogle.com is more of a 'sandbox' for Google one-off programs, labs, events, etc. which don't need to have the same branding guidelines as on google.com domain.


...so?

It's still a phishing vector. Teaching users that sometimes Google throws together half-assed domains encourages them to trust any domain with "google" in it.


Just for example, the following domains are all available:

workingoogle.com labsgoogle.com labsatgoogle.com learngoogle.org learnatgoogle.com youatgoogle.com bygoogle.co securitywithgoogle.com mailatgoogle.com realgoogle.com

etc.


AFAIK they don't have any pages there that allow account login, for that and other security reasons.


Yes, but:

> Create a name and email — neither need to be real — to make this quiz seem more realistic. Don’t worry, this information won’t leave your device.

I'd trust this notice if I knew it came from Google, but since it was placed on a phishy-looking website, it really gave me pause.


That doesn't help the situation much, even if it were true. If a phisher creates a fake Google domain, how many users will go, "Aha! I was about to login using my Google credentials, but then I remembered Google only asks users to login to *.google.com domains, so I know this is an attempted phish!"



Ask Equifax why this is such a terrible idea:

https://www.nytimes.com/2017/09/20/business/equifax-fake-web...


I assumed that I passed the test by not filling out the form


You're supposed to use whatever information you wanted the example phishing e-mails do be directed to. I used "Bob" and "bob@example.com".


I guarantee at least 25% of users used their real name and email.


Google has one billion different domain names that they officially use for user facing features. Why would they register blog.google and use it other than to show off that they have their own tld


I wanted to point out one of the phishing schemes used a google amp link to disguise a URL as being from google..... sigh <insert regular complaint of google amp ruining the web>


My bet is on this site being developed by a google security team to try to embarrass other teams around google to get their act together and close flaws like this.

The concept of AMP for example should have been built into browsers, perhaps as a new protocol, for example:

amp:https://newyorktimes.com

Then the browser can go to any amp-provider to retrieve the amp page, which will be signed by the origin that it came from so the browser can still validate the amp-provider hasn't tampered anything. That model would also let any company be an amp provider with no trust required.

The benefit of AMP is much reduced with QUIC zero-rtt resume anyway.


Or just `amp://nytimes.com`, would make more sense even if it's being sent over https.


A bit annoying that the fact that Dropbox used HTTPS-links are highlighted as a sign of it being legit. I have always suspected such advices makes people think HTTPS are actually somehow magically secure, while it has nothing to do with phishing related issues.


I guess that depends on whether or not MITM is an attack vector that you're concerned about


I missed two: the "allow some random person to read your email" which I would never click on, and the one that had a PDF, even though they don't allow you to do anything with it. Just because someone sends you a PDF doesn't mean it's an attack vector. It would have been more helpful to say something like "this is someone you do business with as well, or someone you've never heard of." (which I find to be more useful signal on if I want to look at an attachment, though even if they are someone I know, do they have a reason to send me that PDF is the second question). Unsolicited attachments are always suspect.


And that's the rub: knowing what's phishing depends on who you are. Receiving a PDF with financial data has a completely different probability of being an attack if you know who the sender is and were expecting them to send such a file today.

Also, assuming that a message is phishing is usually not harmful in any way. If I got an email from dropbox.com (and were a Dropbox customer), I'd ignore the email, and just type "dropbox.com" in my web browser to see what's up. If you're paranoid, you don't need to be super smart about what exactly is phishing.

This isn't a fair test.


This is exactly what I do for any kind of account stuff: never click on the email, always just sign into the website itself and look for the message. I really like the companies that just say "sign in and see a new message" or whatever, rather than, "click on this link."


PDF's especially are pretty low risk. They normally open with the in-chrome PDF viewer, which is sandboxed pretty much as well as web pages, so you would need two zero day exploits (since chrome generally auto-updates within a few days of an axploit being published) in addition to tricking them into opening the PDF to get into someones device.


Same with Firefox. In fact, I rarely open PDFs outside of Firefox, and when I do, it's either in Edge (if I'm on Windows) or Evince (on Linux). I never use Abobe Reader, so there's very little chance that I'll get attacked.

And yes, I failed that question because I assumed that it's information that I was expecting. I don't open PDFs unless I am expecting it, because who wants to spend the time waiting for it to download and render for something that's likely spam?


On the PDF one, it tells you in the "intro" blurb that the sender's email address is wrong. Should be .edu and it's .org.


I don't know if that would be enough in real life for me. I know some organisations use two different domains (e.g. they did a transition but they don't want to turn off .org just in case something still uses it, the IT team forgot that Sam has two Outlook profiles, one is on .org).

And while pdfs can be attack vectors, they're not an especially strong one - it's not like running an exe with administrator privileges.

Comparatively giving a third party access to your emails should definitely raise flags.


They even had a legitimate example, of Dropbox sending an email from dropboxemail.com.

I honestly think this should never be done because users shouldn't be expected to know which domains you do and don't own.


Your first point is definitely correct - their guide is confused at best.

As to your second point, I agree in terms of 'best practices', but in terms of teaching about phishing, the fact is, companies do use multiple domains (and some deliverability guides actively encourage different domains for marketing emails and transactional emails - companies should use subdomains for this, but not all are that savvy).

Given that companies are sending from multiple domains, I think the litmus test for phishing is:

"Is the email trying to get me to give me information? E.g. a login on the wrong site, sending card details or anything like that"

Your pdf reader should allow you to open a pdf without being compromised (just as your browser should allow you to click a dodgy link without being compromised). So I think that item should pass the litmus test (unlike the email reading one).


I took that to be a hint along the lines of "schools should have .edu domains", which is unrealistic; lots of academic institutions use non-.edu domains, for better or worse (in fact, the school district in which I attended uses (DISTRICT).net to this day, and (DISTRICT).edu isn't even registered!).

If that blurb was meant to be taken as "You happen to know that your school only has a .edu domain", then yeah, this would have been conclusively phishing. Otherwise, just because it might be malicious doesn't mean it's phishing.


That's a very US-centric view.


On my phone, I didn't see the TLD, and depending on the type of school, a .org is completely reasonable (e.g. private school). In fact, the types of schools I would be interested in a financial report from would potentially not use a .edu TLD.

And PDFs are mostly harmless if you don't use Adobe Reader, since it's either a small attack vector or in a sandbox.


Ah thanks, I must have missed that. If it's the wrong address then definitely suspect.


The PDF one seemed like a pitch for using Chrome as your PDF viewer.


And they completely failed to mention that Firefox and Edge also have built-in PDF viewers (I don't know about Safari since I don't use it).


And yet if that's what you already normally do you would've "failed" that question for correctly identifying it as not actually phishing.


Hi All,

I posted this here because I think it's great there's some effort being put into free training in this region.

I do however agree with some of the comments here. I had been hunting for something like this to use as our own training, but it won't be this because I don't agree with the TripIt example.

Edit: Maybe there should be a "maybe" or "consider" answer. "This is a legitimate company. However, their desire to access your email is something you should carefully consider".


100% this. I think sometimes people miss the target demographic for something like this. My 70s+ year old dad and mom got phished. This might help them understand why they shouldn't have clicked the link.

A technical solution to security should be sought out as well. This doesn't remove ANY responsibility from companies for having good security.

It does help to empower the less technical users.


Phishing, especially the targeted type, is impossible to combat at scale, and expecting users to know the ins and outs of what's a safe domain (withgoogle.com? Is it safe or not?) or to try to identify legitimate communications is a stupid waste of time.

Long term the solution is ubiquitous hardware-based 2FA, ideally incorporated into the physical devices themselves.


True, but a solution doesn't have to be single sided.

I can easily send this link to my parents and then they know a little more.

Expecting users to know is ridiculous, but offering tools for people to help educate their less tech savvy loved ones is awesome. That's kinda how I see this. It helps me empower my parents a little more.


I agree that it doesn't have to be single-sided, and we need multiple angles to protect against phishing.

This quiz isn't it, though. You and I know what domains are; we know what's possible; we can sense when somethings off. It's our bread and butter. The average user knows none of these things, and giving them a dozen rules to follow that will work a lot of the time is in the end confusing.

A better set of rules to link your parents to is this:

1) Trust nothing over email. If your bank sends you a notification, don't click on the link in your email: just go directly to your bank's website and log in.

2) That's about it.


I’m not even convinced “don’t click links” is the best guidance. That message has been pushed so hard that people immediately think their machine has been compromised once they have clicked a shady link. That is nearly never the case. Clicking links isn’t something that should cause fear. Nobody is burning a modern browser vuln in a spam email. I think the message should be more focused on not manually entering credentials into a site. Lean on your browser to validate domains and know which sites are associated with which credential. I say that somewhat aspirationaly , as I still think there is lots of room for how well browsers and password managers work for novice users.


Agreed that clicking links is usually safe.

My point is, as a broad-based message, as soon as you start saying complicated words like "browser" and "validate domains" and "credential" and "password managers," nontechnical eyes immediately glaze over. I think your advice works for the most technically inclined 25% of users. It just confuses the rest.

"Don't click links," despite having more false positives when used as an individual's safety heuristic, resonates more and thus will result in many fewer false negatives when applied to the general public. The cost of a false positive is relatively low, while the cost of a false negative is high.


Clicking links can be a problem in corporate environments where automatic login has been enabled on Internet Explorer and outbound SMB not blocked.

The phishing site immediately gets their domain ntlm hash, which can often be cracked to gain a password.

This can also be a problem in PDF and Word docs without the need to employ a 0 day. https://resources.infosecinstitute.com/steal-windows-login-c...

Also to note that password managers can help mitigate phishing, as they will not offer to complete passwords if the domain does not match.


Funny considering Google still has a UX vulnerability in their gmail interface: https://eligrey.com/blog/google-inbox-spoofing-vulnerability...

"The link mailto:​”support@paypal.com”​<scam@phisher.example> shows up as “support@paypal.com” in the Google Inbox composition window, visually identical to any email actually sent to PayPal."

It has been fixed in the web version, but apparently the Android app still has this issue


What happened with the Gmail's Authenticated Senders key icon for e-mails from certain high profile sites that properly validate through DMARC? (described e.g. here [0])

[0]: https://www.pcworld.com/article/2921383/software/4-gmail-lab...


I had no idea google allows arbitrary redirects through its own https://google.com domain. Why?


They don't seem to consider open redirects an issue worth mitigating (see https://sites.google.com/site/bughunteruniversity/nonvuln/op...). Though in the example given, they have taken the sensible step of inserting an interstitial warning page, there are known URLs (e.g. https://vagmour.eu/google-open-url-redirection/) that don't use such a page.

Personally, I don't think it's particularly realistic to expect users to be able to work out when an open redirect is being abused in a phishing attack - particularly if e.g. other junk query string parameters are used to obfuscate the destination, or a domain is chosen that looks like it could legitimately be part of a site's URL structure.

Checking the domain gets you some peace of mind (assuming it's not abusing lookalike Unicode characters!) but if there are "reflected" or even "stored" open redirects [1] on the domain then all bets are off. I don't think I could confidently make a decision regarding the safety of such a link except by following it (with e.g. curl -L) and seeing what happened.

[1] I'm abusing XSS terminology here by applying it to redirects, but hopefully the meaning is clear. I consider a "stored open redirect" a page under a user-known-safe domain where an attacker can persist the final destination s.t. it's not visible in the original URL.


Actually, it looks like navigating to the link you're talking about https://google.com/amp/tinyurl.com/y7u8ewlr, or any link beginning with https://google.com/amp/, will first bring you to a redirect confirmation, not immediately redirect you.

(The shortlink above is actually safe - it redirects to https://jigsaw.google.com/)


does anyone know where google documents this?


open redirects have always been a thing.


It says:

  Incorrect!  Not everything is bad.
I think that is mistaken.


LOL One of the phishing examples is a page hosted on Google AMP Cache.


”This one is a little tricky”. No, it's a complete security trainwreck that Google have opted into for no good reason.


Same as people using goo.gl URLs


I missed the one with the PDF attachment, for multiple reasons:

* To my knowledge, there are no extant PDF-based viruses that would affect me (on either Linux or OpenBSD), and just because something's infected with malware doesn't mean it's a phishing attempt (it could be that it's a legitimate email from a sender whose computer is infected with some malware that spreads itself through PDFs).

* The PDF is actually attached, so if this were a real email it would pop up in Gmail's built-in attachment viewer (and any errors occurring there would be more cause for alarm).

* Not all schools use .edu domains at all, let alone exclusively.

All things considered, the question's wrong. It's not conclusively a phishing attempt. It might be some other kind of malicious email, but phishing emails are a subset of malicious emails, not the other way around (just like how all carrots are vegetables but not all vegetables are carrots).


The Tripit one is very problematic. They don’t say that you installed TripIt. I’m supposed to allow any Google third-party access to my email? Even if I didn’t initiate that?

Hovering over the “allow” button doesn’t show anything. They need to reword that one.


I dislike several aspects of this quiz, and think it's actively harmful to users. It's great to train on the URLs, but that's not the only warning sign with these.

---

1) "Hey there. Here is the doc you asked for."

Did you ask for a doc? Do you know this person? If no, these facts alone should be giant warning signs.

---

2) Fax Message from efacks.com

Do you have an account with this service, where you explicitly signed up to receive faxes? If not, obviously you shouldn't be getting faxes from them so it's not legitimate.

---

5) "Please find attached the 2019 financial activity report for your perusal."

Aside from giving away the answer in the title [1], this isn't a good example.

First line of defense, once again: Do you have an account with "Westmount Day School", and are you expecting a "financial activity report"?

Also, spoofing "from" e-mail addresses is a thing, and completely trivial, so relying on that is not a way to verify authenticity.

What's not mentioned is being aware of what PDF reader you're using: eg, do you regularly make sure it's up to date? Personally, I use Chrome as my PDF reader as I'm not a fan of Adobe products or their security track record in general.

Also in my experience, these types of e-mails often come in with an attachment like "2019 F.A.R.pdf.exe" (or a zip file that contains an exe), and not an actual PDF file. This would have been a great way to train users on this point.

---

6) "Someone has your password"

The two reasons that this isn't legitimate are listed as "We don't use google.support to send emails" and "This link points to a subdomain of ml-security.org, not Google." [2]

So once again, spoofing "from" addresses is trivial -- so that is not a security measure. Secondly, how should I know what mail comes from? There was an earlier example of a legitimate message from Dropbox coming from a non-dropbox.com address (dropboxmail.com).

Also, the best defense against this is not mentioned: Never log into sites by clicking on links in e-mails! This includes changing your password. The only exception to this is a password reset mail when you explicitly just asked for a password reset.

---

7) "Government-backed attackers may be trying to steal your password"

Once again, "Change password" link in e-mail. Don't click it.

---

8) Tripit Security prompt [3]

Sorry, but this is a terrible example.

First of all, am I trying to perform some action with Tripit that this prompt is expected? If no, don't allow (in fact, just close the window)

Secondly, what does my browser window show? If you're on google.com (or gmail.com) and this appears, that's one thing, but if your browser is showing google.security-check.se then no, don't click anything and just close the window.

Third, even assuming this is all okay, do you want Tripit to have access to view email messages and settings? If all you were trying to do is use your Google account to authenticate, the fact it wants access to view all your messages is highly suspicious. In this particular case (because it's Tripit, a service that parses your email), this is probably your intention, but if it also asked for other permissions -- such as ability to manage contacts and send messages on your behalf -- you might want to think twice.

---

Training like this is good, but phishing e-mails can be very devious and training users on the wrong things -- such as trusting "from" addresses, not considering context, and not looking at actual attachment types -- is extremely dangerous. In the worst case, it can train users to click on things they otherwise wouldn't have, due to false confidence obtained by (inadequate) training.

[1] https://i.imgur.com/8mNePZS.png

[2] https://i.imgur.com/tpJMb5n.png

[3] https://i.imgur.com/KfNDuZI.png


My read was not "trust From" but more "be distrustful when from does not align". Perhaps users will take the former from this, but my understanding of this exercise was more spotting negatives than spotting positives.


It says PDF is a potential attack vector. Have there been any attacks on Preview.app, since it became sandboxed?


I think its referring to adobe reader which allows PDFs to run arbitrary code as well as 100000 other anti-features.


We'll thankfully they gave us the actionable advice to ”be careful”. What does that even mean?



I was really surprise that they could embed a tinyurl inside a google url. Got 6 / 8.


Wait. So why didn't google just put this on a subdomain? It's a phishing quiz at a phishy domain, and the first thing that happens on iphone is it asks for your name and email (instructions are covered up)


Cool idea confounded by the reality that many many people notice phishing on a quiz who would not notice in ordinary life.


Anyone else think the domain for this seems suspect? Why not just use google.com? This is pretty meta.


withgoogle.com is clearly a phishing domain.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: