How the vulnerability of the payment system disclosed credit card information

    Recently I decided to check the sites of payment systems for vulnerabilities (ua, ru). I found the top of this kind of services, on many of which were discovered xss, csrf and other popular vulnerabilities. There were companies that promptly eliminated vulnerabilities, thanked and agreed on cooperation, there were those that silently fixed, and the most unpleasant moment was companies that did not believe in the danger of the problem, I tried to prove to them the opposite, that this was a serious matter, offered to show the vulnerability to them test account, they said that they will fix it, but still have not fixed it.

    There is one payment system on which a vulnerability was present, allowing to obtain critical information about the user, his password, credit card, etc. The bug was very easy to reproduce, although the withdrawal of funds from hacked accounts was difficult for several reasons, I’ll tell about them under the cut.

    Company website , it is 7900 alexarank in Ukraine. I usually do not spend much time on each site, because the owner is still not aware of the vulnerabilities on his site, maybe he will ignore the vulnerability and my time will be wasted. If I found the first standing vulnerability on the site, then I immediately reproach it, look at the reaction of the owner, and if he is positive about such events and wants me to cooperate with him further, I continue my search.

    The first thing I did was check the subdomains and directories in my dictionary, the following subdomains were identified , in general, the brute did not give anything. Next, the results on google dorks were viewed, alas, the search was unsuccessful, and the only thing that was found was an article by Gorodnya on Habr about how he found the vulnerability on plategka, and how he was paid a lot of money - only $ 8. The next step was to test the functionality of your personal account, csrf bugs could not be reproduced due to password confirmation for changing data, there were also filters on xss. The only thing that was discovered was self xss in confirming the form with a password, the danger of such a bug is minimal, so you had to look for something else and more serious.

    One thing that I noticed is the pay2me service . His job is to process credit card data, I found this an interesting subject to study.
    Previously, I came across news with this service , but did not pay much attention to them. Instructions for creating:

    In your personal account there is a corresponding tab - “Pay2me Settings”. To create a unique link, you must enter its name, 16-digit card number and press the "Add" key.

    I created my link .

    Map data was hidden, xss vulnerabilities were absent. Attention was drawn to the response of the burp. In the source code of the page with payment in javascript, the username of the user, md5 hash of his password, name, email and phone number were issued:


    (this is data taken from url ).

    The vulnerability was found, but one of my links for proof will not be enough, it was decided to find other such links.

    There were attempts to find them using dorks of the form site: inurl: pay2me /, issued only one link . I knew that there should be much more links, because the service is very popular.

    The last chance to get the cherished links was bruteforce in the intruder, more than 100,000 popular English words were downloaded and the search began.

    It turned out to find about 40 links, about half the passwords were found out.

    I went to a couple of accounts to check if cvv2 and other card data are encrypted.

    In the first account I found 3 virtual cards:

    the second was 20:

    cvv account is hidden, to disclose only 10 digits of the card number and the term of its action . To cash cards, you can, for example, replenish webmoney, or another electronic wallet. But in order to do this, you will have to enter the cvv2 code in the payment confirmation, even if the card has been verified.

    The first thing we can do is enter a random cvv2 code, for example 111. Often we are redirected to enter otp from the bank, and then the payment fails due to incorrect cvv2.

    We can also get cvv2, but then again you may encounter entering a code from the bank, which is hard to get around.

    If we have a date and a partial card number, then a normal phishing attack can make a user tell about their card number (we received an email , phone number , full name , I was even able to get several links to user pages on social networks), even a regular letter of the form: “You won a cash prize, to receive it you need to send us your card number” may work, the action does not require the provision of critical confidential data.

    To pick up cvv2, you can use some kind of online store, only 1000 requests and we picked up the code ( here is an article about this) Of course, some stores redirect to enter otp from the bank, but many “foreign” stores write off money immediately without the need for a redirect.

    The vulnerability was fixed almost immediately after brute force; in addition to the vulnerability data, it also sent a database of users that were promptly frozen, and the bug itself was quickly fixed.

    They paid only $ 100 for the vulnerability, they said that in order to get more, I need to find out all the credit card information from the account.


    07/13 at 17:00 - report sent.
    07/13 - The vulnerability has been fixed.
    07.20 - $ 100 reward paid.
    07.24 - The article was agreed with support.

    Conclusion from the article: Despite the declared passage of PCI DSS, I would recommend that sites periodically check for vulnerabilities, and customers - start virtual cards for use on the Internet.

    PS: If you need a security audit, write here . Also, if you are interested in monitoring new articles, you can subscribe to vk / twitter / telegram, the links below.

    Previous article .

    Also popular now: