*shakes cane from porch* If I had my 'druthers, there would be zero new TLDs except for country-codes which indicate the a top-level legal jurisdiction over who gets to decide the rest of what happens under 'em.
'Course, that could still backfire this way if someone establishes the Republic of Boxsylvania and won't accept "bx". (Also not great if we enter into an era of unprecedented national mergers, splits, and renames.)
Another reason to point your Fritzbox to a Pihole/Unbounded combo device.
FWIW is it not easy for Fritz to remotely change the default DNS of their devices, similar to what Virgin/Sky/Vodafone modems have been doing for the past decade?
Fritz used to be open source, but they're not since also around a decade, so I would think it would be easy to for them to have a backdoor to all their modems like every other company does.
Imo if DNS requests resolve to an unknown entity and you cannot change that behavior, your DNS resolution has effectively been hijacked, even if no harm is being done yet.
I am just not interested in a router that isn't running open source firmware ever again. Not only do they have all the features you might need but the updates keep coming alongside all the nice security patches. I wish more WiFi devices for access points got their code into the kernel quicker so the support was more extensive.
Fritzbox was one of the first open source modem/router combo boxes though. They closed the source a few years back, but in terms of openness there really is nothing else in the modem/router combo space that is actually open source.
Most people who want a router with open source firmware get one that's compatible with OpenWrt and use that, is there a reason you don't consider that to be using open source firmware?
Helpful. It's still a champion of customizability and supports most major network modes, meaning you don't need to chuck your old wifi devices away. I still have most of my hardware from a decade ago running, and the WRT54GL serves them all quite well as a repeater.
This particular hijack has little to do with being open/closed source (Fritz!Box was open source for many years though). They have been around forever, I don't think custom TLDs such as .box were a thing when they chose fritz.box as the default name.
It has everything to do with being open/closed source. If it were open, you could trivially fix this behavior. Instead, and I quote:
"the DHCP server on these modems hands out leases with the DNS suffix fritz.box, which means that domains in DNS requests are appended with the suffix. Unfortunately, this setting cannot be modified...
...The only proper way to resolve this matter in my opinion is to disable the DNS suffix by default. So far there is no indication that AVM is planning to enable this option in the near future."
Well yeah, quick mitigation is easier with open source. But the cause is still entirely on the gTLD mechanism itself. The ability to register gTLDs such as .zip is ridiculous and opens up this sort of phishing and hijacking in absolutely unforeseen places.
I miss guest WiFi from FOSS solutions. I can't even find a guide quickly for VyOS, and this is the one for OpenWRT: https://openwrt.org/docs/guide-user/network/wifi/guestwifi/g.... I fear that if I go down in this rabbithole, it's going to be like my homeserver, but on steroids. The $40 Tenda I use have it out of the box though, and if they stop updating it some years later, I just might buy another $40 something.
This is a good reason to use domain names with a trailing dot, right? Such as https://news.ycombinator.com./ to specify a FQDN, instead of https://news.ycombinator.com/ which is not fully qualified. The trailing dot keeps the DNS resolver from trying system domain suffixes.
In this case, that won't help, because `.box` is already a TLD and `fritz.box` has been registered by someone. Compare these two, the first is from my laptop connected to a Fritz!Box, the 2nd. one is from a server that's not connected to any sort of Fritz!Box:
Expected result, resolved by the box itself:
$ host fritz.box.
fritz.box has address 192.168.178.1
fritz.box has IPv6 address fd00::e72:74ff:fece:6656
fritz.box has IPv6 address 2a02:908:616:a8c0:e72:74ff:fece:6656
Result if for some reason, DNS resolution fails on the box (e.g. you're not connected to your own network, someone disabled the resolver on the box, someone configured a non-box DNS on your machine):
$ host fritz.box.
fritz.box has address 45.76.93.104
fritz.box has IPv6 address 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828
Your query results make sense, since the Fritz!Box is authoritative for the (local) .box tld. Try again with google.com and google.com. If you're using Windows, it should append .fritz.box to the former, which is the issue here.
But even "works" means that the page makes lots of requests to other subdomains etc which do not have the trailing dot, so are still vulnerable for DNS hijack if you have search domains set on your system. So while using domains with a trailing dot is a strongly good idea for calling APIs, etc. it is not a practical solution for the end user with a web browser.
Hmm. My parents have one of these. Any advice on how to fix it? "Stop using it" obviously isn't an option.
- Does configuring a custom DNS server (like Cloudflare one) on your local computers solve it?
- On the reddit linked at the bottom of the article, someone mentions you can easily use this tool https://www.mengelke.de/Projekte/FritzBox-JSTool to edit the configuration file and change the domain. If that's true, why is the article claiming it's impossible to change?
> Does configuring a custom DNS server (like Cloudflare one) on your local computers solve it?
No. If anything, that'd make it worse. The issue reported in TFA is that Fritz!Boxes by default resolve the domain `fritz.box` to themselves for their admin interface, even if that domain has been registered on the public internet by someone else. If you configure cloudflare, you'll prevent that, which will _always_ get you the potentially attacker controlled DNS results.
Not exactly, for some ISP's, internet only works with Fitzbox. For other modems, you need to go through months worth of to and fro with ISP to even get them working
FritzBoxes are used as voip server/bpx, printer server, nas, and home automation. And probably more. (German) telcos provide specific FritzBox configuation instructions (select correct sub-branch of provider and contract kind), adding the quest to get real connection data to the attempt to migrate to anything standardized.
Switching to something else is not as easy as buying a new modem for most normal people.
There is a class of internet users that doesn't use a search engine, and instead types things like "usedcarsdetroit.com" in the URL bar until they find something they want.
And there is the class that starts with a single word search like "cars", which can't go straight to Google. It instead has to see if "cars.fritz.box" exists, because perhaps there's a server called "cars" on your network.
And god forbid that your parent types "bankofmerica.com" instead of using a bookmark or their smart phone app.
If your upstream recursive resolver does QNAME minimization, then the only query that will leak beyond them is for "com.fritz.box", and because that's a NXDOMAIN, no further query for "google.com.fritz.box" is made.
If your upstream recursive resolver doesn't do QNAME minimization, then yes.
that’s no saving grace. the fritz resolver would return a result for com.fritz.box so that it can see the full (or next successive) part of the query. qname minimization is useful to defend against on path interception, or data collecting resolvers, not against actively hostile resolvers
Completely agree that it creates an unacceptable risk if the fritz.box owner is malicious. I'm just pointing out that currently, com.fritz.box doesn't appear to resolve.
Edit: actually, I'm wrong, "NS? com.fritz.box" returns a NOERROR + fritz.box SOA instead of a NXDOMAIN, which causes QNAME minimization to make the full query, which returns an A. QNAME minimization indeed doesn't actually help.
no, not every request. only those that don’t exceed `ndots` number of dots, typically 1 for unix like OSes. so google.com will not have fritz.box appended
This is not true for Windows unfortunately. Even a lookup for google.com will have fritz.box appended. I added a screenshot to the article for clarity.
Just checked, systemd-resolved doesn't even support that behavior anymore[1], so any multi-label FQDN will get resolved without appending the search domain.
So that's still a mess, but no mess of "rip apart the entire home network right now".
There are domains that will never be sold, but none of them are very sexy. RFC2606+RFC6761 list .example, .invalid, .localhost, and .test, but none of those are practical and some come with certain behavioural expectations. There's .home.arpa as well (RFC8375), which may be the most technically correct TLD to use for these domains, but also is one of the least marketable ones.
Then there are the IDN test TLDs (إختبار, آزمایشی, 测试, 測試, испытание, परीक्षा, δοκιμή, 테스트, טעסט, テスト, பரிட்சை, let's hope my browser+HN did the RTL mixing right) that also probably won't resolve, but most users probably won't be able to enter any of those websites.
AVM could've offered mDNS (if they don't already) and just use .local.
Trademark Claims Period: 13 September 2023 to 17 January 2024
To be fair, .box domains didn't have that much noise attached to them and 4 months is a relatively short period, but if this possible vulnerability had known then it's a little more negligent.
Best case scenario for them seem to be that they pay an undisclosed amount to a "random" that got lucky and bought that domain.
I find it interesting how a decision that may have looked totally innoxious something like 15 years before, was not future proof enough, I for one back then would not have imagined that ICANN would start registering every single TLD under the sun.
Does this not just break all DNS-resolved internet traffic for these devices at this point? Seems like the resolvers for fritz.box. are resolving *.fritz.box. to 45.76.93.104. I would assume the affected (Windows?) clients aren't working at all when they get this kind of response for something like google.com.fritz.box.
I guess if the resolution fails Windows will fallback to a resolution without the DNS suffix, but I'm not entirely sure how it works, and what other operating systems do.
Can anyone explain the design decisions behind this product? Or can the design process be summarized as "let's light these matches and see what happens"?
My Fritz Box does not reply in that way. How come you indicate that _all_ Fritz Box Modems have been hacked and how do I know if I am affected? Apparently I'm not.
It's how the mechanism of DNS suffices works. Especially on Windows, because Windows rewrites all DNS requests with the suffix (even simple requests like google.com). To me it's surprising that somehow not everyone is affected. I only learned that in the comments here.
Here in germany you often get a Fritz Box from your internet provider (preconfigured with access data). So for 99% of users, switching to another router is not an option because thats simply the device that came with their internet access. But apart from this issue those are really nice and capable devices.
You can use your own router in Germany, this is enforced by the regulation agency BNetzA. Your ISP must provide you with sufficient information to set it up.
I think it's fair to say the vast majority of users won't be able to pull that off. I doubt even half of them know what a router is, let alone that there are differences between models.
For those who know they can use their own modems, sufficient information must be available, but only a sliver of the people with AVM modems will have that kind of knowledge.
There is the class that fails at reading and adhering to IKEA instructions, yeah.
But this is something that ask the non-obvious things will get explained to you if you walk into a MediaMarkt to where modern routers are and queue in line for the area's sales person to get to you and tell you what to buy, and how to get your hands on the relevant access credentials/how to get the new one to connect to the ISP.
You're forgetting that most installs of non-ISP-provided moderns for residential Internet are set up by the tech person of the household who quite possibly never heard of what a NAS is and why they may want one.
Often the only paper manual thing in the box is literally the quick start guide that a motivated person who has what could be called "common sense" on treatment of/interaction with computing equipment. You know, the person who knows to check the plugs because they don't consider themselves above it but do know that it's one of if not the first thing they are asked if they can support.
Since 2016, ISPs in Germany are required by law to give you the access data to use third-party modems / routers. Apart from that, I like Fritzboxes, too - I don't use a PC as a router anymore since I first got one.
Sure, but legally allowed and capable and motivated to do so are very different things. Most people I know don’t even change the preset wifi password of their router.
This is stupid clickbait title, and the article isn't even very precise. Yes, that whole fritz.box situation is known and bad. But the problem discussed here doesn't nearly apply to every situation. Specifically, the box's builtin resolver (which is still used by default by a lot of things) knows not to forward fritz.box requests to the outside. That is, `dig google.com.fritz.box` and everything else say NXDOMAIN when you're using the builtin DNS.
Ah, it was looking like that to me, thanks for confirming. Like, if I force dig to use some public DNS, I get the newly registered IPs but if I use my fritzbox as the DNS server, it gives me itself / NXDomains, except for hostnames configured on the local fritzbox.
That on top of the fact that my linuxes won't use the search domain unless explicitly asked for with a single-label DNS makes this a lot less scary.
Yeah but so many things bypass internal resolvers lately. VPNs, “private relay,” individual apps. DNS over HTTP. Local control over DNS is steadily being chipped away. The result is some apps will go out to public or vendor-controlled DNS in ways typical admin tools like ping and dig might not reveal
Skipping over the bad idea that this fritz.box-domain is for a bit, this seems like a pretty major failure on the part of ICANN to prevent name collisions. IIRC they had a whole bunch of plans and policies to prevent name collisions 10 years ago, but somehow a popular brand of modems failed to come up?
I have a Pi-Hole w/ unbound upstream, and the pi-hole is set to conditionally forward requests to *.fritz.box to 192.168.178.1, but should not forward it outside (i.e. to unbound). Quote:
"You can also specify a local domain name (like fritz.box) to ensure queries to devices ending in your local domain name will not leave your network, however, this is optional."
This is in the Conditional Forwarding section to the Pi-Hole, so I assume it's OK.
As far as I can see, Heise assumes that just because there's a link to the URS, the domain is no longer under someone else's control. I can't find any confirmation that the URS has actually been invoked.
If I were someone trying to spy on specific users, or collecting data maliciously, I would host this HTML on my own server to confuse journalists.
Currently, every subdomain (up to any level, as far as I can tell) resolves to an IPv4 and an IPv6 address. I doubt ICANN would do this for seized domains.
Time to make the suffix configurable and default it to something standard like home.arpa (or .internal once it’s official) or a sub-domain thereof, AVM.
To me the root problem still seems to be that we use FQDNs virtually nowhere even though that is the intention. Linux and macOS not applying the suffix for multiple labels is just an implementation detail. Maybe we should standardise the behaviour and maybe it’s better to turn it around: consider everything an FQDN and provide an escape mechanism (e.g. an xx-- prefix or an escape TLD)?
I flagged this post because it's just spreading FUD (in the traditional meaning) at this point. The fritz.box domain had been registered in January, but someone (likely AVM) quickly contested the registration and it was disconnected in March. It is currently in the settlement and resale phase, so very likely AVM, the makers of Fritz! Box, will just buy the domain and ensure it responds NXDOMAIN to any query or something. While I still believe that using a non-reserved domain like 'fritz.box' as their internal domain and suffix is just dumb, they are aware of the issue and working on a resolution that appears sensible.
The fact is that currently DNS requests are forwarded to an unknown entity. The matter is not resolved yet and there is no guarantuee it will be resolved. Imo there's no FUD here. I will happily correct any factual errors ofcourse.
135 comments
[ 5.8 ms ] story [ 201 ms ] thread'Course, that could still backfire this way if someone establishes the Republic of Boxsylvania and won't accept "bx". (Also not great if we enter into an era of unprecedented national mergers, splits, and renames.)
FWIW is it not easy for Fritz to remotely change the default DNS of their devices, similar to what Virgin/Sky/Vodafone modems have been doing for the past decade?
Fritz used to be open source, but they're not since also around a decade, so I would think it would be easy to for them to have a backdoor to all their modems like every other company does.
(PS. I am the author.)
I love my wrt54gl as much as the next guy, but I hate having two devices to connect to the internet instead of just one.
For OpenBSD on Orange France FTTH: https://lafibre.info/remplacer-livebox/remplacer-sa-livebox-... or https://try.popho.be/securing-home2.html
The last time I searched for open hardware, even the implementations running Linux on a desktop PC with a caux adapter were not DOCSIS 3.X compatible.
The companies that multiplex the signal down the cables keep updating their standards, both a blessing (for speed) and a curse for maintained code
VDSL2 Modem with Kernel support. With OpenWRT and mainline Kernel its able to push roughly 100Mbit/s over WAN.
I wonder if I can find a device not fully upgraded
"the DHCP server on these modems hands out leases with the DNS suffix fritz.box, which means that domains in DNS requests are appended with the suffix. Unfortunately, this setting cannot be modified...
...The only proper way to resolve this matter in my opinion is to disable the DNS suffix by default. So far there is no indication that AVM is planning to enable this option in the near future."
Expected result, resolved by the box itself:
Result if for some reason, DNS resolution fails on the box (e.g. you're not connected to your own network, someone disabled the resolver on the box, someone configured a non-box DNS on your machine):https://duckduckgo.com./ - blank page
https://www.google.com./ - 301 redirect to non-trailing-dot
https://www.amazon.com./ - works
But even "works" means that the page makes lots of requests to other subdomains etc which do not have the trailing dot, so are still vulnerable for DNS hijack if you have search domains set on your system. So while using domains with a trailing dot is a strongly good idea for calling APIs, etc. it is not a practical solution for the end user with a web browser.
- Does configuring a custom DNS server (like Cloudflare one) on your local computers solve it?
- On the reddit linked at the bottom of the article, someone mentions you can easily use this tool https://www.mengelke.de/Projekte/FritzBox-JSTool to edit the configuration file and change the domain. If that's true, why is the article claiming it's impossible to change?
No. If anything, that'd make it worse. The issue reported in TFA is that Fritz!Boxes by default resolve the domain `fritz.box` to themselves for their admin interface, even if that domain has been registered on the public internet by someone else. If you configure cloudflare, you'll prevent that, which will _always_ get you the potentially attacker controlled DNS results.
If you have a local machine called "myshare" and you mistype "myhsare", it may resolve to the attacker's machine.
(PS. I am the author. The article is my understanding of the situation but if I'm wrong on some parts please correct me.)
we're only talking about the cost of a commodity modem, so buy a new modem, disconnect old is a potential solution
Switching to something else is not as easy as buying a new modem for most normal people.
Setup a local DHCP server, and don't set the fritz.box search domain.
Ensure that DNS-over-HTTP (DoH) is enabled where it can be.
Set upstream DNS servers that block malware, such as 1.1.1.2 or NextDNS
Delete "fritz.box" from the domain search list in DNS settings.
Educate your parents to be cautious about directly typing domain names or searching from the OmniBox.
https://nextdns.io/
https://blog.cloudflare.com/introducing-1-1-1-1-for-families...
There is a class of internet users that doesn't use a search engine, and instead types things like "usedcarsdetroit.com" in the URL bar until they find something they want.
And there is the class that starts with a single word search like "cars", which can't go straight to Google. It instead has to see if "cars.fritz.box" exists, because perhaps there's a server called "cars" on your network.
And god forbid that your parent types "bankofmerica.com" instead of using a bookmark or their smart phone app.
First it was not clicking links. Now it's not typing addresses?
Jesus Bloody Christ my dude, maybe it really was a mistake to make sand think.
I query google.com and get google.com.fritz.box every fucking time? Shit.
If your upstream recursive resolver doesn't do QNAME minimization, then yes.
Edit: I stand corrected, see downthread
Edit: actually, I'm wrong, "NS? com.fritz.box" returns a NOERROR + fritz.box SOA instead of a NXDOMAIN, which causes QNAME minimization to make the full query, which returns an A. QNAME minimization indeed doesn't actually help.
com.fritz.box. 3514 IN AAAA 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828
com.fritz.box. 3600 IN A 45.76.93.104
Server: fritz.box Address: fd00::[etc]
Non-authoritative answer: Name: google.com Addresses: 2a00:1450:4001:80b::200e 172.217.19.78
So that's still a mess, but no mess of "rip apart the entire home network right now".
1: https://www.freedesktop.org/software/systemd/man/latest/syst...
If there's a list of falsehoods programmers believe(d) about DNS, "that TLD will never ever resolve, not ever" should be somewhere near the top.
There are domains that will never be sold, but none of them are very sexy. RFC2606+RFC6761 list .example, .invalid, .localhost, and .test, but none of those are practical and some come with certain behavioural expectations. There's .home.arpa as well (RFC8375), which may be the most technically correct TLD to use for these domains, but also is one of the least marketable ones.
Then there are the IDN test TLDs (إختبار, آزمایشی, 测试, 測試, испытание, परीक्षा, δοκιμή, 테스트, טעסט, テスト, பரிட்சை, let's hope my browser+HN did the RTL mixing right) that also probably won't resolve, but most users probably won't be able to enter any of those websites.
AVM could've offered mDNS (if they don't already) and just use .local.
I am no expert in this subject
https://newgtlds.icann.org/en/program-status/sunrise-claims-...
But it seems that they had
Trademark Claims Period: 13 September 2023 to 17 January 2024
To be fair, .box domains didn't have that much noise attached to them and 4 months is a relatively short period, but if this possible vulnerability had known then it's a little more negligent.
Best case scenario for them seem to be that they pay an undisclosed amount to a "random" that got lucky and bought that domain.
I find it interesting how a decision that may have looked totally innoxious something like 15 years before, was not future proof enough, I for one back then would not have imagined that ICANN would start registering every single TLD under the sun.
Guess they didn't expect a .box-tld
For those who know they can use their own modems, sufficient information must be available, but only a sliver of the people with AVM modems will have that kind of knowledge.
But this is something that ask the non-obvious things will get explained to you if you walk into a MediaMarkt to where modern routers are and queue in line for the area's sales person to get to you and tell you what to buy, and how to get your hands on the relevant access credentials/how to get the new one to connect to the ISP. You're forgetting that most installs of non-ISP-provided moderns for residential Internet are set up by the tech person of the household who quite possibly never heard of what a NAS is and why they may want one. Often the only paper manual thing in the box is literally the quick start guide that a motivated person who has what could be called "common sense" on treatment of/interaction with computing equipment. You know, the person who knows to check the plugs because they don't consider themselves above it but do know that it's one of if not the first thing they are asked if they can support.
https://de.wikipedia.org/wiki/Routerzwang#Rechtslage_in_Deut...
That on top of the fact that my linuxes won't use the search domain unless explicitly asked for with a single-label DNS makes this a lot less scary.
PS C:\Users\Marco> nslookup google.com
Server: UnKnown
Address: 192.168.0.200
Non-authoritative answer:
Name: google.com.fritz.box
Addresses: 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828
45.76.93.104
How is this not bad?
https://x.com/AVM_DE/status/1779155999204552897
Also, this should be worth an email to abuse@namesilo.com, no?
"You can also specify a local domain name (like fritz.box) to ensure queries to devices ending in your local domain name will not leave your network, however, this is optional."
This is in the Conditional Forwarding section to the Pi-Hole, so I assume it's OK.
If I were someone trying to spy on specific users, or collecting data maliciously, I would host this HTML on my own server to confuse journalists.
Currently, every subdomain (up to any level, as far as I can tell) resolves to an IPv4 and an IPv6 address. I doubt ICANN would do this for seized domains.
To me the root problem still seems to be that we use FQDNs virtually nowhere even though that is the intention. Linux and macOS not applying the suffix for multiple labels is just an implementation detail. Maybe we should standardise the behaviour and maybe it’s better to turn it around: consider everything an FQDN and provide an escape mechanism (e.g. an xx-- prefix or an escape TLD)?
The fact is that currently DNS requests are forwarded to an unknown entity. The matter is not resolved yet and there is no guarantuee it will be resolved. Imo there's no FUD here. I will happily correct any factual errors ofcourse.