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?
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/
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 :)
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.
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).
Anyone have the plain config with the specific domain listed?
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 (https://wiki.archlinux.org/index.php/unbound#Domain_blacklisting) can give some hints.
There are plenty of regexp, but I need the original content.
https://github.com/opnsense/core/blob/master/src/opnsense/scripts/unbound/download_blacklists.py
Add the mentioned URL to a dummy list (e.g. Easy List) and hand it over to the configuration script. Then look, what happens :)
But the question is "how did that URL get into the list in the first place?"
Garbage in - garbage out. I won't expect unbound to gracefully skip syntactically incorrect config statements.
In my own installation e.g. the "Blocklist.site <something>" lists never worked for me and just crashed unbound. I am only using Ad*, Easy*, NoCoin, Simple*, Steven and Yoyo for that reason.
imho
it's definitely garbage on dnsbl record. something like
"0.0.0.0 adelogs.adobe.com ister.co.uk/2014/10/07/adobe_digital_editions_4_caught_snooping_into_ebook_collections_of_users/ #See http://www.theregister.co.uk/2014/10/07/adobe_digital_editions_4_caught_snooping_into_ebook_collections_of_users/"
but perhaps it makes sense to make it with temporary dnsbl.conf file? check it with unbound-checkconf (it doesn't check FQDN syntax, but at least it will catch the label length overflow error) and copy to dnsbl.conf?
Quote from: pmhausen on December 02, 2020, 04:31:13 PM
But the question is "how did that URL get into the list in the first place?"
In my eyes this doesn't matter because the lists' intended use cases are manifold. It could be a copy and paste error made by humans
Quote from: Fright on December 02, 2020, 06:27:39 PM
imho
it's definitely garbage on dnsbl record. something like
"0.0.0.0 adelogs.adobe.com ister.co.uk/2014/10/07/adobe_digital_editions_4_caught_snooping_into_ebook_collections_of_users/ #See http://www.theregister.co.uk/2014/10/07/adobe_digital_editions_4_caught_snooping_into_ebook_collections_of_users/"
but perhaps it makes sense to make it with temporary dnsbl.conf file? check it with unbound-checkconf (it doesn't check FQDN syntax, but at least it will catch the label length overflow error) and copy to dnsbl.conf?
Do you know the list which includes it?
Unfortunately these blocklists definitely may contain garbage data.
Additionaly they use different formats, which may be the reason why "NoCoin" works and "Blocklist.site <something>" doesn't.
- NoCoin: https://justdomains.github.io/blocklists/lists/nocoin-justdomains.txt
uses simple domains
- Blocklist.site: eg. https://blocklistproject.github.io/Lists/malware.txt
uses 0.0.0.0 + domain
- Adaway: https://adaway.org/hosts.txt
uses 127.0.0.1 + domain, this list also contains entries for localhost which should never find it's way into generated dnsbl.conf
As far as i can see filtering of blocklist entries got lost when refactoring download script which happened with these commits:
https://github.com/opnsense/core/commit/5a364f741ce12ada6351a4cdcbeb0cf628c15ab3
https://github.com/opnsense/core/commit/f16b67232c6000137f210eba8567a8abe46d9b1d
I have chosen EVERY blocklist site, but no match on this entry
@mimugmail
QuoteDo you know the list which includes it?
I wish I knew )
I also want to test regex for whitelist )
and wondering why default_pattern_2 not working for this
(although there is a feeling that default_pattern_2 not entirely correct for fqdn syntax check)
but nevertheless, i think a "broken" fqdn is possible that satisfies the "right" regexp, but overflows the label length imho.
so unbound-checkconf would not be useless
test bad dnsbl:
--no more link here--
should import just one string.
now imports everything
seems to work (does not import broken records) with this regex in Blacklist-whitelist domain
^(?![a-zA-Z0-9._-]+$)
imho may work as a temporary workaround
expressions like:
https://www.regextester.com/103452
https://regexr.com/3g5j0
(inverted)
filter out even more garbage records. but cannot be added via GUI
some test results
added
# exclude substandard and garbage entries
default_pattern_4=^(?!(?=^.{4,253}$)(^((?!-)[a-zA-Z0-9-_]{0,62}[a-zA-Z0-9]\.)+[a-zA-Z0-9-]{2,63}[\.]?$))
to blacklist template to filter broken and substandard entries
check on "Blocklist.site Malware" dnsbl: 1108 of 456375 entries filtered (IPs and substandard entries).
filtered entries attached
Quote from: Fright on December 03, 2020, 07:16:39 AM
filtered entries attached
The garbage list looks fine but contains some valid entries (e.g.
securelogin.paypal.it.webapps.mpp.home.autenticazione.cfrsfp8hcpkwdzsetpo8vir0wi1t64yyfq5knbn4ckw231kifi4nz3a9st5m.jafinafara.f).
have you tried to resolve\use this fqdns?
afaik tld min length is 2
i think its parsing error on dnsbl side.
full fqdn was:
https://vulners.com/rst/RST:E77B01C1-CBC6-3AC1-91C0-2825F87F434C
Quote from: Fright on December 04, 2020, 05:12:28 PM
afaik tld min length is 2
That's not correct. FQDNs consist of one or more labels, where each label consists of at least one letter or digit. It's a decision of IANA that nowadays no one character TLDs are existing. But the tech specs still allow them.
A detailed description and restrictions can be found in rfc1035, rfc1123, rfc1912.
@schnipp
Thank you for the clarification! didn't know that.
nevertheless, from a practical point of view, I think the limitation of min 2 characters is logical and allows to identify garbage records
QuoteIt's a decision of IANA that nowadays no one character TLDs are existing. But the tech specs still allow them.
tested some file changes.
so it is quite possible to make the field to accept full regexps (with commas and quantifiers), and the plugin will process them correctly. so user will be able to independently choose the restrictions (use the length of the TLD he likes))
but a decent number of files changed (plugin and core). I don't know how @franco and @AdSchellevis will look at it
Quote from: Fright on December 04, 2020, 07:35:22 PM
nevertheless, from a practical point of view, I think the limitation of min 2 characters is logical and allows to identify garbage records
Sorry, I don't understand the logic to enforce TLDs with a minimum of two characters. The logic is in the well-defined specifications and not in any subjective perception. So, I don't reccomend taking this step because it will introduce a bug in verification of syntactical correct FQDNs.
disagree. the logic is not in creating a generic expression for checking a string for compliance with RFCs, but in trying to find erroneous or non-working records. and while domains of this length are practically not used (https://www.icann.org/resources/pages/tlds-2012-02-25-en), we can use an expression that allows to define garbage and not take up resources for a record that has no practical use.
Quote from: Fright on December 05, 2020, 01:13:13 PM
disagree. the logic is not in creating a generic expression for checking a string for compliance with RFCs, but in trying to find erroneous or non-working records.
It is not my intention to change your philosophy in software development. But, I have seen a lot of software in the past which showed bugs or incompatibilities after a period of time due to developers did not care about standards or just followed trial and error principles.
Just my 2 cents.
too general statement about devs and principles
the proposed solution assumes the ability for the user to independently choose a regular expression and follow those standards or policies that he sees fit.
a discussion of how RFC standards and ICAAN policies relate, and how big the news would be if ICAAN approves a policy for issuing a single character TLDs, I think, is not suitable for this topic.
and yes, i am not a developer )
At first your next step should be to disable one of the two and compare the results again to identify the problem
ข่าวกีฬาออนไลน์ (https://supersportskick.com/)