Skip to main content

Finding ways to misuse application features | An example

I am publishing this without reviewing or re-reading. I apologize if you see any mistake here. Have a great day! 


Introduction

 Hi, I hope you are well. I am writing this blog after a long time so some of my writing skills might have faded away. Talking about skills, I've mastered one, and it is my ability to spend unlimited amount of time trying to understand every single feature of a target application. Sometimes I find a way to leverage those features  into vulnerabilities other times I end up learning a lot of things from them. So, I'm using this article as a means to share one of the findings that ended up being duplicate. 


Bypassing email verification step when registering new email addresses

  

I was looking at a bug bounty program and I found an application that allowed anyone to register and login to it. So, I created an account to poke around with the features. The first feature I looked at was the registration feature itself. When I created an account in the application, it asked me to verify my email address to continue. I tried to login after skipping the verification step, but I got the most expected error message, "You have not verified your email, please enter the code sent to your email address to continue". After this I had no plans of bypassing it, I entered the code and went ahead to test other features. However,  when I logged in for the first time,  application redirected me to "https://application.xyz/dashboard". I poked around and tested for basic flaws like XSS, SQL Injection, SSTI, and CSRFs in the most-common input fields you could imagine like First Name, Last Name, Email, and every single GET/POST parameters I came across. I found nothing, so I moved on to the O.G class of vulnerabilities, Broken Access Control.  I attempted to create a new account to test for cross-user vulnerabilities. However instead of opening "https://application.xyz/register" to create a new account, I accidentally went to "https://application.xyz/dashboard" and it opened up a registration page. So, I created an account, but this time I was not asked for email verification but rather directly redirected to "/dashboard".


Enabling 2 Factor Authentication to lock out arbitrary unregistered email addresses


After bypassing email verification, I asked myself a question, "Can I use this for my advantage?". That's when I thought of enabling 2 factor authentication and it worked. I could enable 2 Factor Authentication for any unregistered account and lock them out using the TOTP method. User would not be able to gain access to their account even if they had changed their password because they would need TOTP token to login and that was controlled by me.


Reporting and expectations


I reported this but I kept 0 expectations because vulnerabilities like these are simple and should've already been reported by other hackers. But, just because of that I found absolutely no reason to leave them vulnerable in case this was introduced by a newly launched feature. Hence, I reported it and as expected it went Duplicate. But, I learned from it in the end and that's what matters I guess, because eventually there's high chance you'll stumble upon the same vulnerability in your other targets too. 


Conclusion


Always try to take advantage of the application features and think about how a bad actor/attacker could leverage the feature to cause harm. 


 





Comments

Post a Comment

Popular posts from this blog

Mysterious Javascript Code Found Infecting Hundreds of Websites

  After installing Wappalyzer in my browser, I decided to test its functionality by visiting a familiar website. To my surprise, I was unexpectedly redirected to a spear phishing campaign. Knowing the website's usual practices, it seemed highly unlikely that they would intentionally redirect their visitors in such a manner. Intrigued by this anomaly, I took it upon myself to investigate the underlying cause of this redirection.   I have not yet known how threat actors implanted the Javascript Code in the victim's application but this is what it looked like.         What does the code do?   The code is simply importing script from biggerfun[.]org domain. In other words, it's simply doing <script src="biggerfun[.]org"></script> Further investigation I wanted to check if others think the website is bad, so I looked into it more. I observed they do things similar to another group called TA569. You can learn more about TA569 here: ...
Post a Comment
Read more

Getting unlimited money by abusing the 'Send Money' feature

      It has been a while since I published a post. So, I am writing this one to share one of my interesting finding while testing an e-wallet application.     I glanced at my Total Balance and I was wondering if there was a way for me to increase it arbitrarily. So, I thought Race Condition would help me here.  What is a Race Condition vulnerability? "A race condition vulnerability typically occurs when your application has access to the same shared data and attempts to change variables within it simultaneously ." - automox.com So, I loaded up Turbo Intruder in Burp Suite and attempted testing it. I failed. I couldn't exploit it.  I didn't want to give up this soon. I kept that fire bottled up and changed my approach. I realized that the 'Send Money' feature uses basic maths to reduce balance from the sender's account and add it to the receiver's account. So, the feature did the following operations:   function sendMoney(sender, receiver, amoun...
Post a Comment
Read more