Security with Roon ARC / Roon 2.0

Great findings. I am very curious about the actual implementation of the API.

I am genuinely surprised that somebody thought enabling UPnP and opening more ports for more services were a good idea. UPnP and port forwarding by themselves are fine since they were reviewed and tested millions of times. But all the services behind the ports can be very much flawed. They are NOT bulletproof.

I had never seen anyone in home lab community said UPnP was OK. Most people would recommend open as less port as possible. If you really need to access something inside your firewall, either open port for just VPN (personally would recommend wireguard) or setting up some proxies with Cloudflare. Reducing the attack vectors is very important.

All who are so worried

  • Run your Roon Core on a separate machine, with its own music storage, no access privileges to any other machines on your LAN
  • Use explicit port forwarding for that machine only, no UPnP
  • Use a well-configured router/firewall with threat analysis

Beyond that, it’s tinfoil hat territory. If the Grand Poobah of Ruritania wants to hack you, they’ll spend a few doubloons on zero-days and all your bits are belong to them.

7 Likes

I found this is harder than said. I believe Roon Core relies on some cast to make itself discoverable for Room Remote, so we cannot just completely block the machine and need to configure it accordingly. It also need to access to all the audio devices. Also need to make sure AirPlay and Chromecast’s multicast/traffic configured properly if you use them.

I wrote “no access privileges,” not “no access.” What I mean is that you don’t want to have the Roon Core machine have credentials for logging onto other LAN devices, especially for logging in to admin/root accounts. My Roon Core sits there, with a copy of my local music library, but no of access credentials for the other machines on the LAN. Fixed IP so that it’s the only port forwarding target.

Good thoughts BUT, you must segment your home network anyway, do not think for a moment that ■■■■ that should stay outside is held there with a firewall. Every device moving between different public networks and then connecting to the inside of your home network is the real pain point. Anyway, is the ROON traffic that important it need to be encrypted? Any hacker will anyway port scan and attack the open TCP port without the traffic info. Sure, they can find interest in the traffic behaviour of roon and use that hmmm. Anyway - you should always use a VPN connecting to your home network from outside - this goes with Roon too to be more secure.

Segment and monitor internal network, and if there is a breach, it will stay on that computer. This is anyway necessary in all internal networks as you always have external devices connecting to the inside all day long spreading ■■■■ without any firewalling if not segmented properly. I will not use a VPN at this time, but will monitor the segmented ROON core very closely, logs and notices if the ROON port is used when I am not using it etc. The ROON core should only answer external IP addresses in your known range (my 4G operator).

1 Like

Great initiative for sure, but until you resolve the serious security issues with UPNP or port forwarding its a no go for people concerned about security. You should advise people so they can decide their own risk/return benefit.

2 Likes

Sadly that is not how things get compromised most of the time. A more likely scenario is that Roon despite good intentions fall vicim to a supply chain flaw where they use some third party library as part of the service that runs on 55000. Whenever such exploits are found the bad guys scan the bulk of the internet using Shodan.io or similar service and then target all the vulnerable systems.

Sadly it is not about someone targeting you specifically. This is why it is critical to always make sure your internet connected devices are up to date with all available patches and that you understand exactly what is exposed to the internet.

While phishing is by far the most exploited attack vector, bad patch management and exploiting poorly patched and maintained systems is also high on the list.

The Grand Poobah of Ruritania, if they could afford it, could certainly buy an exploit from the likes of Zerodium but that is not a likely event for most of us to worry about.

3 Likes

If ARC can initiate requests to the core, regardless through what mechanism, attackers have a point of entry. There’s no way around it. So if you want remote access, you can only mitigate the risk, not remove it completely.

1 Like

Arc is using TLS 1.2 even though it advertises support for 1.3

I’d be more concerned about 1.2 vs 1.3 than having the port forward active

Yes, Thanks. That is why Roon Labs should advise people that there is a risk, so that those that have no understanding of computing can make an assessment of their personal risk tolerance.

1 Like

Usually, that’s something negotiated between client and server. Is the client (in the case at hand) running on iOS or Android?

All my iOS clients natively support TLS 1.3, so I’d be surprised if the Roon ARC client didn’t as well.

Again, if it’s a supply-chain attack, then the malware-infected Roon Core could just as easily open an outbound connection to a C&C server. It would not matter a whit whether it allows inbound connections on Port 55000.

(And, for what it’s worth, the listening port doesn’t have to be 55000. That’s totally configurable. Mine came up as some other randomly-selected high-numbered port.)

2 Likes

Yes, iPhone 13

Arc is choosing 1.2 during the TLS handshake (found/confirmed via packet capture on my edge firewall)

What would the implications of running in a docker be (unraid)

Cheers

Not really my point.

I am not thinking of traditional supply chain attack with direct injection of malicious code in a sub component. These while they exist are exceptionally rare and we should not fret about them.

The bigger concern is a sub library have an unintentional vulnerability that could be exploited like the Log4Shell exploit of the Log4j library.

There are tools that can help in catching these vulnerabilities like BlackDuck or even GitHub to a lesser level but are they part of the process? I have no idea.

Bottom line, an open port to a device that is either sensitive or on a sensitive network is simply a bad idea. Thus before I enable this great feature (and it is great!) I will have to move my Roon core to a sacrificial server on an unimportant and separate part of my network.

2 Likes

Agreed. I’ve refrained from saying this… :joy:

But, if a script kiddie wants to hack you, they’ll find a way.

I’d be more worried about browses, websites, and other such software on the computer…

1 Like

I heartily commend this post to the fora. :+1:

Both your and Fernando’s responses demonstrate a rather naive understanding of the cyber threat landscape. Enough said.

2 Likes

Not at all. My system is pretty locked down. But, I’ve been there and around with SQL injections into software, backdoor trojans in the past. We can only do so much. As shown by the whole QNAP disaster recently. Someone will always find a way in, and sniff around to see what can be accessed.

Yes, by users exposing their networks by publishing services and having UPnP enabled and making it exceptionally easy to attack.

Hackers go for low hanging fruit.

It’s exactly the sort of hubris shown here that was exploited by the gangs operating Qlocker and Deadbolt. And they will continue to pick on those who firmly believe either “it won’t happen to me”, or, “it’s going to happen and there is nothing I can do about it”. Both mindsets are what they are looking to exploit.

1 Like