This post was written by /u/RoofTopPortaPotty in the ETHFinance Subreddit and then I reposted it here with permission this time.
This is the second installment of my series of posts regarding the privacy of various Chrome browser crypto wallet extensions. First entry can be found here, where we analyzed Rabby.
This analysis has shown that my previous approach of broadly categorizing findings under ‘the ok, the bad, the ugly, and the weird’ is insufficient, subjective, and does not properly represent what I wish to convey.
Using Kali Linux, I downloaded Google Chrome directly from google.com/chrome. Analysis of encrypted traffic was completed using BurpSuite + the provided root cert, installed in chrome’s local cert repo. Chrome is then launched with a proxy set to Burp’s listening port. I will not be doing any sort of transactions whatsoever. I will, however, connect the wallet to a dapp.
Tally Ho! Crypto Wallet
On this New Years Day we will be taking a look at Tally Ho! The Tally Ho extension was downloaded from the official Google Chrome extension site. I must start off by giving Tally Ho credit for something that Rabby did not implement. As I went through using the wallet to create a new address, I paid no attention to the seed phrase.
I was hit with a quiz that ensures that the user knows their seed phrase. I reinstalled Tally Ho, created a new address, and passed the quiz this time. An excellent general security practice that every wallet should implement.
Upon installation, the first request Tally Ho generates is to
api.coingecko.com in search of current token prices. Notice crab season in full effect.
This is a ‘web3’ wallet, and as such we see many requests destined for chains and defi services that us ethfinanciers wont (admit to, at least) be using much. An example of such a request, one which is quite demonstrative of the rest, looks like:
I don’t have a problem with this activity, but it would be great to have a more Ethereum-centric version of this wallet.
api.blocknative.com is used to fetch Ethereum gas fees and block info.
Tally Ho reaches out to Compound Finance’s Github repo ‘token-list’ for a list of, you guessed it, tokens. For a benign example of why this is not such a great practice, check out this request to Trader Joe’s ‘token-list’ repo.
The response is a 404. Not a huge problem, just a bit sloppy seeming. Could be bad news if an attacker is able to gain access to that repo, which is likely much less heavily protected than Trader Joe’s other assets.
Here is where things get a bit more subjective.
We see Ankr’s API being used to get the ETH balance of my new Ethereum address, notice the value ‘0x0’ in the response.
And for the Alchemy haters, I’ve got some bad news
Alchemy’s API is used to fetch my address’ balances of various tokens, which are specified by contract address in the POST request body. You may notice requests to
mainnet.infura.io in the above image. No need to worry, these requests were generated strictly by connecting to
One thing that left me a bit puzzled is this request to
My wallet address is sent as a GET parameter. Along with an ‘Authorization:’ HTTP header. I have not had much time to look into this service, and would love to know more if anyone has any insight.
Refreshingly, no requests to telemetry services or advertisers were found.
Happy New Year, yall!