Home / server / Questions / 836736
Accepted
jshizzle
Asked: 2017-03-08 01:14:07 +0800 CST

IIS tilde vulnerability

  • 772

I have the same problem as mentioned here Fixing the IIS tilde vulnerability and have applied all suggested fixes:

  • 8dot3 naming disabled on all drives
  • 8dot3 names stripped from c:\inetpub\wwwroot
  • fsutil & dir /x scan completed and no 8dot3 names found
  • IIS Request filtering deny rule and deny URL in place

I'm still getting a result of vulnerable when using the IIS Shortname Scanner PoC tool with the below result:

IIS Short Name (8.3) Scanner version 2.3.8 (25 February 2016) - scan initiated 2017/03/06 20:10:05

  • Target: https://website.name.com/
  • Result: Vulnerable!
  • Used HTTP method: DEBUG
  • Suffix (magic part): /a.aspx
  • Extra information:
    • Number of sent requests: 145

This to me doesn't really help identify where the problem lies and that it's simply still vulnerable. The command I'm using is:

java -jar iis_shortname_scanner.jar 2 20 https://website.name.com/

I have three app servers sitting behind a load balancer but as long as the servers have been fixed I can't see why this would make a difference....

I thought it better to start a new question as the other thread had been addressed and a successful fix provided but not the case for me unfortunately.

iis vulnerability

2 Answers

  1. For myself I used a request filtering deny sequence entry in my web.config:

    <system.webServer>
      <security>
        <requestFiltering>
          <denyUrlSequences>               
            <add sequence="~" />
          </denyUrlSequences>
        </requestFiltering>
    </security>
</system.webServer>

    This passes the scanner tests I have run against it.

    • 2
  2. Best Answer

    Managed to fix this by adding the URL Rewrite module to IIS on each app server and adding an inbound rule with the following:

    • Pattern: (^[^\?]\~.\?.$)|(^[^\?]\~.*$)
    • Action: Abort Request

    Hopefully that's of some use. A scan after putting this in place gave a result of "Not vulnerable" for this exploit.

    • 1