WebUI login without password exploit #16529
Comments
thalieht
added
Security
|
I think it happens to people who don't change their default passwords and expose their WebUI to public and them blame it on the software developers! |
|
I agree unsecured servers are quite commonly exploited. However, I didn't leave it on the default password, and like I said there weren't any failed password attempts in the logs. I did have the local side whitelisted so it was technically open to something like CSRF. But FWIW the user that replied to my thread on the forums didn't have it whitelisted locally. I hope you're not taking a bug report as trying to place blame. Bugs happen. I certainly introduce my fair share of bugs too :P |
|
You can’t rule out the possibility of a local application being the intruder here. They won’t require any password and even if they did, they could easily change it locally. |
|
That's exactly why I didn't post this a few months ago, but now we've seen that other users have had their instances exploited despite requiring a password locally. Also in my case had it been exploited through the local net, wouldn't the logs show the internal IP that made the connection? In this case it showed the attacker's external IP. |
|
If a local application is the intruder, it can very well write values to qBt config that can allow local access to webui without requiring any passwords. Edit: |
|
Ahh I misunderstood, you mean a local application being on the same box. That definitely can't be ruled out for sure but that seems pretty unlikely. It's maybe worth noting that this was a headless linux server that I wasn't just installing random crap on. Plus, if the attacker had that kind of access to my machine already, they wouldn't need to send a payload through qbt. And the payload was literally just trying to get my machine to spam hate mail. There's some additional context for my case, I grepped through the logs of my roommate's nextcloud server, and their logs contained an attempted apache exploit from the same external IP. It looked like they were trying to send a malformed request to maybe exploit something. |
|
I have had a similar issue yesterday. I wasn't using the default username or password, there are no IPs in the whitelist and I am running inside a docker container. No other parts of my system seem to have been compromised. Some logs are below: I can't explain how they managed to login with no failed attempts unless they already had access which seems unlikely given nothing else was touched and this is running in a container. Any thoughts on this matter would be appreciated. |
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 |
|
Hey @sledgehammer999 @glassez this issue should remain open. That's really good that you have gotten rid of default credentials, that should greatly reduce simple attacks in new installs going forward. Absolutely a security win. However, this issue is about a still-unidentified exploit on a webui with non-default credentials. Your change likely doesn't address this. |
qBittorrent & operating system versions
qBittorrent: 4.3.5 armhf
Operating system: Raspbian
I don't still have this system running, the qbit version is all I took note of.
What is the problem?
This happened a little while ago and after posting on the forums I figured it was just bad security practices on my part. But it was just brought to my attention that this is actually more widespread, and potentially affects other torrent clients. Leading me to think this is some kind of upstream issue. Maybe libtorrent? I have no clue so I'm posting here anyways.
So I had my home server's qbittorrent (4.3.5) WebUI exposed externally through UPnP, cause I'm careless, and it got exploited. I'm kind of lost as to why though, the logs only provide enough detail to show that they were able to login directly without brute forcing a password, as there had been no failed logins. I did grep through all the logs.
Exploit went as follows:
Also they changed the WebUI password just to be a shit.
I'm not exceptionally dumb, and my qbittorrent was not running elevated. I also got lucky; even if it contained some privilege escalation exploit the payload was x86 and I'm running on ARM.
Still kind of concerning that there's some exploit to login without needing the password, since there are many users that access without an ssh tunnel, as that is the default config.
Worth noting maybe is that I have authentication bypassed for the 192.168.1.0/24 subnet, but the connection was from an external IP anyways.
I reverse engineered the binary and it seemed to be just something written by some asshole to spam a handful of hateful emails targeting a few particular individuals. Just people they knew presumably.
Steps to reproduce
No response
Additional context
As I mentioned, there have been other reports of this happening in qbittorrent as well as other torrent clients. Thanks to the person that brought this up in the forum.
Funny enough transmission closed their issue for the same bug cause qbittorrent has the bug too. I get that it's probably not an issue with either project, but would be cool if someone can figure out what the common problem is.
https://qbforums.shiki.hu/viewtopic.php?t=9643 (my thread)
https://www.reddit.com/r/truenas/comments/swcuow/unknown_torrents_added_to_qbittorrent_plugin/
https://www.reddit.com/r/qBittorrent/comments/swcr5r/unknown_torrents_added/
https://community.synology.com/enu/forum/1/post/151239
https://forum.transmissionbt.com/viewtopic.php?f=2&t=20962&sid=c6550af19688a3566269628649b1bbb4
transmission/transmission#2653
Log(s) & preferences file(s)
qbittorrent.log
The text was updated successfully, but these errors were encountered: