The curious case of XSS and the mouse middle button.

Hi guys! Today I will share my experience of how I exploited an XSS in a pretty particular scenario. 

During analysis, there was a feature on the application that allows the customer to add external reference links for specific options.

So, there were input filters not allowing double quotes, <,>, and other chars. The injection would happen only in the href parameter.

Basically: 

<a href="<xss_here>" target="_blank">ClickMe</a>

At this point, I thought, piece of cake, I will inject a standard payload like javascript:alert(1), and that's it, exploited! 

<a href="javascript:alert(1)" target="_blank">ClickMe</a> Right?

 

WRONG! 

As you know, the "target" parameter controls the window link behavior. 

In this case, it forces the link to open in a new tab due to the _blank value. When you left-click (the usual behavior), on the link, even with the javascript:alert(1) payload, the browsers handle it differently:

Firefox: Opens a new blank tab with the payload on the URL address bar

 

Chrome and Edge: Open a new blank tab with about:blank#blocked on the URL address bar. 

So, based on this behavior, it's clear it cannot be exploited just by left-clicking on the link.

I tried to change the target parameter value using javascript, but the instruction to open a new tab executes first, so there is no way to rewrite the value on the fly. 

After some research, I found these links https://bugzilla.mozilla.org/show_bug.cgi?id=55696 and https://support.mozilla.org/en-US/questions/1289787 related to new tab/window and javascript execution. Then the idea to use the mouse middle button popped up, and BANG!  

By default, the browsers(Firefox, Chrome, and Edge) have the middle button configured to force open links in a new tab. So, by using this button, the browsers executed the Javascript! Also, this time, the behavior was slightly different, and it can interfere during the exploitation. To test these conditions, I changed the payload to javascript:alert(document.cookie) 

Firefox: The browser executed the javascript in a new blank tab. However, the javascript could not read the cookie, as expected, due to run in a blank tab out of the application context.

Chrome and Edge: The browsers weirdly did not open a new tab, even forced by the middle button. So, the javascript is executed in the application context. That is, it can read the application cookies.

That's all, folks! Cya!

Burp Suite - Adding Internal Path Disclosure Capabilities

Hi guys, I hope everyone is healthy.

If you work with Burp suite, maybe you noticed Burp cannot identify Internal PATH Disclosure vulnerabilities by default.

I know most of the time, this vulnerability is ranked as Informational or Low. But I decided to write this after using the information acquired due to the internal path leakage to perform a more complex chain attack.

For this reason, the vulnerability was ranked as high due to the overall impact. In other words, I would not be able to create an effective attack chain without this leaked path.

The implementation is quite simple:

Install the extension Burp Bounty (Unfortunately, it is available for Buro Pro only).
On the tab Profiles -> Passive Response Profiles -> Add
Fulfill the fields(Response) and click on Add
Here you add the regex you are looking for. It's possible to add more than one regex. In my case, I created two different profiles, one for Windows issues and another one for Linux. 

Following the regex for both cases: 

Linux:  (?<!\S)(?:/[^/\s>]+)+
Thanks to codeworm for the help with Linux regex.

Windows: ([a-zA-Z]):\\?(\\[a-zA-Z0-9._-].*\s.*+)+\\
For Windows, the regex needs some enhancements.  

The new issues:

Now, some extra configuration is required to Burp shows it properly on the Target tab.
Click on the Issue tab and fulfill the fields. The Severy and Confidence must be selected. You are free to select the rating you want. The issue detail is the information that will be displayed on the Target tab.

After you added all the information, click OK and double-check if everything is saved. Sometimes the extension does not save the regex, them you must add it again.

Testing your new issues:

Navigate to: https://owasp.org/www-community/attacks/Full_Path_Disclosure and run a passive scan on this page.

Your Burp should show something like that:

Note: The Severity and Confidence are different on purpose, just to show it is possible to assess it differently.

Checking the match on the source code:

Linux: 

Windows:

 
This it, guys! 
Since I update the windows regex, I will update the post.

WebNBF

WebNBF
https://github.com/crashbrz/WebNBF

Simple Bash "Multitask" Web NTLM Authentication Bruteforcer.
Usage/Help./webnbf.sh <userlist> <passwordlist> https://target

Proxy

Add or remove the curl proxy parameters according to your environment.

WebXmlExploiter

WebXmlExploiter
https://github.com/crashbrz/WebXmlExploiter

The WebXmlExploiter is a tool to exploit exposed by misconfiguration or path traversal web.xml files.
It will try to download all .class and XML files based on the information extracted from the web.xml file.

Notes
WebXmlExploiter is an exploitation tool only, not a vulnerability scanner.
I will not add a brute-forcing feature since tools like wfuzz,ffuzz, and burp suite can do it better.
I recommend running the jadx to decompile the .class files.

Installation
Download the latest release and unpack it in the desired location.
Remember to install GoLang in case you want to run from the source.
WebXmlExploiter uses the github.com/antchfx/xmlquery libraries.

Check the following link for more information: https://github.com/antchfx/xmlquery/

Run: go get github.com/antchfx/xmlquery before running the WebXmlExploiter.

License
WebXmlExploiter is licensed under the SushiWare license. Check docs/license.txt for more information.
Usage/Help

Please refer to the output of -h for usage information and general help. Also, you can contact me on ##spoonfed@freenode.org (two #)


Example: go run webxmlexploiter.go -u https://vulnapp/somedir/anotherdir/../../../WEB-INF/

Go Version

Tested on:
go version go1.14.4 windows/amd64
go version go1.15.2 linux/amd64

To Do
Parsing enhancements Add cookies support.