Wha the heck? You do realize that Roon is doing something that is proven and done by other software all the time, right? There are established mechanisms and security protocols for this, and Roon has done a very good job, most importantly by sending an alert to your email as soon as a successful ARC connection has been made. The only additional thing they could add is password lockout, and I would bet it’s in their roadmap.
That doesn’t mean it is best practice or even secure at all. Every implementation is different and even the smallest mistake in a line of code can be disastrous. Not saying there is actually anything wrong here but just because some other companies do things a certain way is meaningless.
Open source is generally the way to go with secops related implementations. I also like to see an independent security audit and published vulnerability testing with anything that has the potential to compromise a secure system, punching holes in firewalls falls into that category.
4 Likes
Well neither is any operating system by that standard. Projection doesn’t equal truth. We should be respectful to the thoughtful engineers who are being throughout these threads.
Another good reason to run Roon Core as a non-privileged user (rather than as root). It is standard procedure that Internet-facing daemons should run as unprivileged users (if they need to bind to a low-numbered port, they can start up as root, then drop privileges).
1 Like
No they aren’t, that is what firewalls are for.
It is not for Roon Labs to determine the greater good for its users.
As a non ITtecho I have read all the posts regarding security of the ARC application, read the advice from many external experts and consulted with a few CIOs that I know.
It appears that there is a major disagreement between Roon Labs and pretty much the rest of the world on this security issue of use of uPNP and opening ports.
Roon Labs would have been well aware of this before launching ARC and it should have been disclosed upfront.
Given that this is the case IMO it is incumbent on Roon Labs to advise all potential users that the security industry does not agree with Roon Labs and that users need to consider the risk/benefits of using the ARC product.
It goes to the credibility of Roon Labs. It also potentially opens Roon Labs to litigation for not disclosing the potential downside risks of this product.
2 Likes
I dont allow UPnP but configured manually a port forward BUT I have big concerns about what is actually running on 55000.
I am thinking it is some sort of API that is used to communicate with the core but is it encrypted? Is the API implemented with any libraries like Swagger etc, or is it a tunnel like ssh if so what kind of SSH?
Ultimately if whatever software stack running on 55000 is compromised either by the code written by Roon or more likely a supply chain attack on some library they use the attacker will have access to my NAS as the user running the Roon Core process this would give access to my files (not just music files).
I would like to understand more about what is actually responding on 55000 if this is a standard https API I would think I could stand up a proxy and proxy this inside to my Core rather than port forward. This would allow my proxy to sit on my DMZ and not be a path in to the heart of my network,
I am willing to work with Roon to work through this process and see if there are other ways we can improve security and be somewhat transparent about the processes involved here.
In the meantime I suppose I will do some Qualys and Nessus scans and see what I can work out.
5 Likes
That seems quite sensible. Manually configuring a port-forward is no more complicated than digging into the average home router’s setting to turn on UPnP.
And, since that suffices in the present circumstance, it is stupid to turn on UPnP when it is manifestly not needed.
Yes.
SSH? That seems extremely unlikely. Like any API of the past n decades, I expect it is implemented with HTTPS.
Umh. Under the scenarios you just listed, it really doesn’t matter at all whether Roon Core is listening on port 55000. Malware installed under those scenarios can just as easily open an outbound connection to a C&C server.
The scenario one has to worry about is some flaw in the API implementation.
And that would help how?
OK, so let me ask the obvious question. Is your Roon Core running as root?
If so, then you have much bigger problems than precisely what encryption library is being used by the daemon listening on port 55000.
That would be interesting. But running a fuzzer against Port 55000 would be more interesting.
1 Like
Initial digging shows.
- HTTPS is running on port 55000 (the open port)
- It is using a certificate from RoonCA (private CRT) but as I can scan it it is not doing a client certificate so ANYTHING can connect. It would have been easy to put a RoonCA Cert in the ARC App as a client cert so only that app would be able to connect but they did not do that.
- Initial scans with Zap and SNYK did not reveal anything egregious.
Next steps would be to stand up a new Kali Linux box so I can run some more advanced pentest tools like Nessus, BurpSuite or KiteRunner to try and map the API
It may also be worth standing up a proxy to see if I can proxy this rather than having my NAS port open but it is possible the ARC client is looking for the RoonCA certificate and if it does not find it may not connect. (This is pretty silly as the real risk is rogue hackers hitting the open port not having your ARC client connect to an unknown server, as it obviously get the server IP via the login).
4 Likes
Yes proxy gives very little benefit. See other post it is confirmed to be some sort of REST API over HTTPS.
With respect to my current Setup it is Roon Core running on a QNAP NAS, while I very much doubt it would be running as root though I would not put it past QNAP to be that stupid (they have constant security issues). Regardless, Roon core must have access to the file stores (to get the media) so whatever user it is running as can probably also get all my other files as well, so that is very bad even if it is not running as root.
The “default” Roon Core setup runs as root. You actually have to do something to run it as a non-privileged user.
Umh. All it needs is access to the media files, not the rest of the files on your NAS. That’s the point of not running it as root.
That would, indeed, be very bad. But it would be a broken setup. In a proper setup, the roon user would be able to access its own files and noone else’s.
2 Likes
Bollocks looks like you are right.
It is running as admin (essentially root)
[~] # ps -ef | grep -i roon
4786 admin 3472 S /bin/bash /share/CACHEDEV2_DATA/.qpkg/RoonServer/RoonServer/start.sh
4787 admin 2328 S /bin/sh /share/CACHEDEV2_DATA/.qpkg/RoonServer/RoonServer.sh start
10723 admin 1152 S grep -i roon
13560 admin 43516 S /share/CACHEDEV2_DATA/.qpkg/RoonServer/RoonServer/RoonDotnet/RoonServer RoonServer.dll
13619 admin 1303620 S /share/CACHEDEV2_DATA/.qpkg/RoonServer/RoonServer/RoonDotnet/RoonAppliance RoonAppliance.dll -watchdogport=37823
13623 admin 220 S /share/CACHEDEV2_DATA/.qpkg/RoonServer/RoonServer/Server/processreaper 13619
13807 admin 69540 S /share/CACHEDEV2_DATA/.qpkg/RoonServer/RoonServer/RoonDotnet/RAATServer RAATServer.dll
Port closed back down for now this is going to need some very carful consideration.
I may have to re-engineer my entire network and put Roon and endpoints on its own vlan, with a dedicated server and its own data and make it sacrificial before i’m comfortable with this.
4 Likes
Running as a ‘roon user’ does complicate the attack vector but does not mitigate it. It means you would need a two step attack chain to be in real trouble. The first is some compromise of the API or underlaying libraries allowing for remote code execution as the roon user then an escalation of privilege attack to raise to root. Sadly QNAP has already suffered two CVE’s with straight CVSS scores of 10.0 this year alone, I have zero faith in anything they do.
Little steps.
At least make things harder for the attacker.
sudo adduser --system --group --home /var/roon roon
sudo adduser roon audio
sudo chown -R roon:roon /opt/RoonServer /var/roon
sudo chmod 755 /opt/RoonServer
sudo vi /etc/systemd/system/roonserver.service
Edit the file so that RoonServer starts as User=roon.
Then
sudo systemctl daemon-reload
sudo systemctl start roonserver
Now RoonServer should be running as an unprivileged user.
If you’re still queasy about running an Internet-facing daemon on QNAP, then consider buying a NUC, running RoonServer on that (NFS-mounting your media files from your QNAP).
Or run Roonserver in a Docker Container on your QNAP…
6 Likes
Going to have to think on this one. I think dedicated host and vlan (or at least move these to my IOT vlan) is probably the way to go.
I am however willing to go the extra mile as I really hope this is the beginning of getting Roon for Android Auto!!! I listen to more music on my commutes than everything else put together.
1 Like
I am not an expert - therefore I prefer to have no access for anybody from outside the home network. I do not see that this nice tool justifies to deviate from that which makes the app quite useless. But curious to hear from data security experts if my concerns are not justified.
And this kind of information is what we’ve been facing with QNAP for some time now. We cannot depend on them for security assurances until we see better from them. As a customer, I cannot open my router to anything running on it while these attacks continue. I won’t even run the VPN server they provide (not that I have to but for some customers, this is their best security response to have external access). QTS 5.01 just dropped but outside of some of the published information I’ve seen regarding the upgraded kernel, I haven’t seen anything about running applications as non-privs users or other enhancements.
Moving Roon Core off the QNAP NAS is a possibility but it is an additional expense I’d have to swallow and manage…something I was hoping going with the QNAP NAS would avoid. Of course Roon isn’t the only service I run. Plex is the other major entertainment service and I cannot present that to the exterior world either. Plex is a far bigger and well known target to organized criminals than Roon is.
This is quite scary. I have a Nucleus so everything was pre installed. Will need to check if it runs as root as well.
At this point, I am personally not comfortable turning this feature on.
Generally people who purchase Roon are not security experts or network administrators. Some guidance or best practices from Roon on securing your Roon core config and your home network before enabling ARC would be a good idea.
Thanks to all who are digging in on this question.
2 Likes
Yes. I just tested my setup with a GRC Shields Up probe to the specific port that Roon Core opened up and I got “Status OPEN! - Unknown protocol for this port - Unknown application for this port”. I agree that it would be much more reassuring if Roon Core could not respond at all except to legitimate traffic.
1 Like
What does that mean?
How do you decided whether the traffic is “legitimate” until after doing the TLS handshake, and the client has authenticated itself?
- The port is “open” because clients have to be able to connect to it.
- The protocol is HTTPS.
- The application is, of course “unknown” because it was just released yesterday.
2 Likes