Over the past year, the Ethereum Foundation has significantly increased its team of dedicated security researchers and engineers. Members have come together with a variety of backgrounds ranging from cryptography, security architecture, risk management, exploit development, and have worked on red and blue teams. Members come from many different fields and have worked to secure everything from the internet services we all depend on every day, to national health systems and central banks.
As The Merge approaches, the team spends a lot of effort analyzing, auditing, and investigating the consensus layer in various ways, as well as The Merge itself. A sample of the work is below.
Client implementation audits 🛡️
Team members audit the various customer implementations with a variety of tools and techniques.
Automated scans 🤖
Automated scans for codebases are aimed at finding close-up 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.
Since many different languages are used between clients, we use generic and language-specific scanners for codebases and images. These are interconnected through a system that analyzes and reports new findings from all the tools in the relevant channels. These automated scans make it possible to quickly get reports on problems that potential adversaries can easily find, increasing the chances of fixing problems before they can be exploited.
Manual Audits 🔨
Manual audits of stack components are also an important technique. These efforts include critical shared dependency (BLS) auditing, libp2p, new functionality in hardforks (eg synchronization committees on Altair), a thorough audit on a specific client implementation, or L2 and bridging audits.
Additionally, when vulnerabilities are reported through the Ethereum bug bounty programinvestigators can cross-reference issues with all customers to see if they are also affected by the reported issue.
Third party audits 🧑🔧
Sometimes third-party firms are hired to audit various components. Third-party audits are used to gain external insights into new customers, updated protocol specifications, upcoming network upgrades, or anything else deemed to be of high value.
During third-party audits, our team’s software developers and security researchers work with the auditors to educate and assist at all times.
Fuzzing 🦾
There are many ongoing fuzzing efforts led by our security researchers, members of customer teams, and collaborators in the ecosystem. Most of the tools are open source and run on a dedicated infrastructure. Fuzzers target critical attack surfaces such as RPC handlers, state transition and branch 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.
Simulation and tests at the network level 🕸️
Security researchers on our team create and use tools to simulate, test, and attack controlled network environments. These tools can quickly activate local and external testnets (“attacknets”) running in various configurations to test exotic scenarios that customers need to protect against (eg DDOS, peer segregation, network degradation). .
Attacknets provides an efficient and secure environment to quickly test different ideas/attacks in a private environment. Private attack networks cannot be monitored by potential adversaries and allow us to break things without disrupting the user experience of public testnets. In these environments, we regularly use disruptive techniques like thread pausing and network partitioning to further expand the scenarios.
Infrastructure and customer diversity research 🔬
Diversity of clients and infrastructure It has received a lot of attention from the community. We have tools to monitor the diversity of statistics from a client, OS, ISP and tracker. In addition, we look at network engagement rates, certification time anomalies, and overall network health. This information is shared at the other side of multiple places to highlight any potential hazards.
Bug bounty program 🐛
EF currently hosts two bug bounty programs; one pointing to execution layer and another addressed to consensus layer. Security team members monitor incoming reports, work to verify their accuracy and impact, and then cross-reference any issues with other customers. We recently published a disclosure of all previously reported vulnerabilities.
Soon these two programs will be merged into one, the overall platform will be improved, and additional rewards will be provided for bounty hunters. Stay tuned for more on this soon!
Operational Safety 🔒
Operational Safety encompasses many efforts in the EF. For example, asset monitoring has been set up that continually monitors infrastructure and domains for known vulnerabilities.
Ethereum network monitoring 🩺
A new Ethereum network monitoring system is being developed. This system works similar to a siem and is designed to listen and monitor the Ethereum network for pre-configured detection rules, as well as dynamic anomaly detection that looks for outlier events. Once installed, this system will provide early warnings of ongoing or upcoming network outages.
Threat Analysis 🩻
Our team conducted a threat analysis focused on The Merge to identify areas for improvement regarding security. Within this work, we collect and audit security practices for code reviews, infrastructure security, developer security, build security (DAST, SCA, and SAST built into CI, etc.), repository security, and more from the development teams. customers. Additionally, this analysis investigated how to prevent misinformation, what disasters can arise from, and how the community might recover in various scenarios. Some efforts related to disaster recovery exercises are also of interest.
Ethereum Client Security Group 🤝
As The Merge approaches, we formed a security group consisting 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 🚒
Blue Team’s efforts help bridge the gap between the Execution Layer and the Consensus Layer as the Merge approaches. War rooms for incident response have worked well in the past, when chats with relevant people arose during incidents, but with The Merge comes a new complexity. More work is being done to (for example) share tools, create additional debugging and classification capabilities, and create documentation.
Thank you and participate 💪
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 think you have found a security vulnerability or bug, please submit a bug report to execution layer either consensus layer Bug bounty programs! 💜🦄
