< Previous Next >
Thoughts on the Coinomi Spellcheck Vulnerability
The other day I opened up Twitter to be greeted with the following tweet pinging me:
I noticed he had made many such other such tweets pinging public cryptocurrency enthusiasts, so I went to the bitcointalk thread and found out that a vulnerability had been discovered in Coinomi, a wallet that I have regularly lauded in my educational articles.
In my defense I’ve always pointed people towards hardware wallets when it comes to maximum security, and touted Coinomi as an inexpensive solution which isn’t necessarily suited to holding large amounts of coins. I’m getting ahead of myself though — first, let’s discuss the vulnerability and how serious it is.
Spellchecking your Recovery Phrase
The long story short is this: the desktop version of Coinomi had a glitch which inadvertently sent your recovery phrase to Google’s spellcheck API. This was not intended behavior. Here’s a rundown of the facts as we now know them:
- The bug was not in Coinomi’s code. It was in a jxBrowser, a library which allows one to embed a web browser into Java applications. The desktop version of Coinomi was built on top of this library.
- Desktop versions were patched as soon as the disclosure was received by Coinomi.
- The recovery phrase was sent via HTTPS, and it was only sent if one was using the wallet restore feature. Only Google received this phrase.
So, before I go any further, the ramifications are this: if you never used the desktop version of Coinomi, this vulnerability does not affect you. If you used the desktop version of Coinomi but never restored a wallet, this vulnerability does not affect you (but you should immediately update your software). If you’ve used the wallet restore feature on the desktop version of Coinomi, my opinion is that you should immediately move all your funds somewhere else and trash that wallet. Someone else — perhaps a Google employee — may have the seed phrase. It’s not worth the risk to keep using that wallet!
The Disclosure Drama: Coinomi’s Response
This is a messy situation; the vulnerability was bad, but the circumstances surrounding the disclosure and the official Coinomi response are troublesome. Warith Al Maawali was the one to disclose the issue, and Coinomi had some very harsh things to say about him including calling him a blackmailer.
Here’s the executive summary: I do not believe Warith lost any money. At the same time, I do believe Coinomi made some major mistakes — both with the initial vulnerability, and with the way they handled the response. Let’s talk about both of these points and why I hold them:
I do not believe Warith lost any money
It may sound like I am calling Warith Al Maawali a liar, but it’s not quite that simple. As Coinomi said in their official response, there is no proof that he’s not still in control of the coins. To put it simply, I don’t like to believe things without incontrovertible or near-incontrovertible proof. Furthermore, I find much of his communication with Coinomi very suspicious-sounding. Before I’m willing to believe that Warith lost such an enormous amount of money, I’d want more evidence. I believe this will come out as people track the funds from address to address and see what happens to them.
Coinomi made its communications with Warith public. I will reproduce them here, with commentary:
This appears to be his first email regarding the vulnerability. There are no details about the vulnerability at this point — only assertions that he’s lost funds, and that he is demanding his money back from Coinomi.
“You have few hours to return my assets back or I will go public with all the evidence against you.”
Right off the bat this sort of phrasing concerns me. I understand being livid or emotional if you think all your money is gone, but it seems very irrational to expect Coinomi to send you a pile of money for a vulnerability you have yet to describe at all. Likewise, it’s coupled with a threat against Coinomi’s reputation. I’m picturing an Italian mafia man coming up to you and telling you that it would be a shame if something happened to your business and that you had better pay up.
Now, this isn’t proof of blackmail by any means. It just sounds off to me. Moving on:
This email was sent six minutes after the first. Addresses are good — these can be tracked and we can see where the funds end up. This will greatly help during follow-up investigations. In any event, about an hour later we get our first Coinomi reply:
Seems reasonable so far. A customer has come forward claiming loss of funds — something that is probably due to user error 9999 times out of 10000 — and Coinomi’s response is information about hacking and next steps, as well as a request for more information. It seems a little boilerplate — I’d probably be annoyed to receive this in this situation, to be fair — but appropriate. An hour later, Warith replies:
I’m unclear what Warith means when he says that none of the email replies to what he asks. Did he expect Coinomi to hand him $60,000 in crypto just based on his word alone? Again, I understand the duress a person is under in this situation, but this just isn’t rational behavior. At this point he appears to be unaware of the specific vulnerability and has given no details whatsoever that could help track down the issue. Five minutes later (a sign the company is taking this seriously), Coinomi replies:
An “XPUB” or “extended public key” will help in any investigation. Likewise, the screenshots of the wallet overview page will help legitimize Warith’s claims. This is all well and good so far. A series of back and forth emails follow in which Warith provides the information. Eventually — the next morning — Warith sends an email with partial details about the vulnerability which he has uncovered:
This is where things get particularly nasty. At this point he is refusing to give anything but the barest of details about the vulnerability unless they pay him around $60,000. Again, we still have no proof he actually lost money — Coinomi certainly had no proof at the time of this email that he actually lost money. This could be a scam. It would be insane for Coinomi to hand over a sweaty pile of money at this point, and it seems deeply immoral that Warith refused to give details until they promised to pay him. Are these the actions of a desperate man who just wants his money back? Are they something more sinister? I don’t know, but it doesn’t sit well with me.
Coinomi investigates further, and requests more information about the vulnerability.
Warith refuses to give more information without a promise that he’ll receive all of his money. Considering this from Coinomi’s perspective, they still have no real proof that a vulnerability exists, let alone that Warith actually lost funds. Likewise, these repeated threats of “going public” are doing nothing to help the situation. I’m not saying this is blackmail, but I am saying that you wouldn’t have to squint too hard to read this as a blackmail attempt.
Half a dozen emails go back and forth in which Coinomi asks for more information about the vulnerability Warith has supposedly found, and Warith consummately refusing to provide them until he’s promised money. After a great deal of bickering, he discloses the vulnerability. Coinomi promises him a bug bounty, the amount of which will be determined at a later date as they analyze the flow of the “hacked” funds. Warith’s reply was interesting:
Decide for yourself if this looks like blackmail. Also — if you’d like to read the whole unbroken comment chain, it can be found here. My opinion: it doesn’t seem too farfetched that someone might have been looking for a real vulnerability in order to use it in a scheme to make quite a lot of money.
I believe Coinomi made some major mistakes
As sketched out as I am by the way that Warith communicated with Coinomi, there is still incontrovertible proof that Coinomi screwed up badly in a number of ways. In their official response they make a number of claims that seem specious. Firstly, they state that, unlike what was reported:
The seed phrase wasn’t being transmitted in plain text, instead it was being encapsulated inside a HTTPS request with Google being the sole recipient
This is hand-waving at best. I don’t think anyone cares if it was being sent via HTTP or HTTPS (though, obviously, HTTPS is better since it reduces the chance of a man-in-the-middle attack). Yes, the data was technically encrypted. That’s not the point. The point is that — in the end — Google itself still received people’s passphrases. This is not the situation in which you start looking for a technicality to get you off the hook, Coinomi. I understand wanting accuracy, but this is missing the point.
Coinomi also states:
The spell-check requests that were sent over to Google API were not processed, cached or stored and the requests themselves returned an error (code: 400) as they were flagged as “Bad Request”¹ and weren’t processed further by Google
There’s a footnote at the bottom of their response related to this statement:
We have asked Google to confirm that bad requests’ text body isn’t stored on their servers, we will update our statement accordingly.
My bullshit detector started going off pretty hard when I read this. If you’ve ever done any kind of LAMP stack work, you know that this sort of thing tends to go straight into a log file. It’s very difficult for me to imagine that Google — an evil empire which uses data to make ungodly amounts of money — ever throws any data away. I can guarantee you that they store bad requests attempts to their various APIs somewhere — possibly many somewheres. All it would take is one unscrupulous Google employee with access to one of these places, and voila: he builds a regex script to look for something that looks like passphrases and he steals all your money.
The important bit: should we trust Coinomi now?
Because Coinomi is listed on my site as a convenient wallet for storing coins in mobile phones, this is a very serious question. While I’ve always maintained that it shouldn’t be used for large amounts of coins, obviously I will not point people towards something I believe to be unsafe. So, do I think Coinomi is unsafe? In a word: maybe.
Their questionable responses aside, the fact that this vulnerability existed in the first place is very bad. They chose to use a third-party library, which in and of itself was a mistake. Why would you not just write your own GUI which you know is safe? Why would you take the shortcut of using a wacky Java library that lets you embed a web browser into your application? What the hell?
On top of that, they very clearly didn’t do enough testing on their desktop client — any intelligent network analysis done during testing would have caught this issue in an instant. If I worked for Coinomi as an information security analyst, I’d have a script that watches the network for things that look like passphrases during tests. I have no idea how this slipped past them. It seems woefully irresponsible at best.
My theory is that Coinomi had their B team working on the desktop version of their app and simply released it too soon without enough testing. This is the only explanation that makes sense, considering the fact that their mobile wallet has never had any major issues like this.
With that said, I will probably keep using the mobile version of Coinomi for small amounts of crypto like I always have. Meanwhile, I will be researching alternatives such as Exodus, Eden, and Jaxx. You can expect articles on these wallets at some point. Stay safe out there, and remember: if you are holding large amounts of crypto, invest in a hardware wallet for your own safety and peace of mind.
Come back soon because more content like this is always coming! If my work helped you or gave you something to think about, share it with others:
Sharing helps more people find my articles, and I’d love to be able to assist as many people as possible with cryptocurrencies. Also, if you have any ideas for future articles or specific questions, I’d love to hear them. One last thing: if you’d like to chat with me in real time, check out my Discord!
Best of luck, and happy trading!
< Previous Next >