Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pizza-power opened this issue Feb 17, 2022 · 8 comments
Assignees
Labels

Comments

@pizza-power
Copy link

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
Copy link

Thank you for your notification.

@zagrim
Copy link
Collaborator

zagrim commented Feb 18, 2022

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 starbasessd reopened this Feb 18, 2022
@starbasessd
Copy link

@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
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

change made in motioneye/handlers/config.py, commit c60b64a

@MichaIng
Copy link
Member

MichaIng commented Mar 15, 2022

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.

@MichaIng MichaIng reopened this Mar 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants