Web UI - apparent path traversal vulnerability
dionb2023 opened this issue · 32 comments
qBittorrent & operating system versions
qBitTorrent version: 4.5.1 (latest stable as of today).
Operating System: Windows 10, version 22H2. x64 architecture.
What is the problem?
I ran a Nessus vulnerability scan on a machine running qBitTorrent and found that the Web UI can be used to access arbitrary files on the host's filesystem - unauthenticated - via what appears to be a path traversal vulnerability.
Have done some searches on your bug tracker for an existing bug report - and can't find one, some am raising this. Note that this is my first open source bug report - so apologies if I've missed anything. Please let me know if there's anything you need from me.
Steps to reproduce
If you were on my network, you'd do the following:
- Enable the qBitTorrent web UI (in my case it runs on port 8080)
- From a command prompt, run curl -i "http://192.168.2.8:8080/..\..\..\..\..\windows\win.ini"
Expected result: a 403 or 404 response
Actual result: the win.ini file from the remote machine is displayed
Have attached a screenshot where I create a file on the remote machine then retrieve that file unauthenticated from my laptop.
Additional context
Log(s) & preferences file(s)
No response
This is an important find, but you really should have disclosed this privately to the developer before going public with it (their contact info is in the README), especially considering this works without any authentication. Posting it here has it in the clear for attackers to potentially exploit before the necessary fixes are available.
@notdatabase If you have ideas for a good process, I suggest using GitHub's option to "suggest a security policy" at https://github.com/qbittorrent/qBittorrent/security/policy to improve things for future disclosures.
Security through obscurity is no security at all
@sserdda-liamE thats not what he's saying, what he's saying is to disclose it responsibly. common practice is to report vulnerabilities like this privately so they can't be used by a malicious actor, then if nothing happens after a few months then disclose it publically. this is not the way to do
That doesn't respect my freedom™ to use a better client.
Well, since this is worked on publicly I'll chime in with my preliminary findings so far:
- I've confirmed vulnerability in Windows on 4.5.1
- I was not able to reproduce this on Windows with 4.4.5
- I have not yet been able to reproduce this on Linux on either version
I'm going to start bisecting this, but it'll be slower while I figure out how to build this for Windows. I don't think I've ever compiled anything on Windows.
someone might want to start a CVE?
I cannot reproduce on a Win10 21H2 VM, with a fresh install of qbit 4.5.1. After launching qbit, the only config setting I changed is enabling the webUI. Is there some specific config setting that is needed to trigger this?
EDIT: ah nvm, I can trigger it. Looks like some versions of curl are removing the backslash-path-traversal from the URL... :
$ curl -ikvvv "http://192.168.1.xxx:yyyy/..\..\..\..\..\windows\win.ini"
* Trying 192.168.1.xxx:yyyy...
* Connected to 192.168.1.xxx (192.168.1.xxx) port yyyy (#0)
> GET /..\..\..\..\..\windows\win.ini HTTP/1.1
> Host: 192.168.1.xxx:yyyy
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
$ curl -ikvvv "http://192.168.1.xxx:yyyy/..\..\..\..\..\windows\win.ini"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.1.xxx:yyyy...
* Connected to 192.168.1.xxx (192.168.1.xxx) port yyyy (#0)
> GET /windows/win.ini HTTP/1.1
> Host: 192.168.1.xxx:yyyy
> User-Agent: curl/7.87.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
EDIT2: curl has a --path-as-is option that disables the path mangling.
Suspected problematic lines:
https://github.com/qbittorrent/qBittorrent/blob/release-4.5.1/src/webui/webapplication.cpp#L154-L156
Error on path traversal, ignoring windows line separators.
I checked git blame, that line looks really old. So I suspect there may have been another layer offering protection that broke. But we should likely add support for windows separators there for defence in depth in addition to whatever bisect eventually turns up.
Suspected problematic lines:
https://github.com/qbittorrent/qBittorrent/blob/release-4.5.1/src/webui/webapplication.cpp#L154-L156
Error on path traversal, ignoring windows line separators.
I checked git blame, that line looks really old. So I suspect there may have been another layer offering protection that broke. But we should likely add support for windows separators there for defence in depth in addition to whatever bisect eventually turns up.
Thanks for this. It gave me a head start on where to look.
Everyone take a look at PR #18625. I think I have fixed it. Once the CI finishes, there are build artifacts for Windows. You can download them, run them and test if it fixes the problem.
@sledgehammer999 As this problematic condition has been present since at least 2015 (going through the blame), do you have any clue what could have caused this to just start happening in 4.5.0?
@winterqt I am not at all familiar with the webui code. I was able to produce the PR due to the comment above me, which pointed me to the correct direction (IMO).
There was probably some kind of other guard mechanism that got lost in the refactoring that took place for 4.5.0. Probably someone else from the team will answer your question in a while.
do you have any clue what could have caused this to just start happening in 4.5.0?
Did someone manage to trigger the bug on 4.5.0?
I can trigger it on 4.5.1, but not on 4.5.0 or 4.4.5.
I've seen a report of 4.5.0 being vulnerable, yes.
I can trigger it on 4.5.1, but not on 4.5.0 or 4.4.5.
Also not able to reproduce on 4.5.0 (so far).
65611cd looks like the offending commit - didn't check, only by looking at changelog between 4.5.0 (which supposedly is not affected) and 4.5.1
At a glance, I'm unsure how that would affect path normalization/stripping for the controllers -- that looks like it just defines how paths will be returned, unrelated to how they're parsed. Who knows, though, I've barely touched this codebase.
Suspected problematic lines:
https://github.com/qbittorrent/qBittorrent/blob/release-4.5.1/src/webui/webapplication.cpp#L154-L156
Error on path traversal, ignoring windows line separators.
I checked git blame, that line looks really old. So I suspect there may have been another layer offering protection that broke. But we should likely add support for windows separators there for defence in depth in addition to whatever bisect eventually turns up.Thanks for this. It gave me a head start on where to look.
Everyone take a look at PR #18625. I think I have fixed it. Once the CI finishes, there are build artifacts for Windows. You can download them, run them and test if it fixes the problem.
At least from my side, looks like this build does indeed fix it.
I am able to reproduce this with 4.5.0, but not 4.4.5, so I don't believe the offending commit is in 4.5.1.
65611cd looks like the offending commit - didn't check, only by looking at changelog between 4.5.0 (which supposedly is not affected) and 4.5.1
Path::toString() just called QDir::toNativeSeparators before, which also returns Windows backslashes, so this is not it.
Once the CI finishes, there are build artifacts for Windows
Is there a URL to grab the windows build artifacts from CI, where I can just throw in a commit hash?
I could probably figure out where the commit was introduced more quickly. It's taking me ages to setup a Windows build environment, between install times and lack of familiarity.
@anthonyryan1
With a commit open in the github web ui, e.g. 37e348e, click the CI icon in the commit message line. Then click "Details" for e.g. "CI - Windows / Build (2.0.8) (push)", then click "Summary" in the top left. Then scroll down to "Artifacts". (note that you have to be logged in to be able to download them)
Unfortunately GitHub Actions only seems to store the uploads for 3 months, so this is not going to be useful for you. I've already tested with the oldest commit from the v4_5_x branch that still has artifacts available and it exhibits the bug -- i.e. it's not possible to bisect this way.
I use remote access with a 10 character, auto-generating password for every session. By the way, utorrent also had something similar, the web interface in the client, it seems, will never become 100% bladeless
Well, since this is worked on publicly I'll chime in with my preliminary findings so far:
* I've confirmed vulnerability in Windows on 4.5.1 * I was not able to reproduce this on Windows with 4.4.5 * I have not yet been able to reproduce this on Linux on either version
Seems the exploit only affect Windows builds, I'm updating the issue label.
Hi,
There's something to be said about the disclosure process here, but as the cat is out of the bag already it's probably best to go ahead and get a CVE allocated for users to track this.
Leveraging this to disclose sensitive information related to WebUI authentication took me about 10 seconds to figure out.
Using Windows on 4.5.1
It appears that the maintainer is already active in this issue, but I went ahead and emailed the contact provided in the README to notify them and close the loop via proper channels.
这是一个重要的发现，但你真的应该在公开之前私下向开发人员披露这一点（他们的联系信息在自述文件中），特别是考虑到这在没有任何身份验证的情况下工作。将其发布在此处可以清楚地表明攻击者在必要的修复程序可用之前可能会利用它。
@notdatabase issues 就是用来汇报问题的。
@1265578519 What is your problem with using civilized language?
@1265578519 What is your problem with using civilized language?
Although it is really customary here to use English for communication, but this does not mean that it is more civilized than others. Please refrain from insulting other participants in the future.
Perhaps devs could consider including tips on both the issue templates and the readme. Additionally, devs could require any vulnerabilities to be reported via private email.
I have personally experienced the effectiveness and professionalism of the devs through the private disclosure and bugfix process.
This was a serious concern, but I'm glad it's fixed. Can someone confirm whether it was possible for remote peers/seeds to access files, or does it mostly relate to the local network?
This was a serious concern, but I'm glad it's fixed. Can someone confirm whether it was possible for remote peers/seeds to access files, or does it mostly relate to the local network?
This only affects WebUI, so it depends on whether you expose the WebUI port to the Internet, what kind of authentication you use, any proxies, etc.