Tags: phishing

Spear phishing with Slackbot for fun and profit – Eric Bailey

Sneaky social engineering in Slack.

Last month I wrote some musings on default browser behaviours. When it comes to all the tasks that browsers do for us, the most fundamental is taking a URL, fetching its contents and giving us the results. As part of that process, browsers also show us the URL of the page currently loaded in a tab or window.

But even at this fundamental level, there are some differences from browser to browser.

Safari only shows you the domain name—and any subdomain names—by default. It looks like nice and tidy, but it obfuscates what page you’re on (until you click on the domain name). This is bad.

Chrome shows you the full URL, nice and straightforward. This is neutral.

Firefox, like Chrome, shows you the full URL, but with a subtle difference. The important part of the URL—usually the domain name—is subtly highlighted in a darker shade of grey. This is good.

The reason I say that what it highlights is usually the domain name is because what it actually highlights is eTLD+1.

The what now?

Well, if you’re looking at a page on adactio.com, that’s the important bit. But what if you’re looking at a page on adactio.github.io? The domain name is important, but so is the subdomain.

It turns out there’s a list out there of which sites and top level domains allow registrations like this. This is the list that Firefox is using for its shading behaviour in displaying URLs.

Safari, by the way, does not use this list. These URLs are displayed identically in Safari, the phisherman’s friend:

• example.com
• example.github.io
• github.example.com

Whereas Firefox displays them as:

• example.com
• example.github.io
• github.example.com

I learned all this from Jake on a recent edition of HTTP 203. Nicolas Hoizey has writen a nice little summary.

Jake acknowledges that what Apple is doing is shi… suboptimal, what Firefox is doing is good, and then puts forward an idea for what Chrome could do. (But please note that this is Jake’s personal opinion; not an official proposal from the Chrome team.)

There’s some prior art here. It used to be that, if your SSL certificate included extended validation, the name would be shown in green next to the padlock symbol. So while my website—which uses regular SSL from Let’s Encrypt—would just have a padlock, Medium—which uses EV SSL—would have a padlock and the text “A Medium Corporation”.

Extended validation wasn’t quite the bulletproof verification it was cracked up to be. So browsers don’t use that interface pattern any more.

Jake suggests repurposing this pattern for all URLs. Pull out the important bit—eTLD+1—and show it next to the padlock.

I like this. The full URL is still displayed. This proposal is more of an incremental change. An enhancement that is applied progressively, if you will.

I also like that it builds on existing interface patterns—Firefox’s URL treatment and the deprecated treatment of EV certs. In fact, I think the first step for Chrome should be to match Firefox’s current behaviour, and then go further with something like Jake’s proposal.

This kind of gradual change was exactly what Chrome did with displaying https and http domains.

Jake mentions this in the video

We’ve already seen that you have to take small steps here, like we did with the https change.

There’s a fascinating episode of the Freakonomics podcast called In Praise of Incrementalism. I’ve huffduffed it.

I’m a great believer in the HTML design principle, Evolution Not Revolution:

It is better to evolve an existing design rather than throwing it away.

I’d love to see Chrome take the first steps to Jake’s proposal by following Firefox’s lead.

Then again, I’d love it if Chrome followed Firefox’s lead in implementing subgrid.

Security Checklist

Exactly what it sounds like: a checklist of measures you can take to protect yourself.

Most of these require a certain level of tech-savviness, which is a real shame. On the other hand, some of them are entirely about awareness.

Google AMP - A 70% drop in our conversion rate. - Rockstar Coders

Google hijacking and hosting your AMP pages (in order to pre-render them) is pretty terrible for user experience and security:

I’m trying to establish my company as a legitimate business that can be trusted by a stranger to build software for them. Having google.com reeks of a phishing scam or fly by night operation that couldn’t afford their own domain.

We need more phishing sites on HTTPS!

All the books, Montag.

If we want a 100% encrypted web then we need to encrypt all sites, despite whether or not you agree with what they do/say/sell/etc… 100% is 100% and it includes the ‘bad guys’ too.

Extended Validation is Broken

How a certificate with extended validation makes it easier to phish. But I think the title could be amended—here’s what’s really broken:

On Safari, the URL is completely hidden! This means the attacker does not even need to register a convincing phishing domain. They can register anything, and Safari will happily cover it with a nice green bar.

Phishing with Unicode Domains - Xudong Zheng

Domains registered with punycode names (and then given TLS certificates) are worryingly indistinguishable from their ASCII counterparts.

Can you spot the difference between the URLs https://adactio.com and https://аdаctіо.com?

PushCrew Push Notifications for HTTP websites

A nasty service that Harry noticed in his role as chronicler of dark patterns—this exploits the way that browser permissions are presented below the line of death.

Certified Malice – text/plain

Following from that great post about the “zone of death” in browsers, Eric Law looks at security and trust in a world where certificates are free and easily available …even to the bad guys.

The Line of Death – text/plain

A thoroughly fascinating look at which parts of a browser’s interface are available to prevent phishing attacks, and which parts are available to enable phishing attacks. It’s like trench warfare for pixels.

Twitter Status - Phishing scam

And this, boys and girls, is why the password anti-pattern is bad, m'kay?

Maybe the effort we go to as we think about the... · Ben Ward's Scattered Mind

"Facebook has rolled out an identity system — Facebook Connect — with a slick UI that trains a gazillion tech-naïve users to slap their identity credentials into any old website."

FatBusinessman.com : On Authentication

David has written an excellent comparison of the two differing mindsets when approaching online authentication. In no uncertain terms, OAuth (or an OAuth style authentication) is right and the password anti-pattern is wrong, wrong, wrong.

bunnyhero dev » Scaring people with fullScreen

Fullscreen mode for Flash movies could be used to totally freak people out. Here's how.

disambiguity - » Design Ethics - Encouraging responsible behaviour

Leisa joins in on the password anti-pattern. As she says, this is a question of ethics. I've already made my position clear to my colleagues and clients. Have you?