Man in the middle attack – Protect online merchants & payment solutions

 

Problem Statement:

How to protect from man in the middle attack in the payment’s world?

How to integrate a payment gateway in a secure way?

Why payment gateways and online merchants need to validate hash?

Example: When a payment gateway returns response to merchant system that a transaction has FAILED, the man in middle changes the status of the transaction to SUCCESS while the message is on the way, merchant gets a transaction response with status as SUCCESS, and merchant delivers the product or service to attacker but the status of the transaction with payment gateway is FAILED.

What & How: An attacker can change content of a message when the message is on the way between two payment systems. This is an old but frequently exploited attack pattern. The above is a very basic example of such an exploit.

But you will ask me how the message can be changed when it’s secured with HTTPS encryption – It can be done without spending much time. There are different ways, mainly it captures the content of the message on the web-browser using some tools and changes the content. If you want to learn how to perform an attack, then you may want to search the internet for how to guides. It’s hard to perform such an attack in a server-to-server API call, but it’s easy in case the message is flowing through the web-browser. For example, an HTTPS POST redirect by payment gateway web-application to web-application of merchant.

If you need a protection for your online payment system or not? It’s not a question of If. It’s only a matter of time when the attacker targets you.

How to know if your system is already under attack: A very basic symptom of being a victim is that there are differences in transaction status at different payment systems found at the time of reports reconciliation. For example, a merchant would say that payment gateway returned SUCCESS for a transaction but payment gateway company status that they returned FAILED. This can be validated by comparing the logs or database of the merchant vs payment gateway. One hint is that such reconciliation issues will be found with transactions of higher amount only. But sometimes it can be much sophisticated.

What can a payment gateway or online merchant do to protect against man in the middle attack:

• Validate the message hash: All messages flowing through the payment systems can be validated by generating and validating hash. It’s a simple, effective way to protect. Just make sure that there is a unique seed for each client, and the seed is not supposed to be part of the message. Only the client and server must be aware of the seed at the time of generation and validation of the hash. Make sure that you are using a modern hashing algorithm.
• Change the hashing seed on regular interval: The hashing seed should be changed on regular intervals, may be quarterly. It should not be same for ever because sometimes it’s shared with other people without understanding the consequences. It’s like you change login password with banking systems.
• Perform a server-to-server API based inquiry: A merchant can perform a transaction status inquiry with payment gateway to be double sure of the transaction status before delivery of goods/services. A payment gateway should also perform a status inquiry (with payment processor/acquirer) before delivering a successful response to merchant. Such an inquiry should be a server-to-server call only. Almost all payment systems in the world support such inquiries. Such enquirers can be exposed through restful APIs or ISO 8583 messages.
• Reconcile your payment reports daily: A merchant must reconcile the payment reports on daily bases and should be vigilant of any mismatches. Similarly, a payment gateway should reconcile with up-stream payment solutions.
• Have positive & negative integration tests: The integration test suite must have positive and negative test cases to validate the hash. Such tests must be performed at the time of integration between two payment systems. Such test cases should also be documented in the integration specification documents and should also be part of the integration kit. The technical integration team must perform these tests before the client on-boarding is completed.
• Test invalid hash transactions on production on regular bases: One such production test case can also be set to regularly test if the hash is being validated properly.
• Be vigilant: While the above-mentioned steps can be performed but your information security is not limited to these steps. Being vigilant about what’s happening in the system and having a mind-set of security is must for protection against sophisticated attacks.

 

Thanks for your read. Don’t forget to comment if you need further information.