Whoa! This is not a vulnerability 😠
Welcome to SPITFIRE’s Blog!
From the title, you might have got an idea about what this write up is about. Yes, readers who think “whoa! this is not a vulnerability (with anger)”, are the words of an application developer; you are right! When you perform a penetration testing for any organization, you will be working in association🤝 with Web Application Developers, Software Engineers, Android Developers, Mobile Application Developers, different application vendors and last but not least SOC guys. Trust me, none of them is going to like you😞. Because this is a human tendency, if they are working hard to build an application and you are finding flaws in it, what else reason do they need to dislike you? If they are pushing their efforts to a next level, day and night, to release an application before the deadline, and you keep them waiting䷄ for security approval for more than 3 months of the deadline, why won’t they hate you? Thus, there is a lot of chaos between the InfoSec team and development team, many of you might be familiar with it.
I came across the same situation many times, but the one I am going to tell you here is a little bit interesting⌘. I was testing an application developed by French guys. For the record, I would like to tell you, that was one of the secure application I have ever tested in any organization. I did not find any findings for the first two days, even penetration testers who tested the same application before me could not find any findings. Point to be noted here is, I am calling it as a “findings”, not “vulnerabilities”. Because findings don’t necessarily come with security risk, but they might come with business risk. Like they are something that may harm business regarding finance, reputation etc. And in my opinion, that is the main difference between a “Bug Bounty Hunter⚔” and a “Professional Penetration Tester⦿”. A bug bounty hunter will generally focus on vulnerabilities that will allow him/her to get a big pay cheque. He/She will work and join those programs which are new to bug bounty programs and are offering a good amount of money to find a bug. He/She will barely bother about a business requirement, business logic, application flow or something that may cause the business loss financially and reputationally. However, this is not the case for all the bug bounty hunter. Some professional penetration testers (part-time bug bounty hunters) who are working for the security, not for only money is focussing on all the approaches of security testing. A professional penetration tester will always focus on all these aspects. He/She will not just try to find vulnerabilities in the application using OWASP methodologies or SANS methodologies, but he/she will surely try to understand the application flow, working of an application he/she is testing, business requirements, business logic and functionality of every single request and response.
So, here is the story. While performing a penetration test, on the forgot password page, I noticed when a user enters a Client Number that is registered with the account to reset his/her password, that user gets One Time Password on his/her registered mobile number. So it was like enter correct Client Number, get OTP, enter correct OTP and change the password. However, when you enter a wrong Client Number, that does not have any account associated, you will get a message on the screen, “please contact our nearest branch to open an account with us”. If you enter Client Number that is in an invalid format, an application will throw an error accordingly. I also observed that there was a client-side validation where the user cannot ask for another OTP before 30 seconds. There was no limit on how many SMS user can ask before blocking his/her account. Here it ends my information gathering part.
If you have worked as a bug bounty hunter or professional penetration tester, you might have got an idea about the finding I have got here. There were two findings, the first one is Client Number enumeration and another one is request as many SMS as you can. I made an attack scenario using these two findings and reported them under the name “SMS Bombing — Finacial Loss”. As it was reported under HIGH severity, Cheif Information Security Officer stopped the release of an application. Here come the trouble and anger of application developers. Very next day, all the team members and the project manager came to my office and denied the security risk of the finding. Even though my report was excellent and convincing, they told me this is not a vulnerability and it is a business requirement.
I am telling you when you give any findings in the “Penetration test” report, you are accountable for everything in it. You are the one who needs to prove the security/business risk of that finding. There was a high-level meeting with CICO, project managers where I was asked to present the attack scenario and the potential threat of that finding. I made a presentation and the next day, I was ready to perform a real-time attack during the presentation. Below is the summary of the presentation and steps to produce that finding.
Ultimate Attack Scenario:
Step1: Application was using 9 digits Client Number and Client Number enumeration was possible. So I used the Burp proxy tool’s payload in the intruder to get the Client Number’s of 20 customers of my client, say Natheland Bank (Because of privacy, I won’t disclose name; however, this finding is not there anymore😉)
Visit Forgot password page as shown below, cannot disclose the client URL or anything, so I am going to use hoaxed screenshots.
Enter any Id in a valid format with 9 digits, as shown below,
After entering 9 digits Client Number; if you get following error, the customer is not registered with Netherland Bank.
If entered Client Number is Netherland Bank’s customer, it will send him the OTP and forward you to enter OTP page. See below screenshot.
The thing to notice here is, there is a time of 30 seconds. Before 30 seconds, the user cannot ask for another OTP. However, this is a client-side validation only, in a while I will show how to automate the attack even though there is a time limit.
To get the client numbers of 20 customers, I entered client number and sent a request in an intruder. Selected position to hit the payload as shown below,
As it was a test environment, and I was performing Grey Box testing, I had access to the admin portal. So I knew the registered user’s client numbers. I put those numbers in the starting of my payload and fired payload as shown below. Response code “200” was the successful response of OTP sent.
From here I got all 20 client numbers. I was ready with my sword in the air😎
Step2: Click on Resend (ask for another OTP after 30 seconds), capture the request and send it to the intruder, select payload position as a random number (I select Mozilla agent 5 and hit the payload till it becomes 1000). As shown in below screenshots,
A set timer in Burp (known as Throttle, Intruder->Options->Request Engine->Throttle) where you will instruct the intruder that wait for 30 seconds before sending next request. I had set throttle timer of 31 seconds.
The project manager who was sitting there started getting SMS after every 30 seconds. I was like,
Step3: Repeat step 2 for all the 20 Client Numbers using automated tool or script. All the 20 customers of Netherland Bank will receive an SMS/OTP from Netherland Bank every 31 seconds.
“Point to mention here is, there was no limit on how many times a customer can ask for an OTP”.
I presented my attack scenario to the management. The project manager asked me what is the security risk here?
I was like, what the FUKC, you are still not believing me? It’s okay!!!!!!!!!!
So my next job was to tell them the impacts of that finding. I was ready with my next slide. I presented them the impact that was something like this.
1. Using information gathering skills, an attacker will gather Client numbers of as many customers as he/she can. Say attacker was successfully able to enumerate client numbers of 1000 customers.
2. Send the SMS to all the 1000 customers every 30 seconds. They will be worried that their Bank account is under attack as they are not requesting OTPs and they are getting SMS every 30 seconds from Netherland Bank.
3. All the 1000 customers will panic and everyone will discuss it with each other. This will lead to an idea that Netherland bank is under cyber attack. It will cause reputational damage.
4. To send 1 SMS to the customer, the average charge Netherland bank pay is $ 0.011. An attacker is requesting 2 SMS in one minute, it means approx 3000 SMS in one day. For all 1000 customers, 3 million SMS in one day. That means $ 33k in one day.
5. If an adversary writes a script to bypass the client side validation that prevents a user from sending a request for another OTP before 30 seconds, the adversary can ask an OTP every second. It means the loss per day will be 33*60k USD. I won’t talk about the loss any organization might face in Share Market after the cyber attack.
We provide the security to save any organization from a financial loss. If this finding leads to that financial loss, it may be or may not be a security vulnerability; but, surely it is a potential threat to an organization. That is why I mentioned it as a finding. That is why when penetration tester submits a report, he/she calls them findings, not vulnerabilities.
Everyone in the conference hall was convinced that it is a business risk. I was appreciated for the finding and YEAH!!!!!!!, I got the apologies from application team as well😌. When the project manager said “Nice job, I am sorry”, I was like,
Let’s discuss the prevention measures that should be taken by every organization to prevent such types of attacks.
A: To reset a password, do not just take one input and send OTP/Email to reset the password. Implement a web page in a way that will ask more than one input such as Client Number/User Id/National Id with ATM card number, ATM Pin and Date of Birth.
B: Implement CAPTCHA on the same page so that it will prevent automation by which user/adversary can enumerate all the Ids using automated tools such as Burp Proxy’s intruder.
C: Set the limit on the max number of OTPs a user can ask before blocking his/her, mention it on the website as well.
I hope all of you readers have liked my write-up. Please comment below to get the response for your doubts from SPITFIRE😎
You can follow me on Twitter: https://twitter.com/Wa_sim_sim