OneDev Unauthenticated Arbitrary File Read (CVE-2024-45309) #19614
Conversation
documentation/modules/auxiliary/gather/onedev_arbitrary_file_read.md
Outdated
Show resolved
Hide resolved
| fail_with(Failure::NoTarget, 'No valid OneDev project was found.') unless project_name | ||
|
|
||
| fail_with(Failure::NoTarget, 'Provided project name is invalid.') unless validate_project_exists(project_name) |
There was a problem hiding this comment.
This will validate twice that the project is valid. It's not super-duper-critical, but it would be nice to minimize the amount of requests :)
There was a problem hiding this comment.
Yes I agree that this double check is redundant, I updated this section on c9e0668 to validate the project name only with the user-provided project name
| def find_project | ||
| print_status 'Bruteforcing a valid project name…' | ||
|
|
||
| File.open(datastore['PROJECT_NAMES_FILE'], 'rb').each do |project| |
There was a problem hiding this comment.
I noticed there is no PROJECT_NAMES_FILE included in the PR. Could you add a guard here incase the file doesn't exist to prevent the module from failing?
There was a problem hiding this comment.
I used as the PROJECT_NAMES_FILE option fallback a metasploit wordlist namelist.txt that exists in every metasploit installation. Even if the provided file path doesn't exist, the module doesn't crash because it throws a validation error (Msf::OptionValidateError) before running the module.
The only thing I can do is to remove the default fallback path for the case that somehow the default wordlist file doesn't exist.
| ## | ||
|
|
||
| class MetasploitModule < Msf::Auxiliary | ||
| include Msf::Exploit::Remote::HttpClient |
There was a problem hiding this comment.
This will run the check method automagically
| include Msf::Exploit::Remote::HttpClient | |
| include Msf::Exploit::Remote::HttpClient | |
| prepend Msf::Exploit::Remote::AutoCheck |
There was a problem hiding this comment.
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?
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.use auxiliary/gather/onedev_arbitrary_file_readRHOSTSandRPORToptions as necessaryTARGETFILEoption with the absolute path of the target file to readIf a valid project name is known:
PROJECT_NAMEoption with the known project namerunIf there is no information about existing projects:
PROJECT_NAMES_FILEoption with the absolute path of a wordlist that contains multiple possible values for a valid project namerun