Security #3: Security Team | Ethereum Foundation Blog

Over the past year, the Ethereum Foundation has significantly grown its team of dedicated security researchers and engineers. Members come from a variety of backgrounds, including cryptography, security architecture, risk management, and exploit development, and have worked on red and blue teams. Members come from a variety of sectors and have worked to protect everything from the internet services we all use every day to national health systems and central banks.

As The Merge approaches, the team is putting a lot of effort into analyzing, auditing, and studying the consensus layer in a variety of ways, as well as The Merge itself. Samples of the work can be found below.

Client Implementation Appreciation 🛡️

Team members audit a variety of client implementations using a variety of tools and techniques.

Auto Scan 🤖

Automated scanning of your codebase aims to find findings that can be easily hung, such as dependency vulnerabilities (and potential vulnerabilities) or areas for code improvement. Tools used for static analysis include CodeQL, semgrep, ErrorProne, and Nosy.

Because the languages ​​used between clients vary, we use both generic and language-specific scanners for our codebase and images. These are interconnected through a system that analyzes new results from all tools and reports them to relevant channels. These automated scans allow you to quickly get reports of issues that are easy for potential attackers to find, increasing the chances of resolving the issue before it becomes exploitable.

Manual Audit 🔨

Manual auditing of stack components is also an important skill. These efforts include auditing critical shared dependencies (BLS), libp2p, new features in hard forks (e.g. Altair’s synchronization committee), thorough audits of specific client implementations, or L2 and bridge audits.

Additionally, if a vulnerability is reported Ethereum Bug Bounty ProgramResearchers can cross-check issues across all clients to see if they are affected by the reported issue.

Third party audit 🧑‍🔧

Sometimes third-party companies are brought in to audit various components. Third-party audits are used to get an outside look at new clients, updated protocol specifications, future network upgrades, or anything else deemed high value.

During third-party audits, software developers and security researchers on our team work with auditors to train and support them throughout.

Purging 🦾

There are many ongoing fuzzing efforts led by security researchers, customer team members, and ecosystem contributors. Most tools are open source and run on proprietary infrastructure. Fuzzers target important attack surfaces such as RPC handlers, state transitions, and fork selection implementations. Additional efforts include Nosy Neighbor (AST-based automatic fuzz harness generation), which is built on the Go Parser library and is CI-based.

Network-level simulation and testing 🕸️

Our team of security researchers builds and leverages tools to simulate, test, and attack controlled network environments. These tools can quickly spin up local and external testnets (“attacknets”) running in a variety of configurations to test exotic scenarios (e.g. DDOS, peer separation, network degradation) that require clients to be hardened.

AttackNet provides an efficient and secure environment to quickly test various ideas/attacks in a private environment. Private attack nets cannot be monitored by potential adversaries and issues can be addressed without disrupting the user experience of the public testnet. In these environments, we regularly leverage disruptive techniques such as thread pausing and network partitioning to further scale up the scenarios.

Client and Infrastructure Diversity Research 🔬

Client and Infrastructure Diversity We received a lot of interest from the community. We have tools to monitor the diversity of clients, OS, ISP and crawler statistics. We also analyze network participation rates, proof timing anomalies, and general network health. This information shared across majority This is a position that highlights potential risks.

Bug Bounty Program 🐛

EF currently hosts two bug bounty programs: The one is execution layer Another target is consensus layer. Security team members monitor incoming reports, verify their accuracy and impact, and then cross-check issues against other clients. Recently we released all the information. Previously Reported Vulnerabilities.

Soon, these two programs will be merged into one, the overall platform will be improved, and bounty hunters will receive additional rewards. More details on this coming soon!

Operational Security 🔒

Operational security involves a lot of effort at EF. For example, asset monitoring has been set up to continuously monitor infrastructure and domains for known vulnerabilities.

Ethereum Network Monitoring 🩺

A new Ethereum network monitoring system is in development. This system works similarly to: CM It is built to listen and monitor the Ethereum network for dynamic anomaly detection that searches for outlier events as well as pre-configured detection rules. Once installed, the system provides early warning of ongoing or upcoming network outages.

Threat Analysis 🩻

Our team conducted a threat analysis focused on The Merge to identify areas that could be improved upon when it comes to security. In this work, we collected and audited security practices from client teams on code review, infrastructure security, developer security, build security (such as DAST, SCA, and SAST embedded in CI), and repository security. The analysis also examined how to prevent misinformation, how disasters can occur, and how communities can recover under different scenarios. Some efforts related to disaster recovery training are also of interest.

Ethereum Client Security Group 🤝

As The Merge approached, we formed a security group comprised of client team members working at both the execution and consensus layers. This group meets regularly to discuss security-related issues, including vulnerabilities, incidents, best practices, ongoing security work, and suggestions.

Incident Response 🚒

The blue team’s efforts will help bridge the gap between the execution and consensus layers as the merge approaches. War rooms for incident response have worked well in the past, with chats happening with the people involved when an incident occurs, but The Merge introduces new complexities. Additional work is underway to, for example, share tools, create additional debug and classification features, and generate documentation.

thank you Join us 💪

These are just some of our ongoing efforts in various forms, and we look forward to sharing more with you in the future!

If you believe you have discovered a security vulnerability or bug, please submit a bug report to: execution layer or consensus layer Bug bounty program! 💜🦄