Seems to be a fairly big issue with any device that runs on a local network. Https certs won’t be valid for local IP addresses.
It would be good if there was some kind of unverified https mode where you could use a cert that isn’t valid and your saved passwords/cookies are tied to that cert and then if you connect to another device the certificates won’t match and it will count as a different origin.
It would be good if there was some kind of unverified https mode where you could use a cert that isn’t valid
The Ubiquiti routers do this. Just setup the cert to be trusted on your device and you’re set- this attack wouldn’t work. (Chrome doesn’t autofill https passwords on http)
If the attacker uses HTTPS the page wouldn’t even load since the cert would be invalid.
It’s almost impossible for the browser to tell that 192.168.1.1 on this network is different from 192.168.1.1 on that network.
What it can do though, is expect some meaningful user interaction with the form input elements, before filling things in. What we call “meaningful” and “user interaction” is a fine line here. And potentially circumvented with clickjacking, but it seems the next logical step to solve this.
The Mitigations section in the article is pretty lame, imho. I think there is an actual technical solution to this.
Abusing ‘by design’ behaviour to attack millions of WiFi networks.
During a recent engagement we found an interesting interaction of browser behaviour and an accepted weakness in almost every home router that could be used to gain access a huge amount of WiFi networks.
IMHO this shows (once more) how dangerous is any “accepted weakness” in a mass-distributed artifact.
I’d say that adopting HTTPS in home routers is the only correct solution, but each router should have its own certificate so that stealing the private key from one router would not reduce the security of the others.
After all, if you give physical access to your router to strangers enough for them to attack its firmware, you are doomed anyway.
On a side note: I’m not sure about the effectiveness of the proposed mitigation in the browsers (to avoid automatically populating input fields on unsecured HTTP pages), but for sure it’s an easy to deploy one, while waiting for every router manufacturer to fix their production line.
Do you mean they are above the Law?
Or maybe that browser developers are?
I don’t think so.
The real issue, when competent people do not solve the problems they create, is that other less competent might have to.
For example: if routers’ manufacturers won’t fix their products by themselves, they will be obliged to in the very moment governments will realize this attack can be used to enter their private networks. Or the private networks of their banks… or their hospitals… and so on.
However, it’s nothing we can’t handle with a location-based strategy.
But do you really want to be forced to?
That’s why Technology is a continuation of Politics by other means.
Not just because we are political animals ourselves, but because (as you can see with these routers) software is always the cheapest component to change.
This give us an enormous power, but also a huge responsibility: with each hack, with each line we write, we remove or we refuse to, we can either make the world better or worse, but we cannot justify the preservation of a broken status quo.
We cannot look at our own component in isolation and say “everybody does the same! it’s broken by design! it’s too expensive to fix!”. Nor we can delegate to others the fixes of our own faults: for example, while modifying all the browsers would mitigate the severity of this routers’ issue, it’s too naive to think that browsers are the only components caching credentials!
Doing the right thing is totally up to us. And it is always possible.
Seems to be a fairly big issue with any device that runs on a local network. Https certs won’t be valid for local IP addresses.
It would be good if there was some kind of unverified https mode where you could use a cert that isn’t valid and your saved passwords/cookies are tied to that cert and then if you connect to another device the certificates won’t match and it will count as a different origin.
TOFU.
The Ubiquiti routers do this. Just setup the cert to be trusted on your device and you’re set- this attack wouldn’t work. (Chrome doesn’t autofill https passwords on http)
If the attacker uses HTTPS the page wouldn’t even load since the cert would be invalid.
It’s almost impossible for the browser to tell that 192.168.1.1 on this network is different from 192.168.1.1 on that network. What it can do though, is expect some meaningful user interaction with the form input elements, before filling things in. What we call “meaningful” and “user interaction” is a fine line here. And potentially circumvented with clickjacking, but it seems the next logical step to solve this.
The Mitigations section in the article is pretty lame, imho. I think there is an actual technical solution to this.
What are other people’s thoughts?
IMHO this shows (once more) how dangerous is any “accepted weakness” in a mass-distributed artifact.
I’d say that adopting HTTPS in home routers is the only correct solution, but each router should have its own certificate so that stealing the private key from one router would not reduce the security of the others.
After all, if you give physical access to your router to strangers enough for them to attack its firmware, you are doomed anyway.
On a side note: I’m not sure about the effectiveness of the proposed mitigation in the browsers (to avoid automatically populating input fields on unsecured HTTP pages), but for sure it’s an easy to deploy one, while waiting for every router manufacturer to fix their production line.
sure, the solution from plex media server software would make a lot of sense too: they give you a free subdomain and help you get a certificate for the device.
But making the router ecosystem change is a lost battle. those devices are cheap and come with lots of other, arguably worse, security problems.
I think the browser needs to be part of the solution for this specific problem, if you want to see change.
I pretty much agree except for one point.
This assumes that the only battle field available is the market.
Law can easily fix the technological problem here.
And it could also fix more severe vulnerabilities, actually. ;-)
Law is local. Browsers aren’t ;-)
Funny!
Do you mean they are above the Law?
Or maybe that browser developers are?
I don’t think so.
The real issue, when competent people do not solve the problems they create, is that other less competent might have to.
For example: if routers’ manufacturers won’t fix their products by themselves, they will be obliged to in the very moment governments will realize this attack can be used to enter their private networks. Or the private networks of their banks… or their hospitals… and so on.
No. My point is that laws work very differently in every country, while fixing one browser touches all countries. Nothing more and nothing less.
Well, this is a very good point!
Indeed, it’s my own point since the very beginning of this conversation.
However, it’s nothing we can’t handle with a location-based strategy.
But do you really want to be forced to?
That’s why Technology is a continuation of Politics by other means.
Not just because we are political animals ourselves, but because (as you can see with these routers) software is always the cheapest component to change.
This give us an enormous power, but also a huge responsibility: with each hack, with each line we write, we remove or we refuse to, we can either make the world better or worse, but we cannot justify the preservation of a broken status quo.
We cannot look at our own component in isolation and say “everybody does the same! it’s broken by design! it’s too expensive to fix!”. Nor we can delegate to others the fixes of our own faults: for example, while modifying all the browsers would mitigate the severity of this routers’ issue, it’s too naive to think that browsers are the only components caching credentials!
Doing the right thing is totally up to us. And it is always possible.