Recently, I've been bored during quarantine, so I decided to practice auditing.
I've always been curious about the operation mode of H-site, so I targeted the program of H-site.
There are actually only a few video site source codes that have become well-known. Previously, there were also Apple and Ocean, but it seems that these two have already died (gone underground) due to crackdowns on piracy in China. So the only one I know is Jiucao.
To be honest, I used to think that Jiucao was also a video site program, just cleverly utilized. However, when I first opened their official forum, I was shocked.
Open and aboveboard GHS
(This image is provided by the official template)
Regardless, I downloaded the source code and started auditing.
I downloaded the latest version here.
│─adminx //backend directory
│─assets //backend stylesheets
│─class //backend columns
│─Jccms_json //data storage
│─JCSQL //video data
│─lib //data module
│─static //player files
│─template //template
│─index.php //entry file
(Structure description provided by the official)
I got the source code and put it in PHPStudy. First, I went to install it, but I couldn't find the common "install" directory. After looking at the instructions, I realized that there was no need to install it at all, which made me suspicious. If there's no need to install, where is the data stored?
When I directly accessed the homepage, I found that there were already videos and such. I guessed that they were directly fetched remotely (which also solves the problem of video storage; I mean, those small movie sites can't possibly store all the files locally).
Let's get to work.
First, I used Seay Audit to automatically audit it. According to the preset rules, it shouldn't miss anything.
First, we need to find vulnerabilities, so we need to look for "big" ones. So naturally, we look for front-end vulnerabilities. Considering the nature of this website, there shouldn't be much interaction, so let's look for injections directly. After searching for a while, I found that the entire program is actually SQL injection-free. SQL injection is dead~~
However, when I found it, I also discovered its user authentication method.
JCSQL/Admin/Security/AdminUser.php
This file stores user account passwords and acts as a database. It is saved in text format to avoid the risk of SQL injection, and it exists in PHP form to avoid being downloaded. Brilliant~
Then take a look at the third line, which is called IP filtering.
The backend actually has this feature.
So the question is, when we modify the information, we are actually reading and writing to a text file. And the text file exists in PHP form. So, if we insert the appropriate payload, we can directly create arbitrary file read and write operations. Alright, let's take another look. The value of IPPASS.
Alright, it's directly written as a string. There are no other security functions for filtering. This program itself has a filtering function.
Classic protection
(There seems to be another function, but I couldn't find it when writing the article)
So let's take advantage of this arbitrary file read and write vulnerability. Our target is the AdminUser.php file. First, access it through the browser to see if it returns a 403 or something. If it shows up as blank, it means that any user can access it, but there is no displayed content (the code is only three lines, so there's really nothing to display).
Go back to the backend and fill in our payload in the whitelist.
Based on the original code, we should close the first single quote, then insert our code, and then close the remaining single quotes and brackets.
In general, the format should be like this: ');payload; //'127.0.0.1
If we want to write a file:
');$myfile = fopen("1.txt", "w") ;$txt = "奥里给";fwrite($myfile, $txt); //'127.0.0.1
After writing is complete, access AdminUser.php again to execute the code. Then access 1.txt in the same directory to see "奥力给".
That's basically it. This CMS is too small, with a simple and clever structure, so there's nothing else interesting.
Finally, let's do a reflected XSS.
The automatic audit found three suspicious XSS points.
Let's take a look at the first one.
We can see that the GET parameter "Play" is directly outputted in the src attribute of the script tag.
So, we can construct it directly. There are so many ways to do it.
When accessing this file, just add the parameter XXXX.PHP?Paly=payload.
That's it.