This was the short story of how I Protected/Secured one of Indian Dating Site.
The Story started when I heard the news that Ashley Madison, an American most prominent dating website, has been hacked by Hacker.
After this breach they publicly announced below news :-
Well After reading the whole story I was like Dating Websites, What about in India ?
Do India have such Dating Sites ??
The answer is MANY:-
So I started searching top dating applications/sites which is popular in India. And here I found it.
I Installed the application and tried using it. Well being an single and testing dating application is really fun :D
So lets see If I can find any girl of my type :P
While my research was going on I came to know that they are using web module for authentication and chatting with other peoples same as mobile application :D
So I jumped into their web portal/site to find how that web site looks.
You won't believe, but this is the fact that this days when I see any Application or Site or Anything I see it as
So my Girl hunting was ON :P
And there it is I found some critical bugs on their site which can easily leads to full account takeover of many users even admin user also.
Now for me to takeover any user account is pretty easy task. But Being a White Hat Hacker I have to secure that dating site. Before the bad guy takes advantage of this. So my target is to responsibly submit this bug/Issues to site owner and tell them to fix it.
Before we go further please follow this Note:
I AM NOT GOING TO DISCLOSE THE SITE NAME WHICH I DEFACED SO DON'T ASK ME WHICH SITE IT WAS :)
I found their CEO email address and all the details of their company. So I wrote nice email stating all the details of bug.
Emailed to the CEO - Time: Jul 22 at 10:50AM
Got reply - Time: Jul 22 at 10:53AM <= See the time ;)
After exchanging a few emails.. Someone from their team send me below email:
Lets come back to Reporting part. So I Reported all the bugs as follow:-
Proof Of Concept:-
I found that their entire web application was vulnerable to XSS. Not 1-2 but bunch of many XSS.
XSS on Login,Signup, Visitors profile it was everywhere.
After finding XSS I came to know they have not protected user cookie value i.e
No HttpOnly Flag set in cookie :D
So next step you know very well #Session Hijacking + Full account takeover :D
Also, I reported many other low hanging fruit as a findings.
Action taken by them:-
After my all the submission. I asked them whether they patched bug or not. The action taken from their end
1] Removed Signup Option
2] Removed Login Page module
They fixed my all the bug in short duration of time.
So Finally I got Appreciation Letter, Good money :D and #RESPECT But my status remained Single :P
MORAL OF THE STORY:
If you are hacker then use your hacking skill to protect other user, you never know jesus will bless you like this.
I would like to thanks company CEO and their team who took security very seriously and Fixed all the bugs so quickly.
This will be a very short blog post on how I got my first swag.
Introduction:-
This days I am regular user of hackerone platform for bug hunting. Well, one day I woke up started my machine and rather than going to hackerone url, I googled it and where I landed was at hackerrank site, whose name is similar to hacker one.
What is HackerRank?
HackerRank is a site for hackers from all over the world to solve programming problems in different CS domains like algorithms, machine learning and artificial intelligence, and to excel in different programming paradigms like functional programming.
WOW... What a site to learn coding :) So I registered myself on their platform. Well and you know all when I visit any site, I see it differently.
POC:-
After my registration completed. I went to their setting section and guess what I found XSS :D
I informed this bug to hackerrank team. And they fixed it right away.
Reward:-
I would like to thank hackerone team for fixing bug so quickly and rewarding me with my first swag :D
This is my first swag so writing this blog post. But soon I will be writing more blogs on some interesting bugs which I found recently
In this Blog Post I will show you how I was able to reset all cobalt users passwords.
Introduction:- Cobalt is a bug bounty platform where security researcher participates in various programs. Cobalt itself runs a bug bounty program.
How it Started:-
Long time back when I was no where in to bug hunting. I have created my account on multiple platforms who runs bug bounty just to see how this program works and In a thought of soon I will participate, Then later on when I sharpen my skill sets I I decided to start participating in bug bounty programs.
I started my bug hunting from normal sites which gives Hall Of Fame to Security Researcher and then I started on Hackerone platform. I got a good number of hits in that ;)
Later on I thought, lets try finding bugs on some other platform. I selected cobalt platform.
I started my research by checking their email address change functionality to check whether it's secured or not.
And there it is I found some juicy bug on their site which is quite interesting
Proof Of Concept:-
In every application you must have observed feature that you can reset your email id as an when you require. Similarly In Cobalt also that feature was there but problem here is their reset email address module for changing users email id was vulnerable.
Explaining Furthermore,
Say,
1] There are two user who are part of cobalt User A and User B
2] User A has email address abc@gmail.com and
3] User B has email address xyz@gmail.com Then
4] If User A thinking to update his email to xyz@gmail.com then generally we get prompt message saying email address already taken OR email id already in used by someone.
But this is not happening here in cobalt. Hence if User A by mistakenly setting User B email address and that User B know this flow then he can reset User A Email address well this is it, Then this leads to full account takeover of all the cobalt users whose email id is @gmail.com.
Well this issue may looks small but hold on this is "Account Takeover bug"
Lets see the attack scenario.
Attack Scenario:-
=>Victim - code who wants to change his email address to new email address
=>Attacker - nilesh knows this bug in cobalt
Victim as code thought to change his email address, so he decided to change his new email address as nilesh.s.sapariya@gmail.com
Now code is not aware that this user is already part of cobalt. Once code changes his email address to nilesh then nilesh receives email confirmation notification alert in his email address. Nilesh knows this bug so nilesh will simply accepts the email confirmation mail. Once confirmed code mail address will be updated to nilesh mail address :)
Now, Nilesh will go to login page => Click on forgot password => Put his email address => bang nilesh resets code password
I explained this to cobalt security team And I got reply as below:-
Directly rejected.
They said its gmail behavior of not accepting dots(.)
https://support.google.com/mail/answer/10313?hl=en
Because the bug is any user (part of cobalt) If updating someone else email id(who is part of cobalt) then that someone by confirming the email confirmation link can reset the email address.
So I got this reply again.
So finally I decided to create video POC :
Its bit lengthy so If you have time so you can click here to see. OR skip :)
After this video POC again I started explaining from the scratch and reply response continued and this mail thread gone bigger and bigger.
Again I have given entire explanation what is wrong happening here. And see what I got reply.
Kill me pls..
After that again on a same point discussion started this way reply response of all repeated things was going on,
I am trying to finish this short as there was so many communication happens.
Just to make them understand that:- 1st point: No user should have permission to set email address which other user already using in the same application (cobalt). 2nd point: No email confirmation link should be trigger, If victim changes email address to someone else who is part of cobalt.
Only this 2 point :(
And note this was happening only for @gmail users and not for @cobalt users. Well but all cobalt users uses @gmail id.
Again I wrote explanation with all the point,
And Again See what I got a reply from their end
After this again same conversation got continued explaining each point again and again :(
While we are exchanging mails someone from their team, Putted my email address on his account for changing email
Well that's what attacker want to exploit this bug: :)
At this point of time I came to know again this guys doing something i.e he putted my email id in his account and I got mail notification alert.
So now I decided that I will takeover his account.But I will record everything so that they will understand. :P
So I created another Video POC demonstration but this time hacking cobalt team member account.
On below video POC you will see how I hacked cobalt team member account and changed his password :-
PS: He sets 2 factor Authentication but then he has no way to change his password after I take over his account
Later on his team member asked me for the password which I changed it :P XD
I gave him the password which I reseted. But you know what if he will try to change his password then again notification will be
trigger to my email id. So Again I can change his reset password and
there is no way he can reset it back.
THIS IS THE IMPACT OF THIS BUG.
Anyways, later on Cobalt senior member fixed this bug by not allowing users to update existing used email address which is already part of cobalt
So now no users can update email address which someone else using in cobalt. So no account takeover possible.
So finally they patched the bug.
So What I Got is :-
1] Reward: Declined
Yes you heard it right they said the reason "This turned out to be invalid, and you ignored our repeated mentions of the GMail-.-artifact."
Phewwwww.....I have no comments here.
At the end:
I would like to thanks Cobalt team for fixing this bug. And I appreciated what reward they have given me.
#Happy Learning For Me :/
Well well well wait this is not ended yet.
MORAL OF THE STORY:-
=>Never Give Up. Do not give it up ever If such things happen to any Security Researcher.
=> Focus where your research got appreciated and work hard on it.
This is my first write-up and i would like to start it with the CSRF vulnerability that I've found recently in Blackberry domain by using this bug i was able to change any user profile information ;)
Introduction:-
Few months back, I had taken presentation on the topic Cross-Site Request Forgery at Null-Mumbai chapter meet, You can find my slides here Its all about CSRF . And also I had taken seminar explaining various ways to bypass CSRF tokens.
Well all this motivated me to research more about CSRF bug and its bypasses techniques.
Then I started digging deep to find these types of bugs
So here my first experience goes...
About BlackBerry Beta Zone : Site says it has 400,000 members and growing!
I started doing my security research on BlackBerry. While I was checking this portal for finding bug I came across the user profile details where they have not set any protection against CSRF.
Which means by using this bug I can able to change all the users profile information.
Now for me it's like having cup of tea :P
Proof Of Concept:-
This attack works by sending a crafted request to victim and victim has to click on the request.
So I crafted forged html request as below.
AFTER: Victim Account Details changed after clicking on request sent by attacker
So i wrote nice mail to blackberry security team explaining this issue. After reporting my submission, blackberry security team was not able to find my report :(
At-last after exchanging few mails with blackberry security team I got a reply.
I am happy that they patched this bug so quickly and here I got this HOF (Hall Of Fame) :D
Hall Of Fame:-
Video POC:-
Below is the video POC demonstration of this attack : (Enjoy the music ;))
Time-Line:
Vulnerability timeline:
July 12, 2015 at 5:43 PM : Reported to vendor- Blackberry Team
July 15, 2015 at 1:45 AM : Received initial reply from Blackberry Team
July 30, 2015 at 2:30 AM : Blackberry Team released a quick fix for the vulnerability
Aug 10, 2015 at 6:30 PM : Public responsible disclosure
