Sonos please task one of your engineers with adding a password option to the Sonos system just like Apple has done with their Homepods!
Airplay2 is a game changer when it comes to an open system like Sonos because any device with Airplay2 capability can take control of a sonos system without intentionally installing the Sonos app. While this is convenient on some networks it is a royal pain in the arse for others.
Take my home network as an example. I have two wireless networks - one for the family and one for guests. The guest network has no access to Sonos which is great. But everyone on the family network can control any speaker in the Sonos system because there is no way to secure them. Unfortunately I can't put them on a separate subnet due to the shared media and backup servers. Sure, I ask them not to connect to certain speaker and groups, but they don't see the harm in having the house filled with their cool tunes while I'm at work. Can't really blame them but it causes problems with the neighbors and even me (sucks to ask Alexa to play CNN on a speaker and have it blaring close to full volume because someone forgot to turn it down).
BTW, this wasn't much of a problem before the Airplay2 update because none of the kids had the Sonos app installed on their devices but now they connect without a 2nd thought.
Please give us the option to protect speakers and groups of speakers.
This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.
Page 4 / 4
You know your snipping does not preclude me actually quoting the original request?
Never said they did. However, if Sonos devices had the option for authentication this thread wouldn't exist.
Again with your nonsense. Sonos could 100% protect their API from both internal and external attacks and not come close to giving you what you wished for in your OP.
Now that is interesting. How do you propose they do that while allowing Airplay access without any authentication (which is what we have now)?
First, the risk is far greater than playing a song or turning on a light. If you doubt it read this:
https://www.networkworld.com/article/3266375/internet-of-things/best-practices-for-iot-security.html
"Making matters worse is the fact that cybercriminals are incentivized to figure out new and more insidious ways to hack into even the most benign devices because they can provide a convenient gateway to more valuable systems. Your connected rice-cooker might not, at first-blush, appear to present much of a threat to the security of your home if it is compromised by an outside party. But if it can act as a gateway to more important devices on your network it might actually represent your most significant security vulnerability."
The fact is that some of the smartest guys in the industry disagree with you. Maybe you missed this last time so here it is again.
The INTERNET OF THINGS (IOT) SECURITY BEST PRACTICES paper might be educational for you and others that believe it is OK to have unsecured devices on your networks.
https://internetinitiative.ieee.org/images/files/resources/white_papers/internet_of_things_may_2017.pdf
"5. Use strong authentication
IoT devices should not use easy-to-guess username/password credentials,
such as admin/admin. Devices should not use default credentials that are
invariant across multiple devices and should not include back doors and
debug-mode settings (secret credentials established by the device's
programmer) because, once guessed, they can be used to hack many
devices.
Each device should have a unique default username/password, perhaps
printed on its casing, and preferably resettable by the user. Passwords
should be sophisticated enough to resist educated guessing and so-called
brute force methods.
Where possible we recommend two-factor authentication (2FA), which
requires a user to employ both a password and another authentication form
that does not rely on user knowledge, such as a random code generated via
SMS text messaging. For IoT applications, we especially encourage the use
of context-aware authentication (CAA), also known as adaptive
authentication, which use contextual information and machine-learning
algorithms to continuously evaluate risk of malice without bother to the user
by demanding authentication. If risk is high, then the subscriber (or hacker)
would be asked for a multi-factor token to continue having access."
Now that is interesting. How do you propose they do that while allowing Airplay access without any authentication (which is what we have now)?
Still ignoring my original request, I see.
Done with you.
Here is one example of the many exploits intruders use gain access to a network. If this researcher hadn't shared his results with Sonos our devices would still be vulnerable to this attack. This article is well worth the time to read:
https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325
"Like Google Home, Sonos WiFi speakers can also be controlled by a remote attacker (CVE-2018–11316). By following the wrong link you could find your pleasant evening jazz play list interrupted by content of a very different sort. That’s fun for simple pranks, but ultimately pretty harmless, right?
After a bit of digging I found a few other interesting links to be followed on the Sonos UPnP web server that might not be so innocent. It appears that several hidden web pages are accessible on the device for debugging purposes. http://192.168.1.76:1400/support/review serves an XML file that appears to contain the output of several Unix commands run on the Sonos device (which itself seems to run a distribution of Linux).
http://192.168.1.76:1400/tools provides a bare bones HTML form that lets you run a few of these Unix commands on the Sonos device yourself! The Sonos HTTP API allows a remote attacker to map internal and external networks using the traceroute command and probe hosts with ICMP requests with ping using simple POST requests. An attacker could use a Sonos device as a pivot point to gather useful network topology and connectivity information to be used in a follow up attack."
That last sentence is very important. By poking devices an attacker is learning what is on the net. The more information gained the greater the chances of finding a weakness that allows more access to the network. This type of attack is stopped in its tracks with authentication.
https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325
"Like Google Home, Sonos WiFi speakers can also be controlled by a remote attacker (CVE-2018–11316). By following the wrong link you could find your pleasant evening jazz play list interrupted by content of a very different sort. That’s fun for simple pranks, but ultimately pretty harmless, right?
After a bit of digging I found a few other interesting links to be followed on the Sonos UPnP web server that might not be so innocent. It appears that several hidden web pages are accessible on the device for debugging purposes. http://192.168.1.76:1400/support/review serves an XML file that appears to contain the output of several Unix commands run on the Sonos device (which itself seems to run a distribution of Linux).
http://192.168.1.76:1400/tools provides a bare bones HTML form that lets you run a few of these Unix commands on the Sonos device yourself! The Sonos HTTP API allows a remote attacker to map internal and external networks using the traceroute command and probe hosts with ICMP requests with ping using simple POST requests. An attacker could use a Sonos device as a pivot point to gather useful network topology and connectivity information to be used in a follow up attack."
That last sentence is very important. By poking devices an attacker is learning what is on the net. The more information gained the greater the chances of finding a weakness that allows more access to the network. This type of attack is stopped in its tracks with authentication.
I disagree with your statement that this is about port 1400 being open on the router (it did not have anything to do with router/firewall settings, see this article https://en.wikipedia.org/wiki/DNS_rebinding). The issue is that Sonos assumes that the network will be secure and therefore they have not secured the Sonos API with authentication so the devices are vulnerable to this type of browser based attack). There is no such thing as a secure network if the network is connected to the internet or has wifi as part of the network architecture.
I agree with the sentiments expressed in the original post i.e. having some kind of control to restrict open access to the whole Sonos network when using AirPlay2. I have a separate post on related matter ; I have two apartments located one above the other, which both use the same router / wifi. Set up with separate Bridges hardwired to same router, and creating two Sonosnets, each unique to an apartment. Using Apps to control the speakers in this way maintains the integrity of the separate network, with no-one in one apartment being able to play music in the other. I'm considering making these separate homes "smart homes" for lighting etc using Alexa. Sonos One units would replace Play Ones. Using App controllers would be no different to existing set up. However, I think Airplay 2 functionality would make ALL speakers across BOTH homes be transparent as potential speakers, which could lead to annoying unwanted playback in the wrong apartment.
I have another home elsewhere which I've smartened with Echo Dots linked to Sonos. I think this gives me the choice of searching for Sonos products and then deselecting those not required. Using Echo Dots would I think achieve the "closed" Sonos environments required.
Some switch/ selector/ password to restrict open access to ALL sonos speakers would be greatly appreciated.
I can understand in the majority of cases, Airplay2 will fulfil most users' requirements. However, other like me and the premier poster require something a little bit more bespoke.
I have another home elsewhere which I've smartened with Echo Dots linked to Sonos. I think this gives me the choice of searching for Sonos products and then deselecting those not required. Using Echo Dots would I think achieve the "closed" Sonos environments required.
Some switch/ selector/ password to restrict open access to ALL sonos speakers would be greatly appreciated.
I can understand in the majority of cases, Airplay2 will fulfil most users' requirements. However, other like me and the premier poster require something a little bit more bespoke.
I have another home elsewhere which I've smartened with Echo Dots linked to Sonos. I think this gives me the choice of searching for Sonos products and then deselecting those not required. Using Echo Dots would I think achieve the "closed" Sonos environments required.
Some switch/ selector/ password to restrict open access to ALL sonos speakers would be greatly appreciated.
I can understand in the majority of cases, Airplay2 will fulfil most users' requirements. However, other like me and the premier poster require something a little bit more bespoke.
Any user will then need know the password to use each group of speakers. Also you (the Home administrator) can also set access security, so that the user has to be a member of the Home too. You can also disable the 'editing' features for the Home, so that any Home that is shared, remains secure.
Thanks - that sounds most helpful. Hadn't thought of control being via Apple but concentrated on Sonos solutions. It's success all depends on whether HomeKit will recognise two created homes to replicate the two segregated "homes" under Sonos, despite being on same WiFi/ Password etc. If the HomeKit works like this, within a physical house by perhaps enabling Upstairs/ Downstairs groups then indeed it should work since in my set up, the only difference between separate zoned access in a single house and my situation is the existence of front doors since one apartment is immediately above the other. Thanks again.
That's very helpful.
Page 4 / 4
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.