Hacker News Reader

Comment by escobar | Hacker News Reader

So this looks like HR or someone from inside snapchat got a phishing email and happily obliged and sent off a bunch of sensitive information without confirming that it should all be shipped over (unsecure) email.

I do work for some higher ed institutions, and almost every year without fail we have seen (and dealt with) successful phish attempts of various staff members... it's usually something small like a credit card number, but it still amazes me how an email that may look "very suspicious" to me doesn't set of a flag for someone else who isn't really thinking about this type of attack.

View on HN

Social engineering attacks will probably be a thorn in security's side for a very long time, if not indefinitely... There's a sort of fundamental disconnect inherent in "Trust the system! It's secure! Except be careful because sometimes something that is not the system will pretend to be the system..."

We keep treating falling for phishing emails as a user error. But, perhaps, having our most "official" means of communicating online (email) be a protocol that has no identity verification, no authentication and no encryption, is actually a technical bug, not a human one.

I mean, you would expect that we should at least be able to tell that if you get a x@snapchat.com email in your y@snapchat.com inbox, it actually came from x who works at Snapchat. However, that is (in general), not how email works, for some reason (yes, I know, ancient protocol, tons of stakeholders, identity is hard, but come on...).

I thought we had this through SPF. Ie. Your mail server can reject mail if the domain doesn't match spf records in dns.

Maybe it's time to start something like an SPF Everywhere campaign.

SPF Everywhere would be a start. But, as currently deployed, at least, SPF is nowhere near enough. I do research in security, and even I often have no clue, when faced with a new corporate email system, whether the email addresses I see can or can't be forged, depending on domain.

Hell, if I get bob@company.com on my Gmail inbox, I cannot really tell whether even the @company.com part has been authenticated or not. There isn't even an HTTPS like lock icon or anything, let alone a "Google has verified that this email comes from Amazon.com" assurance.

SPF doesn't really do anything to prevent this. It can only protect the return path address, the scammer is free to use whatever From and Reply-To headers they like in the email itself - they don't really care if a bounce goes to the wrong place.

DMARC protects the From header, but isn't widely deployed.

In fact in my experience 99% of users are unaware that anyone can post an email on behalf of someone else's email address, even users under 30.

Of course, because, well, unless you know the whole story of email, down to knowing what SMTP is, there is zero reason to expect that the from address of your email client lies to you. Which is also why all web traffic should be over TLS, because the same can be said of domain names. This is one area of security where our systems really should be made to match the user's expectation, and not the other way around. This is not a "grampa doesn't understand the interwebs" sort of issue, this is clearly broken design.

Non-envelope headers on emails are arbitrary. "From" (as opposed to Envelope-From) is one of these. Some mail clients looking at you, Outlook) just display the minimum amount of data including From, and make it non-obvious that this is not really where the mail was from. You only see this difference in address when you hit reply.

We had a phishing attack on an employee in accounting that was stopped in progress and just in time before a bank transfer took place. The emails in question passed SPF as they weren't actually from another user in our domain.

Adopt PGP signatures as a requirement on emails that include sensitive data. It should be easy enough to have an internal key server and a company key that counter signs all valid company keys. Require the key only be used for signing and kept on a usb stick.

S/MIME and X.509 is a lot more common than PGP signatures -- support for it is built in to most MUAs. Also, typically the keys are on smartcards rather than USB devices where the private key could be accessed.

Or just buy everyone in your company a yubikey that is already set up and ready to go?

I'd even argue that social engineering has been the primary security problem since the birth of the internet.

Much before the Internet.

But how could you be social before the internet?

Sending requests by mail with official looking letterheads for example.

Or fake invoices. I get them regularly.

Phone calls too

http://consumerist.com/2016/02/04/arizona-wendys-jack-in-the...

An unknown person told the manager on the phone that they were with the fire department and needed to conduct a diagnostic test on the fire system, police said. The manager followed instructions and turned on the restaurant’s fire suppression system. The caller then said what the manager had done had caused a gas leak, so everyone had to evacuate the restaurant and the employee was told to break all the windows to avoid an explosion.

Wendy’s employees complied and smashed every single window, while waiting for the fire department to show up. Once officials arrived, they confirmed the call was a hoax.

This got to the point where I actually tossed a real invoice thinking it was a fake one... That lesson cost me 40 euros in extra fees.

Ask Frank Abagnale Jr. That was ten years before even ARPANET.

I have seen so many stores of this on reddit. People's HR departments sending sensitive information to random phishing emails. It seems a little ridiculous that we're still trusting these people with our data.

Honestly, given that you can send these kinds of emails out to like 100 people at a time, i'd be more surprised if it didn't work at least once.

Reply on news.ycombinator.com