Blockchain Network is Secured! But not the apps and their Integrations

Overview

During the security assessment for a blockchain-based web application, it was observed that some of the functions were vulnerable to unauthenticated ETH transfer from an admin wallet to the attacker’s wallet. The web application was a booking application where a user can book tickets and pay with a crypto token. Also, the application was integrated with Metamask framework to support web3 transactions over the blockchain.

Workflow

1.       User Initiates the ticket booking function. Let us say one ticket (T1) needs a payment of (0.1 ETH) to be transferred to the admin’s wallet.
2.       The web application sends the request to transfer 0.1 ETH from the integrated Metamask wallet.
3.       User signs the transaction from Metamask.
4.       After a successful transaction of 0.1 ETH, the web application confirms the payment with a POST API call to https://Redacted.com/api/v1/wallet/metamask_send_token

5. Now as the application has the successful transaction confirmation from Metamask, the ticket is booked for the user via a POST request

https://Redacted.com/api/v1/booking/book_ticket/

6. This POST request is intended for a successful transaction. It contains two parameters i.e., transaction_hash and total_tickets. It is identified that these two parameters are not mapped together.
7. Since it only checks for the transaction_hash, the other parameter can be manipulated in order to book multiple tickets with the same amount.
8. A malicious user can tamper the “total_tickets” parameter and can book any number of tickets just for 0.1 ETH. For this given example we have booked 100 tickets for 0.1 ETH.
9. While further exploiting the vulnerability, it was identified that there was a function that allows the user to cancel the booking and get the corresponding refund.
10. When a user cancels the booked ticket, the backend server only validates whether the booked ticket is valid or not. Post successful verification, the refund is initiated.
11. The following functions are executed upon accessing this functionality flow:
    • Get_total_booked_ticket()
    • Refund()
12. If the users’ wallet contains valid ticket IDs then the underlying server executes a POST request sent to the endpoint: https://Redacted.com/api/v1/booking/cancel_ticket/ with user_ ID and “ticket_id” as the parameters. The backend server retrieves the ticket’s value from the “ticket_id” and sends the ETH to the user’s wallet.

13. Any Refund/Purchase transactions are directed to/from the admin’s wallet
14. Since the API call lacks proper mapping between its request parameters and doesn’t validate the transactions corresponding to the ticket numbers, a malicious user can easily leverage this flaw to substantially increase the number of tickets and get a refund of more than the amount expended.
15. Here 100+ tickets were booked for the purchase of 1 ticket that costs 0.1 ETH. Upon initiating a refund any amount can be retrieved back just by merely changing the number of tickets.

16. As there were a large number of valid tickets in this case, a threat actor can retrieve up to 10 ETH (100*0.1=10) from the admins’ wallets and exhaust the ETH from the admin’s wallet.

17. This payment flaw was further confirmed by verifying the blockchain hashes from Etherscan(a website that tracks all Ether-based blockchain transactions)

Conclusion

The Blockchain network is indeed hard to penetrate as Blockchain has the secure network to build the DAPPS, but the application architecture, Source code, Workflow, and configurations are always open for such attacks. It is necessary to apply security audits and regular assessments to discover the vulnerabilities and bugs in the workflow. A small issue can lead to unauthenticated token drainage from the wallets that will make a bad impact on the users as well as on the whole community.

About Author

Keyur Talati
Security Analyst – WeSecureApp