Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Evernote for Windows, Arbitrary File Download via Update

Update: The Evernote security has reported that this issue is resolved.

Evernote for Windows downloads its update information via HTTP, making it subject to man-in-the-middle attacks – further, this allows an attacker to specify an arbitrary file for the updater to download. The good news is that Evernote will not execute the file thanks to signature validation – but the file isn’t removed, so it’s available for later use.

As the file isn’t executed, it isn’t a critical issue.

The update.xml (and the related release notes HTML file) is served over HTTP, not HTTPS; this allows an attacker to control the content of the file. This allows an attacker to indicate that there is an update, and provide a malicious file that the user will download; as the attacker can also control the release notes, the attacker can use that to encourage the user to upgrade (i.e. indicate that it’s a required update).

Evernote will download the file and save it to the C:\Users\<user>\AppData\Local\Evernote\Evernote\AutoUpdate directory, assuming that the malicious binary isn’t signed, the user will be alerted that Evernote was “Unable to download the update” – but the file is left in the above directory.


If combined with another issue, it may allow an attacker to gain additional access. This could also be used to plant a file on a victim’s machine (illegal content, false evidence, etc.).

13:37:12 [36468] Command line: "C:\Program Files (x86)\Evernote\Evernote\Evernote.exe"
13:37:21 [33800] AutoUpdate: checking for update at:
13:37:21 [33800] Received status code 200 when accessing URL
13:37:21 [33800] AutoUpdate: located update with revision 999999 (local revision is 269614)
13:37:21 [33800] AutoUpdate: selected update with revision 999999
13:37:21 [33800] Received status code 200 when accessing URL
13:37:21 [33800] Evernote is installed PerMachine.
13:37:21 [33800] User is  an administrator
13:37:24 [34508] Received status code 200 when accessing URL
13:37:24 [34508] The update file (C:\Users\&lt;user&gt;\AppData\Local\Evernote\Evernote\AutoUpdate\test.exe) has invalid signature (File has no signature)

13:37:25 [35944] Unable to download update: The data is invalid. (13).

Adam Caudill

Related Posts

  • Evernote: XOR & Passwords

    Update: Evernote has reported that this issue has been addressed. Evernote for Android stores various settings in an XML, this file though isn’t really protected – it’s easily readable, especially if an attacker is able to get physical access to a device, what’s worse is that it contains the user’s credentials. /data/data/com.evernote/shared_prefs/com.evernote_preferences.xml The username in located in the <string name="username"> element, and the password is stored in <string name="encrypted_password"> – from the name you’d assume that the password is actually encrypted.

  • PL/SQL Developer: HTTP to Command Execution

    While looking into PL/SQL Developer – a very popular tool for working with Oracle databases, to see how it encrypts passwords I noticed something interesting. When testing Windows applications, I make it a habit to have Fiddler running, to see if there is any interesting traffic – and in this case, there certainly was. PL/SQL Developer has an update mechanism which retrieves a file containing information about available updates to PL/SQL Developer and other components; this file is retrieved via HTTP, meaning that an attacker in a privileged network position could modify this file.

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

  • First, Do No Harm: Developers & Bad APIs

    Primum non nocere (first, do no harm) – an iconic phrase in modern medicine, yet also applicable to many other fields. This is something I wish more people would think about, developers especially – and primarily when writing new APIs. In general, developers don’t have an impressive history with security – quite frankly, developers suck. Seeing as I consider myself a developer, that’s painful to admit. Chris Andrè Dale posted an interesting article some time ago that got me thinking: Why it’s easy being a hacker: A SQL injection case study – Chris pointed out the problems with educational material that developers are using, and just how bad the examples are.

  • 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. Important: Evernote just implemented a service-wide password reset. Please read our post for details and instructions http://t.