Dropbox Acquisition - Download Any Malicious File name From Hackpad Domain



Hi Everyone,

Remember this ?
How I Able to download any malicious file from Yahoo Domain

If we go back in time then this is my first attempt of calling other domain files in to infected domain.

I was testing one of dropbox domain so called Hackpad. "Hackpad has been acquired by Dropbox."

The Story:- 

Just like in yahoo case that time I was thinking to hunt for RFD (Reflected file download) Attack.
As per RFD Requirement:-
1] Reflected - Some user input is being "reflected" to the response. This is used to inject shell commands.

But what I was thinking is opposite of RFD :P
i.e. What If I can able to call or download malicious file from other domain ??
Lets try something different.

PS:- This is not RFD Bug.

After a bit of fiddling, I discovered below URL
https://hackpad.com/comet/channel?v=2&r=57495082114&id=775884413603&channel=shortpolling&seq=07de3524a29&tag=L7YZlnAPsZU

If you will observe above URL you will find many parameter to try different attacks say SQLi,XSS and so on. But neither of them worked out for me except one parameter which caught my attention.

Vulnerable parameter: channel

Replace vulnerable parameter with any other executable file path (other domain files).

So I injected other domain downloadable file path, for testing purpose I used .exe zip file download from 7-zip domain.
www.7-zip.org/a/7z1505.exe 

 Below is the result




As you know on HackerOne everyone tries to submit their report As quick as possible, just to make sure they do not fall under Duplicate. Thinking the same I quickly submitted this report with a hope that this report won’t be duplicate for sure. 

Without doing further more research on it, I submitted the bug report.

And I got quick revert from their team.


Yes, if you will see the first screenshot then you will observe that file is being downloaded in html content type and not as per .exe which I was trying to download from other domain.

Well Big mistake from my end. 

`Mama always told me to learn from the past experience. `

I had many bad experience in my past and thanks to my mentors and friends who always supported me and guided me. Thanks to GOD :)

Take away here is “Learn from past and try to not repeat those mistakes"
Well by thinking that I will always go ahead and hit the success.

So here also I had to learn from my mistake and had to TRY to change this into success..

Digging deep into this I came to know that there is no way I can execute other attack or there is no way by which I can control the file content or file type which I was trying to download from other domain. Just like in yahoo case.

The reason behind this is:- 




Content-Type : text/html
Inside the file : 16:oob:restart-fail (weird message)

So I concluded that there is no way I can download the file from other domain because I am not able to handle Content-Type  :(

But what is in my hand is I am able to control the name of the file which is being reflected to users. So do I have anything left here ??? 



YES, The answer is Content Spoofing Bug.



So I again wrote back to dropbox team about content spoofing bug which I am able to perform.

Below is the reply from their team.




Well so they are saying that this is not bug and then too they might fix in future. Jesus

So I reverted them back.




After this reply from my end.




So they accepted my submission. Really ?

Hold on.

At this point of time summary will be :-

1] I was able to call remote file name via hackpad domain. 
    But then what will be Impact ?
    Answer:-  Ummm may be low but this is the thing which you need to care about.

NOTE:- 
Just like in yahoo my mentors suggested me you might have tried reading local files etc.
i.e. trying something like
/etc/passwd OR
file///etc/passwd but in either of the case it will reflects the inputs provided by you and not the file content.

Neither of them working for me. Though thanks to my mentor for this suggestion. :)

2] I was able to inject my desired input which is reflecting back to end users
     But then what will be Impact ?
     Answer:- Content Spoofing Bug. This may have some severity. 


Wait the bug is not fixed yet.

After many follow up with @Dropbox Security Team I got below reply from their end.




I generally not prefer blog-posting bug report which are not patched/fixed, but in this case they are willing to accept the risk.

Let me tell you same type of bug I found in few private programs where I was able to call remote file name to infected domain and I got rewarded for the same.  I dunno about dropbox security team .


Video POC:-




Time-Line:-

Vulnerability timeline:

July 27, 2015   : Reported to Dropbox Team 
July 27,2015    : Received initial reply - Report Marked as NA
Aug 10,2015    : Further explanation given 
Aug 10,2015    : Report accepted and Marked as Triaged
May 4 ,2016    : They said they are willing to accept the risk.
May 21,2016   :  Public Responsible Disclose.
        


Share this

Related Posts

Previous
Next Post »