How to Check Project Security
Last updated
Last updated
When people dive into the digital world, the topic of security is often discussed as the afterthought. The utility of the app often prevails, and many people choose to use less secure products if they give them more streamlined user experience. As for the companies, many of them are ready to cut corners to reach high user accumulation, and often security is something that is discussed later in the development cycle.
This pattern of behavior leads to a situation where users are satisfied with their experience until they are not. It often happens abruptly, taking away all the positive aspects of using the app, as well as assets and information that should belong to the user.
In Web3, a hack of an application may lead to the loss of funds - either invested in the dApp, or even those which are located on the user's wallet. The database breach can take away user’s privacy and expose them to the possibility of being robbed in real life. It is happening all the time, and our goal is to be mindful about the possibilities of such attacks.
A Web3 researcher not necessarily should be the security expert - but they have to understand possible vectors of attack. By knowing the most common ways a dApp can fail, researchers can study the documentation of the project and see if the main security bases are covered or not.
The best place to start the analysis is by going through the documentation of a crypto project. In most cases you will be able to find the link to documentation on the crypto project’s website or on their Github. The absence of such documentation should be a bright red warning sign.
A sufficient crypto documentation should be comprehensive, well-organized, and addressing all crucial aspects such as project overview, list of smart contracts, tokenomics, community engagement, roadmap and team. By fostering transparency and maintaining active communication channels with the community, sufficient documentation can promote informed decision-making, facilitate adoption, and encourage a thriving ecosystem.
The company may have the required parts written in their documentation, but the true test comes from the actuality of information displayed there. The advantage of a blockchain is that if a company points out all the necessary information about the structure of their smart contracts, it can be then checked independently.
However, if a company hides the structure of their smart contracts, initial token distribution, or uses a lot of pretty words to describe what they are capable of without detailed explanation of the practical implication - that is a worrying sign.
Below you may find a link to the GameFi project that on the surface provides an explanation to what they are doing - but in reality it has no significant information neither about the token, nor about the smart contract structure.
https://docs.metroverse.com/overview/met-token
This creates a misunderstanding when CoinMarketCap points to the token that Etherscan consider to be malignant:
While there are many crypto projects with sub-par documentation, others are doing their best to write down the list of all smart contracts that constitutes every version of a project. An example of such effort may be Kyber Network that has several services, and all of them have a page that lays down the whole architecture including testnet:
Same thing can be found in Uniswap documentation - they are very meticulous in describing all of their smart contracts for every version of the product they have.
Audits play a significant role in Web3 project security. They involve an independent third-party examining a project's code to find potential vulnerabilities. The goal is to ensure the system is secure and reliable, keeping users' assets and information safe. For instance, when researching a DeFi project like Aave, you should look for information about their most recent security audits.
https://docs.aave.com/developers/deployed-contracts/security-and-audits
Audits are not foolproof, but they are an essential component of a project's security strategy. Regular audits can help identify and address vulnerabilities before they become a significant issue. As a researcher, you should be aware of the audit history and the reputation of the auditing firms involved to gauge a project's commitment to security.
But be mindful of projects that may boast they passed the audit without addressing the issues it brought to the spotlight!
There are multiple types of audits a Web3 company may go through. The most common and necessary is the Smart Contract Audit - an investigation in functions, potential vulnerabilities and unintended functionality an smart contract might have.
Similarly important is the blockchain protocol audit - a check on the functionality of an architecture of an underlying protocol. If dApps are running as intended, but the underlying infrastructure is faulty - it’s still a huge risk factor to consider.
Speaking of dApps - an audit of a front-end of a dApp is another important part of a thorough security audit. If the user interface can be exploited - it can lead to large losses in funds as it has happened with BadgerDAO.
There are also several other types of audits that a centralized Web3 company should go through - from Proof-of-Reserves and Proof-of-Liabilities, to an industry standard CCSS Audit.
Now that we’re aware of the types of audits possible - let’s look at some limitations and scope of them. For example, when we talk about the Smart Contract Audit, we have to keep in mind that a crypto project often consists of many contracts. Pay attention to which contracts are audited - it can be core contracts of a business, or just a token contract.
While going through blockchain protocol audit, it’s important to note which parts of it are checked. What's the auditor's analysis of the code base, architecture, consensus mechanisms etc. Although you might not be able to adequately analyze the severity of issues found in the audit, you can notice whether the crypto project has addressed the problems and has fixed them.
Whenever there is a talk about proof-of-reserves, also notice if there is a proof-of-liabilities. First part of an audit is almost useless without the second part - a company has to be able to prove that they hold as much funds as they’ve been provided by the customers.
Another crucial aspect of an audit is the time when it was done. An audit done a year ago may already be outdated due to the new technological stack introduced to the blockchain network or vulnerabilities discovered during this year. An audit done two years ago is almost useless.
A case study of Audios hack may provide a glimpse of why it is important to keep the audits relevant. Smart contract was checked in 2020, then some other parts were checked in 2021. But the attack happened in the middle of 2022 - two years after the deployment.
New types of attacks are emerging all the time, and sometimes if a highly forked piece of open-source code is hacked, most of the copies of this code will be vulnerable and have to be upgraded as well.
There are many reasons why a crypto company may be losing the validity of an audit. Some examples are:
The code that has been audited was upgraded. Any upgrades to the code makes an audit obsolete
Smart contracts that have been deployed are different from contracts that have been audited. Some companies are using the name of an auditor as a marketing strategy.
Issues found in the audit weren’t addressed and patched.
Enough time since the audit has passed (usually from 1 to 2 years)
Basically any change in the code after the check requires another round of audit.
Bug bounties are essential tools for enhancing security in Web3 projects, as they incentivize developers and security researchers to find and report vulnerabilities in exchange for rewards. These programs help projects identify weaknesses in their codebase and address them before they can be exploited, contributing to a more robust and secure ecosystem.
Web3 projects with bug bounty programs demonstrate a proactive approach to security and a commitment to protecting their users' assets and data. By offering rewards for discovering vulnerabilities, projects can leverage the skills and knowledge of the wider community to bolster their defenses against attacks.
If a crypto project is hacked or exploited, the attacker has a choice - to return the funds for a percent of the assets stolen, or take it all and deal with the consequences. And thoughtful companies prefer to launch bug bounty preemptively, so that white hat hackers know what reward they can expect in case they find vulnerability.
Bug bounties are loosely divided into two categories - self-held, and community based. The first category is hoping to rally the users of a platform to search for bugs in the program. An example of such bug bounty would be The Graph. Some of these programs may have very lucrative rewards for finding critical issues, like the one held by Ethereum.
In other cases, a company would prefer to use the help of a community like HackenProof or Immunefi - a group of advanced hackers can be more effective at finding the bugs than the regular platform users.
In order to find out whether a crypto company has a bug bounty or not, the first thing you need to do is to check both documentation and the footer of their website. Most of the bug bounties are public, and if a crypto project has it - they are interested in promoting it as it gathers more attention of white-hat hackers.
Another option is to go through bug bounty communities like HackenProof or Immunefi - if a company has the program with these communities, it will show you all the relevant details about it.
Last, but not least option is to just Google the name of a company you’re interested in with the “bug bounty” key word.
Another activity that strengthens the overall security of a company is penetration testing. It is a process of simulated cyberattack on the system, trying to breach through security measures by utilizing sets of reconnaissance and exploitation tools, vulnerability scanners and other ways to get access to the system.
After the test, specialists who were executing it provide a report with description of all found vulnerabilities, as well as the methods of fixing it.
The key difference between penetration testing and something like an audit is the multi-level approach to detecting security issues. Pentesting is usually done by simulating both internal and external environments of the project, then to find ways to disrupt the service from many angles.
There are three main approaches to pentesting, called Black Box, White Box and Grey Box. The first approach probes the running program without knowing any internal structure, while the White Box method looks at the source code and tries to detect vulnerabilities there. The Grey Box is a mixture of both.
This proactive testing is especially useful in assessing centralized Web3 companies as they can be most vulnerable to the security breach of their application and key management.
Despite the whole plethora of security testing, the most common way of attacking a service is to target the human that controls it. By exploiting our trust, curiosity or lack of awareness, an attacker can do a significant amount of damage.
One of the most prominent examples of such an attack was the Ronin Bridge exploit, when a victim had access to the funds located on the Bridge. His machine was infected by a file masquerading as a CV - then only to compromise the access to the bridge.
This is where true decentralization shines: by giving away the power to control funds unilaterally, a crypto project significantly decreases the chance of being exploited through social engineering methods.
