Developer, remember - your application’s traffic is being watched

    WOG

    At the moment, there are so many types of vulnerabilities that developers completely forget about the elementary ones. The other day, I managed to bypass authorization in the new WOG application (TOV VOG RETAIL is the second largest gas station network in Ukraine). In 2017, I found exactly the same vulnerability in the application of one of the mobile providers of Ukraine (also the second largest). Identical situations - a new application and lack of protection against brute force.

    Not so long ago I received a notification - the company released a new application and offers to install it. I honestly liked the functionality of the application - viewing bonuses in the account for which you can buy fuel. The ability to attach a bank card and pay for goods contactlessly or by QR code. My profile and contact details are also displayed in the profile, a complete transaction history is a list of goods and their value at the time of purchase.

    Authorization in the application has become easier - now you do not need to enter the number of the loyalty card, just specify the mobile number. However, even at the entrance, I suspected that anyone could view my data - I specially, more than 5 times, entered a code different from what I received in SMS. What for? - Because earlier, in a similar application of a mobile operator, I found a vulnerability that gave full access to managing a subscriber’s account.

    Entering the incorrect code, it was possible to find out that protection against brute force is most likely not.

    I was right - the application has no protection. You can access any account, and moreover, “hijack” your account - link to another number, spend other people's funds.

    I got the impression that application developers completely forget that network traffic is not difficult to intercept, even https requests.

    Personally, I use the fiddler program - this tool makes it possible to proxy traffic, view it or change it. In order to access the content of https requests, in addition to the proxy settings, in the connection properties of the smartphone, you must additionally install the trusted certificate that the program generates.

    First of all, I was pleased with the self-esteem of the developers of the application - the API that uses the application is located on thebestapp4ever .wog.ua domain . Just by going through the URLs, I was able to find out that IIS 7.5 and 1C: Enterprise 8 live on the server, as well as a picture from the title (maybe the Machinarium fans wrote the API?).

    The authorization scheme is simple - a request with a “request” to send a code to SMS flies to one of the API methods . And here the first vulnerability is the absence of any limits. On the same phone number, from one IP you can "order" as many SMS as you like.

    Later, in the company's tenders, I found information that they plan to send up to 1,000,000 SMS per month (they are ready to spend ~ $ 98,000 on this for a year). It turns out that the vulnerability can cause the company losses of ~ $ 8,200 per day if 12 requests are sent per second.

    It is worth noting that for correct processing of requests by the server, basic authorization is required- This is one of the protection methods that the developers used. What for? It’s not clear - I don’t see any sense from it - intercepting the login / password or the required http header is not a problem at all.

    After the user received SMS and entered the code into the application, it sends a request in order to verify the reliability of the code and receive a token. The next and most critical vulnerability was here - there is no protection against brute force. The selection of a code, which consists of 4 (!) Digits, does not require much time.

    Having received the token, you can use other API methods. One of which makes it possible to change the PIN code from the loyalty card. The procedure is standard - enter the old PIN, enter a new one. I want to focus on this method, because here the developer used another method of useless "protection". Naturally, there was also no protection against brute force, but the old pin was sent in hidden form. The idea is good - just sorting through combinations 0000-9999 will fail. The implementation is bad - instead of the code, an md5 hash is sent. Without salt substitutions or anything else.

    Honestly, I have no idea how to access the application code and whether this is possible - so even the outdated md5 would stop me if salt were used.

    I also managed not only to brute force a token for a “foreign” account, but also to slip it into the application - I wrote a small script on node.js that proxied traffic and replaced only the responses of the gettoken method.

    The article was written after talking with the "deputy director of the IT department" of the company. The guys reacted briskly - I was able to get contacts for communication within 24 hours. I sent a description of vulnerabilities and a question about the presence of bug bounty.

    In response, I received a letter with information that I was allegedly “spotted” - “ We saw you (380958302 ---) immediately and the locks worked ... I won’t tell about all the locks, but a lot of them appeared yesterday

    How to me, it’s more like frost - for, as I replied to this letter, “the joke is that this number is not familiar to me. I tested on numbers 095866 ... "

    In contrast to the WOG company, the head of the information security department of the mobile operator was much more talkative, and they fitted a smartphone as a thank you =)

    Also popular now: