Unbound DNS vulnerability exploit DDOS attack

Started by scalaechlon, December 01, 2020, 06:15:40 AM

Previous topic - Next topic
Good Day,

Reporting Unbound DNS vulnerability consisting of the following:
- error parsing local data resulting in a Label Length Overflow
  - happens when Unbound DNS cannot resolve a non standard DNS FQDN
    - when the FQDN exceeds the limit of standard DNS naming 
- Label Length Overflow error resulting in a Bad local-data error
- resulting in Unbound DNS fatal error: Could not set up local zones
- Unbound DNS then stops working entirely, even configuration is reverted to factory default

the issue is further aggravated if Split DNS is implemented using Unbound DNS and DNS Crypt
- DNS Crypt also stops working together with Unbound DNS after the DDOS attack

the DDOS attack originated in the ster.co.uk site with the following non standard FQDN:
- ster.co.uk/2014/10/07/adobe_digital_editions_4_caught_snooping_into_ebook_collections_of_users/
- has an A record with a broadcast address of 0.0.0.0
- has multiple public ip as detected by the sensei plugin

vulnerabilities:
- Unbound DNS has observed failure to resolve long non standard FQDN
- there is a difficulty to directly edit the unbound.conf to block or mitigate the said issue
- Unbound DNS results to a DNS fatal error: Could not set up local zones that persists even the
  opnsense configuration is reverted to factory defaults

workaround:
- to momentarily use Unmasq DNS as the DNS resolver
  - has no capability to implement Split DNS with DNS Crypt

additional issues:
- Sensei plugin cant implement its web and application filtering properly when opnsense is upgraded to its
  latest version.

Can we find an immediate remidiation for this kind of DDOS attack?

Thank you

I can confirm that I'm affected by this as well. Last night at almost the exact time you posted this, I lost DNS through Unbound with the exact same lines about the Adobe ebook in my log file. This definitely seems to be getting exploited in the wild.

But this needs to be attacked from outside? Or is this a link you received and clicked?
I mean, Unbound should only be accessible from inside?

@scalaechlon:
Can you share any reports (or CVE number) describing this issue? I was not able to find any reports regarding this vulnerability in the internet.

I am wondering regarding the FQDN you mentioned, because it isn't a FQDN. Maybe a rogue DNS-Server sent this answer? Or, do you have imported DNS blacklists?
OPNsense 24.7.11_2-amd64

Unmasq DNS? What is that? I just get alot of malware when I search, but maybe I am doing something wrong?

I'm not aware that I clicked anything when my DNS went out last night. I was doing some light web browsing on my phone and definitely nothing shady. Unfortunately, the weather was very stormy here at the time, so I assumed my internet stopped working because a tree had downed the line and didn't make a mental note of what site I was on at the time. Perhaps a malicious advertisement?

I am using the DNS blacklist feature in Unbound; however, the CRON job to reload those lists daily doesn't coincide with the time of the errors in my log file, so I don't think it was a bad entry from one of the blacklists.

Quote from: schnipp on December 01, 2020, 05:17:56 PM
@scalaechlon:
Can you share any reports (or CVE number) describing this issue? I was not able to find any reports regarding this vulnerability in the internet.

I am wondering regarding the FQDN you mentioned, because it isn't a FQDN. Maybe a rogue DNS-Server sent this answer? Or, do you have imported DNS blacklists?

Unbound does not seem to be aware of any public exploited recent vulnerability. Their last entry is from 2020 May:
https://www.nlnetlabs.nl/projects/unbound/security-advisories/

December 01, 2020, 07:05:20 PM #8 Last Edit: December 01, 2020, 07:07:38 PM by schnipp
Quote from: Ricardo on December 01, 2020, 06:26:30 PM
Unbound does not seem to be aware of any public exploited recent vulnerability. Their last entry is from 2020 May:
https://www.nlnetlabs.nl/projects/unbound/security-advisories/

I know this report. But, the entries are quite old and do not affect the unbound version 1.12.0 shipped with opnsense 20.7.5. To be more precisely, I couldn't find any vulnearability report regarding the latest unbound version in opnsense 20.7.5  :)
OPNsense 24.7.11_2-amd64

Good day,

Opnsense is used in our production webserver network to provide the following security implementations:
- DNS over HTTPS by both Unbound DNS for uncrypted traffic and DNS Crypt for encrypted traffic
- integrated C-ICAP and CLAMav implementation
- DNS server, recursion and caching thru Unbound DNS
- IDPS through suricata

the vulnerability is actually based on the error log i have submitted here in the forum which describes the nature of the over flow error leading to the malfunction by Unbound DNS.

the incident happened after upgrade to 20.7.5 

we confirm that the attack is coming from the outside since there are no other workstations connected to opnsense except the monitoring pc that i use and the production webservers, and the webserver infrastructure is isolated from the rest of the productivity network infra that we are currently using.

what we did is to revert the opnsense build to 20.1.9 and all services including Unbound DNS and DNS Crypt returned to expected operation.


 

December 02, 2020, 02:08:05 AM #10 Last Edit: December 02, 2020, 02:11:10 AM by madj42
I don't think this is a ddos vulnerability.  I think this is rather something that is coming from one of the blocklist providers as I found this was due to the same line in the dnsbl.conf file.  I had this over the weekend and I was able to resolve it by SSHing into my system and removing the offending line manually.  I haven't had time to figure out where it came from but this fixed my issue.  Its most likely due to the fact that unbound can't parse the non standard characters in the line (the /).

good day,

thanks for the clarification everyone.

will check into the unbound and dns crypt blacklists via ssh terminal

maybe the blacklist issue must be reported to unbound?

so that blacklist providers can remove the entry.

Quote from: scalaechlon on December 02, 2020, 04:27:04 AM
maybe the blacklist issue must be reported to unbound?

I think it's an issue of opnsense. Unbound has a predefined syntax for configuration files, and opnsense performs the setup of the blacklist files. In this case opnsense needs some more parsing that only FQDNs are added and incorrect blacklist entries are ignored.

Btw, I noticed that Unbound needs to be restarted manually after modifying the blacklists. There is no hint in the gui like for other services (e.g. modifying firewall rules).
OPNsense 24.7.11_2-amd64


December 02, 2020, 03:52:22 PM #14 Last Edit: December 02, 2020, 03:56:28 PM by schnipp
Quote from: mimugmail on December 02, 2020, 03:06:00 PM
Anyone have the plain config with the specific domain listed?

No, but I think it's a list which contains a bunch of FQDNs, one per line. And one line contains a full URL ('ster.co.uk/2014/10/07/adobe_digital_editions_4_caught_snooping_into_ebook_collections_of_users/').

So, a regex should do the job.

Btw, is it better to refuse blacklisted FQDNs instead of redirecting to 0.0.0.0 (IPv4)? In the former case, this will also cover IPv6 and other RR. Maybe Arch-Wiki can give some hints.
OPNsense 24.7.11_2-amd64