Replay Attack in payment apps

Hello, I’m Wareeq Shile and I’d like to share a recent discovery I made regarding a logic vulnerability in a payment system. This vulnerability allowed an attacker to add funds to an account using a previously authorized callback request. I must note that the target company’s name has been withheld to protect their privacy.

BACKGROUND

Replay attacks occur when a message between a client and a server is copied and replayed at a later time, potentially with altered parameters. These attacks can be successful if the server does not have measures in place, such as message signature validation, to prevent parameter manipulation. Even if a message is signed or encrypted, it may still be vulnerable to replay attacks if it was originally sent by a trusted party.

It is common for payment systems to redirect users to a specific page after a payment has been processed or has failed. However, it is possible for an attacker to replay a request for a successful payment in order to authorize a transaction that has not yet been processed.

Applications can be vulnerable to serious security issues if they trust replayed requests without properly validating them to ensure they have not already been received or are being sent in the correct order.

CASE STUDY

One example of a replay attack can be seen in a payment system where a user is redirected to a specific page after a successful or failed payment. It is possible to replay a request for a successful payment to authorize a transaction that has not yet been processed. If an application trusts replayed requests without performing any further validation, it can be vulnerable to serious security issues.

To illustrate this vulnerability, let’s consider a scenario where a user owes $5000 credit on an application. The user makes a payment of $1000 and is redirected to a third-party website to complete the payment. After the payment is successful, the user is redirected back to the application and confirms the payment of $1000, reducing their debt to $4000. If the user is able to intercept and repeat the callback request that confirms the payment was successful using a tool like Burp Repeater, they can reduce their debt to $3000 without actually spending any additional money. This is possible because the application does not enforce proper checks to prevent replay attacks.

In this example, I demonstrate how a vulnerability in a payment system’s lack of proper validation allowed me to exploit it through a replay attack. By intercepting and understanding the requests and responses of a successful payment transaction, I was able to use a tool like Burp Repeater to repeat the request and trick the server into thinking I had made additional payments. As a result, I was able to pay off all my debt without actually spending any more money. This vulnerability highlights the importance of implementing proper checks and validation in order to prevent unauthorized transactions and protect sensitive financial information.

CONCLUSION

In this particular instance, the application was vulnerable to replay attacks due to a lack of proper validation to check if requests had already been received or sent in the correct order. This allowed me to repeat a request for a successful payment, effectively bypassing the payment process and reducing my debt on the application without spending any additional money.

Replay attacks can be difficult to detect with automated scans, as they often involve the application functioning as intended but lacking proper validation for sensitive actions. In this case, it was similar to a cross-site request forgery (CSRF) attack.

To conclude, replay attacks have been around for some time and it is important for testers to be aware of them. Proper validation and message signature validation are key in preventing these types of vulnerabilities. .