Facebook Web Security Bug Bounty: Directory Traversal Vulnerability / RCE In Parse.com

http://parse.com  directory traversal vulnerability

Little Insight:

http://parse.com  was vulnerable to a directory traversal / RCE vulnerability. As a result, it was possible for an attacker to load web server-readable files from the local filesystem. or Run commend on That

Well this is my 4th reward form facebook  Directory Traversal or RCE Vulnerability 

That  give me 5th position in Facebook white-hat Page

Report Date :23  July 2014

Reward For Directory Traversal or RCE Vulnerability :  20000$

How This work......?

As we discussed earlier on my old post Flowdock Directory Traversal Vulnerability exposed files outside of Rails’ view paths. '%5C' turns into '\' after decoding. Using Rack::Protection   it only rejects '/../' segments in the request path.  

patch apply for Rack::Protection acording CVE-2014-0130  and  also Reject now '%5C' turns into '\' after decoding

now my work ....

My Finding....

In the above summary ( CVE-2014-0130 )  it  rejects '/../' segments in the request path and path is also sanitized to filter out malicious characters like "..%5c", 

now m try to bypass filter  with " \../ or \..%2f "  segments in the request path  more details i am disclose in next post ruby on rails  Rack::Protection bypass effected on old version

patch version you can use 4.1.1, 4.0.5, 3.2.18


Now coming back to Parse.com  Facebook Acquisitions 



here is the proof of concept that I included with bug LFI/RCE. It displayed the contents of the /etc/passwd Or /Gemfile of the http://parse.com server 

More Then 5 pages Vulnerable on parse.com with same vector 

one of them

Poc Url :   https://parse.com/about/\..%2f\..%2f\..%2fGemfile

 After some time

i am  found  how to convert ruby on rails LfI in remote code execution or Shell

Thanks to Jeff Jarmoc for great Article on remote code execution or Shell That make  possible  to make Rce on parse.com

POC URL :    https://parse.com/about/\..%2f\..%2f\..%2fproduction .log?codetoexec=?

More about :

The vulnerability mentioned here has been confirmed & fixed by Facebook Team.

I’would like to thank Jeff Jarmoc for such a great article and Neal for handling this issue and  the vulnerability was patched and the fix was deployed in production within 2 hour  after my initial report.


Well this is my 4th reward form facebook  Directory Traversal or RCE Vulnerability 

That give me 5th position in Facebook white-hat

you can also meet me   

FACEBOOK

TWITTER

 

 

Nokia Web Security Bug Reward: Directory Traversal / Local File inclusion Vulnerability

 

Little Insight: 

 

Well this is my first Directory Traversal Vulnerability / Local File inclusion Vulnerability

 

which I spotted in  http://conversations.nokia.com  

 

Report Date :  5th march 2014 

 

Reward For  Directory Traversal Vulnerability  : Nokia  Lumia 925 Phone

 

How This Work

when i was testing it was found url a link on  subdomain 

http://conversations.nokia.com/wp-content/themes/polaris13_r/admin-ajax.php

with post request 

action=get_ajax_post_template&page=2&param=4614&postPerPage=12&template=

when i am use any word template=Jeet thats show 200  responce with result as 0

Template parameter show its access another url form site

 ... now work begin....

My Finding....

http://conversations.nokia.com/wp-content/themes/polaris13_r/admin-ajax.php

with post request 

action=get_ajax_post_template&page=2&param=4614&postPerPage=12&template=

Template parameter show its access another url That's gave me a hint may be there is an LFI

Then i am  Googled for a cheat sheet For Directory Traversal

In a few minutes complete Task and found Traversal parameter....as

../.../.././../.../.././../.../.././../.../.././../.../.././../.../.././etc/passwd

 

 

 Normal Request..

 

 

 

 

 

 After Payload...

 

 

 

 

More Information

 

The vulnerability mentioned here has been confirmed patched by the Nokia Security Team.

 

 

Microsoft: Exploiting XSS with clickjacking

Little Insight: 

Click jacking just hide-the-button-and-follow-the-mouse. also know as  UI Redressing (its just playing with the UI of the victim application by clicking and mouse event . In this post we'll show  UI-Redressing attack and how an attacker may trigger an unexploitable XSS flaw in an application

How This Work?

UI-Redressing follow some techniques for making successful attack

1. using mouse clicks
2. making an invisible iframe & follow the mouse
3. showing only a certain small part of a web page in a frame
4. dragging a text out of an application
5. dragging a text into an application

My Finding....

Domain: http://m.microsoft.com

vulnerable parameter : phrase = xss

 Poc url :

http://m.microsoft.com/showcase/en/US/search?pageindex=sv1:2&phrase=[url%3djavascript:alert%28document.cookie%29]click%20here%20and%20see%20your%20result[/url]

After using url .In result its xss payload store as  hyperlink tag as click here to see result

 

When user click on hyperlink tag that xss run 

 

That's an Self Xss which want user interaction but in that m found domain not set any security for X-Frame-Options Header its make an idea for Exploiting XSS with clickjacking 

I am set an iframe with poc url on my website  with some button when user come to my site and click on any button I can steal users cookie of Microsoft account with sessions 

 See  behind the click button

When User click button Exploiting XSS with click-jacking

More Information

 

The vulnerability mentioned here has been confirmed patched by the Microsoft Security Team.

Nokia : Exploiting cross-site scripting in Referer header in Trade.online.nokia.com

Little Insight: 

 

The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks or referer page back link . The payload Referer: javascript:prompt(1); was submitted in the Referer HTTP header. This input was store on page back link when user click back link that's make an XSS.

How This Work?

 

Suppose we have an application that generates a "Back" link from Referer header

<?php
echo '<a href="';
echo $_SERVER['HTTP_REFERER'];
echo '">Back</a>\n';
?>

We can inject HTML and JavaScript if we can set the Referer header. This can be done if we first get the victim to visit a page created by the attacker. Consider the following page (let's call it exploit.html):

<html>
<body>
<form   id="jeet"
        name="jeet"
        method="GET"
        action="http://victim.example.com/xss.php">
</form>
<script>
document.getElementById("jeet").submit();
</script>
</body>
</html>

If the victim is tricked into visiting 

http://attacker.example.com/exploit.html?<script>alert(1);</script> 

he will end up on the vulnerable page with the Referer header containing XSS attack.

This attack works in Internet Explorer, but does not work in Firefox, because Firefox will URL-encode the characters after the question mark. 

My Finding....

 

Host: trade.online.nokia.com


vulnrable pages :

https://trade.online.nokia.com/cps/
https://trade.online.nokia.com/cps/script/
https://trade.online.nokia.com/cps/script/common/
https://trade.online.nokia.com/cps/script/console/.
https://trade.online.nokia.com/cps/script/preview/.
https://trade.online.nokia.com/cps/theme/common/corporate/style/.
https://trade.online.nokia.com/cps/theme/common/corporate/
https://trade.online.nokia.com/cps/theme/common/
https://trade.online.nokia.com/cps/theme/
https://trade.online.nokia.com/cps/theme/console/corporate/style/
https://trade.online.nokia.com/cps/theme/console/corporate/
https://trade.online.nokia.com/cps/theme/console/
https://trade.online.nokia.com/login/fonts/.
https://trade.online.nokia.com/pics/
https://trade.online.nokia.com/pictures/
https://trade.online.nokia.com/siteminderagent/dmspages/.
https://trade.online.nokia.com/siteminderagent/forms/.
https://trade.online.nokia.com/siteminderagent/
https://trade.online.nokia.com/siteminderagent/pw/.

Continue..............

 

 Normal Request..

 

 After Payload...

Xss....on back link..

 

More Information

 

The vulnerability mentioned here has been confirmed patched by the Nokia Security Team.

 

 

Flowdock Web Security Bug Bounty: Directory Traversal / Local File Inclusion In Flowdock.com

 

 

Little insight on LFI

 

https://www.flowdock.com was vulnerable to a directory traversal / local file inclusion vulnerability. As a result, it was possible for an attacker to load webserver-readable files from the local filesystem.

 

How This work..?

 

On the Flowdock API documentation source files in a separate, public GitHub repository. This allows anyone to contribute and report issues, or ask questions in public. they serve the documentation in Rails by rendering markdown as HTML and injecting the generated HTML files as views.

To avoid adding a new route every time we add a new page, our route file had the following rule:

              get '/api/*action', controller: 'docs' 

In this setup the controller is only responsible for setting up the layout.

A request such as 

api//%5c../%5c../%5c../%5c../%5c../%5c../%5c../etc/passwd/

Or

api/%5C../%5C../%5C../Gemfile 

exposed files outside of Rails’ view paths. '%5C' turns into '\' after decoding. Using
Rack::Protection  didn’t help as it only rejects '/../' segments in the request path.  

My Finding....

 

In the above summary it only rejects '/../' segments in the request path and path is not sanitized to filter out malicious characters like "..%5c", It is easily possible to access any file which is locally stored on the system outside the root directory.

Now coming back to Flowdock.com 

here is the proof of concept that I included with the bug. It displayed the contents of the /etc/passwd file of the Flowdock.com server

https://www.flowdock.com/api//%5c../%5c../%5c../%5c../%5c../%5c../%5c../etc/passwd

The vulnerability was resolved now and more Info about Fix

https://groups.google.com/forum/#!msg/rubyonrails-security/NkKc7vTW70o/NxW_PDBSG3AJ 

http://blog.flowdock.com/2014/05/07/how-we-found-a-directory-traversal-vulnerability-in-rails-routes/

More about

The vulnerability mentioned here has been confirmed fixed by Flowdock Team.

I’d like to thank Otto Hilska , Tuomas Silen and ville Lautanal for handling this issue and  the vulnerability was patched and the fix was deployed in production about two and a half after my initial report.

Its my first writing for poc....

Blog Writing style copied from Neal Poole blog thanks for write such a great blog.....