PARTNERBecome a Partner
Book a call

Broken Authentication: API Keys and How to Lose $26M in Crypto

Carlo De Micheli, Zoran Gorgiev
Broken Authentication: API Keys and How to Lose $26M in Crypto

No, this is not a Monty Pythonesque guide to bad cryptocurrency trading. It’s an analysis of a highly severe and frequent API vulnerability, broken authentication, and here, you’ll pick up a lot about:

  • How hackers can steal millions from a cryptocurrency exchange by taking advantage of API keys
  • Why abused API keys fall within the broken authentication category

We’ll examine the consequences of broken API authentication through the security incident that cost Kronos Research $26M in cryptocurrency and disrupted its business continuity.

Broken Authentication in APIs

Broken authentication refers to inadequate measures or a complete lack of mechanisms that prove a user’s or client’s (application’s) identity. It comprises multiple security shortcomings, some of which are:

  • Weak passwords
  • Poorly implemented authentication measures, such as unencrypted JWTs
  • Authentication information sent as parameters in URLs
  • Easy-to-bypass authentication mechanisms
  • Low-entropy auth tokens
  • API keys used for user authentication

This API vulnerability has consistently held second place on the OWASP lists of top ten API security risks since 2019. That’s a sad and disturbing fact. It tells a story of a continuous disregard for a most elementary security requirement. If you don’t do authentication right, what do you do right?

Broken authentication allows malicious actors to appropriate legitimate users’ identities and act as if they were those users. Since this vulnerability makes your APIs and systems unable to tell between hackers’ and genuine users’ activities, the consequences can be profoundly damaging.

The Kronos Research security incident is a concrete example of how insufficient authentication affects businesses’ finances and continuity.

The 10,000-Foot View of the Kronos Research Security Incident

What Happened to Kronos Research?

Kronos Research is a Taiwan-based cryptocurrency trading firm.

On November 19, 2023, the company announced on X (Twitter) that it suffered an API-related security incident. Someone gained unauthorized access to part of the company’s API keys, which allowed them to misappropriate Ethereum worth approximately $26M.

The stolen Ethereum was redirected to six different cryptocurrency wallet accounts. The lowest transaction was 2,507.5 ETH, and the highest was 2,780 ETH.

The anonymous on-chain researcher ZachXBT and the data analysis platform Lookonchain confirmed the Ethereum outflows on the same day.

Kronos Research had to halt trading to investigate the hack. In its announcement, the company assured no partners were affected during the incident.

API security incidents like this can have terrible fallout. They may lead to regulatory implications, destabilize partner exchanges, disrupt the crypto market, and diminish investor confidence.

Kronos Research was quick to say that the $26M didn’t make up a significant portion of the company’s equity (contrary to appearances).

But even if that was the case, what about reputation and trust loss? And business discontinuity? These three may not have an immediately visible effect. Still, they undoubtedly have a tangible, harmful financial impact in the long run and are variables businesses must factor in when considering API security.

Negotiating With Hackers

Surprisingly, after the incident, Kronos Research decided to negotiate with its attackers, thus joining in what appears to be a growing trend among cryptocurrency exchanges.

The company posted its suggestion on Etherscan, offering the hackers 10% as a bounty for returning 90% of the stolen sum. It also promised not to take any further action against the attackers.

From a cybersecurity perspective, this is a worrying way of dealing with threat actors because it can encourage an avalanche of new, similar cyberattacks. After all, if you can get away with hacking without consent and even be rewarded, why not keep doing it? And what would prevent other bad actors from taking the same route?

Are Security Incidents Common in the Crypto Industry?

Undoubtedly yes.

In “Hack3d: The Web3 Security Report for Q3 2023,” the blockchain security firm CertiK calls Q3 2023 “the most financially damaging quarter of the year.” The losses totaled $699,790,794—more than Q1 and Q2 combined.

The report states there were as many as 184 security incidents in Q3 alone. Of course, they were not all API-related incidents. Still, considering how essential APIs are in blockchain and crypto and what happened to Kronos Research, it’s reasonable to expect the number of API-related incidents to grow.

The Technical Details of the Kronos Research API Incident

What We Know So Far

We know that the Kronos Research hack resulted from a threat actor coming into possession of some of the company’s active API keys. Those API keys allowed them to manipulate funds that did not belong to them.

Unfortunately, this is the only publicly available, loosely said, technical information we have. That makes it challenging to do a precise analysis of the incident.

Nonetheless, what we can do is discuss API keys’ role in security and cryptocurrency trading and provide you with an account of the routes the hacker might’ve taken to steal millions from Kronos Research.

What API Keys Do

API keys are primarily identifiers, nothing more than that, and you should not use them as a security mechanism per se. (Apart from identification, they’re suitable for analytics and tracking API usage and cost, but that’s a different topic.)

As a reminder, identification and authentication are related but different. An identifier makes a user or client unique, separating it from all the other users and clients. In our context, each API key is a unique alphanumeric value that identifies one and only one entity: it shows that this particular entity makes the request, not that one or the third one.

But that’s not authentication. Authentication is a confirmation, often multiple confirmations (MFA), that the entity with a particular unique alphanumeric value in possession is its original owner—is indeed who/what it claims to be. Therefore, you cannot treat API keys as an authentication mechanism and, by extension, a security feature.

Another point to emphasize is that API keys are client identifiers. They differentiate between clients, that is, applications accessing an API. In other words, they show what makes the requests, not who. Hence, it would be best if you didn’t employ them as user identifiers.

The third crucial point is that, as Google emphasizes, API keys cannot be used for secure authorization. They lack granular control and can leave the gates open to API abuse.

API keys only make sense in conjunction with proper user authentication and authorization mechanisms. Using an API key along with user credentials is one way to go, so even if someone stole the API key, they couldn’t access and manipulate sensitive data, like in the Kronos Research case.

How Hackers Steal API Keys

Hackers can use multiple methods to get their hands on API keys.

1. Reverse-engineering

One way is to reverse engineer already published apps, that is, to decompile the binary. Extracting API keys from the application code is possible when developers hard-code the keys, in this case called static secrets.

An open-source tool such as MobSF (Mobile Security Framework) is all a hacker needs to achieve this feat.

2. MITM (Man-in-the-middle) attack

Another method is intercepting an HTTPS request and stealing the sent API key. This method is suitable for scenarios when API keys are computed during runtime. In this case, they’re called dynamic secrets.

Attackers can intercept HTTPS requests using a free proxy tool such as Mitmproxy to decrypt, inspect, and replay SSL traffic. Another tool with similar capabilities is Burp Proxy, which is the fundamental component of Burp Suite. The commercial version of Burp Suite can be a precious asset for these purposes.

However, it’s worth noting that this type of attack is becoming increasingly infeasible.

Attackers must first find a way to install a mitmproxy certificate on the device making the request to decrypt HTTPS requests and steal API keys. They can achieve that by creating a fake Wi-Fi access point masked behind the appearance of a free Wi-Fi network and tricking the victim into downloading and installing the certificate, but that’s a far-fetched scenario.

And even if they mislead the victim into downloading the certificate, Android devices typically trust certificates installed by end-users only if developers configure their apps that way. A workaround for this problem is for hackers to trick end-users into installing a fake, i.e., tampered version of the app. However, that increases the complexity of the attack even more, making it highly unrealistic and impractical.

3. Search of public repositories

The easiest and presumably most common way is for malicious actors to do an in-depth search of publicly accessible repositories and find unprotected API keys. This search is a routine part of the API recon phase.

Google dorking is one way to do it. Scanning public web application environment files and code repositories is another. The third way is to examine issues and pull requests on GitHub.

In 2019, a North Carolina State University team studied billions of GitHub files for several months. The results were disturbing. Over 100,000 repositories exposed secret API keys or cryptographic secrets, and thousands of new ones leaked daily. We doubt things have changed much recently.

How is API key leakage that common?

Sometimes, organizations make an oversight. For instance, developers may miss when a repository becomes public and fail to remove API keys and other sensitive data.

Other times, they lack a robust and mature security culture. The probability of misconfigurations and fatal errors creeping into your application code dramatically increases when security is not integrated into SDLC (software development life cycle).

The Role of API Keys in Cryptocurrency Trading

Since the tremendous growth of the cryptocurrency market, traders have begun to automate their activities—reading exchange account data, executing trades, opening and closing orders, asset management, and storing information—by relying on third-party clients.

APIs play a fundamental role in this process. And API keys are crucial for authorizing third parties to act on the traders’ behalf.

The API key:

  • Communicates to the cryptocurrency exchange that the third-party service is allowed to access the trader’s account.
  • Demarcates the operations the third party is permitted to execute.

Typically, third parties lack withdrawal permissions by default. Hence, even if someone stole a cryptocurrency trader’s API key, they could not withdraw cryptos at their whim.

How Hackers Abuse Crypto API Keys

The tragedy is that hackers have managed to find their way around this limitation. All they need is an API key that gives them trading authorization, and stats say that over 90% of API keys grant this authorization.

The two main techniques attackers use to steal crypto through abuse of stolen API keys are:

  • Sell wall buyouts
  • Price boosting

You’ll find an excellent, thorough explanation of the intricacies of these techniques—in the context of API key abuse—in the recently published Cybernews report (December 7, 2023).

For our purposes, these two are manipulative techniques that play with the value of the crypto—temporary artificial decrease or increase in crypto’s value—so that hackers can trade away balances of the accounts whose API keys they stole.

The Cybernews report indicates that the two techniques work regardless of the cryptocurrency exchange company. That means the exploitation potential is endless as long as exposed API keys are our reality. Especially if the keys lack an expiration date and the responsible side doesn’t revoke or regenerate them on time.

The same report reveals that the total worth of the analyzed exchange accounts with leaked API keys in public code repositories is over $1M in cryptocurrency.

API Keys and Broken Authentication

User authentication can be easily circumvented through stolen API keys if the API keys are entrusted with responsibilities they were never meant to carry. Again, API keys are not a user authentication mechanism and a security feature. That’s why improper usage of API keys falls under the broken authentication rubric.

We need much more than just an API key to validate users. The prominent ethical hacker Alissa Knight manipulated data (transferred money) via a bank’s APIs without being authenticated. And that might have been what happened to Kronos Research.

In the Kronos Research case, too, the attacker seemed to bypass authentication through the stolen API keys. The keys allowed the attacker to act with the rights of an authorized user without having to authenticate as the genuine owner of the misappropriated Ethereum.

Conclusion

The Kronos Research hack is another warning that no technology is inherently safe if it relies on improperly secured APIs, not even blockchain. We must protect API keys and make earnest efforts to implement layered authentication.

Use a vault to store API keys, but never in cleartext. Generate long, complex, and random keys with expiration dates. Regenerate them periodically, don’t store them in your app’s source code visible on GitHub, and invalidate them in the event of accidental exposure. But above all, don’t use API keys as a user authentication mechanism if you want to avoid grabbing the headlines for all the wrong reasons.

As with everything else, the best way to do something well is to start right from the beginning. Make API security an integral part of SDLC and test your APIs for vulnerabilities in development and production. Nip the problem in the bud.

Reach out to us at Equixly to talk about API security and learn about the benefits that continuous security testing brings to your table. We’ll be happy to extend the conversation we’ve started here.

Carlo De Micheli

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.