Hi All,
Back in time I wrote a blog post "A Story Of How I Landed On Dating Site and Secured it ", in which I targeted `Web Application` module . As time flies skill sets of a researcher grows by leaps and bounds. Likewise I sharpen my skill sets towards "Mobile application security"
TL;DR:
Brute force and Rcon are always a game changer if executed properly on the weaker target implemented by the developer. Anything is possible. "Anything" yes you heard it right. By doing brute force attack I was able to takeover any users account who has done the registration via email address. Apart from that there are many critical issue which I found during the course of engagement.
All the reported vulnerability is now fixed. As its "private program" hence I will not be disclosing any details of the dating application.
Proof Of Concept:-
1x1 - Brute force - The Boss
Brute force attack leads to full account takeover
I was playing around with the most critical part of any mobile application, which is authentication module. Users on that dating application can authenticate via 0Auth (Facebook) OR via registration process and then login via their email id and password.
So I selected method as login via my registered email id and password. I observed that there is "no rate limiting" in place when user logs in into that dating application. For me to practically brute force legitimate user's I encountered one challenge i.e. In order to make brute force attack easier I require legitimate user's email id so the amount of time can be saved to run my brute force attack.
Well in order to be more precise as an attacker, I need to have atlest valid email id of victim and that I was able to guess by using “email address enumeration” bug. When user enters incorrect email address application throws error message as “This email id is not register with "dating app name"”. When user enters correct email address then its shows message as “Reset password instructions has been sent to your email address that is registered with mobile app.”
BINGO. ;)
No one want to disclose publicly that which dating site you are using, unless and until you are single like me XD. But using this bug I was able to enumerate whether his/her friend using that dating application or not. Not only that this bug gives extra benefits to me for running brute force attack at authentication module. So my first step was collecting legitimate uses email id and then running the brute force attack to takeover users account.
BINGO. ;)
No one want to disclose publicly that which dating site you are using, unless and until you are single like me XD. But using this bug I was able to enumerate whether his/her friend using that dating application or not. Not only that this bug gives extra benefits to me for running brute force attack at authentication module. So my first step was collecting legitimate uses email id and then running the brute force attack to takeover users account.
Being lazy, for POC purpose I tried brute forcing more than (20 times) 1 correct email id with a random password. As per the above screenshot you can clearly see I was able to get the correct password of my own test account. For POC purpose I have take over my own account so that there will be no impact to `Live` dating app users.
1x2 - Read the chat history - Victim did with other female/male users
Every time you dive, you hope you'll see something new - some new species. Sometimes the ocean gives you a gift, sometimes it doesn't. Hence its very important that you should keep trying. #NeverGiveUp
Likewise I decided to deep dive in their internal storage in a hope to get some juicy fruits.
Within 5-10 mins I was able to get something interesting. If I as a malicious user by doing social engineering getting victim internal storage data then I can easily take out
all the information about
1- Victim done friendship with whom
2- How many boys/girls victim chatting with.
3- Chat History
4- App Key
5- What are user ids of their friend list
6- Their friend’s private details etc.
The best part about this bug is "imagine married" couples having fun on this app and his rival gets those chat history details. XD
1x3 - Application .apk can be RE (Reverse Engineer)
This is evergreen finding which you can find in most of the mobile application. If developers are not that smart.
I was able to decompile and the
code that can be reverse engineered to understand the working of the entire applications.Since, the code has not been obfuscated, it
is possible for me to reverse engineer the code and create my own malicious .apk which can later be spread on behalf of the respective application name. Simply by inserting a malware in the application. Once done we can publish that malicious .apk with injected malware via social engineering to hijack all the user data.
Now next step for me is "Responsible disclosure" So I wrote nice email stating all the details of bug to that application owner CEO. I am good in re-con you know what I mean. XD
Well this team is really amazing within and hour I got a positive response from the respective team.
Email sent :- Aug 1, 2016 at 12:41 PM
Reply from the CEO :- Aug 1, 2016 at 1:46 PM <= See the time ;)
I wish all company should be like this.
Action taken by them:-
After all the submission, we had a quick conversation via email and after exchanging few emails they fixed my all the bug in short duration of time.
Last but not least all "Gray Hat Hackers" are not that bad they do think about organisation and their security. Also I would like to thank the company CEO and their developer team who took security very seriously and fixed my all reported bugs so quickly.
Moral Of The Story:-
Some times its good to try on some private site.
Stay focused, Don't Quit, keep trying #NeverGiveUp
Time-Line:
Vulnerability timeline:
Aug 1, 2016 : Sent email to the CEO
Aug 1, 2016 : Got prompt reply.
Aug 8, 2016 : Shared all the findings with developer team.
Sep 29, 2016 : They fixed my all the reported bug.
Sep 30, 2016 : Bounty Awarded <= MY CURRENT SALARY
Oct 16, 2016 : Public responsible disclosure
Some times its good to try on some private site.
Stay focused, Don't Quit, keep trying #NeverGiveUp
Time-Line:
Vulnerability timeline:
Aug 1, 2016 : Sent email to the CEO
Aug 1, 2016 : Got prompt reply.
Aug 8, 2016 : Shared all the findings with developer team.
Sep 29, 2016 : They fixed my all the reported bug.
Sep 30, 2016 : Bounty Awarded <= MY CURRENT SALARY
Oct 16, 2016 : Public responsible disclosure