Customer has run a vulnerability scanner against the NetWitness Platform on version 11.4.x or 11.5.x and received one or more of the below DNS vulnerabilities.
- DNS Server Cache Snooping Remote Information Disclosure Vulnerability
- DNS Server Dynamic Update Record Injection Vulnerability
- SA UDP 53 server dynamic update received injection
- Oilrig (APT34) DNS-Over-HTTPS
- CVE-2020-25681: Dnsmasq versions before 2.83are susceptible to a heap-based buffer overflow in sort_rrset() when DNSSEC is used. This can allow a remote attacker to write arbitrary data into target device?s memory that can lead to memory corruption and other unexpected behaviors on the target device.
- CVE-2020-25682: Dnsmasq versions before 2.83 are susceptible to buffer overflow in extract_name() function due to missing length check, when DNSSEC is enabled. This can allow a remote attacker to cause memory corruption on the target device.
- CVE-2020-25683: Dnsmasq versions before 2.83 are susceptible to a heap-based buffer overflow when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in get_rdata() and cause a crash in dnsmasq, resulting in a Denial of Service.
- CVE-2020-25687: Dnsmasq versions before 2.83are vulnerable to a heap-based buffer overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of Service.
- CVE-2020-25684: A lack of proper address/port check implemented in dnsmasq versions
- CVE-2020-25685: A lack of query resource name (RRNAME) checks implemented in dnsmasqs versions before 2.83 reply_query function allows remote attackers to spoof DNS traffic that can lead to DNS cache poisoning
- CVE-2020-25686: Multiple DNS query requests for the same resource name (RRNAME) by dnsmasq versions before 2.83 allows for remote attackers to spoof DNS traffic, using a birthday attack (RFC 5452), that can lead to DNS cache poisoning.
- CVE-2019-14834: dnsmasq: memory leak in the create_helper() function in /src/helper.c
To resolve the vulnerabilities outlined in the Issues section, determine the version of NetWitness Platform that is running in the environment and consult the following sections.
NetWitness 11.4.x Customers
Important: The steps in How to add custom firewall rules after nwsetup-tui has completed in RSA NetWitness Logs & Network 11.x must be followed before performing any steps in this section. If the steps are not followed, the firewall rules can revert back to their original configuration without notice.
For customers on NetWitness 11.4.x that would like to mitigate possible DNS vulnerabilities the option provided below will walk the customer through blocking all DNS requests directed at the NetWitness device.
Note: The following steps need to be performed on all devices.
- SSH into the device that contains the DNS vulnerability.
- Copy the iptables file from /etc/sysconfig to /root to back up the existing configuration.
> cp /etc/sysconfig/iptables /root/iptables-backup
- Edit the existing iptables file and comment out, using the pound (#) symbol, all ACCEPT rules referencing dports 53. Once done, save and exit the file.
> vi /etc/sysconfig/iptables
# -A INPUT -p tcp -m tcp -m multiport --dports 53 -m comment --comment "dnsmasq-tcp-port" -m conntrack --ctstate NEW -j ACCEPT
# -A INPUT -p udp -m udp -m multiport --dports 53 -m comment --comment "dnsmasq-udp-port" -m coontrack --ctstate NEW -j ACCEPT
- Reload the iptables rules into the service for the changes to take effect.
> systemctl reload iptables
The above steps will completely block all DNS traffic to the device. If DNS is required but can be restricted to a specific IP address or subnet, a change to the iptables DNS rules can be made instead of commenting them out.
- SSH into the device that contains the DNS vulnerability.
- Copy the iptables file from /etc/sysconfig to /root to back up the existing configuration.
> cp /etc/sysconfig/iptables /root/iptables-backup
- Edit the existing iptables and modify all ACCEPT rules referencing dports 53 to accept traffic only on certain ip/subnets. Once done, save and exit the file.
> vi /etc/sysconfig/iptables
-A INPUT -p tcp -m tcp -m multiport --dports 53 -s 10.10.10.0/24 -m comment --comment "dnsmasq-tcp-port" -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m udp -m multiport --dports 53 -s 10.10.10.0/24 -m comment --comment "dnsmasq-udp-port" -m coontrack --ctstate NEW -j ACCEPT
- Reload the iptables rules into the service for the changes to take effect.
> systemctl reload iptables
NetWitness 11.5.x Customers
In 11.5.x NetWitness no longer uses DNSmasq. It is still enabled to allow for upgrades from 11.4.x and earlier to 11.5.x. Once all NetWitness servers are on 11.5.x, DNSmasq is no longer required. Follow the below steps to restrict DNS access.
- SSH into the Admin server.
- Create a new directory called nw-component-descriptor.d under /etc/netwitness/component-descriptor/descriptor/<version number>.
Note: <version number> is the version of NetWitness the Admin server is running. Example: 11.5.1
> mkdir /etc/netwitness/component-descriptor/descriptor/11.5.1/nw-component-descriptor.d
- Navigate into the newly created nw-component-descriptor.d directory and create a new file, dnsmasq-override.yaml.
> cd /etc/netwitness/component-descriptor/descriptor/11.5.1/nw-component-descriptor.d
> touch dnsmasq-override.yaml
- Edit the dnsmasq-override.yaml file.
> vi dnsmasq-override.yaml
- Add the following to the open file. Once done, save and exit the file.
components:
dnsmasq:
firewall_rules: []
- Run the following command to tell the Admin server to use the new configuration file. Node-Zero-Address is the IP address of the Admin server.
> nw-manage --refresh-host --host-key <Node-Zero-Address>