Category Archives: My Advisories

Soroush Dalili’s Security Advisories

Rare ASP.NET request validation bypass using request encoding

I had blogged about this in NCC Group’s website. I thought it is the best to add a link to it here as well.

It is possible to bypass the ASP.NET request validation capability when errors are ignored using request encoding techniques. This can be abused to perform stored cross-site scripting (XSS) attacks.

The full article can be read here: https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/september/rare-aspnet-request-validation-bypass-using-request-encoding/

PDF version can be downloaded from: https://soroush.secproject.com/downloadable/Rare_ASP.NET_Request_Validation_Bypass_Using_Request_Encoding.pdf

Request encoding to bypass web application firewalls

I “think” I have discovered a “new” technique in bypassing external web application firewalls using request encoding. The idea is very simple but I had not seen this before to be used to bypass any protection mechanisms. Details of this technique has been published via NCC Group’s blog:

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/august/request-encoding-to-bypass-web-application-firewalls/

This technique was presented as one the methods to mutate the HTTP requests in:

There are loads of other anomalies that can be used to bypass WAFs using webservers behaviour in accepting HTTP requests; my plan is to complete this research and put all the results via the https://http.ninja/ website. Please feel free to contact me via my Twitter (@irsdl) if you have some ideas regarding this.

The unofficial PDF version of this blog post can be downloaded from here:
https://soroush.secproject.com/downloadable/request-encoding-to-bypass-web-application-firewalls.pdf

Almost all the cloud-based WAFs that I had tested could be bypassed using this technique at the time of discovery.

CVE-2017-8592 – XMLHttpRequest in IE followed 307 redirections with additional or customised headers

If you are doing web application security assessments, you probably have seen many APIs that do not have any cross-site request forgery (CSRF) protections other than checking the Content-Type header.

Although this seems like a bad way of doing this, browsers do not normally allow you to use unusual Content-Type headers for another website (without CORS) and therefore the exploitation is quite impossible. However, a vulnerability was found in Internet Explorer and Edge that allowed users to set these arbitrary headers (anything that JavaScript can set). This issue was patched in July 2017. More details can be seen here:

https://www.nccgroup.trust/uk/our-research/technical-advisory-cve-2017-8592-xmlhttprequest-in-ie-followed-307-redirections-with-additional-or-customised-headers/

As mentioned in the above URL, bypassing security features using redirection is a common attack vector and it was interesting that this issue had not been reported to Microsoft previously. A similar issue in Adobe Flash had been patched a long time ago (see https://www.whitehatsec.com/blog/flash-307-redirect-game-over/).

Analysis of setting cookies for third party websites in different browsers

I had done a research into the ability of third party websites setting cookies for first party websites across different web browsers. This was published in the NCC Group blog which is available via the following link:

https://www.nccgroup.com/en/blog/2015/01/analysis-of-setting-cookies-for-third-party-websites-in-different-browsers/

The PDF version of this blog post is also available here: https://soroush.secproject.com/downloadable/Analysis_of_setting_cookies_NCCGroup_blog.pdf

IIS Short File Name Disclosure is back! Is your server vulnerable?

After a few years of finding IIS Short File Name Disclosure vulnerability/feature, I discovered a new method that can work on the latest versions of IIS!

It is a simple trick: If OPTIONS method is used instead of a GET method, the latest versions of IIS will produce a different error message when a short file name is available on the server. The actual bug is exactly the same as the original report and therefore this does not count as a new issue but a new technique.

I have also updated my Java scanner which is accessible via my GitHub repository: https://github.com/irsdl/iis-shortname-scanner/tree/master/

I have successfully tested this scanner on a freshly installed IIS7.5 on Windows 2008 R2 and also on an IIS8.0 on Windows 2012. It seems 8.3 names are still enabled by default… and Microsoft does not seem to be keen to patch this low risk issue after a few years. Well, it is a feature now just like the semi-colon vulnerability in IIS6! ;-)

Test your IIS server and see if it is vulnerable! You may need to add valid headers and cookies to the scanner to be able to scan some special servers.