Unauthenticated Reflected XSS Vulnerability

[byt3hx]

Summary

I have discovered a reflected XSS vulnerability in the Croncile app. This vulnerability doesn't require any authentication. To reproduce the XSS, two parameters are needed: "format" and "callback". The "callback" parameter is not sanitized and can parse user input to the JSON value. However, we can change the content type using the "format" parameter, which allows the attacker to execute JavaScript code on the browser.

Steps to reproduce the problem

1.Navigate to this url: http://localhost:3012/api/xxxx?format=html&callback=bytehx%22%3E%3C/script%3E%3Cimg%20src=x%20onerror=prompt(document.domain)%3E
2.Our javascript payload will execute an alert box.

Your Setup

Ubuntu Linux VM

Operating system and version?

Ubuntu 22.04.4 LTS

Node.js version?

v20.12.2

Cronicle software version?

0.9.47

Are you using a multi-server setup, or just a single server?

Single server setup, one master.

Are you using the filesystem as back-end storage, or S3/Couchbase?

I am using filesystem.

Can you reproduce the vulnerability?

Yes .

[jhuckaby]

Thank you so much for reporting this. Working on it right now.

[jhuckaby]

Fixed in v0.9.49. Thanks!

[byt3hx]

Hey,

No problem. Thank you for fixing this issue. Could you please verify the /api/app/config endpoint? Currently, this endpoint exposes the internal IP address and the username. Can you add authentication to the endpoint to allow only authorized users??

Regards,
bytehx.

[jhuckaby]

Ah yes, so the /api/app/config API is what "bootstraps" the front-end UI, and provides it with some initial base configuration used to fire up the app. I carefully curated this to only send back essential information, but maybe I missed something. Here is the config API response on my local dev instance, pretty-printed:

{
	"code": 0,
	"version": "0.9.49",
	"config": {
		"name": "Cronicle",
		"debug": 1,
		"default_password_type": "password",
		"privilege_list": [
			{
				"id": "admin",
				"title": "Administrator"
			},
			{
				"id": "create_events",
				"title": "Create Events"
			},
			{
				"id": "edit_events",
				"title": "Edit Events"
			},
			{
				"id": "delete_events",
				"title": "Delete Events"
			},
			{
				"id": "run_events",
				"title": "Run Events"
			},
			{
				"id": "abort_events",
				"title": "Abort Events"
			},
			{
				"id": "state_update",
				"title": "Toggle Scheduler"
			}
		],
		"new_event_template": {
			"enabled": 1,
			"params": {},
			"timing": {
				"minutes": [
					0
				]
			},
			"max_children": 1,
			"timeout": 3600,
			"catch_up": 0,
			"queue_max": 1000
		},
		"job_memory_max": 1073741824,
		"base_api_uri": "/api",
		"default_privileges": {
			"admin": 0,
			"create_events": 1,
			"edit_events": 1,
			"delete_events": 1,
			"run_events": 0,
			"abort_events": 0,
			"state_update": 0
		},
		"free_accounts": false,
		"external_users": 0,
		"external_user_api": "",
		"web_socket_use_hostnames": 0,
		"web_direct_connect": 0,
		"socket_io_transports": 0
	},
	"port": 3012,
	"master_hostname": "joemax.local",
	"servers": {
		"joemax.local": {
			"hostname": "joemax.local",
			"ip": "192.168.3.23"
		}
	}
}

I don't see any "username" exposed in the response, as this call happens before the user logs in. So this API doesn't know anything about users.

While the response does include the master server hostname and IP, this should already be known by the user, as this should be the same hostname or IP from the browser location URL. The user has to navigate to the master server to even load the UI. So it's just a redundant copy of the hostname from the browser page location.

However, there is a special case. If Cronicle is integrated behind a proxy or load balancer, and the user loads the UI via the proxy or load balancer host, then the master server hostname / IP will be "exposed" via this API. But the application cannot really work without this, as it connects to the master server directly via WebSocket.

Is this a security issue? It could be I guess. It depends on the integration. But I would also say that if people are exposing Cronicle to the public internet, this is a really bad idea. Because using this app you can basically run any shell commands on any server in the cluster.

In my opinion Cronicle should always be hosted behind a VPN or on an internal network, in which case exposing the master server hostname / IP is a non-issue.

What do you think?

[byt3hx]

Thank you for providing me with the information. I agree with your point, especially regarding the privilege_list and hostname. I noticed that some people are using Croncile on the public network, which is why I reported this issue. Based on your suggestion of running Croncile behind a VPN or within the internal network, I think it would be good idea not to fix this issue. Thank you for your incredibly fast response.

[jhuckaby]

No no, thank YOU, for doing what you do. Bug bounty hunters are EXTREMELY important in our industry right now, and I am immensely thankful to you 🙏🏻 . Is there some way I can help support you?

i.e. give you credit for this fix, and/or donate some money?

[byt3hx]

Oh, thank you so much for the words. I appreciate it. Would it be possible for you to register this vulnerability for CVE and publish it?

Resources:
https://mrempy.medium.com/how-to-register-and-publish-a-common-vulnerabilities-and-exposures-cve-88512f4f7b1c
https://infosecwriteups.com/how-to-register-and-publish-a-cve-for-your-awesome-vulnerability-e68a6a5f748f

[jhuckaby]

Absolutely! Will do so right away.

[byt3hx]

Thank you so much!

[jhuckaby]

Request submitted to Mitre.org. Awaiting response from CVE team 👍🏻

[byt3hx]

Thank you so much!

[jhuckaby]

@byt3hx We have a CVE: CVE-2024-35478

Looks like it's reserved, awaiting details: https://www.cve.org/CVERecord?id=CVE-2024-35478

[byt3hx]

Hey man,

Thank you so much for this sorry for late reply! I was really busy this week!