The proxy design pattern allows Ethereum smart contracts to be simultaneously immutable and upgradeable, in which an original contract is split into a proxy contract containing the data storage and a logic contract containing the implementation logic. This architecture is known to have security issues, namely function collisions and storage collisions between the proxy and logic contracts, and has been exploited in real-world incidents to steal users’ millions of dollars worth of digital assets. In response to this concern, several previous works have sought to identify proxy contracts in Ethereum and detect their collisions. However, they all fell short due to their limited coverage, often restricting analysis to only contracts with available source code or past transactions.To bridge this gap, we present Proxion, an automated cross-contract analyzer that identifies all proxy smart contracts and their collisions in Ethereum. What sets Proxion apart is its ability to analyze hidden smart contracts that lack both source code and past transactions. Equipped with various techniques to enhance efficiency and accuracy, Proxion outperforms the state-of-the-art tools, notably identifying millions more proxy contracts and thousands of unreported collisions. We apply Proxion to analyze over 36 million alive contracts from 2015 to 2023, revealing that 54.2% of them are proxy contracts, and about 1.5 million contracts exhibit at least one collision issue.

Blockchain networks allow multiple client implementations of the same consensus algorithm by different developers to coexist in the same system. Ensuring correct implementations among these heterogeneous clients is crucial, as even slight semantic discrepancies in their implementations can lead to safety failures. While existing fuzzing frameworks have discovered implementation flaws in blockchain, they suffer from several challenges in testing them with sequences of conflicting blocks, called forks. Existing tools fail to adequately assess the forkhandling processes in blockchain implementations when relying on traditional code coverage feedback, which lacks the granularity needed to navigate the diverse and complex fork-handling scenarios. This paper introduces FORKY, a fork state-aware differential fuzzing framework designed to detect implementation discrepancies within the critical fork-handling process with its novel fork-aware mutation and fork-diversifying feedback mechanisms. We test FORKY on the two most influential blockchain projects: Bitcoin and Ethereum, which are the representatives of the two major blockchain consensus algorithm families, Proof-of-Work (PoW) and Proof-of-Stake (PoS) consensus algorithms.

Mining pools have been the driving force for ensuring the security of multiple proof-of-work (PoW) cryptocurrencies. Under the de facto protocol Stratum, pools allow miners to collaborate, discover new blocks, and earn rewards collectively. Recently, the blockchain community has been promoting the adoption of a more secure Stratum protocol known as Stratum V2. In this paper, we introduce Erosion, a novel network-level attack that applies to both Stratum and Stratum V2 protocols. The essence of the Erosion attack lies in its ability to disrupt connections between miners and a targeted mining pool, significantly impairing the miners’ contributed PoWs and reducing the victim’s mining power. We also discover a vulnerability in the Stratum V2 protocol that allows the adversary to persistently disrupt a connection by tampering with a single packet, thus enhancing the attack’s stealthiness. Our survey shows that the Erosion adversary can readily execute attacks against a significant majority (e.g., 91%) of mining pools across the top ten cryptocurrencies. We also observe an extreme mining centralization that enables Erosion adversaries to simultaneously target multiple pools and cryptocurrencies. Furthermore, our focused evaluation of pooled mining in Bitcoin reveals that thousands of different adversaries can gain control over the majority of Bitcoin mining power, with one potentially malicious Autonomous System capable of taking down 96% of the total mining power.

The Lightning Network (LN) is a widely-adopted off-chain protocol that not only addresses Bitcoin’s scaling problem but also enables anonymous payments. Prior attacks have shown that an adversary controlling several peers at the central position of the network (e.g., by hijacking payment routes) can deanonymize such payments. However, these attacks are highly observable or require many parties to collude.This paper presents Revelio, a stealthier, passive network-level privacy attack against LN that exploits its joint centralization at the application and the network layers. Indeed, network-level adversaries can see most of the LN traffic (e.g., five autonomous systems can see up to 80 % of all observable communication channels) despite the encrypted communication between LN nodes and the widespread usage of Tor. This comprehensive view allows Revelio adversaries not only to estimate the payment amount but also to effectively reduce the anonymity size of its endpoints. We show that the Revelio attack is practical: it perfectly deanonymizes the senders or the receiver in almost one-third of tested payments in today’s LN and underlying network topologies.

Network adversaries, such as malicious transit autonomous systems (ASes), have been shown to be capable of partitioning the Bitcoin's peer-to-peer network via routing-level attacks; e.g., a network adversary exploits a BGP vulnerability and performs a prefix hijacking attack (viz. Apostolaki et al. [3]). Due to the nature of BGP operation, such a hijacking is globally observable and thus enables immediate detection of the attack and the identification of the perpetrator. In this paper, we present a stealthier attack, which we call the EREBUS attack, that partitions the Bitcoin network without any routing manipulations, which makes the attack undetectable to control-plane and even to data-plane detectors. The novel aspect of EREBUS is that it makes the adversary AS a natural man-in-the-middle network of all the peer connections of one or more targeted Bitcoin nodes by patiently influencing the targeted nodes' peering decision. We show that affecting the peering decision of a Bitcoin node, which is believed to be infeasible after a series of bug patches against the earlier Eclipse attack [29], is possible for the network adversary that can use abundant network address resources (e.g., spoofing millions of IP addresses in many other ASes) reliably for an extended period of time at a negligible cost. The EREBUS attack is readily available for large ASes, such as Tier-1 and large Tier-2 ASes, against the vast majority of 10K public Bitcoin nodes with only about 520 bit/s of attack traffic rate per targeted Bitcoin node and a modest (e.g., 5-6 weeks) attack execution period. The EREBUS attack can be mounted by nation-state adversaries who would be willing to execute sophisticated attack strategies patiently to compromise cryptocurrencies (e.g., control the consensus, take down a cryptocurrency, censor transactions). As the attack exploits the topological advantage of being a network adversary but not the specific vulnerabilities of Bitcoin core, no quick patches seem to be available. We discuss that some naive solutions (e.g., whitelisting, rate-limiting) are ineffective and third-party proxy solutions may worsen the Bitcoin's centralization problem. We provide some suggested modifications to the Bitcoin core and show that they effectively make the EREBUS attack significantly harder; yet, their non-trivial changes to the Bitcoin's network operation (e.g., peering dynamics, propagation delays) should be examined thoroughly before their wide deployment.

In light of ever-increasing scale and sophistication of modern distributed denial-of-service (DDoS) attacks, recent proposals show that in-network filtering of DDoS traffic at a handful of transit networks can handle volumetric attacks effectively. In this paper, we identify a subtle but important security risk in existing in-network filtering proposals. That is, a transit network may use the in-network filtering services as an excuse for any arbitrary packet drops made for its own benefit. For example, a malicious transit network may execute any filtering rules to discriminate against some of its neighboring networks based on its business preference while claiming that it is for the purpose of DDoS defense. We argue that this is due to the lack of verifiable filtering-i.e., no single party can check if a transit network executes the filter rules correctly as requested by the DDoS victims. To make in-network filtering a more robust defense primitive, we propose a verifiable in-network filtering system, called VIF, that exploits emerging hardware-based trusted execution environments (TEEs) and offers filtering verifiability to DDoS victims and neighboring networks. Our proof of concept demonstrates that a VIF filter implementation on commodity servers with TEE support can handle traffic at line rate (e.g., 10 Gb/s) and execute up to 3,000 filter rules. We show that VIF can scale to handle larger traffic volume (e.g., 500 Gb/s) and more complex filtering operations (e.g., 150,000 filter rules) by parallelizing the TEE-based filters. As a practical deployment model, we suggest that Internet exchange points (IXPs) are the good candidates to be early adopters of our verifiable filters due to their central locations and flexible software-defined architecture. Our large-scale simulations of two realistic attacks (i.e., DNS amplification, Mirai-based flooding) show that adopting VIF filtering service at only a small number (e.g., 5-25) of large IXPs is sufficient to handle the majority (e.g., up to 80-90%) of DDoS traffic.

Large botnet-based flooding attacks have recently demonstrated unprecedented damage. However, the best-known end-to-end availability guarantees against flooding attacks require costly global-scale coordination among autonomous systems (ASes). A recent proposal called routing around congestion (or RAC) attempts to offer strong end-to-end availability to a selected critical flow by dynamically rerouting it to an uncongested detour path without requiring any inter-AS coordination. This paper presents an in-depth analysis of the (in)feasibility of the RAC defense and points out that its rerouting approach, though intriguing, cannot possibly solve the challenging flooding problem. An effective RAC solution should find an inter-domain detour path for its critical flow with the two following desired properties: (1) it guarantees the establishment of an arbitrary detour path of its choice, and (2) it isolates the established detour path from non-critical flows so that the path is used exclusively for its critical flow. However, we show a fundamental trade-off between the two desired properties, and as a result, only one of them can be achieved but not both. Worse yet, we show that failing to achieve either of the two properties makes the RAC defense not just ineffective but nearly unusable. When the newly established detour path is not isolated, a new adaptive adversary can detect it in real time and immediately congest the path, defeating the goals of the RAC defense. Conversely, when the establishment of an arbitrary detour path is not guaranteed, more than 80% of critical flows we test have only a small number (e.g., three or less) of detour paths that can actually be established and disjoint from each other, which significantly restricts the available options for the reliable RAC operation. The first lesson of this study is that BGP-based rerouting solutions in the current inter-domain infrastructure seem to be impractical due to implicit assumptions (e.g., the invisibility of poisoning messages) that are unattainable in BGP's current practice. Second, we learn that the analysis of protocol specifications alone is insufficient for the feasibility study of any new defense proposal and, thus, additional rigorous security analysis and various network evaluations, including real-world testing, are required. Finally, our findings in this paper agree well with the conclusion of the major literature about end-to-end guarantees; that is, strong end-to-end availability should be a security feature of the Internet routing by design, not an ad hoc feature obtained via exploiting current routing protocols.

Bitcoin provides only pseudo-anonymous transactions, which can be exploited to link payers and payees -- defeating the goal of anonymous payments. To thwart such attacks, several Bitcoin mixers have been proposed, with the objective of providing unlinkability between payers and payees. However, existing Bitcoin mixers can be regarded as either insecure or inefficient.