ISC BIND Denial of service and ISC BIND Service downgrade/reflected DOS on NetApp FAS and AFF system

[PnaveenKumar]

Hi Guys,

When we perform internal scans on our NetApp Cluster mode storage systems, we found below vulnerabilities.

ISC BIND Denial of service

ISC BIND Service downgrade/reflected DOS

We found these issues on all Netapp clusters except one cluster. Now my task is to  compare the configurations on the clusters with one cluster where these vulnerabilities are not found. 

What are all the configurations I need to check on my clusters to resolve this ISC BIND issues?

Any help on this is appreciated.

CVE: CVE-2020-8616
Plugin Name Severity IP Address Protocol Port
ISC BIND Denial of
Service High IP Address UDP 53
Plugin Text:
Plugin Output:
Installed version : 9.6.2-P2
Fixed version : 9.11.19
Synopsis: The remote name server is affected by an assertion failure vulnerability.
Description: A denial of service (DoS) vulnerability exists in ISC BIND versions 9.11.18 / 9.11.18-S1 / 9.12.4-P2 / 9.13 / 9.14.11 / 9.15 / 9.16.2 / 9.17 /
9.17.1 and earlier. An unauthenticated, remote attacker can exploit this issue, via a specially-crafted message, to cause the service to stop responding.
Solution: Upgrade to the patched release most closely related to your current version of BIND.
See Also: https://kb.isc.org/docs/cve-2020-8617
CVE: CVE-2020-8617
Plugin Name Severity IP Address Protocol Port
ISC BIND Service
Downgrade / Reflected
DoS
Medium IP Address UDP 53
Plugin Text:
Plugin Output:
Installed version : 9.6.2-P2
Fixed version : 9.11.19
Synopsis: The remote name server is affected by Service Downgrade / Reflected DoS vulnerabilities.
Description: According to its self-reported version, the instance of ISC BIND 9 running on the remote name server is affected by performance
downgrade and Reflected DoS vulnerabilities. This is due to BIND DNS not sufficiently limiting the number fetches which may be performed while
processing a referral response.
An unauthenticated, remote attacker can exploit this to cause degrade the service of the recursive server or to use the affected server as a reflector in
a reflection attack.
Solution: Upgrade to the ISC BIND version referenced in the vendor advisory.
See Also: https://kb.isc.org/docs/cve-2020-8616

[TMACMD]

So, you need to remember a lot of these scans do in fact provide false positives.

The reason is roughly because they scan certain elements and assume a particular operating system and version.

ONTAP is uses different chunks of code for different areas. (like IP/TCP/DNS/etc).

A lot of scans think ONTAP is FreeBSD. It is not. It is loosely based on it with updated modules.

So assuming FreeBSD is not good especially if the module in question is already patched.

You may be able to correlate the CVE to a NetApp here: https://security.netapp.com/advisory/

Which I did here: https://security.netapp.com/advisory/ntap-20200522-0002/

But also looking:

Affected Products

• E-Series SANtricity OS Controller Baseboard Management Controller (BMC) - EF600A
• NetApp HCI Baseboard Management Controller (BMC) - H410C
• Storage Replication Adapter for Clustered Data ONTAP for Windows 7.2 and above

Products Under Investigation

• NetApp SteelStore Cloud Integrated Storage

And I see "Clustered Data ONTAP" under "Not Affected". So, it is very likely that your scanner is detecting an old version of FreeBSD that does not have the patch, however, ONTAP has already been patched and is not affected.

[PnaveenKumar]

Hi @TMACMD 

Thank you so much for your response. The information provided by you is very helpful to me. 

As I mentioned earlier, we don't see this ISC BIND vulnerability in one of our cluster which is running in the same Ontap version(9.5P6). I don't know what is the difference between this specific cluster compared to remaining clusters. Please review the attached screenshots and kindly respond back if you find anything 🙂

[TMACMD]

Can’t tell anything from that shot 

i suspect you likely have different visions of ontap on those clusters which is why the response is a little different (refer to my original post about modules)

[PnaveenKumar]

Hi @TMACMD 

All my NetApp Clusters running on the same Ontap version - 9.5P6.

[parisi]

BIND is likely being scanned on your data LIFs. We have a feature called "on-box DNS," where the ONTAP LIFs can listen for DNS queries and ONTAP uses BIND to serve DNS requests to data LIFs based on a calculated weight. 

You probably have it enabled on the data LIFs for the cluster in question. You can check with the following command:

::*> net int show -listen-for-dns-query true -fields dns-zone

For more information regarding on-box DNS, see TR-4523.

https://www.netapp.com/us/media/tr-4523.pdf

[PnaveenKumar]

Hi @parisi 

Thanks for the information.

All my Clusters are configured with On-box DNS. The On-box DNS BIND configuration is same on the cluster where we don't find BIND Vulnerabilities and Where we have BIND vulnerabilities.

I am confused, as both of them have same configurations and BIND vulnerability is showing on only one cluster.

No BIND issue Cluster:

TORNASCLUSTER_MGMT::> network interface show -listen-for-dns-query true -fields dns-zone
vserver lif dns-zone
------------- ----- --------------------------
TORNASCLUSTER NAS01 tornascluster.corp.frk.com
TORNASCLUSTER NAS02 tornascluster.corp.frk.com
TORNASCLUSTER NAS03 tornasds.corp.frk.com
TORNASCLUSTER NAS04 tornasds.corp.frk.com

BIND issue Cluster:

CHENASCLUSTER1_MGMT::> network interface show -listen-for-dns-query true -fields dns-zone
vserver lif dns-zone
-------------- ----- ---------------------------
CHENASCLUSTER1 NAS01 chenascluster1.corp.frk.com
CHENASCLUSTER1 NAS02 chenascluster1.corp.frk.com
CHENASCLUSTER1 NAS03 chenasds.corp.frk.com
CHENASCLUSTER1 NAS04 chenasds.corp.frk.com
4 entries were displayed.

Is there anything I need to take a look 🙂

[parisi]

Probably should just do a config comparison between the clusters. As TMAC pointed out, ONTAP isn't exposed to the vulnerability, so it shouldn't be a concern, but there's likely one setting that's different between the two.

[paul_stejskal]

Can you get details about how the security scanner is finding the "vulnerability"?

[PnaveenKumar]

Hi @paul_stejskal 

Security team is using Tenable Nessus for these scans. I don't know anything apart from that.

[TMACMD]

Ahh....

There is another method they should use....

Essentially, you create a nessus user in ONTAP. Allow the scan to connect to ONTAP and scan from inside. This results in far fewer false-positive results.

[PnaveenKumar]

Hi @TMACMD 

Is there any documentation or process to do that?

[paul_stejskal]

Yeah the scan is likely signature based and is looking probably for a specific string, not actually performing the DNS attack.

[TMACMD]

Exactly. And allowing Nessus to scan from inside ONTAP gets rid of the issues.

I have a had a few customer allow this and all the false-positives went away.

[PnaveenKumar]

Hi @TMACMD 

Can you please help me with the procedure so that I will try it in my environment.

[TMACMD]

Based on this link:

https://docs.tenable.com/nessus/compliancechecksreference/Content/NetAppAPIScanRequirements.htm

Create a user, with admin, read-only, applications: ontapi/http:

security login create -user-or-group-name nessus -application ontapi -authentication-method password -role readonly
security login create -user-or-group-name nessus -application http -authentication-method password -role readonly

Set the password.

Use the API method to Scan ONTAP.

I cannot help beyond that. I have never run Nessus. I have only assisted in creating the connection-point in ONTAP. 

[kryan]

Nessus has correctly identified the BIND version in ONTAP and is flagging known vulnerabilities in it.

NetApp security advisories report the exploitability status of our products.