Categories
Cybersecurity Advisories

Remediation Plan: Strict Transport Security Not Enforced (RFC 6797 – CWE-523)

Finding: Strict Transport Security Not Enforced (RFC 6797) – CWE-523

Description:
The web server is not enforcing HTTP Strict Transport Security (HSTS), a critical web security policy mechanism defined in RFC 6797. HSTS allows web servers to declare that user agents (e.g., browsers) should only interact with it over secure HTTPS connections, thereby preventing downgrade attacks and cookie hijacking over insecure HTTP.

Risk:
Without HSTS, users may unknowingly make HTTP requests, exposing session cookies and sensitive data to interception via man-in-the-middle (MITM) attacks. Attackers can exploit this gap especially on open or public Wi-Fi networks.

CWE-523: Unprotected Transport of Credentials
This vulnerability is related to the transport of credentials and other sensitive data without enforcing a secure channel.

Remediation Plan for IIS

Objective:
Enable and enforce HTTP Strict Transport Security (HSTS) on IIS-hosted websites to ensure all communication occurs over HTTPS.

Step 1: Prerequisites

– Confirm the site is already served over HTTPS with a valid SSL/TLS certificate.
– Ensure all HTTP requests are redirected to HTTPS to avoid mixed content or accessibility issues.

Step 2: Add HSTS via HTTP Response Headers

  • Option A: Using IIS Manager (GUI)
  1. Open IIS Manager.
    2. Navigate to your site under ‘Sites’.
    3. Double-click HTTP Response Headers.
    4. Click Add… and input:
    – Name: Strict-Transport-Security
    – Value: max-age=31536000; includeSubDomains; preload
    5. Click OK to apply.
  • Option B: Using Web.config

Add the following inside the <system.webServer> section of your Web.config:

<httpProtocol>
  <customHeaders>
    <add name=”Strict-Transport-Security” value=”max-age=31536000; includeSubDomains; preload” />
  </customHeaders>
</httpProtocol>

Explanation of Header Components:
– max-age=31536000: Enforce HTTPS for 1 year (in seconds).
– includeSubDomains: Apply policy to all subdomains.
– preload: Indicates intent to submit the domain to HSTS preload lists.

Step 3: Redirect HTTP to HTTPS

  • Option A: HTTP Redirect in IIS

– Select the site, go to HTTP Redirect, enable it, and set the destination to your HTTPS URL.

  • Option B: Rewrite Rules

Use the URL Rewrite module:

<rewrite>
  <rules>
    <rule name=”Redirect to HTTPS” stopProcessing=”true”>
      <match url=”(.*)” />
      <conditions>
        <add input=”{HTTPS}” pattern=”off” ignoreCase=”true” />
      </conditions>
      <action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />
    </rule>
  </rules>
</rewrite>

Step 4: Test Implementation

Use tools such as:
– SSL Labs (https://www.ssllabs.com/ssltest/)
– curl -I https://yourdomain.com (Confirm presence of the Strict-Transport-Security header)

Step 5: (Optional) Submit Domain to HSTS Preload List

Once the policy is stable, you may submit the domain at:
https://hstspreload.org/

Verification: How to Confirm HSTS is Properly Enforced

After implementing the HSTS policy, it’s important to validate that the configuration is correctly applied and functioning as intended. Use the following steps to confirm the remediation:

  1. Use curl to inspect the response headers:

Run the following command:
`curl -I https://yourdomain.com`
Look for the `Strict-Transport-Security` header in the output. It should match the expected value:
`Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`

  1. Use SSL Labs Test:

– Visit: https://www.ssllabs.com/ssltest/
– Enter your domain and start the test.
– Check the ‘HTTP Strict Transport Security (HSTS)’ section to verify correct setup.

  1. Use a browser with developer tools:

– Open your site in Chrome or Firefox.
– Open Developer Tools (F12), go to the Network tab.
– Refresh the page and click on your HTTPS request.
– Check the ‘Response Headers’ for the presence of `Strict-Transport-Security`.

  1. Test HTTP to HTTPS redirection:

– Navigate to http://yourdomain.com (without HTTPS).
– Confirm that it automatically redirects to https://yourdomain.com using a 301 or 302 status code.

  1. Optional: Check HSTS preload status:

– Visit: https://hstspreload.org/
– Enter your domain to check preload status or submit it for inclusion.

Categories
Cybersecurity Advisories

Remediation Guidance: SWEET32 Vulnerability on IIS (Windows Server 2019)

Finding: SWEET32 (CVE-2016-2183) 

The SWEET32 vulnerability affects SSL/TLS protocols that use 64-bit block ciphers, specifically 3DES (Triple DES) and IDEA. These ciphers are susceptible to birthday attacks when large volumes of data are transmitted over a persistent connection, potentially allowing an attacker to recover parts of plaintext traffic. IIS servers with 3DES enabled are affected. 

Remediation for IIS on Windows Server 2019 

Windows Server 2019 supports TLS 1.2 and 1.3 by default, along with modern AES-based cipher suites. However, 3DES may still be enabled for legacy compatibility and must be disabled to fully remediate SWEET32. 

Step 1: Disable 3DES via the Windows Registry 

Navigate to the following registry key and create or set the value as below: 
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168nnSet the DWORD value ‘Enabled’ to 0. 

Alternatively, create a .reg file with the following content and import it: 

Windows Registry Editor Version 5.00 
 
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168] 
“Enabled”=dword:00000000 

A system reboot is required for changes to take effect. 

Step 2: (Optional) Use IIS Crypto Tool 

To simplify cipher and protocol management, use the free Nartac IIS Crypto tool: 
• Download from https://www.nartac.com/Products/IISCrypto 
• Run the tool on the server 
• Select the ‘Best Practices’ template 
• Ensure 3DES and TLS 1.0/1.1 are disabled 
• Apply the changes and reboot the server 

Step 3: Verify Remediation and Confirm SWEET32 Is No Longer Present 

After applying the remediation steps and rebooting the server, verify that the SWEET32 vulnerability has been resolved. Use one of the following tools to confirm that 3DES is no longer supported: 

  • SSL Labs Server Test (recommended for public-facing servers):
    Visit https://www.ssllabs.com/ssltest/ and enter the domain name of the affected server. 
      Review the results to ensure 3DES is not listed among the supported cipher suites. 
  • Nmap (quick CLI-based check):
    Run the following command: 
      nmap –script ssl-enum-ciphers -p 443 [hostname or IP] 
      Look for 3DES or other 64-bit ciphers in the output. 
  • testssl.sh (thorough internal scan):
    Run the following command: 
      testssl.sh –vulnerable –cipher-per-proto –html customerDomain.com 
      This generates an HTML report showing all supported ciphers and any related vulnerabilities, including SWEET32.