Infiltrating the EVM-II: Inside the War Room’s Arsenal

This is the second part in the Infiltrating the EVM series.

In September 1947, Grace Hopper found a bug, “a moth in the inner working of the Harvard Mark II computer.” The legendary machine was debugged, literally, and the moth was removed. This incident catalyzed a coordinated awareness within the burgeoning field of computer science, emphasizing the importance of attention to detail, perseverance, and problem-solving.

A decentralized system such as web3 fundamentally differs when debugging and removing errors from a computer system or its applications. One cannot simply restart the world computer or take the software offline to implement fixes.

In the fast-paced world of decentralized applications (dApps), where every second counts and user trust is paramount, a malfunction can quickly escalate into a crisis. When the stakes are high, and downtime is not an option, merely adding to a to-do list won’t suffice.

Enter the War Room.

War Room is an immersive, high-energy environment incorporating a dedicated team of experts that comes together to form the backbone of the War Room. These professionals encompass a wide range of talents, including but not limited to blockchain engineering, smart contract security, cryptography, and DevOps. Combined with the urgent nature of the problem, their collective knowledge qualifies for a comprehensive analysis of the issue, ensuring no stone is left unturned.

Imagine this scenario: a heavy-traffic DApp, with tens (or even hundreds) of millions of dollars invested in it, suddenly collapses due to a bug. Transactions fail, data becomes unreachable, monetary value is locked, and panic spreads. If you have experience in the blockchain industry, you know that panic is not uncommon.

In these high-pressure moments, traditional troubleshooting processes fall short and swift action is the only acceptable course. What we need is a War Room!

Within the War Room, clear communication channels are paramount. Efficient collaboration hinges on effective information sharing. A monitoring system is a watchful eye, tracking user activity and contract behavior. Real-time data feeds into the War Room, providing crucial insights into the malfunction’s scope and impact. Vital to the War Room’s success is access to the contract’s source code and documentation in the realm of blockchain, where transparency and security reign supreme; a thorough understanding of the codebase is imperative. Testing environments and tools are indispensable to navigating the treacherous terrain of troubleshooting. Simulating scenarios within controlled environments allows the team to recreate issues, observe their behavior, and test potential fixes. These testing mechanisms provide a safe space for experimentation, minimizing the risk of unintended consequences. In the face of unexpected challenges, a robust incident response plan guides the team’s actions.

This plan outlines the necessary steps to take in the event of a security breach or bug discovery. The team can respond swiftly and efficiently by establishing a predefined roadmap, minimizing downtime, and mitigating potential damage.

War Room – in Short

The War Room is a high-energy environment with a diverse team of experts tackling critical dApp issues. Their collaborative knowledge and skills ensure a comprehensive analysis of the problem. Clear communication channels, monitoring systems, access to source code, testing infrastructure, and sandbox environments are crucial for effective collaboration and troubleshooting. A robust incident response plan guides the team’s actions, enabling swift and efficient resolution of security breaches or bugs.

When the War Room Calls!

In the realm of Blockchain Security, there exists an exhaustive list of scenarios that demand the presence of a War Room. Within this dynamic environment, the team of experts converges, ready to confront the challenges that arise. These challenges vary widely in nature, with some selected explicitly from real-world experiences, as listed below:

A Security Breach Occurs

A security breach in the context of a smart contract refers to unauthorized access, manipulation, or exploitation of vulnerabilities present within the contract’s code or associated applications. The magnitude of the harm caused by a security breach can be significant. It may result in losing or locking funds from and within the smart contract, compromising user data, disrupting services to users, negatively impacting the contract’s reputation, and potentially triggering legal and regulatory consequences.

SushiSwap, a top DeFi protocol, where the admin turned rogue by executing the perfect rug pull ever to exist; such a protocol is liable to attacks as the contracts remained unaudited even when the TVL touched its first 9 digits. And when the audits did happen, according to Finematics, “… no critical or high severity issues found.“ It’s crucial to voice these concerns and take proactive measures to prevent such incidents. Take the SushiSwap case for instance, the single admin should have been flagged as high-severity as the centralization risk lied to a pseudo-anonymous owner, Chef Nomi. Although, the psuedo-anonymous owner did apologize for the consequences, this does not guarantee that similar situations will always result in the rightful compensation for affected individuals. Therefore, it is wise to prioritize safety and precaution, as demonstrated by SBF’s immediate implementation of a multi-sig contract. This not only enhances security measures but also helps to rebuild users’ confidence in the platform.
At BlockApex, we believe that ensuring a secure user experience goes beyond just examining the codebase. Security experts shoulder a significant responsibility in identifying potential attack vectors that could harm users and damage the overall blockchain ecosystem.

Substandard audits of SushiSwap Protocol – BlockApex’s Opinion

User Identifies Some Discrepancy

In the ever-evolving landscape of smart contracts, users play a crucial role in identifying potential vulnerabilities. Their vigilance and attention to detail can uncover bugs that may compromise the security of the contract. Such issues are usually reported through several channels, for instance, a list maintained by Crytic containing contact details for all hot and trending DApps, social media like Discord and Telegram, or even public bug-bounty programs to handle responsible disclosures.

Unexpected Behaviour Of Contact

Smart contracts aim to carry out transactions and specific tasks consistently and predictably. However, there may be instances where a contract displays unexpected behavior, indicating the presence of a potential bug. This issue could be detected by a legitimate user, an adversary, the protocol itself, or even a random developer experimenting. In some cases, such behaviors may not immediately lead to an exploit; failing to address them could draw unwanted attention.

Security Audit is Due for Smart Contract

Before a smart contract progresses to the next phase of its journey, it undergoes a critical evaluation—an independent security audit. This evaluation aims to uncover potential vulnerabilities and weaknesses in the contract’s design, code, and functionality.

REMEMBER, provided enough time and set of eyes, any bug can be identified!

Fortify the War Room, First. Period.

When setting up a War Room, it is imperative to prioritize the security of this critical environment. The following measures can help fortify the War Room and ensure its integrity:

Multi-Factor Authentication

• MFA and strong passwords for all team members should be used.
• Implementing multi-factor authentication adds an extra layer of security by requiring multiple verification forms before granting access. Strong, unique passwords further bolster the defense against unauthorized entry.

A Secured Physical Location

• Virtualized and Secure Location of the War Room should be ensured and accessible only to authorized personnel.
• Physical security is a fundamental aspect of safeguarding the War Room. Restrict access to designated team members and employ keycard systems or biometric authentication measures to limit entry.

Encrypted and Secure Communication Channels

• Encrypted Channels for all sensitive data and information exchanged within the War Room should be utilized without compromise.
• Encryption transforms data into an unreadable format, protecting it from interception and unauthorized access — secure communication channels, such as encrypted messaging platforms, shield discussions from prying eyes.

Limited Access to Vulnerable Code

• Secret Sharing of Buggy Code can be ensured when the contract’s source code and documentation are only shared with authorized team members once the bug is identified.
• Granting access solely to those who require it minimizes the risk of unauthorized modifications or leaks. By carefully controlling access, the team can ensure the confidentiality and integrity of the contract’s sensitive information.

Team-wide Awareness

• Issue Brief can be ensured about the standard incident response plan, and each member’s roles in case of a security breach or bug discovery are predefined.
• Regular training and drills familiarize team members with the procedures to follow during critical situations. This awareness promotes a swift and coordinated response, minimizing the impact of potential security incidents.

By incorporating these strict security measures into the War Room’s setup, the team can establish a fortified environment. Now, the focus remains on effectively addressing smart contract security challenges and protecting the project’s integrity.

Like any code, smart contracts aren’t immune to bugs and vulnerabilities. Fixing bugs in smart contracts requires careful attention to detail and a comprehensive understanding of the underlying code. We further need addressing and resolving bugs in these contracts is paramount with the potential for substantial financial losses and reputational damage.

Complexities Of Fixing Bugs in Smart Contracts

Fixing smart contract bugs in production is one intricate and multifaceted endeavor. With the potential for significant financial losses and reputational damage, addressing and resolving bugs requires a meticulous approach and a deep understanding of the underlying technology. Auditors face challenges while fixing bugs!

Spotting Bugs in Smart Contracts

Bugs have the potential to inflict significant financial losses, tarnish the project’s reputation, and even lead to legal consequences. Identifying and confirming the presence of a bug requires meticulous analysis of the contract’s code. This task is particularly arduous due to the intricate nature of the code and the intricate web of interactions between different code segments.

To tackle this challenge, the team must create a testing environment and develop comprehensive test cases encompassing various potential interactions. Any deviations in the test results necessitate a thorough investigation to determine if a bug exists.

Creating a Robust Task Force For Bug Resolution

Addressing and fixing a bug in a smart contract demands the expertise of a highly technical team proficient in understanding the contract’s code and the underlying blockchain technology. So, this team should encompass individuals well-versed in software engineering, cryptography, blockchain technology, DevSecOps, and security auditing.

A prime example of assembling such a team can be found in the Yearn Finance emergency procedure, designed in response to a critical vulnerability discovered in the platform’s code. The procedure outlines the formation of an “emergency multi-sig” composed of the project’s core team and trusted external experts. This multi-sig possesses the authority to make decisions on behalf of the project during emergency situations.

Assets and Risks in the War Room

Within the war room, the most crucial assets at stake are the funds belonging to users and the project’s hard-earned reputation. Failing to promptly and effectively address the bug can lead to substantial financial losses for users and the project.

Additionally, there exists a risk that the team’s actions during the war room process might inadvertently exacerbate the problem or introduce new vulnerabilities. However, meticulous planning and execution of each step and a comprehensive understanding of individual roles and responsibilities can minimize this risk.

Confirming the Implementation of Top-Quality Fixes

After the team identifies and fixes the bug, it is imperative to conduct rigorous testing to confirm the implementation of a high-quality solution free of new issues. This process typically involves automated testing, manual testing, and thorough code review.

Furthermore, the initial testing phase should occur in a staging environment resembling the production environment. This testing should encompass various scenarios to ensure the fix’s effectiveness.

Following testing, the team should engage in an exhaustive code review. This review aims to identify and address any potential new vulnerabilities or issues.

Finally, considering a third-party security audit can provide an additional layer of assurance, validating the fix and instilling confidence in its robustness.

TL;DR

The discovery of a bug in a smart contract deployed in production raises significant concerns due to potential financial losses and reputational damage. Identifying bugs requires thorough code analysis, while fixing them necessitates a highly technical team of experts. Assets at risk include user funds and the project’s reputation. Confirming high-quality fixes involves comprehensive testing, code review, and potentially third-party security audits. Diligent adherence to these steps ensures the resolution of bugs and upholds the utmost level of security.