Over the past year, the Ethereum Foundation has significantly expanded its team of security researchers and engineers. Members come from diverse backgrounds ranging from cryptography, security architecture, risk management, exploit development and have also worked in red and blue teams. Members come from different fields and have worked to secure everything from the internet services we all rely on every day, to national healthcare systems and central banks.
As we approach The Merge, the team is spending a lot of effort analyzing, auditing, and researching the consensus layer in various ways as well as The Merge itself. A sample of the work is below.
Customer implementation audits 🛡️
Team members audit different customer implementations with a variety of tools and techniques.
Automated analyzes 🤖
Automated scans of code bases aim to detect low-hanging fruit, such as dependency vulnerabilities (and potential vulnerabilities) or areas of code improvement. Some of the tools used for static analysis are CodeQL, semgrep, ErrorProne and Nosy.
As many different languages are used between clients, we use both generic and language-specific scanners for codebases and images. These are interconnected via a system that analyzes and reports new findings from all tools to the relevant channels. These automated scans provide rapid reporting on issues that potential adversaries are likely to find easily, increasing the chances of resolving issues before they can be exploited.
Manual audits 🔨
Manual audits of stack components are also an important technique. These efforts include auditing critical shared dependencies (BLS), libp2p, new features in hardforks (e.g. sync committees in Altair), a deep audit of a specific customer implementation or auditing L2 and bridges.
Additionally, when vulnerabilities are reported via the Ethereum Bug Bounty Programresearchers can cross-reference issues with all customers to see if they are also affected by the reported issue.
Third-party audits 🧑🔧
Sometimes third-party companies are hired to audit various components. Third-party audits are used to get an external look at new clients, updated protocol specifications, upcoming network upgrades, or anything else deemed of high value.
During third-party audits, our team’s software developers and security researchers work with auditors to train and support them throughout.
Blur 🦾
Numerous fuzzing efforts are underway led by our security researchers, customer team members, as well as ecosystem contributors. The majority of tools are open source and run on dedicated infrastructure. Fuzzers target critical attack surfaces such as RPC handlers, state transition and fork choice implementations, etc. Additional efforts include Nosy Neighbor (AST-based automatic fuzz harness generation) which is based on CI and built from the Go Parser library.
Network level simulation and testing 🕸️
Our team’s security researchers create and use tools to simulate, test, and attack controlled network environments. These tools can quickly launch local and external test networks (“attack networks”) running under various configurations to test exotic scenarios that clients need to be hardened against (e.g., DDOS, peer segregation, network degradation). network).
Attacknets provide an efficient and secure environment to quickly test different ideas/attacks in a private setting. Private attack networks cannot be monitored by potential adversaries and allow us to break things without disrupting the user experience of public test networks. In these environments, we regularly use disruptive techniques such as thread pausing and network partitioning to further expand scenarios.
Research on customer and infrastructure diversity 🔬
Diversity of customers and infrastructures received a lot of attention from the community. We have tools in place to monitor the diversity of a client’s, operating system’s, ISP’s and crawler’s statistics. Additionally, we analyze network participation rates, attestation timing anomalies, and overall network health. This information is common through multiple locations to highlight potential risks.
Bug bounty program 🐛
The EF currently hosts two bug bounty programs; one targeting the Execution layer and another targeting the Consensus layer. Security team members monitor incoming reports, work to verify their accuracy and impact, and then cross-reference any issues with other clients. Recently we published a disclosure of all previously reported vulnerabilities.
Soon these two programs will be merged into one, the general platform will be improved, and additional rewards will be offered to bounty hunters. Stay tuned for more information on this soon!
Operational security 🔒
Operational security encompasses many efforts within the FE. For example, asset monitoring was implemented to continuously monitor infrastructure and domains for known vulnerabilities.
Ethereum Network Monitoring 🩺
A new monitoring system for the Ethereum network is under development. This system works similarly to a SIEM and is designed to listen and monitor the Ethereum network for preconfigured detection rules as well as dynamic anomaly detection that looks for outlier events. Once in place, this system will provide early warnings of ongoing or upcoming network disruptions.
Threat Analysis 🩻
Our team conducted a threat analysis focused on The Merge to identify areas that can be improved in terms of security. As part of this work, we collected and audited security practices for code reviews, infrastructure security, developer security, build security (DAST, SCA and SAST integrated with CI, etc. ), repository security, and much more from client teams. Additionally, this analysis examined how to prevent misinformation, from which disasters can arise, and how the community could recover in various scenarios. Some efforts related to disaster recovery exercises are also of interest.
Ethereum Client Security Group 🤝
As we approach The Merge, we formed a security group composed of members of client teams working on both the execution layer and the consensus layer. This group will meet regularly to discuss security-related issues such as vulnerabilities, incidents, best practices, ongoing security work, suggestions, etc.
Incident response 🚒
The Blue Team’s efforts help bridge the gap between the execution layer and the consensus layer as The Merge gets closer. Situation rooms for incident response have worked well in the past, where discussions arose with those affected during incidents, but with The Merge, a new complexity arises. Additional work is underway to (for example) share tools, create additional debugging and sorting functionality, and create documentation.
Thank you and get involved 💪
These are some of the efforts currently underway in various forms, and we look forward to sharing even more with you in the future!
If you believe you have found a security vulnerability or bug, please submit a bug report to execution layer Or consensus layer bug bounty programs! 💜🦄
