Vulnerability of Hashing Algorithm in MIGS Platform
With the advent of credit cards and the Internet, shopping has become much easier and, as they say, safer. Just a couple of clicks and the product you need is on the way to your home. However, not all systems are perfect, or rather there are none. You can always find some kind of mistake, a breach, allowing attackers to do their dirty work. Today I would like to draw your attention to the study of a very talented programmer Yohanes Nugroho, who spoke about vulnerabilities in the MIGS system.
This text is a translation of the words of the explorer Yohanes Nugroho himself. Have a nice acquaintance.
Vulnerability of Hashing Algorithm in MIGS Platform
Last year, I discovered an error in the MD5-based hashing algorithm that MIGS (Mastercard Internet Gateway Service) used. She allowed to make changes to the size of the transaction. The company rewarded me for finding this problem. In the same year, MIGS switched to the use of HMAC-SHA256, but even there it was not without a vulnerability.
What is MIGS?
When you pay on a website, its owners usually connect their system to an intermediate payment gateway (it goes to another page). This payment gateway is then connected to several payment systems available in a particular country. For credit cards, many gateways connect to other gateways (one of which is MIGS), which work with many banks to provide 3DSecure.
How it works?
The sequence of payment, if you use MIGS, usually looks like this:
- You choose the product on the site.
- Enter your credit card number.
- The card number, payment amount and other parameters are signed and returned back to the browser, which automatically generates a POST request to the intermediate payment gateway.
- This gateway converts information into a format that is supported by MIGS, signs with a MIGS key and returns to the browser. After that, the browser forms another POST request to the MIGS server itself.
- If the 3DSecure service is not enabled, then this step is skipped. Otherwise, MIGS transfers the request to the bank that issued the card. The bank requests OTP and generates HTML, which generates a POST request for the MIGS server.
- MIGS returns the signed data to the browser and creates a POST request for the intermediate payment gateway.
- Validation of data and signature by an intermediate payment gateway. If the data is incorrect, then an error page is generated.
- Based on the MIGS reply, the payment gateway transmits the payment status to the merchant.
MD5-based hashing algorithm vulnerability
This error is very simple. In the hashing method, the following formula is used:
MD5 (Secret + Data)
But there is no vulnerability to hash lengthening (some checks were performed to prevent this). Data (Data) is formed in this way: all query parameters that begin with vpc_ are sorted, and then the values are linked without separation. For example, we have the following data:
Name: Joe
Amount: 10,000
Card: 1234567890123456
vpc_Name = Joe & Vpc_Amount = 10000 & vpc_Card = 1234567890123456
Apply sorting:
vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = Joe
We connect values:
100001234567890123456Joe
Notice if I change the parameters:
vpc_Name = Joe & Vpc_Amount = 1 & vpc_Card = 1234567890123456 & vpc_B = 0000
Apply sorting:
vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = Joe
We connect values:
100001234567890123456Joe
That MD5 value will be the same. That is, in fact, when the data is transferred to MIGS, we can add an additional parameter after the amount of payment to remove the last digit, or before it - to remove the first digit. And you can pay $ 2 instead of 2000 for a MacBook.
Intermediate gateways and vendors can avoid this vulnerability by always checking whether the amount of payment returned by MIGS matches what was requested.
MasterCard rewarded me for revealing this mistake with a premium of $ 8500.
HMAC-SHA256 hash vulnerability
The new system HMAC-SHA256 has a vulnerability that can be used if we inject the wrong values into the intermediate payment gateway. I checked the presence of this error on one of the payment gateways (Fusion Payments). They paid me a $ 500 premium for this. This vulnerability may affect other payment gateways connected to MIGS.
In the new version, separators (&) between fields, field names (not only values) and, of course, HMAC-SHA256 were added. For the same data as before, the hashed string looks like this:
Vpc_Amount = 10000 & vpc_Card = 1234567890123456 & vpc_Name = Joe
We can not move anything, everything in this plan is in order. But what if the value contains the characters & or = or some other?
After reading the MiGS Virtual Payment Client Integration Reference document, I found:
"Note: The value in all name / value pairs, for the purpose of hashing, must NOT contain URL characters"
I focus on " NOT ". This means if we have the following fields:
Amount = 100
Card = 1234
CVV = 555
Hashing is as follows: HMAC (Amount = 100 & Card = 1234 & CVV = 555)
And if the fields are (using & and =):
Amount = 100 & Card = 1234
CVV = 555
That hashing looks like this: HMAC (Amount = 100 & Card = 1234 & CVV = 555)
Similar. But so far not such a problem.
Of course, I thought that there might be a problem in the official documentation, maybe the URL symbols should still be used. But I checked the behavior of the MIGS server, everything was the same as in the document. Maybe they do not want to work with another encoding (like + instead of% 20).
It seems there should be no problems, incorrect values will be checked by MIGS and will give an error (for example, an incorrect amount of payment will be rejected).
But I noticed that in some payment gateways, instead of checking the entered data on the side of their server, everyone simply signs and redirects to MIGS. It is much easier to check JavaScript on the client side, sign the data on the server side, and then let MIGS decide whether the card number is correct, whether the CVV should consist of 3 or 4 digits, whether the card should be valid, etc. The logic is: MIGS will double-check the data and make it better.
At Fusion Payments, I found out that this is the case: they allow you to enter any length of CVV code (validation takes place only in JavaScript), then sign the request and send it to MIGS.
Exploit
To exploit this vulnerability, we need to create a string that will be the correct query and get the correct response from the MIGS server. We do not need to contact the MIGS server, we will simply force the client to sign the correct data.
Basic query:
vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25%
And the basic response from the server will be:
vpc_Message = Approved & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 72281965821313 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & vpc_eze
In the case of Fusion Payment, the exploit is implemented by implementing vpc_CardSecurityCode (CVV)
vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999% 26vpc_Message% 3DApproved% 26vpc_OrderInfo% 3DORDERINFO% 26vpc_ReceiptNo% 3D722819658213% 26vpc_TransactionNo% 3D2000834062% 26vpc_TxnResponseCode% 3D0% 26vpc_Z% 3Da & vpc_OrderInfo = ORDERINFO & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256
The client / payment gateway generates the correct hash for this string.
Now we can enter this data into the client itself (without any interaction with the MIGS server), but we will change them a bit so that the client recognizes the necessary variables (most clients check only vpc_TxnResponseCode and vpc_TransactionNo):
vpc_AccessCode = 9E33F6D7% 26vpc_Amount% 3D25% 26vpc_Card% 3DVisa% 26vpc_CardExp% 3D1717% 26vpc_CardNum% 3D4599777788889999% 26vpc_CardSecurityCode% 3D999 & vpc_Message = Approved & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_Z = a% 26vpc_OrderInfo% 3DORDERINFO & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256
Notice:
Hashing will be the same as with previous data.
The client will ignore the vpc_AccessCode and its value.
The client will process vpc_TxnResponseCode, etc., assuming that the transaction is correct.
It can be said that this is a client MIGS error, but the hash method used by MasterCard allows this error to exist. If the values were encoded, this vulnerability would not exist.
Answer from MIGS
MasterCard did not respond to this bug in HMAC-SHA256. I contacted several people with whom I had previously spoken about previous vulnerabilities. No answer. Even the "we check it" formal replies. They have my Facebook if they want to contact me (since the time of the correspondence about MD5).
Some apparently pretend that they did not see my report, but I put a password on the letter. There were at least 3 views from the MasterCard IP address. At the same time, these are not random clicks without reading, since you need to consciously enter the password. I write them every week.
My expectation was that they would warn everyone who connects to their system to check and filter the embedded data.
Gaps in payment gateways
In addition, I want to say: in spite of the fact that payment gateways deal with money, they are not as safe as they seem. During my pentest (penetration tests), I discovered several vulnerabilities in payment protocols in several intermediate gateways. Unfortunately, I can’t tell the details (if I say “pentest”, then this is something that falls under a non-disclosure agreement).
I also found implementation errors. For example, attacks by lengthening hashing, XML, signature verification errors, etc. One of the easiest bugs I found in Fusion Payments. The first bug I found was: they don’t even check signatures from MIGS. This means that we can simply change the data returned by MIGS and mark the transaction as successful. This means just changing one character: from F (unsuccessful) to 0 (successful).
That is, in fact, we can enter any card number, get an incorrect response from MIGS, change it, and suddenly the payment becomes successful. This is a company with a budget of 20 million, and I received from them 400 bucks. This is not the only payment gateway with such a vulnerability, during my pentest I found similar in other gateways. Despite the small reward, Fusion Payments is currently the only payment gateway I contacted, which is very clear in its rewards program for the bugs it found. They very quickly responded to my messages and quickly corrected their bugs.
Conclusion
Payment gateways are not as secure as you think. With such low rewards (and in some cases I received $ 0), I wonder how many people have already taken advantage of these vulnerabilities in payment gateways.
Remark from the translator
From myself I want to add a few words to the conclusions of the author of the study. First of all, this study is a warning and a call for caution for sellers, since the found vulnerabilities make precisely of them the victims of intruders. But there are many other bugs that can be harmful to customers (cardholders, users of payment systems, etc.). Be careful when entering your personal billing information on an unverified site. Better yet, have a separate bank card at your disposal, on which there will be exactly the amount you need to make a purchase online.
Have you encountered any bugs in payment systems, or perhaps you were even the victim of such bugs? Share your experience, opinions and advice on how to protect yourself in the comments. Have a nice day and secure shopping.
As advertising. Stock! Only now get up to 4 months of free use of VPS (KVM) with dedicated drives in the Netherlands and the USA (configurations from VPS (KVM) - E5-2650v4 (6 Cores) / 10GB DDR4 / 240GB SSD or 4TB HDD / 1Gbps 10TB - $ 29 / month and above, options with RAID1 and RAID10 are available) , a full-fledged analogue of dedicated servers, when ordering for a period of 1-12 months, the conditions of the promotion are here, existing subscribers can receive a 2-month bonus!
How to build the infrastructure of the building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?
All Articles