What attacks lead to dApps being hacked
As a result of vulnerabilities inside the project's code or third-party integrations
TL;DR
With over $4 billion stolen from DeFi protocols and dApps just in the past 2 years, the issue of cyber security in blockchain has become top of the agenda.
Usually, dApps are attacked in two ways - either via their smart contracts or frontend. But how do these exploits actually work?
Smart contract attacks exploit deficiencies in the contract code or lack of communication between a number of contracts to drain them, dump token prices or steal user assets.
Frontend attacks exploit frontend code vulnerabilities. These can come from poor code architecture and implementation, or from insecure integrations with third parties.
At Getit, when we work with dApps on installing our ad plugin, we don’t interact with the dApp’s smart contracts. This means it is impossible for there to be smart contract-related attacks.
Additionally, our plugin doesn’t capture any sensitive or personally identifiable information. It uses end-to-end encryption when communicating with the dApp, tackling the frontend attack vectors.
Oh my hack…
Only in the past 2 years, over $4 billion were stolen by hackers from DeFi protocols and dApps, leading to smart contract and dApp security becoming hot topics. Understandably, Web3 businesses have become even more cautious about how they approach their cyber security both internally and externally, especially when it comes to partnerships which involve tech integrations.
This means it's extremely important for web3 business professionals: BD, marketing, product and others - to also understand the fundamentals of cyber attacks, starting from potential attack vectors.
When it comes to dApps, the hazard often comes from either smart contract or frontend vulnerabilities.
Smart contract-level attacks
Let’s dive into the specifics of what smart contract level attacks exist:
Reentrancy attacks
Imagine you're in a conversation, and someone keeps interrupting you before you finish speaking. In a reentrancy attack, a smart contract is interrupted during its execution, allowing an attacker to repeatedly call the same function before it completes, potentially draining funds.
Front-running attacks
Think of a race where someone sees your moves and tries to get ahead of you. In the blockchain, front-running happens when an attacker observes a transaction about to be executed and quickly submits their own transaction with higher fees to take advantage of price changes, limited token allocation or other opportunities.
Overflow and Underflow Attacks
Imagine you have a cup that can only hold a certain amount of water. If you pour too much, it overflows; too little, and it's empty. In programming, overflow happens when a number becomes too large, and underflow occurs when it becomes too small, allowing hackers to, for example, mint an excessive amount of tokens or drain tokens from the contract at minimum cost.
Unprotected withdrawal attacks
Picture a vault that doesn't have a lock. If someone finds it, they can take all the money. Similarly, in smart contracts, there are functions allowing for funds withdrawals, and, unless those are properly protected, an attacker might freely take funds from the contract.
Flash loan attacks
Imagine someone borrowing a massive amount of money for a split second, exploiting price differences across DeFi platforms, and returning the money so quickly that the system doesn't catch on. That's a flash loan attack—a rapid, collateral-free manoeuvre on the blockchain, where the attacker aims not only to profit from quick trades but also manipulate asset prices as they do so.
Although flash loan attacks don’t exploit vulnerabilities of a particular contract, they do benefit from those contracts not having a way for a rapid consensus regarding an asset price. One of the popular decentralized oracles to help tackle this bottleneck is Chainlink.
There are also other types of attacks related to smart contracts, however the above 5 tend to be the most popular ones. One common thing here is that for a hacker to succeed with these attacks, your smart contract code needs to have hidden deficiencies.
There are multiple high-quality external auditors (like Hacken or CertiK) helping ensure smart contract security and minimize the risk of being hacked.
However, even with your smart contract secured, you should still keep your eyes peeled, as your dApp’s frontend is another major target.
Frontend-level attacks
Aside from the smart contract attacks, hackers can target the dApp’s frontend to bring the service down, drain user wallets, affect the token prices and much more.
Phishing attacks
Imagine you're searching for a treasure, and suddenly, a fake map leads you astray. Phishing attacks are like fake treasure maps; they create deceptive websites to trick users into revealing sensitive information like sharing private keys. They can also drain wallets by making users unknowingly sign malicious transactions.
Solutions like the Fire extension attempt to tackle malicious transactions by alerting users that they are about to allow for their assets being transferred to a suspicious wallet or smart contract.
Sometimes, phishing attacks are combined with network-layer attacks such as a DNS (Domain Name System) attack. This happens when hackers take control of the dApp’s domain and redirect users to a malicious destination.
Cross-Site Scripting (XSS) attacks
Imagine you're writing a letter, and someone sneaks in to add false information. Cross-Site Scripting is like a sneaky addition to website code, allowing attackers to tamper with what you see and do online.
Cross-Site Request Forgery (CSRF) attacks
Picture having a magical pen, and someone tricks you into drawing unwanted things. CSRF is like tricking users into unintentional actions on websites where they're logged in.
Man-in-the-Middle (MitM) attacks
Hackers exploit poorly encrypted communications between users and the site, or between the site and a server, which gives them an opportunity to steal the user data or tamper with it. This can lead to user credentials being stolen and wallets being drained.
Credential Theft through Fake Pop-ups
Imagine you're opening a treasure chest, and suddenly a fake chest appears, collecting your keys. Fake pop-ups trick users into entering sensitive information and signing unwanted transactions.
Are there any other front end attacks?
Yes, there are other sophisticated attacks, however, they all have one thing in common - a suboptimal level of frontend security, whether it is caused by the frontend code complexity of the dApp or by deficiencies on the side of third-party integrations. Set aside a prosaic access credentials exposure.
What does it mean?
Undoubtedly, Web3 projects must audit all their smart contracts both internally and with external firms. Also, they need to make sure the attack vectors on the frontend are understood and avoided: for example, it can be done by encrypting communications and setting security policies to block malicious scripts.
So with that in mind, is there a way that using Getit can result in a hack?
No. Our partners are fully secure because:
Our ad plugin doesn’t interact with blockchain at any time, this means smart contract attack vectors don’t apply.
We don’t use any cookies and we don’t install anything within user browsers. We only take publicly available wallet addresses, geolocation and the device type/OS info. No personally identifiable information is collected, and no malicious scripts can penetrate the user’s browsers or the dApp’s frontend.
We encrypt all client-server communications with HTTPS, protecting dApps from man-in-the-middle attacks that intercept and tamper with the data.
We encourage our publishers to investigate our lightweight ad plugin SDK to make sure it’s safe and secure to integrate with.
So, if you are a dApp wishing to securely monetize your traffic with relevant Web3 ads, or to advertise to your target crypto audience at scale, drop us a line or DM me 🙂
Stay safe, friend! 🍀