Tag Archives: vulnerability

Patch Your DNS Servers! SigRed

Posted on by
4

KB ID 0001687

Problem

WARNING: This is rated 10 on the CVSS scale.

Affected Server OS: Windows 2003, Windows 2008, Windows 2008 R2, Windows 2012, Windows 2012 R2, Windows 2016, Windows 2019

Yesterday Microsoft released a critical notice (KB4569509) to address vulnerabilities identified in (CVE-2020-1350). Basically it allows a remote attacker to perform remote code execution on your DNS servers (unless you patch them!) The reason its so important is that its considered ‘wormable’, (can jump from machine to machine with our user interaction).

To see how easy that is to do, watch the video below;

To be attacked from an external source the DNS Server has to be publicly addressable, however if you have a compromised machine in your network, it wont be long before a malicious payload can be delivered from that vector also.

Solution

The correct fix is to update you servers from Windows Update as soon as possible! However if you want to protect yourself in the interim.

You need to make a slight change in the Windows DNS Server registry. I’ve written the PowerShell out, to save you poking around in the registry, it will change the key for you, and then restart the DNS Service.

[box]

# Set DNS Registry Key (Vulnerability CVE-2020-1350)
$RegKey ="HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters"
Set-ItemProperty -Path $RegKey -Name TcpReceivePacketSize  -Value 0xFF00
Get-ItemProperty -Path. -Name TcpReceivePacketSize
Restart-Service DNS

[/box]

If you have a Cisco Firewall you can use the default DNS inspection to mitigate this, RFC 1035 define DNS packets should be less than 512 bytes. But Window uses EDNS so you may have “message-length maximum client auto” in your config, If you remove that, and change the maximum allowed size to 65280 you will mitigate THIS problem. Though I don’t like that as a solution, (unless you have a lot of DNS servers to update, and want to throw in a quick fix while you patch them all). 

Note: This vulnerability has existed for 17 years! But now it’s public knowledge, so the clock is ticking before it gets exploited, ACT NOW!

Related Articles, References, Credits, or External Links

NA

Cisco ASA – Disable SSLv3 (Force TLSv1.0) – Mitigate POODLE

Posted on by

KB ID 0001052

Problem

By default the Cisco ASA will allow connection via SSLv3. The POODLE exploit works by forcing SSL to fall back to SSLv3 and then decrypting that communication. However you are still not completely protected as per this Threat Validation, so the ASA platform can still be attacked via TLSv1.0. Note: At time of writing TLSv1.2 is not supported, but it is on the road-map for version 9.3(2).

So this procedure will not completely eliminate the threat, but it’s as mitigated as it’s possible to be at this time, (And TLSv1 is considered more secure than SSLv3 anyway).

Solution

1. You can check your firewall is contactable via SSLv3, here I’m on MAC OSX and I’ve got OpenSSL installed. If I try to initiate an SSLv3 connection it works.

[box] openssl s_client -connect {IP_or_Hostname} -ssl3 [/box]

Or if you have nmap installed you can use that as well;

[box]nmap –script ssl-enum-ciphers {IP_of_Hostname}[/box]

2. Below you can see I’m confirming the SSL settings (i.e. it will accept SSLv3). Then I force the firewall to only accept TLSv1.0.

[box]

Petes-ASA# configure terminal
Petes-ASA(config)# ssl client-version tlsv1-only 
Petes-ASA(config)# ssl server-version tlsv1-only

[/box]

You can see, afterwards when I view the SSL options, only TLSv1 will be accepted.

3. If you prefer to use the ADSM, then you will find the same settings at, Configuration > Remote Access VPN > Advanced > SSL Settings;

The SSL version for the security appliance to negotiate as a ‘server’ = TLS V1 Only

The SSL version for the security appliance to negotiate as a ‘client’ = TLS V1 Only

 

4. Don’t forget to ‘Apply’ and then save the changes.

Cisco ASA Testing for SSLv3

Simply perform the tests that I did above;

1. Proving the absence of SSLv3 with OpenSSL.

2. Proving the absence of SSLv3 with nmap.

Related Articles, References, Credits, or External Links

NA