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.
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 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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 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?
Can somebody explain to me how a PDF opened in, say your OS's default PDF viewer, could be harmful? Aside from you acting on some misinformation within it.
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.
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.
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.
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.
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!"
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
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.
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.
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:
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.
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.
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.
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.
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.
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.
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 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
I missed only the .org instead of .edu (was thinking the establishment have the two domain name)
As for the TripIt we may don’t have the same definition of fishing
As the mail was a ligitime mail from google to request access to my account from an app (and that’s what’s about the quizz) as for if did I used that app or now that’s another story
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).
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)
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.
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])
102 comments
[ 2.9 ms ] story [ 151 ms ] threadPersonally, 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/)
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-...
[3] https://plaid.com/
[4] https://plaid.com/products/
[5] https://plaid.com/products/income
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!
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?
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:
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.
---
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] _asummers ↗ 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. [dead] khacking ↗ > 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.
Agreed. They also would be giant warning signs to the most non-tehcnical users. Quiz could definitely have included more context.
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
As for the TripIt we may don’t have the same definition of fishing
As the mail was a ligitime mail from google to request access to my account from an app (and that’s what’s about the quizz) as for if did I used that app or now that’s another story
* 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.
[0]: https://www.pcworld.com/article/2921383/software/4-gmail-lab...