Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Steffen_Appel
Collaborator

Are the SMB devices vulnerable to DNSpooQ?

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?

32 Replies
G_W_Albrecht
Champion
Champion

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.
0 Kudos
John_Fleming
Advisor

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]#

0 Kudos
PhoneBoy
Admin
Admin

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 

0 Kudos
Steffen_Appel
Collaborator

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
Admin
Admin

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

0 Kudos
Steffen_Appel
Collaborator

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.

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
Steffen_Appel
Collaborator

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

0 Kudos
Steffen_Appel
Collaborator

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

0 Kudos
Steffen_Appel
Collaborator

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

Steffen_Appel
Collaborator

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

PhoneBoy
Admin
Admin

Thanks for staying on top of this.

Steffen_Appel
Collaborator

That is a different bug from 13 years ago.

G_W_Albrecht
Champion
Champion

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

0 Kudos
Steffen_Appel
Collaborator

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

G_W_Albrecht
Champion
Champion

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.

0 Kudos
Steffen_Appel
Collaborator

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

G_W_Albrecht
Champion
Champion

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

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
PhoneBoy
Admin
Admin

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

John_Fleming
Advisor

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

0 Kudos
G_W_Albrecht
Champion
Champion

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

0 Kudos
Amir_Ayalon
Employee
Employee

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
Advisor

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

0 Kudos
Steffen_Appel
Collaborator

any update to the 1100?

0 Kudos
Amir_Ayalon
Employee
Employee

in progress

Steffen_Appel
Collaborator

Thanks

0 Kudos
Steffen_Appel
Collaborator

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

0 Kudos
Amir_Ayalon
Employee
Employee

Hi Steffen

when R&D will finish the development, we will update TAC.
 
 
 
 it will happen soon.
 
 
 thanks