Coin_Auditor - A Security Analysis of the Verge (XVG) Ecosystem

[mikeacuna]

Hi Verge team,

Please reference https://medium.com/@coin_auditor/a-security-analysis-of-the-verge-xvg-ecosystem-bc7aface6319 for the original post. I'm not the original poster of this article and I tried to look for similar bugs in the issue list but could not find them. I'm posting here in its entirety. There are several points raised on the article that appear to be valid and once this issue is closed, the community will know that all concerns have been addressed and Verge is now more secure.

Please reclassify if this needs to be enhancements or bugs or if these are already fixed in 4.1.

Thank you.

SOTC (State of the cryptocurrency) - As of Dec. 29th 2017.

• The funds of users of the Bitcoin Core-derived Verge desktop wallet are vulnerable based on application defaults.
• The confidentiality of transactions made to, from, or involving addresses stored on the Verge Android wallet are potentially compromised.
• It would be trivial for a well-resourced attacker to poison blockchain snapshots downloaded from verge-blockchain.com to provide altered data to users.

Prerequisites

• [ ] Are you running the latest version? - No, Article was posted Dec. 29th, 2017

User Story:

• "I'm submitting a ... "
  • [x] bug report
  • [x] feature request
  • [ ] support request
  • [ ] translation request

1. Android Verge Wallet PIN storage The Verge Android wallet is a fork of the Coinomi wallet, where Verge is the only available cryptocurrency. Some aspects of the multicoin codebase have been unmodified despite the reduced scope, and some additional functionality has been added.

When a user conducts the initial setup of the Verge wallet, they will be asked for a four-digit PIN code to protect their wallet. This PIN is requested whenever the user opens the wallet, and serves as an application lock so those with unauthorised access to your device cannot make transactions from the wallet, unless the application has been previously unlocked.

Analysing the source code, we can see that the code is stored and compared as a simple MD5 hash

The PIN code subsystem has clear flaws:

• A PIN code should not be used for securing the wallet public key for a private currency
• Any secret should be salted
• Any secret should be stored and evaluated using a collision-resistant algorithm
• A secret with a search space larger than 10⁴ should be protecting the application
• The effect of this is limited by the fact that we must still unlock the wallet before spending funds, though this flaw jeopardises the private nature of Verge, as an attacker can then see the user’s public key — allowing for retrieval of balances and addresses.

Effect:

Verge’s privacy is reduced to Bitcoin-level for conducting blockchain analysis. Users can view the balance of any address derived from the public key for the duration of the key’s use.

2. Variable evaluation side-channel vulnerability Throughout the Verge Android wallet, comparisons done against variables — including those which provide security functionality — are often performed using the Java Runtime Environment .equals function.

The .equals function is implemented for speed efficiency, which means the function executes upon the first disjoint element of the object. The use of non-cryptographically secure comparisons theoretically allows for an attacker to use return time to inform a brute force attack.

Time-vulnerable comparisons are used for PIN-code authentication

Effect: An attacker would be able to use a timing attack to speed up the time required for a bruteforce attack

3. Verge blockchain snapshot issues As previously mentioned, Verge’s main desktop wallet is a fork of the Electrum wallet commonly used for Bitcoin and Litecoin. Initial setup of the Electrum fork can take a while due to a lack of nodes, though the VergeCurrency.com website points to a direct link to download the blockchain at verge-blockchain.com.

The verge-blockchain.com domain is configured to use SSL and automatically redirects users from using http to https.

The second of the domains hosting the Verge blockchain is directly from verge-blockchain.com, however the first is from a host at the IP address 83.169.38.218, worryingly over insecure HTTP. A reverse IP lookup provides no information as to who owns the domain or why it is used in the Verge project, showing a half dozen previously connected domains:

While it is reassuring one of the links is provided by the website directly, it is the inexplicably referenced as the second server link. It is reasonable to assume that most people download the blockchain will use the foremost link on the page, which is provided from the non-HTTPS server.

Furthermore, there has been no content added to the site allowing us to verify the authenticity of the downloaded file. A signed statement of the file hash (not in MD5, please) using a key connected to the Verge developers would suffice, though would slow down the automatic generation of these files.

Effect:

A malicious attacker would be able to man-in-the-middle the blockchain download, providing a modified ledger to would-be node operators.

4. Verge wallet insecure wallet.dat When opening the Verge-QT wallet for the first time, a wallet.dat file is generated and the user is presented with the usual open wallet view, familiar to users of the Bitcoin Core client and its’ forks.

The wallet allows users to encrypt any wallet using a passphrase, and enforces some reasonably secure standards for user-supplied passwords, but does not make the user encrypt the software before viewing a receiving address.

Once the user loads the wallet.dat, they can retrieve the private key by using the dumpprivkey <

> command.

The user should be prompted to create a new wallet upon first load, instead of automatically generating a wallet for the user. This way, it’d be impossible to use the Verge wallet without at least first being prompted to add a password.

Effect: Malicious actors with file access would be able to copy the default wallet.dat, then write code for automatically clearing out addresses connected to the wallet

[justinvforvendetta]

a lot of this is not accurate. what is the background of the author? maybe he doesn't realize some of the things in this article aren't related to verge. like the blockchain snapshots hosted by community members lol also the Android wallet doesn't just use pin, it also uses fingerprint, and both are part of the Android OS.

[swat69]

3. Verge blockchain snapshot issues All 3 download links of the blockchain-zip using now HTTPS and the domain verge-blockchain.com.

[justinvforvendetta]

no someone could not alter the downloads even before swat69 threw ssl on it.

[underdarkskies]

https://github.com/vergecurrency/verge-core-installers/blob/6bf4c9260052d6bbbd1dbf37914dc23041285f6e/Window_Installer_Src/installer.nsi#L163 references non https server that hosts an old copy of the blockchain from jan 8. For consistency please remove chain from these locations, or implement ssl (probably could cause issues) on the electrum servers. Further inspection revealed that both http://e1.verge-electrum.com and http://e2.verge-electrum.com host a copy of the jan 8th chain on non ssl servers. Also as a side note http://e3.verge-electrum.com displays the standard post install apache splash page. may want to remove.

[justinvforvendetta]

the electrum servers do use ssl, on the port the wallets connect to. but yes the servers http is on ssl now too, read the post above yours @abovedarkskies

[underdarkskies]

I was only making the recommendation for consistency, I understand that the likelihood of a mitm blockchain data swap is low. It's just if you say you are gonna slap ssl on all servers hosting the chain, then.... hit them all! Even easier, remove that static jan 8 blockchain from the electrum boxes as currently neither server have valid ssl cert on port 80 for hosting that file. Edit the installer.nsi to point to the valid boxes for the block chain that swat69 already hit. Problem fully resolved! as of 7:24pm EST no ssl on http on e1 or e2 @justinvforharmony ;)

[justinvforvendetta]

wait, which blockchain data server doesn't have ssl?

[Noworize]

I think he is referring to these

http://e1.verge-electrum.com http://e2.verge-electrum.com http://e3.verge-electrum.com

On Fri, Feb 2, 2018 at 5:27 PM, sunerok notifications@github.com wrote:

wait, which blockchain data server doesn't have ssl?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vergecurrency/VERGE/issues/560#issuecomment-362760615, or mute the thread https://github.com/notifications/unsubscribe-auth/AeSL8opfuXOuyBFYAH8K5AgqMkmtPtPoks5tQ7YCgaJpZM4RsLvJ .

[underdarkskies]

Both http://e1.verge-electrum.com and http://e2.verge-electrum.com host "Wallet_v3-v4.x_Verge-Blockchain_2018-January-8.zip" and one of the automated installers(verge-core-installers/Window_Installer_Src/installer.nsi) calls a download from said host instead of the verge-blockchain.com addresses

[underdarkskies]

2 electrums(e1,e2,) contain localhost.localhost signed ssl not tracing up to a CA for web requests neither do http connections redirect to https dunno why any block chain is being hosted on them as electrum servers dont need to get hit with blockchain downloads...

[swat69]

The domain verge-electrum.com is only for the electrum server not for access with http/https, but anyway I changed the config to avoid access to the zip from verge-blockchain.com. And pull request to change the download URL.