Question about security in Webconf

SrMouraSilva · March 13, 2018, 1:20am

I’m Paulo and I am investigating the webconf auth for implements something similar in a project.

Point one

I observer that some methods have @tornado.web.authenticated, mostly get.
Why post methods haven’t? If it has a power for change the data, why it isn’t protected?

In other words, why do I need authentication to see current configuration, but I do not need to change settings in Zynthian?

Example:

GET

github.com

zynthian/zynthian-webconf/blob/ec09ae3daa43eb462c18c382b7e5794d1551d249/lib/SecurityConfigHandler.py#L38


      
          from collections import OrderedDict
          from subprocess import check_output
          from lib.ZynthianConfigHandler import ZynthianConfigHandler
          
          #------------------------------------------------------------------------------
          # System Menu
          #------------------------------------------------------------------------------
          
          class SecurityConfigHandler(ZynthianConfigHandler):
          
          	@tornado.web.authenticated
          	def get(self, errors=None):
          		#Get Hostname
          		with open("/etc/hostname") as f:
          			hostname=f.readline()
          
          		config=OrderedDict([
          			['HOSTNAME', {
          				'type': 'text',
          				'title': 'Hostname',
          				'value': hostname

POST

github.com

zynthian/zynthian-webconf/blob/ec09ae3daa43eb462c18c382b7e5794d1551d249/lib/SecurityConfigHandler.py#L66


      
          				'type': 'password',
          				'title': 'Repeat password',
          				'value': '*'
          			}]
          		])
          		if self.genjson:
          			self.write(config)
          		else:
          			self.render("config.html", body="config_block.html", config=config, title="Security/Access", errors=errors)
          
          	def post(self):
          		errors=self.update_system_config(tornado.escape.recursive_unicode(self.request.arguments))
          		self.get(errors)
          
          	def update_system_config(self, config):
          		#Update Password
          		if len(config['PASSWORD'][0])<6:
          			return { 'PASSWORD': "Password must have at least 6 characters" }
          		if config['PASSWORD'][0]!=config['REPEAT_PASSWORD'][0]:
          			return { 'REPEAT_PASSWORD': "Passwords does not match!" }
          		check_output("echo root:%s | chpasswd" % config['PASSWORD'][0], shell=True)

Point two

Other point, I think that the cookie token need be random, not a deterministic and commited string

github.com

zynthian/zynthian-webconf/blob/a28c658a8e1dbd34b71b6fb671942e28859950e3/zynthian_webconf.py#L80


      
          logging.basicConfig(stream=sys.stderr, level=log_level)
          
          
          #------------------------------------------------------------------------------
          # Build Web App & Start Server
          #------------------------------------------------------------------------------
          
          def make_app():
          	settings = {
          		"template_path": "templates",
          		"cookie_secret": "hsa9fKjf3Hf923hg6avJ)8fjh3mcGF12ht97834bh",
          		"login_url": "/login",
          		"upload_progress_handler": dict()
          	}
          	return tornado.web.Application([
          		(r'/$', DashboardHandler),
          		#(r'/()$', tornado.web.StaticFileHandler, {'path': 'html', "default_filename": "index.html"}),
          		(r'/(.*\.html)$', tornado.web.StaticFileHandler, {'path': 'html'}),
          		(r'/(favicon\.ico)$', tornado.web.StaticFileHandler, {'path': 'img'}),
          		(r'/img/(.*)$', tornado.web.StaticFileHandler, {'path': 'img'}),
          		(r'/css/(.*)$', tornado.web.StaticFileHandler, {'path': 'css'}),

From tornado security docs

Tornado’s secure cookies guarantee integrity but not confidentiality. That is, the cookie cannot be modified but its contents can be seen by the user. The cookie_secret is a symmetric key and must be kept secret – anyone who obtains the value of this key could produce their own signed cookies.

Problems:

Commentary

@guysoft had commented that it would add a hotspot to the Zynthian image. Today, if the application is insecure, there are no problems, because it is necessary to access the network of the device to carry out some attack.

However, with the implementation of the hotspot, more chances of attack. Imagine someone ruining your performance live!

I thought about this problem previously and the solution I considered was to add a led to blink if the network is in use and a button to activate / deactivate the hotspot.

jofemodo · March 13, 2018, 9:38am

Hi @SrMouraSilva!

Thanks a lot for your analisys. You are completely right. Until now, security hasn’t been an issue because Zynthian boxes are not too exposed. But this is changing with the development of new features, so we should take care of it. We should improve the security in webconf, securing every API call and regenerating the cookie private key for authentication. Also, the system SSH keys should be regenerated too on the first boot. Finally, a button for regenerating all the keys will be added to the webconf, so already running zynthian boxes can be easily secured.

Kind Regards,

guysoft · March 13, 2018, 9:39am

In ZynthianOS build the ssh keys are already generated at first boot

I think all the LED and buttons described could be just added to the GUI.

jofemodo · March 13, 2018, 9:44am

Nice @guysoft !

I will add a little script for regenerating in current systems.
I’ve opened a issue in github.

Regards,

SrMouraSilva · March 13, 2018, 11:04am

Make sense.

In my original problem, I don’t have a display and (yet) a security layer. So what I thought the easiest was this led strategy.

jofemodo · March 13, 2018, 1:08pm

OK! Zynthian security is acceptable now:

All webconf API calls are now authenticated
webconf cookie secret is generated and stored in a config file. If the file is deleted, it will be regenerated on the next webconf start.
A button for regenerating keys has been added to the Security/Access tab. This action will regenerate the cookie secret and the system SSH keys.

Regards,

riban · May 22, 2019, 6:40pm

I have been reviewing some elements of security recently and observe there may be some vulnerabilities. I won’t discuss them here (yet) until I have validated them and hopefully have a resolution however… may I ask what purpose we are implementing security measures? The current constraints seems to be slightly contradictory. There have been messages about Zynthian only being a synthesizer and hence requiring little security and yet we impose limitations on users such as minimum password length. I think it would be beneficial to describe why we implement security and hence why we implement it in a particular way. We could waste lots of time implementing security measures that are not proportionate.

My thoughts:

Avoid inadvertent disruption or corruption, especially during performance
Someone connecting to the device may put extra load on it or they may change settings due to pure curiosity.
This may be avoided by simple password protection at the hotspot, webconf, console and ssh level.

Avoid intentional disruption or corruption
An adversarial actor may wish to interfere with the device. This may be malicious intent to spoil a performance or maybe just someone doing it to prove they can.
This kind of attack may require more robust protection such as cryptographic password protection of hotspot, webconf, console, ssh, etc.

Protect personal data
A user may include personal information within the data elements of Zynthian. They may use engine configuration for unexpected storage of data. They add extra applications or data storage for personal data storage.
This would generally be an intentional activity on the part of the Zynthian user who should consider the impact of such data being shared. This may be protected similar to the previous point.

Protect connected networks
Although Zynthian is a musical instrument it is also a computer with regular operating system. It provides tools for hackers to use as a staging point to access any connected networks which may include the Internet. I feel that Zynthian should have the same level of protection as any other computing device connected to the network. This may be greater or lesser depending on the network administrator’s policy. That may be home, school, venue, anywhere really.

Protect passwords
Protection of data in transit should be considered. If we decide we want to provide a high level of security then we should protect sniffing of data such as password. A recent change to password change routine has removed one such vulnerability. Basically, if we want it safe then make it safe!

Why is the password length constrained to minimum 6 characters? This feels like an arbitrary constraint that may have limited (if any) specific requirement. I would suggest it be up to the user (or local administrator) to define such constraints. If I want to have an empty password or a password that is 20 characters long with only unprintable content then that should be my choice. I will have made that choice with the benefit of a system that is intrinsically secure and so I decide how low I want to take the security.

Sorry for a rather long post on an old subject but I think it would be advantageous to agree why there is security so that we can agree what that security should look like. With it defined we can ensure that our design and testing implements it consistently.

jofemodo · May 23, 2019, 7:05am

Currently, zynthian can be accessed in several ways from network:

SSH: That’ is secure enough
Webconf: use HTTP, so it shouldn’t be accessed from untrusted networks or with point to point ethernet connections. It can be changed easily, but we should solve the problem with certificates.
MOD-UI: use HTTP and have no password. It only should be used in trusted networks, or with point to point ethernet connections
QMidiNet: MIDI over IP. This protocol hasn’t authentication layer, so it should be used only in trusted networks or with P2P ethernet connections.
WIFI Access Point: It’s secure enough, although we have to add some options in webconf for configuring the password, SSID, etc.

Please, feel free to complete or add to this list

Regards,

riban · May 23, 2019, 2:11pm

OSC: Any client can send OSC commands without authentication. This exposes zynthian to being controlled by third parties.

jofemodo · May 23, 2019, 2:18pm

Ups, I forgot that … it’s too new and almost untested. In fact, the level of exposure is very similar to QMidiNet (MIDI-CUIA). Perhaps we should limit OSC to local connections by default and have a flag in webconf for opening to external connections.

Anyway, to be clear:

Currently, when using Zynthian for live performance, it shouldn’t be connected to the network, specially to an untrusted network.

riban · May 23, 2019, 2:22pm

I think that sounds like a pragmatic approach. We may want to consider improving security in future if there are use cases that require network connectivity. One example may be an OSC controller used for performance that connects via wifi. In this case we would want to test that hotspot security is sufficient and is not adversely affected by DoS type attacks, e.g. your massive audience all trying to connect to your zynthian. (There could be an audience participation element that might seek such a scenario .)

jofemodo · May 23, 2019, 2:37pm

That’s the point. I don’t want to waste resources developing more security than required for real-world use-cases.

Using WIFI for live-performance is looking for problems. It ALWAYS can be attacked (almost DoS-attacks). I strongly recommend using wired networks for that. In fact, if you need to connect several devices, you should create your own isolated local network using a tiny cheap switch. It’s soooo easy

riban · May 23, 2019, 7:36pm

Yeah but how do I stage dive whilst continuing with my killer synth solo???

jofemodo · May 23, 2019, 7:53pm

It’s a risk you have to take. Diving is dangerous … wifi networks too, my friend

Tithrion · February 3, 2025, 11:33am

Old one, I know, but an important topic and as we discussed it on zynthian club as well:

Think about encryption for webconf and noVNC. One could use the same cert as for webconf. At least we should encrypt connections where we transmit passwords and/or where we could easily implement it. Currently passwords just can be read in plain text with http connections.
To circumvent potential security warnings with a self signed, generative certificate we could provide a download of the used root cert to be imported in a browser.
Think about the default user. Currently we are running as root. Best practice would be to run as a normal user and that should be feasable if the correct rights are provided to this user. The exploitability is much higher if someone manages to access the Zynthian and directly has root permissions.

May I also propose to start a “Security” thread for catchall security related topics? I searched and found several discussions here and there. Maybe it would be a good idea to have a central collector for infosec discussions.

wyleu · February 3, 2025, 12:00pm

The second thread I read on here was about that. 2017 apparently.

Obviously security is a concern, and as with so much it’s grown wildly in that time.
But it sits at a complex user case, in that a system that doesn’t allow you access at a gig five minutes before the curtain goes up is not generally conducive to a good after gig party.

There are certainly moves a foot. Running within a python virtual environment is evidence of that.
But this is all amateur nonsense in our current age and bolting it down, to an acceptable level is essential. But we need to define what we mean by secure. Really about adherence to standards, which within our own Audio/MIDI world we believe we do quite well.

What security model do we operate and how is our compliance confirmed?

Thank you Mr wyleu. . . .
Our next presentation will be the on going dispute over who has been nicking the biscuits from the tin . . . .

HR…?

jofemodo · February 3, 2025, 12:12pm

Hi @Tithrion !

Zynthian is a synthesizer, an embeded system. It’s not a multi-user environment, not a concurrent server exposed to the wild, etc. Everything runs as root and this is not going to change in the future. It would overcomplicate everything without a clear benefit.

Our resources are best invested in solving more musical subjects: Adding new features, fixing bugs and improving usability. Security is not a big concern because we never had a single report about any kind of abuse and it would be poor resource management to assign resources to solve an issue that doesn’t exist yet.

I really appreciate your interest, but we (developers) are not going to be worried about increasing security up to a server level until we have some report about real abuse.

Of course, users should take care of not exposing their zynthians to the wild internet because they are not safe devices. If you want to do so or you don’t trust the networks you connect your zynthian, please, follow this 3 rules at less:

Change the default password to something “good”
Don’t enable VNC / MOD-UI
Verify you are using “https” for webconf

Anyway, if somebody want to invest some time and share a simple recipe to get VNC working with https, we could consider adding this.

All the best,

riban · February 3, 2025, 4:07pm

Maybe we should add an option to disable OSC. I just discovered that I can control all of my zynthians simultaneously by sending OSC messages to the broadcast address. How funny to send the shutdown command just as the gig commences! (BTW I am exploiting the broadcast OSC for my AoIP project…)

jofemodo · February 3, 2025, 4:47pm

We should have OSC open for local connections only by default