Step 2 of first time setup forces a default password change. There is no way around this step.
The defaults for the router also do not allow router access from the WAN port.
This means:
1) These routers all have secured passwords that are non-default.
2) These routers were deliberately placed on the internet by people that knew enough about them to do so.
Just because it's not how you would configure your router doesn't make it wrong. There are legit reasons to place a router on the internet, so long as it's secured properly... how else would you remotely manage a router at a different physical location, for instance.
__Lastly__ click "Next Page" on the OP search results. The estimated 7,000+ results becomes 21. Many of which are HN aggregators reporting on this thread here.
So... out of the possible millions of routers TP-Link has sold in this model line, less than 21 are on the public internet - many of which no longer load via IP address (indicating they are no longer publicly accessible), and the rest have professional CNAME's attached, indicating professional management.
> Folks - these routers are secure. There is nothing to see here, move along.
If experience is any guide, they are not.
Consumer routers have horrible track of embarrassing, easily exploitable vulnerabilities. That are not patched for a long time or ever.
And exposing your router to public like that suggests the owner knows very little about security. This typically goes in hand with other neglect. Tell me, how many home users that are not security conscious keep their routers regularly patched and will replace the router when the manufacturer stops supporting them?
Buy something well supported by OpenWRT; that typically correlates to at least OK hardware that is known to work well enough. Ideally you'd also install OpenWRT on it, or another choice of OSS rather than factory firmware.
Funny enough, I recently purchased one of the latest TP-Link Archer 5400x (AX73) routers. Ended up not needing it, so I opened it up and connected via UART.
Once you log in it appears to be running a version of OpenWRT, although they don't specify that on their website.
Is it too much to ask to have competently built hardware with competent software for a reasonable price enabled by mass production?
I mean, just don't make stupid things like open access to it from a single point of failure where a single engineer can loose their AWS key and enable attackers to access million networks?
Or build devices that overheat placed on an open shelf in home office in truly unreasonably hot Polish climate?
It depends on your experience. For me it didn't require much time at all. You might also consider it a valuable learning experience so worth making the time. I would highly recommend being on top of your own home network as you really never know when networking skills will come in handy.
I have some ops experience but that was 20 years ago. Nowadays if I need to do something like that I have to do a bunch of research and spend a lot of time on it. Which I would prefer spending, for example, with my son teaching him programming.
I can sympathize with people that don't have technical background -- these are practically defenseless.
I'm willing to invest time once to get something better working. I'm not willing to invest time on an on-going basis to keep my router secure. My normal router is a !@#$%, but the company does push out security updates.
Most of the DIY projects I've seen require me to do it manually.
Yeah, I love the older Ubiquiti stuff (Edgerouter) and the Unifi access points, but all their new routers (like the UNMS ones) seem to require cloud hook-in which I really don't want.
When the EdgeRouter-4 I have dies, I suspect I'm going to need to find a new hardware brand, this time preferably running OpenWRT. Potentially it could get to the point where I'll have to look for an ARM based server with low enough power usage and a few independent network interfaces and just run pfSense or VyOS or something...
Yeah, I’ve used Microtik gear, and I never liked their software. I hear the performance has improved a lot though (that was a big selling point of the Ubiquiti gear when I got into it with their hardware acceleration).
I expect I will eventually move to embedded server hardware (even maybe Xeon-D) on a machine running vSphere or something with a router VM and other VMs for stuff I want to run. Just have a few separate NICs and pair it with a separate managed switch (which I already have anyway).
I've had good experience as a basic home user with Fritzboxes. I can't vouch for them in terms of security or unusual and fun uses that people here may have for their home network though.
Owner of a C7 v4 here. There has not been a firmware update from TP-Link since December 2019 (note that v4 is the second-most recent HW revision). No way these are not affected by at least some CVE somewhere in their stack. Calling them secure is a leap of faith that TP-Link does not deserve.
I recently flashed openwrt exactly to be able to be on a more recent stack.
I would never dream exposing that UI to the Internet as-is. They don't even have any form of brute forcing protection. If they really needed access to the router remotely, it would be much saner to expose an SSH server with pubkey-only access or VPN, both with brute forcing protection, and allow tunnelling to the router UI only from the LAN side.
Either who set those up really has nothing to lose if they get owned, or they do not know what they are doing. In both cases, it does not qualify as being a secure setup. (Sure, they may also be honeypots - in which case your argument was incorrect anyway, as they are secure, but they are not routers)
Same model, but the interface showed build 20180316 as "up to date", and when I've tried manually downloading the 2019 build it showed "invalid type". Swapped it with DD-wrt not long ago (DD-wrt support was why I've decided on this model, but I was too lazy to do that before).
> If they really needed access to the router remotely, it would be much saner to expose an SSH server with pubkey-only access or VPN, both with brute forcing protection, and allow tunnelling to the router UI only from the LAN side.
> it would be much saner to expose an SSH server with pubkey-only access or VPN
It would be safer to leave open to the public only a secure protocol based on strong cryptographic keys instead of a password. Or you have to be signed in to a VPN to see the page.
> brute forcing protection
Try too many passwords? Try again in 1 minute. Again? 30 minutes
> allow tunnelling to the router UI only from the LAN side
I think this one means don't expose it to the internet at all. Just from your local network.
>
Exposing your router's admin page to the internet is not good security practice. These routers are protected by nothing but a password, and I couldn't see anything in the manual that enforces password length/complexity. So while the password might be non-default, it could still be incredibly insecure.
Also, to expose these routers to the internet, all it takes is a single checkbox to enable "Remote management". So your assumption that these have all been deliberately placed on the internet also doesn't hold up because I can definitely see a curious home user playing with these settings without realising the impact of this. There have been tons of similar reports in the past where home users have exposed things to the internet without realising the impact.
> The estimated 7,000+ results becomes 21. Many of which are HN aggregators reporting on this thread here.
Nope, Google is just collapsing them because they are all identical copies of the same "page", being the same login screen. Most of them look like routers, you can ask Google to "include" them all and see for yourself. https://www.google.com/search?q=%22Please+log+in+with+router...
Disagree. In my current country of living, I'm not even sure how I'd properly expose the router I use to the public internet since I sit behind the ISP's NAT-ing, and even when I lived in the US, I am not confident I could tell you how to publicly expose the modem provided by Comcast for non-local access, much less how someone without any tech experience might do this.
If this was a prevalent problem because of default settings, I'd expect far more than 7800 results; I am not willing to concede every instance is intentional, but 7800 out of the billions of routing devices in the world showing up on this search enforces my understanding that these 7800 entries are special in some way.
>I doubt there's MFA or even rate limiting.
MFA is not common at all on consumer routers, which at least quite a few on the first page result are, same with rate limiting.
Even for Enterprise grade gear, the threat isn't the user-defined password, it's the manufacturer backdoors, which we've seen many of in the last few years. Rate limiting doesn't do much if you have a fair chance that you've got a back door.
What likely __does__ help is that as far as I know, "Enable Web Access from WAN" is by default *disabled* on most consumer routers (and enterprise? that I'm not sure of), so I think that this leads credence to the devices on the Google results being exposed intentionally to some degree. (The owners' knowledge level not withstanding, this is a fairly out of the way setting, at least on my Asus router)
> I am not confident I could tell you how to publicly expose the modem provided by Comcast for non-local access
You likely couldn't. That setting is usually gated behind some sort of "technician" or "mso" account (or not present, or only accessible from the devices telnet/ssh interface). Of course, it's probably not difficult to guess Comcast's password; past experience with other companies suggests you try things like "comcast" or "C0mc4s7". (Not even joking, Suddenlink and Spectrum/TWC.)
> much less how someone without any tech experience might do this.
Easy. It's a button that their kid clicked while playing around.
> MFA is not common at all on consumer routers, which at least quite a few on the first page result are, same with rate limiting.
Are you trying to say that's a positive for exposing it on the internet...?
> but 7800 out of the billions of routing devices in the world showing
Click "Next Page" - estimated results turns into 21 results in total... of which a bunch are dead links, a bunch are HN aggregators... leaving just a small handful of actual devices on the internet.
These are not high end enterprise grade kit, folks. Expecting things like MFA, secondary VPN endpoints, etc is just absurd for the target audience of this device.
Again, just because you wouldn't configure it this way doesn't make it wrong. It's as secure as it can be, short of throwing a bunch of other kit in front of it, and then why would you be using a $100 consumer router anyway?
The only vulnerability here is the possibility of a 0-Day. Everything else is either misguided or screaming for the sake of it.
> That's not exactly uncommon in cheap consumer routers.
That's, in my opinion, the only fair criticism available here.
> No rate limiting is as good as no authentication.
Trying to even load some of the links found in Google takes 10's of seconds. That's effectively a rate limit, even if it doesn't temp-ban per IP address.
Someone would have to dump the firmware to find out, but it would be trivial for each device to generate their own salt - making a potential lack of rate limit a non-issue.
> Someone would have to dump the firmware to find out, but it would be trivial for each device to generate their own salt - making a potential lack of rate limit a non-issue.
Salting does nothing to protect against bruteforce attacks, which are what rate limiting defends against. Salting is done to protect passwords in the event the password data is stolen.
The load times are most likely primarily caused either by slow JS or high RTT/multiple requests, either of which could be trivially bypassed by an attacker. Or an attacker could just fire off 100 requests at the same time and saturate the bandwidth anyway, despite a high latency. And any high latency would likely be significantly lower if you happen to be in the same geographic area.
I'm a big fan of rate limiting (and even rate limit my static pages) but if your password is secure enough, the lack of a rate limit isn't going to help attackers.
I kind of agree with the comment that started this thread -- people that have explicitly decided to expose their consumer-grade routers directly to the Internet probably know about password managers. Even if you do guess the password and compromise the router, all you'll have is some remote office that is getting TLS errors because of your MITM, and best case control of some unpatched Windows 3.1 machine and maybe some developer's local MySQL install happily listening on port 3306 somewhere. That's not great, but it's a risk that some people are willing to take.
> maybe some developer's local MySQL install happily listening on port 3306 somewhere.
And usually with default password because not on the internet. People often forget or underestimate lateral movement and metasploit reverse shell kits.
> The only vulnerability here is the possibility of a 0-Day.
You do realize that the last security update for these routers was in 2019, right? So by zero day, you mean something more like 700 day? Yeah, no way anyone could've discovered a system takeover in the last 2 years, when up against the security prowess of... TPLink?
I think it might be a good idea to edit your original comment, you'll save some face.
> 1) These routers all have secured passwords that are non-default.
Who said secure password? Yes, they are not the default, but people are terrible at choosing password, most will choose weak password that are easy to exploit with a dictionary attack.
> 2) These routers were deliberately placed on the internet by people that knew enough about them to do so.
A people that know what it's doing would never expose a router web interface on the internet. Most people doesn't know how to configure his router, and let the ISP technician configure it, and they probably expose the router interface so they can access it remotely for maintenance, but it's not a great idea...
> There are legit reasons to place a router on the internet, so long as it's secured properly...
There aren't. Also you can choose a secure password, but these router interfaces are full of bugs, and highly exploitable. Add to this the fact that the manufacturer rarely updates the firmware of these devices...
> how else would you remotely manage a router at a different physical location, for instance.
With a VPN? By creating an SSH tunnel to one machine inside the local network? By connecting remotely (via RDP, VNC, TeamViewr, whatever) to one PC inside the local network? There are a ton of better solutions.
Also if you don't have a static public IP address, as it's in most situations nowadays, how do you access it remotely anyway? With dynamic DNS but it's not reliable. The best solution to me is using a VPN (I can connect to my home network from anywhere in the world and access all the hosts, including router and other networking equipment of course).
> These routers all have secured passwords that are non-default.
Secure passwords is just a tiny subset of non-default passwords. Chances of an average human being being able to come up with a password with enough entropy to be called as secure is pretty low.
> These routers were deliberately placed on the internet by people that knew enough about them to do so.
This means these people knows how to expose the management interface to the internet. It does not mean these people have enough knowledge on securing their devices -- based on their actions, it is more likely that the opposite is true.
So you think the chance of human beings to come up with 4 random words is pretty low?
You can't brute force millions of guesses per second through a web interface. 40 bits of entropy is already plenty for internet usage especially when the password is properly hashed with something like bcrypt.
> Secure passwords is just a tiny subset of non-default passwords
Actually the exact opposite is true. Since only low entropy and publicly known (which are mostly low entropy) passwords are insecure there are much more secure than non secure passwords.
For the sake of argument, let's say all passwords with less than 40 bits of entropy are insecure. Even if we restrict the set of possible passwords to only 10 characters of lowercase a-z we have about 47 bits of entropy. So the set of insecure passwords would only be about 1/128 or less than 1% of all allowed passwords.
> > Secure passwords is just a tiny subset of non-default passwords
> Actually the exact opposite is true. Since only low entropy and publicly known (which are mostly low entropy) passwords are insecure there are much more secure than non secure passwords.
You're confusing "passwords that are in use" with the set "passwords that are possible". We have data via password dumps that suggests of the "passwords that are in use" the set that qualifies as "secure" is indeed a tiny subset of passwords.
Well, real people won't choose any random 10 characters as a CSPRNG would do. Even when picking words from a dictionary, instead of four words, most people would probably just use one (or maybe two). For those are more inclined, they might mess with the capitalisation and sprinkle some numbers to make it "more secure" and adhere to certain password policies. This does not really contribute to the odds as you might expect.
Anyway, the point is, people are terrible at generating (and remembering) secure passwords. By ruling out the default password just means it is not going to be the most insecure one, but the chances of the custom password being secure is still pretty low.
I think most of this comes down to bad education on how to choose a secure password and not an innate inability. And for the most part we software engineers are at fault for advocating and enforcing mostly useless policies for more than two decates.
I would love for more websites to implement something like the zxcvbn password strength meter [1], but unfortunately I keep seeing new services or recently refreshed ones using outdated and hurtful policies like requiring numbers and special characters.
>So you think the chance of human beings to come up with 4 random words is pretty low?
I've always wondered how effective the random words thing is. sure, there are like 100k english words in current use according to google, but it seems like a list of the most common few hundred of those words would crack a lot of passwords.
If you assume the password to be only based on the 200 most common words you already have 30.5 bits of entropy to brute force or 1.6 billion guesses and you're assuming your attacker knows you're using this password strategy. The Wikipedia entry on Basic English [1] suggests there are about 850 core words for daily life and I could immediately think of simple words like well-known animals you would see in the zoo that are not included. So how many of these "4 words that you could draw as a picture"-passwords actually fall into even the most common 850 words?
30 bits of entropy isn't particularly secure against locally cracking a password hashed with sha256 or a similar non password hash. However at 1000 guesses per second it would already take 28 days to brute-force and 1000 guesses per second is pretty fast against any password stored with a properly configured password hash like bcrypt.
I personally auto-generate readable passwords for most websites at ~70 entropy pure brute-force and ~50 entropy if my algorithm and set of inputs would be exposed.
You also need to be aware that in this case, the attacker is/would not targeting any specific device. For brute forcing, all it takes is a dictionary of most common passwords and a list of devices that are exposed. Attackers won't spend too much time on any single device as there are so many options out there.
OP. I'm posting this because I discovered a box at the hostel I'm at on Google after fat fingering the IP by mistake. (It's disconnected already.) The password was easily guessable.
Aside from the anecdata, a counter argument is that the router manufacturer has taken no steps to obscure the routers from search engines. Sure someone could simply IP scan, but you have to admit this is a little absurd.
not every tp-link model (or revision, or locale, or firmware version) that shares a web interface with the c7 requires you to manually set a password. even if that were the case, there are bound to be users who aren't security savvy and chose a very weak password (e.g. "password", "admin").
many tp-link routers also have configurable vpn servers built in, which can open up the whole network to malicious actors.
There are significantly more than 21 results listed on Google. Google automatically hides what it considers "duplicate results". There's an option to "repeat the search with the omitted results included" on page 2, which reveals all of the 7,000+ results, of which the vast majority are different routers.
There is a lot here. Some of these are university routers. Tells me that the sysadmin wanted to open up the router so s/he can manage from home. Nifty. But not secure. And they are no way taking the extra effort to make their system secure.
The sensible way to secure it would be to have a device behind the router, in an isolated network which is the only network/device allowed to access the management interface. Then you tunnel/vpn/wire guard into that device.
I know what I'm doing. I would be fine with this in some circumstances. There are legitimate reasons adding a VPN to a backdoor like this can make it worse. The trick to "knowing what you are doing" in this case is defense in depth and knowing what's actually accessible from a world-open interface, and how much of that would be really annoying to get to while simultaneously fixing your homebrew VPN that fell over six months ago and that you never got around to fixing.
Most routers are perfectly fine with a limited set of knobs accessible to the public Internet behind reasonably secure access ports. Bastion it behind SSH and/or SOCKS if you're paranoid, but seriously, as long as we're not talking a $50 Target 'router', it's probably fine. My Ubiquiti gear is indexed. It also reliably e-mails me when it successfully authenticates a user and can distinguish between inside and outside access to ACL what it can do.
Just saying, easy with the "if you know what you're doing" thing, because opinions differ (particularly with beyondcorp in an IT setting). Gluing a VPN back together through an SSH tunnel so you can get at the "fail over to my DSL connection" button inside your network is a really crappy deal at 3 a.m. with a few beers in you and 200ms in between.
> I would be fine with this in some circumstances.
Maybe it’s just a matter of difference of criteria, but I would certainly not be fine with this. You have a lot of ways to prevent this from happening, and it only opens an attack surface to APTs.
Being indexed means being searchable, being searchable means exposing yourself to automated targeted attacks.
Here's the user manual for the TP-Link AC2300 "Archer C7", as found in the google results:
https://static.tp-link.com/2019/201912/20191231/7106508598_A...
Step 2 of first time setup forces a default password change. There is no way around this step.
The defaults for the router also do not allow router access from the WAN port.
This means:
1) These routers all have secured passwords that are non-default.
2) These routers were deliberately placed on the internet by people that knew enough about them to do so.
Just because it's not how you would configure your router doesn't make it wrong. There are legit reasons to place a router on the internet, so long as it's secured properly... how else would you remotely manage a router at a different physical location, for instance.
__Lastly__ click "Next Page" on the OP search results. The estimated 7,000+ results becomes 21. Many of which are HN aggregators reporting on this thread here.
So... out of the possible millions of routers TP-Link has sold in this model line, less than 21 are on the public internet - many of which no longer load via IP address (indicating they are no longer publicly accessible), and the rest have professional CNAME's attached, indicating professional management.
Nothing here...