{"id":15759,"date":"2023-03-11T00:00:00","date_gmt":"2023-03-11T00:00:00","guid":{"rendered":"https:\/\/hederav2stg.wpenginepowered.com\/blog\/analysis-remediation-of-the-precompile-attack-on-the-hedera-network\/"},"modified":"2025-12-08T18:43:27","modified_gmt":"2025-12-08T18:43:27","slug":"analysis-remediation-of-the-precompile-attack-on-the-hedera-network","status":"publish","type":"post","link":"https:\/\/hedera.com\/blog\/analysis-remediation-of-the-precompile-attack-on-the-hedera-network\/","title":{"rendered":"Analysis & Remediation of the Precompile Attack on the Hedera Network"},"content":{"rendered":"
\n

Update March 15, 2023:<\/strong><\/p>\n

There have been some questions from the Hedera community regarding how proxy access to the network was disabled. In April 2020, Hedera\u2019s Technical Steering & Product Committee approved, via updates to Hedera\u2019s Node Policy, the placement of IP proxies in front of all Hedera network nodes as a precautionary measure to protect the network against attacks. As shared in a May 2020 Hedera blog post<\/a>, Hedera network operations staff would initially control those proxies, with full ownership and control of the proxies to be transitioned to Council member node operators over time. Currently, 14 Council members have deployed their own proxies to their nodes. Hedera network operations staff (composed of Hedera and Swirlds Labs employees) still have delegated authority and operational responsibility to retain SSH access to all the proxies on the network.<\/p>\n

When the attacker began stealing tokens from the DEXs on March 9th, the Hedera network operations team (Hedera\u2019s CIO\/CISO Alex Popowycz, Swirlds Labs\u2019s Dr. Leemon Baird (who also co-chairs the Council\u2019s Technical Steering & Product Committee), and Swirlds Labs\u2019 DevOps staff), together made the decision to disable the proxies, which prevented the exploit from being used to illicitly gain privileges to tokens managed by smart contracts (which could allow them to be stolen) and prevented the possibility of it being deployed to attack other potentially vulnerable implementations across the network. This decisive action limited the loss to ~$600K (USD equivalent).<\/p>\n

In addition, there have been questions raised regarding whether or not the unauthorized privileges that the hacker had gained for the attack had been revoked. The Hedera community, including developers and DEXs affected by the attack, worked together with the Hedera team to construct and review a whitehat smart contract that used the same exploit as the attacker. The purpose was to remove the privileges that the attacker had illicitly obtained to the DEX\u2019s accounts. The DEXs then oversaw the execution of the smart contract to ensure that the attacker no longer had any unauthorized privileges that could have been used to continue the attack. The ability for a smart contract to be deployed to edit these privileges, even by the Hedera whitehat team, was permanently removed once the mainnet code was updated by the Hedera Council.<\/p>\n

***<\/p>\n

On Thursday, March 9, an attacker exploited the Smart Contract Service code of the Hedera mainnet to transfer Hedera Token Service (HTS) tokens held by certain DEXs\u2019 accounts to the attacker\u2019s own account. The following is a summary of the attack: how it happened, steps taken to pause the attack and then permanently prevent it from happening again.<\/p>\n

TL;DR<\/strong><\/p>\n