Categories
Cybersecurity Advisories

Finding: DNSSEC Not Enabled on Azure DNS Zones

Finding: DNSSEC Not Enabled on Azure DNS Zones

Description:
DNSSEC (Domain Name System Security Extensions) provides origin authentication and integrity for DNS data, helping prevent attacks like DNS spoofing and cache poisoning. By default, Azure DNS zones do not have DNSSEC enabled unless explicitly configured. This exposes DNS clients to potential risks if responses are intercepted or forged. Failing to implement DNSSEC undermines the trust and reliability of the DNS infrastructure supporting your services.

Remediation: Enable DNSSEC on Azure DNS Zones

Pre-Requisites

– You must be using Azure DNS for both the zone and the registrar. – Your zone must be hosted on Azure DNS, not a third-party service.

Step-by-Step Remediation

1. Log in to Azure Portal: Navigate to https://portal.azure.com and sign in with an account that has DNS Zone Contributor or higher permissions.

2. Navigate to DNS Zone: In the left-hand menu, go to ‘DNS zones’ and select the DNS zone you want to secure (e.g., example.com).

3. Enable DNSSEC: Under the Settings section, select ‘DNSSEC’ and click ‘Enable DNSSEC’. Azure will automatically generate Key Signing Keys (KSK) and Zone Signing Keys (ZSK).

4. Verify the Zone Type: Azure DNSSEC works only for public DNS zones. Private DNS zones are not currently supported.

5. Complete Registrar Configuration: If the domain was registered through Azure, DS record submission is automatic. If not, manually retrieve the DS record and update it at your registrar.

6. Save and Propagate: Ensure changes are saved. Allow up to 24 hours for DNSSEC validation to propagate.

Verification: DNSSEC Successfully Enabled

Option 1: Using Dig (Command Line)

Run the following command and look for RRSIG records and a valid AD (Authenticated Data) flag:

               dig + dnssec example.com

Option 2: Using DNSViz Tool

Visit: https://dnsviz.net/ Enter your domain (e.g., example.com), click “Analyze”, and confirm the DNSSEC chain of trust is complete and error-free.

Option 3: Using Azure Portal

Return to the DNSSEC tab in your DNS zone. Confirm DNSSEC status shows as Enabled and KSK/ZSK status is Active.

Note
Azure currently does not support DNSSEC with external registrars or customer-managed keys. Always back up DNS configurations before making changes to production zones.

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.