Google Phishing Quiz
phishingquiz.withgoogle.com
phishingquiz.withgoogle.com
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.
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?
The TLD of the context was .EDU and the one from the email was a .ORG.
I'm no oauth expert, but I would imagine an app would go through a flow like this.
(But personal ones? Go for it...)
- 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.
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.
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.
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-...
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.
[_] phishing
[_] legit
[X] legit, but there's no chance I will accept that!
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.
workingoogle.com labsgoogle.com labsatgoogle.com learngoogle.org learnatgoogle.com youatgoogle.com bygoogle.co securitywithgoogle.com mailatgoogle.com realgoogle.com
etc.
> 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.
https://www.nytimes.com/2017/09/20/business/equifax-fake-web...
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.
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.
The concept of AMP for example should have been built into browsers, perhaps as a new protocol, for example:
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.
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.
I honestly think this should never be done because users shouldn't be expected to know which domains you do and don't own.
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).
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.
And PDFs are mostly harmless if you don't use Adobe Reader, since it's either a small attack vector or in a sandbox.
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.
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?
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".
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.
Long term the solution is ubiquitous hardware-based 2FA, ideally incorporated into the physical devices themselves.
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.
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.
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.
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.
"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
[0]: https://www.pcworld.com/article/2921383/software/4-gmail-lab...
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.
(The shortlink above is actually safe - it redirects to https://jigsaw.google.com/)
Incorrect! Not everything is bad.
* 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).
Hovering over the “allow” button doesn’t show anything. They need to reword that one.
---
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