Are the SMB devices vulnerable to DNSpooQ?

[Steffen_Appel]

1100/1400/1500 are using DNSmasq in version 2.78, which is vulnerable to DNSpooQ: https://www.jsof-tech.com/disclosures/dnspooq/

Could anybody confirm this? And if yes, when will there be a fix?

[G_W_Albrecht]

I can only find sk35484 Check Point response to DNS poisoning vulnerability CVE-2008-1447 stating:

On July 8, 2008 CERT announced a new DNS cache poisoning technique that exploits the fact that DNS servers send requests with non random source ports.

Check Point products are not vulnerable to this attack for the following reasons:

• Check Point products do not implement DNS server functionality.

[John_Fleming]

cough cough cough

[Expert@1500]# netstat -anp | grep dnsmasq
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 4190/dnsmasq
tcp 0 0 :::53 :::* LISTEN 4190/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0:* 4190/dnsmasq
udp 0 0 :::53 :::* 4190/dnsmasq
unix 2 [ ] DGRAM 1861 4190/dnsmasq
[Expert@1500]#

[PhoneBoy]

That's an old SK that doesn't reference this particular issue.
In any case, we're not vulnerable because:

• We don't use DNSSEC
• We only use local zones and not registered ones

See: https://kb.cert.org/vuls/id/434904 

[Steffen_Appel]

The second set of issues does not requie DNSSEC:

JSOF also reported vulnerabilities in DNS response validation that can result in DNS cache poisoning.

• CVE-2020-25684: Dnsmasq does not validate the combination of address/port and the query-id fields of DNS request when accepting DNS responses
• CVE-2020-25685: Dnsmasq uses a weak hashing algorithm (CRC32) when compiled without DNSSEC to validate DNS responses
• CVE-2020-25686: Dnsmasq does not check for an existing pending request for the same name and forwards a new request thus allowing an attacker to perform a "Birthday Attack" scenario to forge replies and potentially poison the DNS cache

Seems like these one could be an issue.

[PhoneBoy]

To the best of my knowledge, we are not vulnerable to any of the issues mentioned. 

[Steffen_Appel]

Could you please check with R&D as the version on the appliance is 2.78 and the first unaffected is 2.83.

Thank you.

[PhoneBoy]

When we say “not vulnerable” that generally means one of two things:

• We patched the vulnerable code already (often without updating the version)
• Due to configuration/usage, it is not possible to exploit the vulnerability remotely.

I recommend a TAC case if you would like a more formal answer.

[Steffen_Appel]

I opened a TAC case, let's see what they will answer.

[Steffen_Appel]

According to https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq-Technical-WP.pdf, the SMB use -c 0 on dnsmasq and thereby disable the cache and avoid the attack by this

[Steffen_Appel]

The TAC confirmed, that it will be updated in the next GA Release.

[Steffen_Appel]

Further Update from R&D, the devices are vunerable in curtain circumstances and that is why there will be an update .

[PhoneBoy]

Thanks for staying on top of this.

[Steffen_Appel]

That is a different bug from 13 years ago.

[G_W_Albrecht]

I know - i can already read  8) and told you above i have only found something about the grandpa of these CVEs.

[Steffen_Appel]

Sure but once again, these are similar but really old.

[G_W_Albrecht]

Once again: I know. I have cited what i did find and not claimed to have found something about your issue. And i also know

sk35623: Hide NAT cancels DNS source port randomization.
sk35624: Preventing DNS cache poisoning when reusing source ports.

[Steffen_Appel]

Yes but unreletant bugs are not useful to answer the question 🙂

[G_W_Albrecht]

Did you ever read these "unreletant" SKs ? Silently shaking my head...

[PhoneBoy]

We're all trying to help out.
Let's keep it friendly 🙂

[PhoneBoy]

Possible we’ve patched this already, I’ll check.

[John_Fleming]

Or you know since its GPL code you could give access to customers so they could see for themselves.

[G_W_Albrecht]

See for themselves ? How ? All customers i know of are absolutely GPL code blind 8). I would suggest that CP answers the question once for all instead.

[Amir_Ayalon]

In some scenarios, SMB 1500 devices can be vulnerable to DNSPooQ on internal (LAN, Wi-Fi) networks.
The issue is resolved in R80.20.20 Build 992001869
http://downloads.checkpoint.com/fileserver/ID/112434/FILE/fw1_vx_dep_R80_992001869_20.img

In some scenarios, SMB 700 and 1400 devices can be vulnerable to DNSPooQ on internal (LAN, Wi-Fi) networks.
The issue is resolved in R77.20.87 Jumbo Hotfix build 990173083
http://downloads.checkpoint.com/fileserver/ID/112528/FILE/fw1_sx_dep_R77_990173083_20.img

In some scenarios, SMB 1200R devices can be vulnerable to DNSPooQ on internal (LAN, Wi-Fi) networks.
The issue is resolved in R77.20.81 Jumbo Hotfix build 990172611
http://downloads.checkpoint.com/fileserver/ID/112500/FILE/fw1_ind_dep_R77_990172611_20.img

[John_Fleming]

Will a CVE be posted if it hasn't already been?

[Steffen_Appel]

any update to the 1100?

[Amir_Ayalon]

in progress

[Steffen_Appel]

Thanks

[Steffen_Appel]

TAC told me there will be no new build for the 1100, but you wrote there will be one?

[Amir_Ayalon]

Hi Steffen

when R&D will finish the development, we will update TAC.

 it will happen soon.

 thanks