So I was listening to the following podcast and it began discussing a question about links inside of emails. I have pasted from the transcribed notes the discussion below. Thanks Steve and Leo for the great podcast.
GIBSON RESEARCH CORPORATION http://www.GRC.com/ SERIES: Security Now! EPISODE: #494 DATE: February 10, 2015 TITLE: Listener Feedback #206 SPEAKERS: Steve Gibson & Leo Laporte SOURCE FILE: http://media.GRC.com/sn/SN-494.mp3 FILE ARCHIVE: http://www.GRC.com/securitynow.htm
"...LEO: Justin Aborn in Boston. He wants to know how to be sure about emailed links. He wants to know how whether to click on them: My bank just emailed me a clickable link. I'm 99.9% sure it's truly them, but I navigate to their site by hand, rather than click on the emailed link. To check the fit of my tinfoil hat, what do you recommend as the minimum procedure to confidently click an emailed URL? It would be a lot more convenient if we could just click on them.
STEVE: Yeah. And I liked this also because in the context of Anthem, as you said, Leo, we're seeing now a big phishing wave of fake email coming out. The only way, I mean, the old-school way is to look at the email headers, which are generally available. But, boy, that's confusing. And headers are highly prone to being spoofed. I think the only thing I could suggest, first of all, is don't. They're just, you know, it's really not worth it. But if you have to, what you need to do is look at the source. That is, you need to be able to examine the source of the email.
The problem is that email today is HTML. And there's what you see is the result of the HTML markup which has created a presentation. And so you can see text that is underlined that says "Click here to email Anthem." Or I don't think he gave an example. Or his bank. And in fact it can even show you http://bankofamerica.com, like with no typos, exactly that URL, except that that's the presentation of the HTML. The markup is in brackets on either side of that, and it's hidden from you, by design, by the browser. By the browser or now, you know, email has become HTML, so your email client is hiding that on purpose to give you a nice, visible, simplified link to click on.
So it's only by looking at the source that you can verify the actual URL that you're going to click on, if you did. And you might very well see that http://www.bankofamerica.com inside of brackets where on the left-hand side there is http://fakebankofamericawebsite.com, which is the actual URL that you will visit if you click that link. It's only by looking at the source that you can know. And the other problem is scripting gets involved, too, because there could be an on-click phrase, even if the href, as it's called, is correct. If there was an on-click, it turns out the JavaScript gets invoked before the href in the link is visited.
I just was dealing with all of this, as it happens, because I've added automation to the SQRL demo so that when you authenticate with a client the web page, the SQRL demo web page immediately, instantly updates itself to show you that you're now logged in. So I was visiting all this. And the JavaScript is invoked first. And that could be in an included library that you don't even see. So, boy. Unfortunately, the bad guys have a real advantage here. And I hope maybe I've made the case for my first recommendation, which is don't, because...
LEO: So a number of people in the chatroom are saying in some email clients, if, for instance, you hover your mouse over the - the real problem is that the presentation layer is HTML. That hides what the actual link is, even if it looks like it's a link, as you said. But if you hover your mouse over that, can you capture on hover in JavaScript and prevent the status line from showing the actual URL? Or am I going to see the actual URL in the status line at that point?
STEVE: Whether it was in the status line, or sometimes it comes up as a little toolkit right there.
LEO: As a toolkit, right.
STEVE: Right. Unfortunately, that will show you the static href, not the on-click call.
LEO: On-click.
STEVE: Yes.
LEO: And that's what you're going to go to is what happens when you click.
STEVE: Yes.
LEO: So it can actually be so obfuscated that it's in JavaScript.
STEVE: Even that, right.
LEO: And you can, you know, you say, well, view source. But even then the JavaScript could be further obfuscated.
STEVE: Oh, yeah.
LEO: You wouldn't see anything that says HTTP. You might see just nonsense.
STEVE: Yeah.
LEO: Wow. So hovering is not going to do it.
STEVE: Not even that.
LEO: You really just shouldn't. You should, I guess, what you should do is manually go to the website, by hand enter the URL.
STEVE: I really think, yes, in fact, I think that that's...
LEO: So right-click, copy, and paste isn't going to do it, either.
STEVE: Nope. It won't because you're actually, you're going to execute code as a result of clicking on that.
LEO: Wow.
STEVE: Yeah.
LEO: Isn't that amazing. That's great. That's - I think, frankly, turn off HTML email, period. It shouldn't be allowed. It's a bad idea.
STEVE: And scripting in email. I mean, how much malware has crawled into people's machines from email scripting?
LEO: Yeah, yeah, yeah. A good email client will not do HTML. Unfortunately, most of us now use web browsers to do email.
STEVE: Right.
LEO: Which means you're screwed.
STEVE: Right. Basically you are...
LEO: Don't click that link.
STEVE: You're receiving a web page from someone you have no control over, you don't know who they are, they're claiming to be somebody who is working in your benefit. The best advice, and I don't remember where it originated, if it was from Brian Krebs or someone else, but I loved it, and we've discussed it here through the years, and that is never do something that you didn't go in search of. If a popup says, oh, you need to update your Flash Player, no. If you weren't going, if you didn't have some reason to go looking to update your Flash Player, don't accept an offer to do so. You just can't do that safely..."
I completely understand the impact that javascript can have on a webpage and how it can manipulate html elements. I find that Outlook, Outlook Web Access and many other clients block scripting in the email client.
Below is a quick proof-of-concept showing an HTML page that has a link with an onclick event that will manipulate the link as it is clicked. If it was in an html page by itself the link would be manipulated and take you to google.com verses grc.com. So for this example I emailed the page to myself.
I used php and an email relay to send the message with the link to my Outlook client. Then the email showed up and I was able to click the link, however, due to the way outlook renders the HTML email the script tag and the onclick element is not recognized.
As more research can be done certain HTML is blocked because of the way mail clients render the html. http://www.outlook-apps.com/html-ignored-by-outlook/
Another issue with webmail clients is the way they will redirect to links. This makes it more difficult to see where you are actually going. For example here is the screenshot of the above email opened in outlook web access. As you hover over the link it is somewhat masqueraded by the mail client itself.
While we are discussing issues. On mobile devices as you hover over links they do not give an indication of where they are going before you click on them. Again emphasizing your point of not clicking on links in emails.
As I have told people not to click on links in emails, the user then returns to his computer and looks at his emails and notices 80% or more have links inside of them, most of which they need to conduct business.
What is the best strategy to educate people to not click on links? Is that even a strategy?
I have found educating people about phishing emails is a layered approach containing but not limited to the following steps:
1. Consider who the email is from, is it someone you know.
2. What is the content of the email?
3. Are you expecting the email
4. Is the information in the email expected from the source you received it?
5. If the information is important can I call or text them as an out-of-band authentication of the email
6. Is the grammar in the email expected.
7. Showing them phishing emails and what to look for.
8. Test, Test, and Retest phishing employees to verify they understand the concepts you are teaching and enforcing.
A few thoughts that I had on the podcast as I listened to the last question and answer session.
No comments:
Post a Comment