3

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.

Community
  • 1
jshizzle
  • 341
  • 10
  • 25

2 Answers2

2

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.

Strake
  • 121
  • 3
  • Hi Strake, this was already in place in my environment but forgot to mention that. My above solution was needed in addition to this but may only be relevant when behind a load balancer maybe! – jshizzle Apr 27 '17 at 06:36
  • Interesting. For me I have on-premise installs in multiple locations so I was looking for the most extensible solution without adding a dependency. So far the deny sequence has been working in my cases. – Strake May 01 '17 at 17:55
1

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.

jshizzle
  • 341
  • 10
  • 25