Unamed Blockchain Project

August 5, 2022

Overview & Stats

Issue:

DDoS attack

Solution:

Google Cloud
Armour Policy

Potential Risks:

Waste of resources
Exponential cost
increase
Poor quality services
for end user

Numbers:

Cut of network load
by 66%
Several hundred
euros per month
saved
4 weeks until
problem solved

How not to suffer a horrible boating accident!

Blockchain adoption is growing exponentially, and as any “gold rush” it may come with adjacent risks to networks and users if not managed properly. One of the most common attack vectors is enumerating private keys to wallets. This is what we learned about managing cloud services and infrastructure while helping UBP with securing their blockchain.

All blockchain wallets have a public key to which a private key is attached. Your wallet address is derived from two strings of digits: the public and private key pair.

You can always find the public key from your private key, (easy to compute form your private key), “one way hash function” (and this is how you can send resources from one wallet to another and also authenticate yourself as the rightful owner of the funds in your wallet) but you can never find a private key with the public key as a starting point.

Imagine it like this: you can always make mashed potatoes from boiled ones, but once your mash is done it will never be potatoes again.

Guessing public and private key combinations is nearly impossible

but still…

If someone steals your private key, there is no way to prove that the coins are yours. When your wallet software generates your private key, write it on a piece of paper and keep it in a safe place is what everybody recommends– if it is stored on your computer then there is a chance it can be hacked and stolen during a horrible boating accident Usually, it is not necessary to deal with the public key directly, this is handled by your wallet software. You really only need to think about your wallet address (used to receive funds) and private key (kept secret and backed up). Otherwise anyone with the private key to an address can transfer funds.

An Elixir for malicious actors

Malicious actors use this mechanism to try guessing address and private key combinations in order to steal money from crypto owners. Although the chances of success are incredibly small, they send thousands of requests per second to any network they can find.

This not only wastes a tremendous amount of resources (servers, traffic, bandwidth), but also racks up a lot of costs while at the same time denying users their rightful access to the blockchain.

Community members interacting with the RPC endpoints of UBP noticed a drop in service level. The community discord was off the walls with complaints from legitimate users complaining applications of UBP and all transactions went offline.

Quickly addressing the situation our engineers noticed high CPU and RAM usage on application level, which they marked as highly irregular.

An increase of user activity could also show similar effects when monitoring a system but not to the expert’s eye! In the case of UBP, their server load was not coming from the usual calling protocols. (RPC calls) We noticed that an overwhelming majority of RPC calls were coming from an Elixir based HTTP client that was not related to any of the tools used in the UBP

No wonder! Elixir provides developers with high availability, adaptability, and scalability without really affecting performance. Elixir leverages the Erlang VM, known for running lowlatency, distributed, and faulttolerant systems.

If Elixir then 403 (forbidden)

Elixir is successfully used across a wide range of industries but also very attractive to hackers/ malicious actors specifically because of it’s hugely scalable nature.

How scalable?! WhatsApp and Facebook Messenger have seen great success by using an Erlangpowered stack that helps them process over 50 billion messages per day with greater than 99.9% uptime. That scalable! For a malicious actor this type of scalability IS the holy grail when running a DDoS or enumeration attack.

From this moment on, solving the issue was a piece of cake. A small “if … then” line of code was inserted and ran on UBP’s infrastructure/ access points.. All Elixir scripts/scripted users were excluded and the “traffic” dropped instantaneously.

“What we did is, after identifying a unique property of their requests, and we immediately implemented a Google Cloud Armor policy disallowing them completely.”

The load on the server dropped 66%. We saved bandwidth and therefore money for UBP. In terms of hard core cash, 60% compute amounts to several hundreds of euros per month, not to mention the degraded service users had to put up with.

Keep an eye on high resource usage and high network traffic even if your blockchain project’s hardware can take it and not cause any legitimate users access to services and transactions.

Sometimes, no matter the tools and policies you have in place, you also need an expert by your side!

A curious approach

You should always have a curious approach to traffic increase on your servers/VMs and try to see where and how it’s generated. In today’s connected world just deploying standard firewall and security measures no longer guarantees the protection of any system.

This is what we’ve done for the client highlighted in this case study. Checking their network traffic we ascertained that some malicious factors were clogging the project. Since bandwidth is paid based on traffic, our client was essentially losing money paying for extra, unnecessary, bandwidth, and getting a bad rep from their normal users who, on account of traffic bottle-necking, would be getting below par access to services.

Queue in DevWire and our team of tech private eye specialists who managed to sus out the intruding malicious factor, wash it out, and give back to our client their full control over the project. And all it took was four weeks. Four weeks is all we need to evaluate your blockchain project, or any cloud infrastructure, for that matter! No more losing money and reputation. Are you ready to commit four weeks towards securing your project?