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.
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.
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.
Hm, curious behavior on my Windows box: nslookup is indeed always applying all the search suffixes whenever I do a lookup, but if I just use the normal resolution process (for example running `ping www.google.com` etc), then the value of `HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\AppendToMultiLabelName` is respected, which defaults to 0 since Vista.
So this shouldn't really be an issue for most people, but highlights once again that you should never ever use a domain in your infrastructure that you do not own or at the very least use one of the suffixes from https://www.rfc-editor.org/rfc/rfc6762#appendix-G
That matches my observation on Windows 11. Looking at wireshark while doing the resolution I see the following: Normal queries never use the the suffix. nslookup does, which the resolver answers with NXDOMAIN
Fritz box allows you to capture traffic towards the ISP too and there I never see such a suffix query in either case. So I assume the fritz resolver directly responds to those.
That does not really match the behavior described in the OP but I would be very surprised if the behavior described there wouldn't have lead to a big outcry much earlier.
Can we be absolutely sure the "normal resolution mode" is always used? I'm happy to accept that impact might be not as severe as stated, but to me it's very scary that a simple nslookup for google.com returns the IP address of fritz.box.
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.
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.
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.
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.
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
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".
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.
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.
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?
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.
> 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.
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.
Too bad, I tried to buy that domain some years ago as soon as I got my first fritzbox. Back then, I did not find a registrar and did not invest much time in finding one.
I am running my own DNS server and configured the fritz.box zone.
I have to admit that I got stung when google released .dev as HSTS only, although that was only for local testing.
I'm surprised that this company didn't realise that this was problematic before this happened. Also, if the response in the article is actually their only one so far, that's a "I'll never touch this company again" response. If they deal with it properly then it's just a bug.
It doesn't matter, it's never been a good idea to use a domain that isn't your own or a special-use domain. At some point this might have been a theoretical worry, but it was 13 years ago that ICANN started creating new TLDs by the dozen. There's very little excuse for not correcting this mistake for new hardware at some point in the past 13 years.
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)?
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.
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.
I've noticed my Synology NAS doing lots of DNS lookups for [synology service].synology.com.fritz.box.
Because I had *.fritz.box DNS blocked on my Cloudflare Zero Trust Gateway, these were returning NXDOMAIN, causing the NAS to fail during some operations (checking for software and packages updates, backups).
I've disabled the option "Apply the domain name provided by DHCP server" (Network | DNS | Advanced) and the NAS stopped these.
Now, this is a worry because that option is checked by default so how many Synology NAS could be trying to connect to these sub-domains? What if the block is removed and the new owner can actually create some of these?
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.
*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.)
I own a domain along the lines of 'invoice.zip', I thought it’d be fun. But so far, it’s just been useless and expensive.
Should I keep it? What are uses cases for such a 'misguided' domain? I thought about putting a blog on it but fear it’d get flagged as malicious left and right. It’d look odd to say the least.
If I don’t renew, scammers might get their hands on the domain.
And I don’t buy into .zip being made part of automatic URL detection in tools, for all the illegitimate reasons it’ll be used for. Vendors of email clients, messengers and chat applications tend to stick to a core of well-known TLDs.
I can't reproduce the "worst case" i.e. that if I ping "google.com" it gets first sent to "google.com.fritz.box". I'm on windows 10 and have a FRITZ!Box 7590.
If I ping "google.com" It just queries google.com
If I ping a domain I have never visited it just does a query for that domain.
It only appends .fritz.box if I, e.g. only ping "google".
So maybe they fixed it? I also changed quite a lot of settings throughout the years.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient\AppendToMultiLabelName
[default value - 0 (Do not Append Suffix)]
which resolver built into Windows (DNS Client) respects.
nslookup contains its own DNS resolver and does not rely on the resolver built into the operating system. The DNS (multi-label) query packets sent by the nslookup tool will append the domains listed in the suffix search order (or primary DNS suffix if the list is empty) irrespective of that registry key.
In summary, don't use nslookup to try to get insight into what actually happens when apps/services try to resolve names. ping is probably a better bet, at least it uses Windows resolver which honours the above registry key.
It seems the domain fritz.box has been suspended. March 5 was the first time this message got captured on archive.org[1]:
The Domain Name you have entered is not available. It has been taken down as a result of dispute resolution proceedings pursuant to the Uniform Rapid Suspension System (URS).
The fritz.box name servers also point to URS[2] name servers:
Name Server: ursns1.viagenie.ca
Name Server: ursns2.viagenie.ca
I cannot confirm this behavior. With a router running FRITZ!OS:7.57 configured to use Google's DNS (in the router only) I get the following on Windows 10
Update: the connection does have the DNS suffix, so according to the superuser answer linked in OP (which is the first result when looking up what a DNS suffix is), it should get appended to lookups on windows, but it looks like it isn't in my case.
> ipconfig
[...]
Connection-specific DNS Suffix . : fritz.box
I noticed a lot of comments explaining the same thing, but also some confirming my observations. So far it appears the issue is mostly present if you have configured a separate DNS server in the DHCP settings, e.g. DNS is resolved somewhere outside the Fritz!Box. I will investigate further and update the article.
Is there a way to get a monthly/weekly/whatever announcement of just the new gTLDs coming out? I have never been able to find a method other than manually checking on ICANN.
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.
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?
Having never played with one; if the firmware supports bridge mode that will treat the box as basically just a hop. Of course you'd have to have your own network gear behind it.
Other option, run your own DNS + DHCP stack, a pihole is pretty turn-key if you have a straight forward network.
My home router is an old PC running Linux with some extra 10G ixgbe cards. If you know how to configure it, I'm convinced there isn't a better way: the only real downside is the power use, and it's not that bad.
Given the way mine (not FritzBox) chokes due to NAT being a little stupid when burdened with enough outbound IPv4 dialing, I'd like a PCIe DOCSIS 3.1 (and enough EuroDOCSIS 3.0 to get through bootstrapping, as the ISP doesn't yet support pure 3.1 moderns) modem...
I may settle for a 2.5GBASE-T "classic" modern, though, despite the lost control over the TX queue. It's sadly not possible to just presume a TX speed and forgo backpressure from DOCSIS to the packet scheduler that has the knobs to never turn Internet usage off again just to stop other more sensitive Internet usage from lagging.
Even if you had a modem card, there are too many more potential queueing points upstream of it: what you're proposing here would never make any measurable difference in real life. The congestion that makes cable uplinks suck isn't happening at your modem.
If you want to run BitTorrent and game at the same time, the router can e.g. limit the BitTorrent flows to something below the minimum guaranteed TX rate, so you know there's no queueing on the modem.
Last time I had cable was on Time Warner in the US. It was interesting because they didn't do the token bucket style ratelimiting I've seen from every ISP I've had since: they'd play games with TCP to try and slow down big flows instead. It was weird.
So I wrote a little program that transferred files by sending the data over UDP at a constant rate disregarding loss, then reconciling lost bits later over TCP. That allowed me to get almost double the upload bandwidth I was theoretically paying for at the time!
But on Verizon FIOS, it didn't work at all, because they really limit bandwidth at the packet level instead of trying to trick TCP into slowing down.
I don't care about the L2 interface. I imagine I could twist my ISPs arm and spend a bunch of money to end up with the fiber line directly connected to a card in my Linux box... but why? The ISP's upstream equipment is just as vulnerable as a modem, and there's a lot more of it. That's not the point for me.
When I had DSL (and later DOCSIS), I just bought my own modems that weren't routers, and used ethernet to connect the Linux router (a raspberry pi 3 originally, yes the DSL was so slow it wasn't a bottleneck!). It was economical because Time Warner charged me something like $5/month to use their modem.
There's a lot of reasons I like having a Linux router, a short list:
* I have 10G internet from Sonic, in 2020 building a small Linux machine with ixgbe cards was cheaper than any commercially available 10G router with as many ports as I needed (4+). I get line rate through it, no problem.
* It runs an open source NAT implementation that is actually correct (although this is less of a problem with commercial routers now than it was back in the day...). Sadly, I don't have IPv6, but the same argument would apply there.
* I can run whatever DHCP server implementation I want.
* No web GUIs: I SSH to the thing and write config files.
* If it blows up, it's just Linux, and all the config files are in git: any machine will do, I don't have to worry about some commercial product disappearing and forcing me to waste an afternoon reinventing the wheel.
* I can build and run recent vanilla kernels with all the hardening options enabled. A Linux router spends 99% of its time in the kernel.
* The machine is actually fast enough to scan 10G traffic at line rate in software when I want to do that (it's doing all the routing in software, after all).
It's really easy, I'd estimate I spend 1-2 hours a year maintaining it.
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.
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"?
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.
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.
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.
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.
