Lack of a default user password exposes config file which contains potentially sensitive information

[pizza-power]

Last time I posted (in motioneyeOS maybe) about the default lack of admin password/easily bruteforced password, leaving users open to remote code execution, and it was seen as a non-issue, so this may also be a non-issue to you.

If a "user" password is unset, even if an "admin" password is set, the config file at the "/config/list" endpoint remains viewable to anybody that has access to the MotionEye instance. Using Shodan, I've found a large amount of them open to the public.

This config file contains some highly sensitive information such as email addresses and passwords for various services where uploading of files occur such as external FTP, SFTP, gmail, gdrive, telegram, and potentially others.

I just wanted to post this so people know that even if they set an "admin" password, they also need to set a "user" password - especially if their config contains sensitive information like credentials for an upload service - and even more especially if they also expose their MotionEye instance to the internet.

[starbasessd]

Thank you for your notification.

[zagrim]

I for one didn't know that, and didn't even realise there is such an endpoint in ME. I wonder if /config endpoints should require admin to be able to access them. Not that it would make other auth issues right though.

[starbasessd]

@pizza-power Which set of install instructions did you use for testing on what hardware? I want to confirm at what level is the vulnerability introduced, and is it a python2.7 issue, a libmicrohttp12 issue, or something in the motionEye scripts specifically.

[starbasessd]

Nevermind. It exists in both motioneye and motioneyeOS. It's a json report page. Reporting as a bug. Still need to find out where it is introduced / enabled.

[pizza-power]

I tested with the latest docker image from the docker-compose and then just 0.42.1 I downloaded from github and manually ran. Both on Ubuntu 21.10 x86_64 linux kernel 5.13.

Off the top of my head, it's probably just a route authentication issue in MotionEye.

Could you just change line 545 in handlers.py to @BaseHandler.auth(admin=True) - it is currently @BaseHandler.auth()? That seems to fix the issue, in my very limited testing, but I'm not as familiar with the code as you are, so maybe that will break something else.

[pizza-power]

I put in a simple pull request to change line 545 in handlers.py. Like I said, it will need some more testing. Thanks for the help!

[jmichault]

change made in motioneye/handlers/config.py, commit https://github.com/motioneye-project/motioneye/commit/c60b64af5bb8c09189071522a1f6796cb44340b0

[MichaIng]

Reopening this since the patch needed to be reverted. The surveillance user must have access to the config currently.

Not sure whether it would be possible to split the functions to get a limited required config list for surveillance user and the full list only as admin.

Easier would be to apply a default password for both users. This is pretty common nowadays for web applications, not an issue when documented well, and we may even add a password input and optionally as CLI argument to the new motioneye_init command. General CLI support has already been added to make it usable in unattended installers and CI/CD workflows. Widening it to be an interactive setup script (optionally called unattended via --script/-s or --batch/-b option e.g.) wouldn't be so difficult.