Phishing with Forged Links

TL;DR version: Sophisticated phishing attacks can be hard to detect for most. As software developers, we need to build better detection, prevention, and countermeasures into apps and services that relay and present these messages so users will be less likely to fall victim to them.

The Onion is a satirical news web site that looks like a legitimate news company. They make their living at spoofing the real news. So, they should be keenly aware of the fact that things aren’t always as they seem.

Well, recently, their Twitter account was hacked. Compromised by the “Syrian Electronic Army”. And now you can read about how they did it. The Onion’s tech team published an article about it: How the Syrian Electronic Army Hacked The Onion. Go read that now to get some context for what follows.

In short, it was a targeted attack. An email that was baiting the writers at The Onion to come and see an article about their organization. And look— it’s on The Washington Post! How exciting. The text of the link was an address that pointed to “http://washingtonpost.com/…”, but the link itself pointed to another site entirely. I’ve come to call that kind of link a “forged link”; a fraudulent and deceptive hyperlink. The phrase also works in the sense that such a link is deliberately crafted to deceive.

How Forged Links Work

Stepping back a bit, for those that don’t understand how that works. An email message can be like a web page, where most anything in the email can be linked to a web site. Could be text, could be an image, or even white space. So, an address to something, like my own web site would be like this:

http://bradchoate.com/

But see how it isn’t linked? It looks like an address, and it is, but unless it’s written this way, it won’t be usable:

<a href="http://bradchoate.com/">http://bradchoate.com/</a>

This is the HTML representation of a link, and this is how they’re written, but the bits in-between the < and > symbols are hidden from view when reading a web site or email message, since those are instructions to the computer; not really something for a human to read. But that was me being honest. What if I wrote this instead?

<a href="http://reallybadwebsite.com/">http://bradchoate.com/</a>

and remember, you don’t get to see it that way in the actual email message. You’d see it like this:

http://bradchoate.com/

Now then— the link to my site is still shown, and now it’s underlined, which means you can click on it. But, where you go when you click on it is somewhere altogether different. That’s how the forged link works. The link that the unsuspecting recipient at The Onion clicked on did not take them to “washingtonpost.com”, but instead, to a different web site that looked very much like a Google.com account login page. When that happened, it should have sent off alarms in the mind of the user— “why did that happen?”. But instead… at least for one or two that got this far… they entered their Google credentials and unknowingly sent them to their attacker. And, after sending the login information, they were simply passed over to their actual Gmail account, which probably displayed their email since they were likely still logged into Google.

Okay, Blame the User, Right?

The tech guys at The Onion give some advice on how to protect yourself from this kind of attack. But these recommendations put all the onus on the end-users:

  • “Make sure your users are educated…” Right off the bat— “the user was wrong, so teach them not to do that!”. Well, good luck with teaching everybody.
  • “The email addresses for your Twitter accounts should be on a system that is isolated…” Okay, so if we can’t avoid these attacks, might as well put their target a little further out of reach.
  • “All Twitter activity should go through an app of some kind…” Sure, cause nobody would ever attempt to obtain your HootSuite credentials.
  • “If possible, have a way to reach out to all of your users outside of their organizational email.” Not really anything preventative here, just disaster recovery planning.

Well, I prefer to place more blame on everyone else.

Antispam/Antiphishing Filters Failed

The fact that this email included a forged link like this and was not flagged in some way is frustrating. Computers are great at spotting a discrepancy like this— especially for pure-text links— and they should be helping us to be safe.

Of course, it could have been an image of a link to washingtonpost.com that was linked the bad web site. In that case, it may be necessary to use text recognition on images that are linked to see if they’re misdirecting.

The User’s Email Client (Gmail, Apple Mail, Outlook, etc.) Failed

If the message did reach the inbox, it should be flagged in a way to identify the forged link, and the fact that this is coming from a stranger (someone that has no correspondence history) and as such, links clicked on should be programatically and visually verified.

A programmatic verification would check the domain of the link against a database of known risky web sites.

A visual verification would involve (at a minimum) showing the user the actual link they’re about to visit. But it could also display a screenshot of the web page so they can see where they are about to go in a safe way before they actually visit the site.

Currently, some email apps offer some visual verification in the sense that if you put your mouse pointer on top of a link and hold there for a second or two, it will reveal the link address in a “tip” window. That’s cute, but not good enough.

The User’s Web Browser Failed

The user’s web browser allowed them to enter sensitive information (data into a password field) on a site they’ve never done that on before. The user should be warned— even before the keypress registers in the password field— that they are about to do something potentially risky. Something akin to this, but generalized for any untrusted web site asking for a login (and doesn’t call you an idiot, ideally).

And again, the web browser could check the domain against a database of risky sites (including all of these free web hosting services, God bless ‘em). A stronger warning should be given if the user is trying to enter sensitive information on a web site without a secure connection. These types of attacks rarely ever use a secure web site, since that requires money and creates a paper trail that can be followed.

We Can Do Better Than This

To sum up, there are many gaps to be filled in here. As software developers, we have to stop telling people that they are to blame for falling for these tricks. Let’s at least give them some better tools to arm themselves against the “Syrian Electronic Army” and other hackers out there.

About

This article was published on May 9, 2013 8:17 AM.

The article previously posted was Re: unauthorized access.

The next article is Google Island.

Many more can be found on the home page or by looking through the archives.

Powered by Movable Type