Blockfolio Quietly Patches Years-Old Security Hole That Exposed Source Code
The security vulnerability, which appeared in older versions of its application, could have allowed a bad actor to steal closed source code and possibly inject their own code into Blockfolio’s Github repository and, from there, into the app itself.
A "white hat," or ethical, hacker found a gaping hole in Blockfolio, the popular mobile cryptocurrency portfolio tracking and management app. The security vulnerability, which appeared in older versions of the application, could have allowed a bad actor to steal closed source code and possibly inject their own code into Blockfolio’s GitHub repository and, from there, into the app itself.
A security researcher at cybersecurity firm Intezer, Paul Litvak, made the discovery last week when he decided to review the security of the cryptocurrency-related tools he was using. Litvak has been involved in cryptocurrencies since 2017 when he used to build bots for trading, and Blockfolio is an Android app he used for managing his portfolio.
“After some time reviewing their [new] app to no avail, I took a look at older versions of the app to see if I could find any long-forgotten secret or hidden web endpoints,” said Litvak. “Soon I found this version from 2017 accessing GitHub’s API.”
This code connects to the company’s Github repository using a set of constants that included a filename and, most importantly, the key Github uses to allow access to repositories. It appears below as the variable “d.”
The app queried Blockfolio’s private GitHub repositories, and that function quite simply downloaded Blockfolio’s frequently asked questions directly from GitHub, saving the company from the effort of having to update it inside its apps.
But the key is dangerous in that it could access and control an entire GitHub repository. Since the app was three years old, Litvak was curious as to whether it was still a threat.
“This is severe, but I thought maybe it’s just some old token not in use anymore, from back when they launched,” said Litvak.
The key, he discovered, was still active.
“And I found that, nope, the token’s still active and has a “repo” OAuth Scope,” he said. An “OAuth Scope” is used to limit an application's access to a user's account.
A “repo,” according to GitHub, grants full access to private and public repositories, and includes read/write access to code, commit statuses and organization projects, among other functions.
“It was using private credentials to access its private code repository,” said Litvak. “Anyone who was curious enough to reverse-engineer the old Blockfolio app could've reproduced it and downloaded all of Blockfolio's code and even pushed their own malicious code into their code base. You're not supposed to have private credentials in apps that anyone can download.”
The vulnerability had been public for two years and the hole was still open. Litvak alerted Blockfolio to the issue via social media, given Blockfolio does not have a bug bounty program to root out vulnerabilities.
Blockfolio Co-Founder & CEO Edward Moncada confirmed in an email to CoinDesk that a GitHub access token was mistakenly left in a previous version of the Blockfolio app codebase, and when alerted to the vulnerability, Blockfolio revoked access to the key.
Over the next several days Moncada said Blockfolio did an audit of its systems and confirmed that no changes were made. Given the token provided access to code that was separate from the database where user data is stored, user data was not at risk.
STORY CONTINUES BELOW
The token would allow someone to change source code, but through its internal processes for releasing changes to the system Moncada said there was never a risk malicious code would have been released to users.
“I'd say worst-case scenario, an attacker would update the app's code and collect data about the users. They also have the feature where you put exchange API keys in the app so that could be stolen as well," said Litvak. "But they [Blockfolio] claim that's impossible because of their 'security reviews.' I'd say it's best nobody got to test those security reviews."