2018-07-19

It seems that newer versions of Jaxx use leveldb instead of the old sqlite format databases. The pin can still by quite easily extracted, as shown by the LinkedIn article, but I don’t yet know if the 12-word phrase can also still be extracted.

If I can make some time, my plan would be to use something like leveldb-json to dump the contents of the leveldb file, and then to analyse that for extraction possibilities.

2017-08-08 18:42 UTC

I have added the exact filesystem locations / paths to the relevant Jaxx local storage file to the demonstration section.

2017-06-20 07:51 UTC

Since the first publication of this post, Jaxx has publically stated several times that storing our wallets unsecurely is not a problem.

If that is indeed the case, why do all other reputable desktop wallets perform this encryption in the correct manner, thus safeguarding our wallets, and only Jaxx does not?

(Jaxx “encrypts” the wallet seed, but with a hard-coded and easily extracted key, which means this is not encryption but rather obfuscation, which is not much better than no encryption.)

2017-06-13 10:14 UTC

Reader Imed reports in the comments below that the 4-digit user PIN is stored as an unsalted sha256 hash, which can easily be reversed using rainbow tables, for example via sites like CrackStation.

I have just confirmed with a test Jaxx installation that I am able to extract a configured PIN from the local storage database without Jaxx running of course.

2017-06-11 10:08 UTC

Daira Hopwood correctly points out in the comments that encrypting using the PIN would be too easily brute-forced. I have updated the post in two places to indicate that instead Jaxx does in fact need to implement support for a strong password. One can discuss whether to do this differently for the desktop (no sandboxing) than for mobile devices (usually good sandboxing).

2017-06-10 20:19 UTC

Introduction

I was curious how easy it would be to extract the 12-word wallet backup phrase from a Jaxx cryptocurrency wallet desktop app / chrome extension install.

After an hour or two of analysis, I can conclude that this is unfortunately far too easy.

Jaxx Chrome extension Eth UI. Throw-away address, don’t use.

Even when your Jaxx has a security PIN configured, anyone with 20 seconds of (network) access to your PC can extract your 12 word backup phrase and copy it down. Jaxx does not have to be running for this to happen.

With the 12 word backup phrase, they can later restore your wallet, including all of your private keys, on their own computers, and then proceed to transfer away all of your cryptocurrency.

The main problem is that the Jaxx software encrypts the mnemonic using a hard-coded encryption key, instead of making use of a strong user-supplied password. (As Daira Hopwood points out in the comments, using the PIN would not be sufficient.)

This means we can easily read and decrypt the full recovery phrase from local storage using sqlite3 and some straight-forward code.

I successfully tested this vulnerability on the Jaxx Chrome extension v1.2.17 and the Jaxx Linux desktop app 1.2.13.

Demonstration

To test this proof of concept, you will need node.js installed. Ensure that your Jaxx is PIN protected, just for fun. It won’t help.

On Linux or Mac, open the Jaxx local storage file using the sqlite3 tool, or if you prefer GUIs you can use sqlitebrowser. You can find this file at the following locations depending on your operating system, and whether you’re using the desktop app or the chrome extension:

(If you opted for sqlitebrowser, just copy out the value of the mnemonic key.)

Note the returned value down. This is Jaxx’s encrypted mnemonic which we shall decrypt into your 12 word backup phrase.

(If the returned string is too short in your case, try sqlitebrowser instead. In my case, sqlite3 works perfectly for the desktop Jaxx, but not the Chrome Jaxx, where I use either the chrome Dev Tools or sqlitebrowser to extract the string.)

Install crypto-js version 3.1.2 by doing either npm install crypto-js@3.1.2 or yarn add crypto-js@3.1.2, and then run the following code using node, after substituting the mnemonicEncrypted variable value with the one you extracted using sqlite3:

How can we fix this?

The thing is, Jaxx is unfortunately one of the better cross-platform multi-currency wallets. Although it has a great UI, I personally don’t like Exodus, because they don’t let me manage more than one Ethereum address.

To mitigate the Jaxx security issue discussed here, keep the Jaxx desktop app’s local storage directory on an encrypted filesystem which you only mount when you’re using Jaxx, and unmount directly afterwards. This is what I’m currently doing using encfs.

If you prefer using the Chrome extension, you can try symlinking just the extension’s local storage file as it lives in Chrome’s global Local Storage directory.

Importantly, keep on encouraging Jaxx support to add support for using a strong user-supplied password as part of the encryption key (just like Exodus) with which they encrypt your mnemonic (recovery phrase) and all other sensitive values in local storage. Refer them to this post for more details. (See Daira Hopwood’s comment, using the PIN for encryption is not sufficient.)

In this post, I’ll show you how you can use Emacs and orgmode to query live data from any RESTful webservice, and then use that data in orgmode tables, a really great way to get live table-based calculation and display functionality in your rich orgmode-based documentation.

As an example, we will query live ticker data from the Kraken cryptocurrency exchange, and then use the current trading values of two different cryptocurrencies to calculate a fictitious investor’s position.

There’s a short YouTube video accompanying this post that demonstrates how the whole business works. Read on for more details!

I can specify any number of pairs, but for the sake of exposition we’re going to work with Bitcoin in Euro, and Ethereum in Euro.

Query the ticker webservice using emacs-lisp

Next we’ll write some emacs-lisp code to embed in our orgmode file. In this case, this blog post is actually an orgmode file which I shall later export to wordpress.

The code makes use of TKF’s great request.el package, installable from MELPA. I started with one of the examples on the request.el github, and then used the shiny new let-alist macro to extract the first element of the c key (the last traded price) of the result - PAIR hierarchy.

The eth-eur and btc-eur pairs are stored in the cpb-kraken-etheur and cpb-kraken-xbteur variables respectively.

Whenever I press C-c C-c with my cursor anywhere over the code, it will retrieve the current values into emacs-lisp variables, and the recalculate the table shown below.

Use the ticker data in a spreadsheet-like table

Next, we construct the orgmode table. If you have never done this with Emacs orgmode, you should try it. The UX for quickly making and maintaining text-mode tables is breathtaking. The table as you see it below is the HTML representation (generated by Emacs and orgmode) of the plaintext table as it lives in this org file:

coin

units

curr unit price

curr val

frac

eth

15.231

197.000000

3000.507

0.36

btc

2.335113

2252.100000

5258.9080

0.64

2017-06-03T14:10:14

8259.415

Everything in column 3 and to the right, and in the last row, is calculated based on the ticker values we have pulled in using the emacs-lisp code above. The table will update whenever I press C-c C-c on the embedded code block, as it ends with (org-table-iterate-buffer-tables), meaning to recalculate all tables in this file, until convergence.

The orgmode formula editor (shortcut C-c '), enables you to edit all cell formulas with live highlighting of the references. The editor interface looks like this:

As you can see, I pull in the three variables retrieved and calculated by the emacs-lisp code using snippets of lisp. The other formulas are the standard spreadsheet fair with an orgmode flavour. @2$3 for example refers to the third column in the second row.

I can make any number of tables in this same file, depending on values from either the lisp code, or other tables. As per usual, I can export the file to PDF, HTML, ODF or even to a wordpress site, as I’m doing right now.

If you more or less know what a hash is (the hash is as a short string, e.g. 32 characters, than can be calculated from a file of arbitrary size; if even one byte in the file changes, the hash will be completely different; read more on wikipedia, or ask me in the comments) and you more or less know how the public and private keys in asymmetric cryptography work (you can encrypt (encode) something with the public key, ONLY its matching secret private key can decode it; you can SIGN any file with a secret private key, the authenticity of that signature can be proven by anyone with matching public key; read more on wikipedia, or ask in the comments!) you can more or less understand bitcoin in particular and cryptocurrency in general.

Let’s say you were to generate a completely random private key, you can then use a well-known procedure to derive its matching public key. By applying two successive hash functions to that public key, you have a bitcoin address!

If I were to owe you money, you could then give me that bitcoin address.

I could then pay you back by writing a specially crafted message called a bitcoin transaction, in which I describe that I am transferring some bitcoins TO the address that you gave me FROM another bitcoin address (henceforth the source address), of which I have the matching secret private key.

In that message, I cryptographically sign the input part, a modified version of the whole transaction, including source and destination address, with the (secret) private key matching that source address. The signature mathematically proves that I own the bitcoins I am about to transfer, and it mathematically locks in the whole transaction, so that the destination addresses also can’t be changed. I generally also allocate a very small amount (by leaving money unaccounted for) as a transaction fee. We’ll see why in a minute.

I broadcast the signed transaction to the bitcoin network, where it eventually gets picked up by one or more of the bitcoin miners. Miners batch together a number of transactions into a block, together with a hash of the last successfully mined block, and a piece of random data called the nonce. They then proceed to continuously hash the block, changing the nonce every time so that the hash changes, until the first few digits of the hash are zeroes.

Based on the nature of cryptographic hashes, this will statistically take a very long time. One could get lucky and get the correct hash early, but generally it requires a whole lot of number crunching, which means kilowatts, which means actual money. The special hash resulting from this number crunching is called the proof of work.

When a miner has hit the jackpot, they broadcast the block to the network, which recognises that it’s the next valid block by checking the hash, and then, in a peer to peer fashion, irreversibly records this as the next block in the globally shared block chain. The successful miner currently receives 12.5 bitcoins (on 2017-06-03 worth about 27500 EURO) as well as all of the included per-transaction fees. This reward is set to halve again sometime in the future.

Now you probably understand why so many people are mining so enthusiastically. (No, you can’t really participate anymore with your home PC like you could in the early days; you have to acquire a large room full of bitcoin mining ASICs, circuitry that has been purpose-designed for one thing: bitcoin mining, to make any kind of impact. On the other hand, if you play the lottery, you might as well fire up your PC.)

You could now go and print out your private key (or its QR code) and the matching bitcoin address (actually you only need the private key, the public key and address can be derived from it) and then destroy all of your computers. Whenever you need to send that bitcoin somewhere, you simply type in the private key or rather scan the QR code, and then repeat the process of creating a bitcoin transaction, using your private key.

The money is never actually stored anywhere, only transactions encoding the movement of money from one random virtual address to another are. The block-chain is mathematically unbreakable and unforgeable.

I find the relative simplicity of the whole thing utter genius: A usable and versatile currency backed by hard math.