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:31am

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