Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Evernote: Doing it (mostly) right

(Update: See here for more information about what they did wrong, including a vulnerability I found in the password handling of the Android app.)

So the big news today is Evernote being popped; with 50m users and user base that often stores sensitive material – it certainly is a tempting target for many reasons.

CNET was able to get a quote from Evernote on the issue, providing some extra insight compared to what’s in their announcement:

Our operations and security team caught this at what we believe to be the beginning stages of a sophisticated attack. They are continuing to investigate the details. We believe this activity follows a similar pattern of the many high profile attacks on other Internet-based companies that have taken place over the last several weeks. Evernote Representative, CNET

But there’s plenty being written about the hack – what I’m more interested in is the response. Let’s take a look at what’s happened (publicly, at least):

Feb 28th: Evernote’s Operations & Security team notices potentially malicious activity.

This Morning: User’s started noticing that the client stopped syncing, complaining of a password issue. If a user logs into the web interface, they are prompted to set a new password.

10:57AM EST: Evernote posted a blog post and linked to it on Twitter (see above); within a few minutes their blog was returning a database connection error. Later visiting the blog returned a maintenance page, a database error, or a 503 error.

11:57AM EST: Evernote posted a new link and redirected the original blog post.

1:45PM EST: Received email notifying of incident and password reset. As this email was sent to ~50m users, it’s to be expected that there’s a large window during which users received it.

What’s not happened yet: Despite several requests from different people, they have yet to release any technical information on how the passwords were stored, beyond that they were hashed & salted.

What’s Right & What’s Wrong #

Two days from finding issue to notifying users – I’ve seen some people complain about this delay, but given that the priority is stopping the attack first, and the need to capture evidence as quickly as possible to give the best chance of understanding just what happened – I’d call this quite reasonable. Compared to some other companies that waited weeks or even months, I’d say they got this one right.

User notification – This is a hard one, on one hand you have the need to secure accounts as soon as possible while on the other, is letting users know why they are being required to change their password. I wish they had been able to get the email notification out sooner, but it was more important that they secure the accounts.

Because of the delay in notifying users, it’s possible for some users to change their password and go on with their day without knowing why they needed to change the password – or that if they use that same password elsewhere it needs to be changed there as well. They should have made what happened clear when changing the password.

Now, the email itself deserves to be called out – it’s known that the email addresses where in the stolen data, so emails claiming to be from Evernote require an extra look to make sure they aren’t phishing. Evernote, to add to the confusion, made a huge mistake: the links in the email don’t go to evernote.com – they go to links.evernote.mkt5371.com/ctt?.... That raises a few red flags…

The blog post – I love WordPress, but it’s not always the best choice when you are expecting lots of traffic. They really should have hosted the notice from a static page from the beginning instead of trying to keep WordPress up under that much pressure.

The password reset process – To reset the password, all you had to do was login with the existing password to the web site – the same password that was just stolen. No proof of identity at all. If the attackers were able to crack the hashed passwords, they could easily change the password themselves and access the account.

This really should have been done better.

Disclosing technical details of password storage – As I stated above, this hasn’t happened despite numerous requests. While researchers need to know this to understand the risks of the passwords being cracked, unfortunately it’s possible that this information could help the attackers if they weren’t able to acquire source code that reveals the inner workings of their password handling.

For example, if the attack vector was SQL injection, it’s possible to exfiltrate the data without being able to get to code.

Overall #

It seems that they have handled this responsibly as possible; this isn’t the kind of event anybody is truly prepared for. Could it have been done better? Yes, in a few ways – but they could have done so much worse.

It could be argued that in the grand scheme, they don’t care about security – from my experience, that’s the impression I’ve gotten.

Adam Caudill

Related Posts

  • Threat Modeling for Applications

    Whether you are running a bug bounty, or just want a useful way to classify the severity of security issues, it’s important to have a threat-model for your application. There are many different types of attackers, with different capabilities. If you haven’t defined the attackers you are concerned about, and how you deal with them – you can’t accurately define just how critical an issue is. There are many different views on threat models; I’m going to talk about a simple form that’s quick and easy to define.

  • 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.

  • Irrational Attribution: APT3.14159

    Note: This is satire / fiction; well, more or less – probably more more than less. Any resemblance to real companies, living or dead, is purely coincidental. WASHINGTON, D.C — Unnamed White House officials that spoke on the condition of anonymity, have stated that a major American company has been hacked, and the attackers are threatening to release terabytes of proprietary information. The name of the company has not been released at this time.

  • Logseq: My External Brain

    Over the years I’ve used most of the major note taking tools around, I’ve been a paying customer of Evernote for over a decade, I’ve used Standard Notes, Good Notes, pen & paper, and a bunch of others I can’t recall now. They were never quite right for my needs — some were close, but none were what I was after. One of the major challenges was that I didn’t know what I needed, and it’s hard to find something when you don’t know what you’re looking for.