What Happened At WazirX? Liminal Custody Provides Inside Details
The attackers targeted the exchange’s Safe Multisig wallet on the Ethereum network, displaying the complexity and precision of a professional criminal operation
India's leading crypto currency exchange WazirX suffered a massive breach on Thursday, where its wallet was drained out by digital thieves leading to $230 million (approximately Rs 2000 crores). The attackers targeted the exchange’s Safe Multisig wallet on the Ethereum network, displaying the complexity and precision of a professional criminal operation. The sophisticated nature of the hack has fueled speculation about the involvement of the Lazarus Group, a notorious North Korean cybercrime cartel known for its activities in the crypto sphere.
But Liminal, which has been providing its services to WazirX per a contract dated 31 January 2023, has detailed what really could have happened.
What Liminal Says
In light of the recent incident, where WazirX’s Gnosis SAFE smart contract wallet was drained, Liminal has prepared a detailed report outlining the sequence of events and the potential cause of the breach.
First of all it is pertinent to note that Liminal’s infrastructure is not breached and all wallets on Liminal’s infrastructure, including WazirX’s other Gnosis SAFE wallets deployed entirely from within Liminal’s platform continue to remain safe & secure. None of Liminal’s customers have been impacted and the platform has been successfully operating and processing millions of dollars in transactions and withdrawals for all Liminal clients without any hitches.
The WazirX team requested Liminal to import an existing SAFE contract on the Liminal platform and our team helped them with the same. This is the only wallet that was compromised in the incident. This wallet was a self custodial, multi-signature, Gnosis SAFE smart contract wallet which was deployed by WazirX as per their configuration well before onboarding with Liminal. As per WazirX’s request this wallet was imported into the Liminal platform to provide a single interface for easy operations to the WazirX operations team.
This contract was set as 4 of 6 multisig with 5 users from WazirX holding the keys which are never exposed to Liminal and one HSM key from Liminal that acts at the behest of authorizations from WazirX’s platform and proceeds to sign transactions.
From our detailed investigations and forensic reports, it is evident that the genesis of this hack stems from three compromised devices at WazirX’s end.
Once the malicious smart contract was deployed, all transactions for fund withdrawals were also made from outside of Liminal’s infrastructure.
The entire sequence of events starts and we have identified the sequences and collated all the logs and transactions that led to the unfortunate incident that started Jul 18, 2024 at 10:08 AM. The following outlines some of the key sequences that explain our position.
First important transaction was part of Sequence #1 – the First Signature Exploit
One of the three victims attempted creating a GALA transaction. However, the transaction that victim 1 created and sent to the Liminal platform, came to Liminal’s platform with a signature mismatch. The Liminal platform rejected the transaction and displayed an error stating that the transaction creation has failed. Now the fact that Liminal provides the correct safeTxHash in the transaction pre-build and receives malicious safeTxhash and signature from the user’s device in return points to the fact that this was a malicious GALA transaction from the victim’s machine, which was already compromised.
Result:
Liminal platform rejected this transaction as tx data did not match the data that was created in step 1. A failure error was displayed to victim 1 on the Liminal platform. Either way, the moment the user sent the signed transaction to Liminal for approval, the signature was already exposed to the attackers owing to the victim’s compromised machine. It is evident that the attacker compromised the machine, and they were able to change the payload using a sophisticated MIM attack or similar client side compromise. A forensic analysis of the victim’s signer machines will likely uncover more details and help address the root cause of this issue.
This is where the first signature exploit was completed.
The attacker now has access to the 1st signature for Gnosis safe. This signature would be retrieved and used at a later stage.
Next important transaction was Sequence #3 – the Second Signature Exploit
Since victim 1 was not able to create the GALA transaction, victim 2 tried to create a transaction. Once again victim 2 tried to create a legitimate GALA transaction, however, the signed transaction received by Liminal included the malicious payload and once again the transaction was rejected by Liminal owing to the mismatch in transaction information and the payload. This points to the compromise of victim 2’s local machine as well, and the attacker was able to include the malicious payload into this seemingly legitimate transaction. Once victim 2 signed this transaction, he exposed the signature for the malicious transaction to the attacker via his local device. When this transaction was sent to Liminal, as expected, the Liminal platform rejected the transaction and displayed an error stating that his transaction creation failed.
Result:
Liminal platform rejected this transaction as tx data did not match the data that was created in sequence #3. The user would have seen a failure error on their side. We believe the attacker has compromised the machine, which explains the mismatch in payload emerging from the transactions generated by victim 2 as well. This is likely to have been executed using a sophisticated MIM attack or similar client side compromise.
This is where the second signature exploit was completed.
Attacker had access to 2nd signature for Gnosis safe now, which would be retrieved and used in a later stage.
Next important transaction took place in sequence #8 – the Third Signature Exploit
By now the attacker already had signatures from victim 1 and victim 2. The third exploit came as a result of an approval attempt to a legitimate USDT transaction, which was started by victim 1 and had two valid signatures. Victim 3 tried to approve this USDT transaction, however his compromised machine came into play and he ended up providing a signature for the malicious payload injected by the attacker, thereby exposing the third signature to the attacker. Once Liminal received the third and final signature from all three WazirX users, the Liminal signer provided the final signature and sent the transaction on blockchain. While the transaction failed due to one of the signatures being an invalid signature (i.e. victim 3’s) the attacker’s purpose of acquiring the third signature was complete.
Now it was clear that the attacker had unauthorized access to victim 3’s machine as well, as the attacker could inject the malicious payload.
Below is the transaction that went on chain and eventually failed due to one of the signatures being invalid.
This is where the third signature exploit was completed.
The attacker now had access to the 3rd signature for Gnosis safe, which was used to generate the malicious transaction.
Final transaction was from Sequence #14
Where the attacker used the signature created in Sequence #8 and approved the fake transaction. The transaction may have used the existing login session of the user to generate a request.
The final malicious transactions had below signatures which were retrieved from:
After all authorized signatures required for tx were received, Liminal provided the final signature. The transaction was crafted in such a way that the fields used to verify policies were using legit transaction details.
The attacker used the Nonce from the failed USDT transaction because that was the latest transaction.
Some of the steps in sequence were done in a very short time (within a span of seconds), indicating some automation was used, which once again points to unauthorized device access.
Conclusion
To reiterate, there is no breach found on Liminal’s infrastructure and it continues to run seamlessly processing transactions and withdrawals. As detailed in our previous response, there is no breach in Liminal’s infrastructure, wallets and assets. Unfortunately three of the victims machines have been found injecting malicious payloads into the transaction indicating a sophisticated, well planned and targeted attack on one specific Gnosis Smart Contract Multi-Sig wallet.
Frequently Asked Questions
Q1.How did the attacker gain access to all three WazirX signatures to deploy the malicious transaction?
This remain unclear and will require a forensic investigation
Q2. How did the UI show a different value from the actual payload within the transaction?
Based on our logs, given that three devices of the victim’s shared transactions sent out malicious payloads to Liminal’s server, we have reason to believe that the local machines were compromised giving the attacker complete access to modify the payloads and display misleading transaction details on the UI.
Q3. Why did the Liminal signer sign this transaction?
Liminal only provides the final signature once the required number of valid signatures are received from the client’s side. In this case, since the transaction was authorised and signed by three of our client’s employees, Liminal’s key added the final approval.
Immediate Security Actions Initiated by Liminal
As an immediate standard operating procedure to ensure hardened security, we have taken all necessary precautionary steps and also carried out the below safety measures:
Thorough audit of all access tokens used on Infrastructure including,
Disabling all unused tokens – Done
Rotating all active keys – Done
Rotating all DB credentials – Done
Thorough audit of code based and paths used for tx verification – Ongoing
Audit of access logs for all infrastructure – Ongoing
Ziminal has been providing its services to WazirX per a contract dated 31 January 2023. In light of the recent incident, where WazirX’s Gnosis SAFE smart contract wallet was drained, Liminal has prepared a detailed report outlining the sequence of events and the potential cause of the breach.
First of all it is pertinent to note that Liminal’s infrastructure is not breached and all wallets on Liminal’s infrastructure, including WazirX’s other Gnosis SAFE wallets deployed entirely from within Liminal’s platform continue to remain safe & secure. None of Liminal’s customers have been impacted and the platform has been successfully operating and processing millions of dollars in transactions and withdrawals for all Liminal clients without any hitches.
The WazirX team requested Liminal to import an existing SAFE contract on the Liminal platform and our team helped them with the same. This is the only wallet that was compromised in the incident. This wallet was a self custodial, multi-signature, Gnosis SAFE smart contract wallet which was deployed by WazirX as per their configuration well before onboarding with Liminal. As per WazirX’s request this wallet was imported into the Liminal platform to provide a single interface for easy operations to the WazirX operations team.
This contract was set as 4 of 6 multisig with 5 users from WazirX holding the keys which are never exposed to Liminal and one HSM key from Liminal that acts at the behest of authorizations from WazirX’s platform and proceeds to sign transactions.
From our detailed investigations and forensic reports, it is evident that the genesis of this hack stems from three compromised devices at WazirX’s end.
Once the malicious smart contract was deployed, all transactions for fund withdrawals were also made from outside of Liminal’s infrastructure.
The entire sequence of events starts and we have identified the sequences and collated all the logs and transactions that led to the unfortunate incident that started Jul 18, 2024 at 10:08 AM. The following outlines some of the key sequences that explain our position.
First important transaction was part of Sequence #1 – the First Signature Exploit
One of the three victims attempted creating a GALA transaction. However, the transaction that victim 1 created and sent to the Liminal platform, came to Liminal’s platform with a signature mismatch. The Liminal platform rejected the transaction and displayed an error stating that the transaction creation has failed. Now the fact that Liminal provides the correct safeTxHash in the transaction pre-build and receives malicious safeTxhash and signature from the user’s device in return points to the fact that this was a malicious GALA transaction from the victim’s machine, which was already compromised.
Result:
Liminal platform rejected this transaction as tx data did not match the data that was created in step 1. A failure error was displayed to victim 1 on the Liminal platform. Either way, the moment the user sent the signed transaction to Liminal for approval, the signature was already exposed to the attackers owing to the victim’s compromised machine. It is evident that the attacker compromised the machine, and they were able to change the payload using a sophisticated MIM attack or similar client side compromise. A forensic analysis of the victim’s signer machines will likely uncover more details and help address the root cause of this issue.
This is where the first signature exploit was completed.
The attacker now has access to the 1st signature for Gnosis safe. This signature would be retrieved and used at a later stage.
Next important transaction was Sequence #3 – the Second Signature Exploit
Since victim 1 was not able to create the GALA transaction, victim 2 tried to create a transaction. Once again victim 2 tried to create a legitimate GALA transaction, however, the signed transaction received by Liminal included the malicious payload and once again the transaction was rejected by Liminal owing to the mismatch in transaction information and the payload. This points to the compromise of victim 2’s local machine as well, and the attacker was able to include the malicious payload into this seemingly legitimate transaction. Once victim 2 signed this transaction, he exposed the signature for the malicious transaction to the attacker via his local device. When this transaction was sent to Liminal, as expected, the Liminal platform rejected the transaction and displayed an error stating that his transaction creation failed.
Result:
Liminal platform rejected this transaction as tx data did not match the data that was created in sequence #3. The user would have seen a failure error on their side. We believe the attacker has compromised the machine, which explains the mismatch in payload emerging from the transactions generated by victim 2 as well. This is likely to have been executed using a sophisticated MIM attack or similar client side compromise.
This is where the second signature exploit was completed.
Attacker had access to 2nd signature for Gnosis safe now, which would be retrieved and used in a later stage.
Next important transaction took place in sequence #8 – the Third Signature Exploit
By now the attacker already had signatures from victim 1 and victim 2. The third exploit came as a result of an approval attempt to a legitimate USDT transaction, which was started by victim 1 and had two valid signatures. Victim 3 tried to approve this USDT transaction, however his compromised machine came into play and he ended up providing a signature for the malicious payload injected by the attacker, thereby exposing the third signature to the attacker. Once Liminal received the third and final signature from all three WazirX users, the Liminal signer provided the final signature and sent the transaction on blockchain. While the transaction failed due to one of the signatures being an invalid signature (i.e. victim 3’s) the attacker’s purpose of acquiring the third signature was complete.
Now it was clear that the attacker had unauthorized access to victim 3’s machine as well, as the attacker could inject the malicious payload.
Below is the transaction that went on chain and eventually failed due to one of the signatures being invalid.
This is where the third signature exploit was completed.
The attacker now had access to the 3rd signature for Gnosis safe, which was used to generate the malicious transaction.
Final transaction was from Sequence #14
Where the attacker used the signature created in Sequence #8 and approved the fake transaction. The transaction may have used the existing login session of the user to generate a request.
The final malicious transactions had below signatures which were retrieved from:
After all authorized signatures required for tx were received, Liminal provided the final signature. The transaction was crafted in such a way that the fields used to verify policies were using legit transaction details.
The attacker used the Nonce from the failed USDT transaction because that was the latest transaction.
Some of the steps in sequence were done in a very short time (within a span of seconds), indicating some automation was used, which once again points to unauthorized device access.
Conclusion
To reiterate, there is no breach found on Liminal’s infrastructure and it continues to run seamlessly processing transactions and withdrawals. As detailed in our previous response, there is no breach in Liminal’s infrastructure, wallets and assets. Unfortunately three of the victims machines have been found injecting malicious payloads into the transaction indicating a sophisticated, well planned and targeted attack on one specific Gnosis Smart Contract Multi-Sig wallet.
Frequently Asked Questions
Q1.How did the attacker gain access to all three WazirX signatures to deploy the malicious transaction?
This remain unclear and will require a forensic investigation
Q2. How did the UI show a different value from the actual payload within the transaction?
Based on our logs, given that three devices of the victim’s shared transactions sent out malicious payloads to Liminal’s server, we have reason to believe that the local machines were compromised giving the attacker complete access to modify the payloads and display misleading transaction details on the UI.
Q3. Why did the Liminal signer sign this transaction?
Liminal only provides the final signature once the required number of valid signatures are received from the client’s side. In this case, since the transaction was authorised and signed by three of our client’s employees, Liminal’s key added the final approval.
Immediate Security Actions Initiated by Liminal
As an immediate standard operating procedure to ensure hardened security, we have taken all necessary precautionary steps and also carried out the below safety measures:
Thorough audit of all access tokens used on Infrastructure including,
Disabling all unused tokens – Done
Rotating all active keys – Done
Rotating all DB credentials – Done
Thorough audit of code based and paths used for tx verification – Ongoing
Audit of access logs for all infrastructure – Ongoing
