Broken Authentication: The Greatest Vulnerability to Cryptographic Systems

What do blockchain, VPN, and SSH all have in common? They’re all implementations of cryptographic technology.  

When we think of cryptography, we usually think of technologies that encrypt our hard drives, or internet services that encrypt our data in transit, such as HTTPS with TLS. But blockchain is also an application of cryptography. It’s an encrypted ledger, a chain of transactions that use a cipher to not only keep user identities confidential, but also to ensure the integrity of the records. And it’s all deployed in a decentralized system. Blockchain is the not-so-secret ingredient that makes cryptocurrencies like Bitcoin and Ethereum work. Blockchain also has other applications, such as in assuring the confidentiality and integrity of medical records.

Laypeople likely assume that when cyber threat actors break cryptography, they do so by cracking the cipher. But modern cryptographic standards often use key sizes of 256-bit, 1024-bit, or even 2048-bit. Until quantum computers are in proper deployment, it’s much easier for threat actors to exploit vulnerabilities in implementation than to try to crack ciphers.

So when cryptographic systems are penetrated, usually the problem is broken authentication. The cyber attacker acquires keys they’re not authorized to have, or they find some other way to maliciously authenticate. Let’s explore this problem for a bit, shall we?

Case studies: Ethereum authentication exploits

Cryptocurrency is the most popular way to implement blockchain. And Ethereum may not be quite as popular as Bitcoin, but it’s still one of the most frequently used cryptocurrencies around. Unfortunately, there are ways that threat actors could bypass the encryption of Ethereum’s blockchain.

Replay attacks work when a valid data transmission is maliciously repeated or delayed by a cyber attacker. Here’s a replay attack where the attacker behaves like the signing entity in a cryptographic transaction, as described by a user on GitHub:

“Suppose there is a transaction in ‘UGT.’  User A wanted to transfer 100 tokens to user B through proxy C, and an extra three tokens should be paid to proxy C as a service fee. In this process, the signatures of user A should be used to sign on A, B, 100 tokens, 3 tokens, and the latest nonce, 1. Then the transfer were carried out by proxy C. After this transaction is completed, user B can get 100 tokens from user A.

Also suppose the user A doesn’t carry out the transfer in ‘MTC.’ The latest nonce is 1. After receiving 100 tokens from user A, user B replays the signatures of user A in ‘MTC.’  They can get another 100 tokens in ‘MTC’ without user A’s permission.”

So user B is working on behalf of the threat actor in this chain of authentication. They have user A’s signatures, and they’re using them maliciously to acquire tokens they’re not entitled to have.

Peter Vessenes describes another authentication exploit that targets Ethereum’s blockchain.  

A safe contract script can become a dangerous script by simply replacing one function, msg.sender, with another, tx.origin.

Here’s an example of a script which checks an Ethereum blockchain while using msg.sender:

contract UserWallet {
function checkOwner() internal {
   if (!(msg.sender == owner)) { throw; }
  function doSpend(address destination, uint amount) {
   if (!destination.send(amount)) {
     LogFailedSend(destination, amount)
contract OurContract {
  function spendMoney(UserWallet w, address destination, uint amount) {
     w.doSpend(destination, amount);

The msg.sender function has limited access, so it’s safer to use to check transactions on the blockchain.  

“What is the value of msg.sender in the UserWallet.checkOwner() call? It is the address of the OurContract contract -- that address becomes the msg.sender, replacing the original caller's address, as soon as an external call is made.

This makes a lot of sense. Otherwise, we can imagine any number of terrible, terrible attacking wallets that could pretend to be worth sending money to. As soon as someone was stupid enough to send them money, they could execute a remote attack on the sender. In fact, if msg.sender worked any other way, there would be horrible security bugs.

Imagine msg.sender told contracts who the original caller was, the one who started it all. Then this attack contract would drain all the money out of every sender wallet.”

And that’s what tx.origin does. By simply replacing one function with another, a contract script can be exploited by a cyber attacker!

Notice how neither of these case studies crack any encryption. They bypass encryption by exploiting keys they aren’t entitled to have or by other forms of privilege escalation.

These types of exploits are difficult to detect because their behavior would look like innocuous activity according to a SIEM, firewall, or any other sort of behavioral security control. The first example involves the threat actor using keys they’re not supposed to have, and the second example involves a script which gives a user too many privileges in a system. So what can we do?

Possible solutions

Code review can help, especially in examples like the second. Search your scripts for the tx.origin function, and be extra sure they’re not being implemented in ways that make your application insecure! Other kinds of application vulnerabilities can be a lot more difficult to check and mitigate, though. Because bugs are often more complicated than just the wrong function being used.

Unless your developers are masters of authentication systems and perhaps have a few related bug bounties under their belt, they may not be able to debug authentication vulnerabilities effectively. And even if they can, it can be super tedious work... just ask a developer.

Application pentesting is often a great idea. You would need to hire experienced pentesters, not just in applications, but in applications that implement blockchain or similar cryptographic systems. Good pentesters don’t come cheap though, you might have to spend tens of thousands of dollars for one application penetration test.  

Bug bounty programs can be useful. But there’s a reason why only large companies like Apple, Microsoft, or Tesla typically have bug bounty programs. Because having a bug bounty program requires having not only a generous budget, but also significant operational maturity as a company to evaluate those bug reports and bounty hunters.

Aside from detecting brute force attacks where a few vectors make a massive amount of authentication attempts in a short period of time, it can be very difficult to detect authentication exploits. Because as I’ve mentioned, with the right keys or privilege escalation, malicious authentication looks like legitimate authentication.

Not only can application firewalls find malicious authentication to be difficult to detect through behavioral rules and metrics, they also have limited visibility into the protocols and data used by blockchain systems. Deep inspection is really limited. You can’t stop what you can’t detect!

Compliance standards can be useful for better securing your public key infrastructure. But they still aren’t useful for security hardening against many other threats to a blockchain.

Blockchain is being implemented in more and more systems and applications everywhere. Its ability to encrypt transactions and records in a decentralized manner is a real asset. The decentralization makes these systems really resilient. Unfortunately, they also pose unique security challenges. Let’s tackle them together!  

About Valid Network  

Valid Network’s blockchain security platform provides complete life cycle security for enterprise blockchains from initial development to active deployment and management. Based in Be'er Sheva, Israel, the company’s solutions enable enterprises to innovate with blockchain faster, providing complete visibility and control over their distributed applications and smart contract governance, compliance, and security posture through advanced platform capabilities.

Secure the block with Valid Network.

Learn more:

Follow us: LinkedIn | Twitter | Blog

Other Blogs

Introducing Ethereplay by Valid Network

We are excited to announce Ethereplay by Valid Network, a free community tool to support examining, analyzing, optimizing and securing of smart contract code on Ethereum.

Broken Authentication: The Greatest Vulnerability to Cryptographic Systems

What do blockchain, VPN, and SSH all have in common? They’re all implementations of cryptographic technology.