Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Linode: Another Breach Notification Gone Wrong

Last night I received an email from Linode about a possible breach and mandatory password reset that reminded me of another recent email, in some disturbing ways.

Dear Linode customer,

Linode administrators have discovered and blocked suspicious activity on the Linode network.

Not too long ago, I received a similar email from Evernote – not just in it’s text, but in the errors made.

Dear Evernote user,

Evernote’s Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service.

When I received the email from Evernote, I quickly noticed that the links were to a different site – was it a thinly veiled phishing attempt? With all the links going to links.evernote.mkt5371.com it took a few minutes to work out that the email was actually legitimate. Instead of being able to quickly reset passwords, users were forced to try to figure out if the email was real or not.

When you are sending out a breach notification, it’s critical that users are able to verify, as quickly as possible, that an email is legitimate, and the the call to action really is necessary. Linode, unfortunately, made a similar mistake.

The first thing that jumps out is that it’s from e2ma.net – not Linode directly, next is that the first link in the email points to e2.ma/message/.... These are immediate red flags, the focus instantly switches from taking necessary action to secure a user’s account to trying to figure out if they are being attacked. From comments on their blog post, I’m not the only one that was disturbed by how the email was sent.

Thankfully, they didn’t include a link to the password reset page, and they even told users not to click reset links in unsolicited emails – so it’s not all bad. Users shouldn’t be spending time trying to figure out if a notice is real instead of taking steps to secure their accounts. In situations where there may be a significant security issue, service providers should take every effort to minimize confusion – provide clear information, and make the source as clear as possible.

Adam Caudill

Related Posts

  • Security Done Wrong: Leaky FTP Server

    Update: I’ve just spoken to AMI, and received some very important information; so here are the key points and clarifications: To clarify, the ‘vendor’ I refer to is a customer of AMI; it is this customer’s public FTP server that exposed this information. Per AMI, the signing key included in the ‘Ivy Bridge’ archive is a default test key; AMI instructs customers to change the key before building for a production environment.

  • LinkedIn: The Breach That Isn't but Is

    The definition of a data breach seems to be reasonably straightforward and easy to understand — but that isn’t always the case. LinkedIn is back in the news thanks to a dataset containing profile information for 700 million records being traded among the darker actors on the internet. But LinkedIn is very clear about how they view this situation: This was not a LinkedIn data breach and our investigation has determined that no private LinkedIn member data was exposed.

  • Verizon Hum Leaking Credentials

    or, Christmas Infosec Insanity… A friend mentioned Hum by Verizon, a product that I hadn’t heard of but quickly caught my attention – both from a “here’s a privacy nightmare” perspective, and “I might actually use that” perspective. While looking at the site, I decided to take a look at the source code for the shopping page – what I saw was rather unexpected. Near the top is a large block of JSON assigned to an otherwise unused variable named phpvars – included was some validation code, a number of URLs, some HTML, and the like.

  • Juniper, Backdoors, and Code Reviews

    Researchers are still working to understand the impact of the Juniper incident – the details of how the VPN traffic decryption backdoor are still not fully understood. That such devastating backdoors could make it in to such a security-critical product, and remain for years undetected has shocked many (and pushed many others deeper into their cynicism). There are though, some questions that are far more important in the long run:

  • Much ado about Juniper

    Since this was published, more detailed information has become available: analysis of the SSH backdoor, the VPN backdoor, and the cryptography of the VPN backdoor. If you want a more detailed understanding of what was done, please take a moment to read these pages. The news is tearing through the information security community – Juniper seems to be on the lips of everyone now, let’s take a quick look at the information available: