Check out our latest blogs

(This is a condensed version of our detailed report which excludes the detailed screenshots and audit logs from our systems for security reasons. The detailed report will be duly made available to all relevant parties in the course of this investigation)

Liminal 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.

https://etherscan.io/tx/0x8b99ae634e1e7180b3fcc66e8fe5d076351477077051a7bbf5ec626a9d0588ef

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:

• Sequence 1: 8e64a89386af2f223b8433a1df65db8f0ff60544b2f02c56ec02b640d6fb15a11f7dffda5b99b0292b5e02d0cc44508d7d8f994515358e9da3016d8098b2258820
• Sequence 3: 3da7c6bd7c130430cf662de3d9af067c4a0629f849e29003c40ad3979cd670720c3ceb3a61e38fb7166353e3262eb6554c3f6571807cf22f9bdc4a83a56441661f
• Sequence 8: 40082eba0f71627a3451d47132b8f4c266bc9be2bebe4424848757d10f13e76963af0b543a2357765d9f290410e919301ad065f0f2efa1233eb8634c93111f0e20

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.

In 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:

1. Thorough audit of all access tokens used on Infrastructure including,
   • Disabling all unused tokens – Done
   • Rotating all active keys – Done
2. Rotating all DB credentials – Done
3. Thorough audit of code based and paths used for tx verification – Ongoing
4. Audit of access logs for all infrastructure – Ongoing

Disclosures & Disclaimer

Liminal Custody is a compliant and insured digital asset custody and wallet infrastructure provider. Launched in April 2021, Liminal Custody is a CCSS Level 3, SOC 2 Type 2 and ISO 27001 & 27701 certified organisation. Based in Singapore, Liminal Custody has operations spread across APAC MENA and Europe, along with offices in Singapore, India and UAE. Presently the company has received FSP licence from FSRA in ADGM and has Initial Approval(IA) from VARA. Liminal Custody takes pride in supporting businesses with its qualified and insured digital asset custody platform that enables stress-free safekeeping of digital assets for institutions. It also provides a cutting-edge wallet infrastructure platform that is secure, compliant and automated and comes with a plug-and-play architecture for faster onboarding of developers, business partners and government agencies.

This incident report is provided solely for informational purposes. Liminal accepts no liability for actions taken based on the information contained herein. The content of this report is based on the data available at the time of its creation and should not be construed as a legal determination of fault or responsibility. Liminal explicitly disclaims any warranties or guarantees, expressed or implied, regarding the information’s accuracy, completeness, or reliability. The report should not be used as the sole basis for any decision-making. All readers are advised to seek independent judgment to address specific concerns and conduct thorough investigations