-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Dedicated WebUI malware #13833
Comments
I don't think removing "run on download completion" is a good change, I use that feature often to update my library, I think forcing users to actually pick a password instead of letting them run with defaults is what needs to be changed. Inevitably the issue lies with the users, if you get robbed it's not the lock company's fault that you left your door unlocked, it IS their fault if their locks are poorly made. So in this case I think we need to force users to actually pick a secure password before they can enable webui. "Hi, I just observed a botnet infecting an unsecured WebUI" I don't know what you expected to happen, but I'm hopeful that you've at least learned from the experience and use proper security practices in the future. I made the mistake of hosting my first website on my home machine, lost a lot of family photos and home videos. It's never easy, but I do think they could at least add a disclaimer for the uninformed. |
As mentioned previously: Random password might confuse some users, so it would be better if when users enable WebUI in qBittorrent options, they get a prompt telling them to change the password into a secure/complex password. An alternative to removing "run on download completion" from WebUI, could be to give it's own separate secure/complex password. |
my suggestion would be requiring the password be changed from the default after first login. psuedocode:
|
It is also the lock company's fault if they give everyone the same lock by default.
Don't call other people "stupid tard" if you don't want to be rude.
Never said that and it's not necessary for the malware to function either.
Never said that.
You too thanks. |
It's 2020, if they can't remember/manage their passwords do they really have any business using it?
This is a very good idea.
The difference is you could clearly see 👀 it was default and decided to leave it that way. I agree that security features need to be improved simply because there are people like you who still need plastic safety plugs in wall outlets. 👶 |
I don't think removing the "run on completion" feature is reasonable. That's the wrong solution to the problem, which is largely on the users' side. qbittorrent-nox warns if using the default qBittorrent/src/app/application.cpp Line 627 in e15df81
Initializing with a random password seems like a good idea though, as an additional safety net. |
I am no user of the webui nor a webui developer but here are my 2 cents: IMO, the most appropriate action is probably to force the user on a password change on login and on the localhost. This has the advantage of working transparently for nox users too. Until the default is changed the server will not respond to any other api call or any other interface apart from localhost. Initializing from a random password probably will create headaches for both UI and nox users. They will not be able to understand why they can't connect. And for nox users it will not be easy to manually change the password. |
So any user that had enabled WebUI from qBt settings for say "testing" purpose and forgot to change the PW is vulnerable! That's alarming! |
Apparently there are users exposing the webui client to the internet without changing the default credentials. And apparently there are attackers out there scanning for exposed clients and then logging in with the default credentials and running code (crypto miners). Closes qbittorrent#13833 Closes qbittorrent#16529 Closes qbittorrent#18731
Addressed with #19777 |
Hi, I just observed a botnet infecting an unsecured WebUI (admin:adminadmin, as is default) with a trojan. It seems to be tailored to
the official qBittorent WebUIother torrent clients (rutorrent) as well. I wrote down my findings here. In summary the botnet brute forces admin passwords, then torrents the trojan and runs it via "run on download completion" of another file.I think one of these changes is necessary to save users who unintentionally opened port 8080 (like me) from harm:
The text was updated successfully, but these errors were encountered: