In the hands of the white hats of the major SRC platforms, there are many magic weapons, either hidden or open. And introduce to you the vulnerability scanning based on CMS, how to dig the vulnerability
1. introduction
1.1 first, obtain the list of manufacturer of sky mending, which is saved here in D: / butian.txt. You can also put the domain name of each s RC
1.2 this CMS is based on the secondary development of pocbase of Kongyu. Vulnerability scanner is mainly the overall framework design of scanning platform, and the real need for time-consuming and long-term maintenance is the preparation and expansion of POC. Here, the focus is on the preparation and expansion of POC.
1.3 write POC and scan websites in batch, submit websites with vulnerabilities to corresponding manufacturers
2.1 system architecture design
This system is a vulnerability scanning tool based on CMS. Specifically, it uses Python as the scripting language, uses the SDK written by POC, automates the call test, writes the payload into a py file in a certain format, registers it as a class, and calls for the tool. Support the two plug-in modes of verification and utilization. You can specify a single target or import multiple targets from a file, and use a single POC or POC collection to verify or exploit vulnerabilities. It can be called using command-line mode, and also supports interaction mode similar to metasolit for processing. In addition, it also includes some basic functions such as output result report. In this paper, pocsuite, a PoC development framework, is mainly used as a vulnerability acquisition platform. In the process of actual batch scanning, it is realized by multithreading, lock and queue. The scanning results are directly written into doc file. When collecting vulnerability information and writing payload file, we should choose as detailed as possible, including vulnerability name, vulnerability number, vulnerability source, vulnerability release time and leakage Hole manufacturer, vulnerability CMS type, vulnerability version, vulnerability writer, vulnerability writing time, vulnerability details, vulnerability repair plan, vulnerability type, vulnerability principle, etc. In this way, it is convenient to check and modify this vulnerability in the future and the vulnerability results will be more automatic and user-friendly output. The system operation flow chart is shown in Figure 2-1:
Figure 2-1 system operation flow chart
2.2 detailed function module design
2.2.1 functional design of basic scanning framework
This system uses pocsuite as the development framework of POC. On this basis, the code is modified to make it more suitable for the design goal of this system, and the vulnerability payload file is written to increase the vulnerability scanning of the rich system, and then the command startup program can be executed. Here are the changes:
(1) Payload file format, adding content such as vulnerability repair, vulnerability description, vulnerability level, etc.
(2) Vulnerability result generation. The change here is to generate a doc file for each URL and each payload file in the random folder. The file name format is [website domain name]. Doc. The file content uses the python library docx to generate the doc format file.
2.2.2 vulnerability type function design
There are many types of CMS vulnerabilities, including command execution, SQL injection, XSS attack, logic vulnerability, unauthorized operation, file upload, file read, etc. These vulnerability types can be further subdivided. In the actual writing, according to the specific situation, write a payload file, not every vulnerability can be written a payload file for batch scanning. We need to work hard on the verification of CMS vulnerability types. Next, we will analyze SQL injection and XSS.
1. SQL injection vulnerability
Including Boolean injection, error reporting injection, joint query injection, multi statement query injection, five kinds of injection based on time delay, among which Boolean injection cannot be written into the tool when writing POC. We can only determine whether there is injection by constructing a special statement to send the request, and whether the return page is normal. The difference between the normal page and the error page is due to the source code design of the website, so the general rules cannot be written out. The POC written based on time delay injection judges the response time based on two different requests. If the first request is less than or equal to 1 second and the second request is more than or equal to 5 seconds, the calculation vulnerability exists [10]. Due to network reasons, the request time will be delayed, which leads to the display of vulnerability when batch scanning just meets the vulnerability conditions, which is actually a false alarm. In this way, after each batch scan, you need to manually verify whether the vulnerability exists, so this vulnerability does not need to be added. Therefore, avoid these two types when selecting SQL injection. The specification is shown in Figure 3-2:
Figure 3-2 flow chart of SQL injection POC
2.XSS attack
If the website can only pop-up box, it can't cause recognizable impact on the page source code. We can't accurately judge whether there is a vulnerability when we write the exploitation script. Unless there is an impact on the web page, this CMS type can be determined through some unique features. For example, the moviename parameter in the / images / swfupload / swfupload.swf file of dedecms 5.7 is not effectively filtered, and the SWF file is affected, resulting in cross site scripting vulnerability. We can only pop up the box when we use it, but we can't write a payload with a unique ID yet. Payload is written as / images / swfupload / swfupload. SWF? Movename =% 22]% 29} catch% 28e% 29 {if% 28! Window. X% 29 {window. X = 1; alert% 28% 22xss% 22% 29} / /. We can't go further without the influence of the page, so we have to stop.
To sum up, the actual operation should be close to the plan, which may deviate from the plan due to different scenarios.
2.2.3 system operation design
CMS vulnerability scanning tool controls different scanning methods by inputting different commands. Input the command to run the program, and then output some interface information, such as what tool, what version, current running time, etc., to indicate that the program has been started. Then, start the thread to call the registered POC class, scan in batch. The scanned website information will be displayed in real time on the scanning process interface. Finally, the scanning is completed, and a report log will be generated. The system operation process is shown in Figure 3-3:
Figure 2-2-3 system operation flow chart
3.1 system overall module realization
The most basic core of the tool is the implementation of the basic framework. It only needs to focus on the basic framework for multi-threaded writing to improve the operating efficiency of the system. The other is the continuous integration of CMS vulnerabilities. The written payload only needs to be written in a certain format to make the whole tool run, and does not need to focus on how to run such a repetitive work. The procedure of running the program is: start the entry file pocbase.py, call main() in pocbase / pocbase_cli. Py, and then call pcsinit() to start the program. The directory structure is shown in table 3-1:
Table 3-1 table of contents structure
Serial number
Name
type
Effect
One
Pocbase
Folder
Overall design of scanning frame
Two
Test
Folder
All payload files written for CMS vulnerability
Three
Pocbase.py
file
Program entry file
The pocbase folder contains the file functions and third-party libraries for the program to run. The directory structure is as follows:
├ - documents
├ - pocapi.md - POC writing specification and related API
├ - pocsuite
Data basic data
│ ├── lib
│ │ ├──controller
core core components
Parse parameter processing encapsulation
A common toolkit for utils
│ ├── modules
The TMP temporary directory
- pcs-attack.py attack program
├├ - pcs-console.py ා console program
├├ - pcs-verify.py ා verification procedure
- pocsuite.py pocsuite main entry program
- Tests test POC directory
The third party
└── README.md
The test folder is a payload file written for CMS vulnerabilities. It contains two subfolders: haha and time SQL Inj. The payload file in the haha folder is 100% of the validation success rate, without any manual participation, and the output data is completely correct and reliable. Time SQL inj is a time blind injection, that is, a payload file that may cause errors due to network reasons. We cannot eliminate it. We can only confirm whether the vulnerability exists by running it twice.
The contents of the haha folder are stored in different folders according to the vulnerability type. From top to bottom are: Code Execution Vulnerability, design vulnerability, file download vulnerability, file read vulnerability, file upload vulnerability, information disclosure, OpenSSL, parsing vulnerability, SQL injection vulnerability, URL redirection vulnerability, XSS attack vulnerability.
The haha folder is shown in figure 3-1-1:
Figure 3-1-1 directory structure of haha folder
These folders are about all payloads with the same vulnerability type that can be different CMS. In the case of SQL inject, the CMS types included are:
Aspcms, dedecms, eyou, Fangwei, ohhu, phpcms, qibocms, searun, shopbuilder, SiteServer, V5 shop, valley, Yongyou, Yucheng, Zhengfang, zuitu, etc. As shown in figure 3-1-2:
Figure 3-1-2 directory structure of SQL ﹣ inject folder
3.2 basic scanning framework module
At the end of the scan, the report file is generated. My design is to generate a doc file, and use the document in the python library docx to formulate general doc generation rules. Kb.results stores the data part of the validation results, and circulates the values of each part to the corresponding location of the doc file.
3.3 payload file writing module
3.3.1 general rules for compiling payload files
This module realizes batch processing. In order to prevent robots, some stations need to check whether you have HTTP request headers. For example, some WAFS will check whether there is user agent in the request, so cookies are needed in POC.
Overall code structure:
The top is to introduce some class libraries. In the middle is a PoC class, which inherits from the pocbase class. There are two functions in the class, i.e. "verify" and "attack", which are the entry functions of verify and attack modes respectively. Then there is a user-defined function "parse" result, which is used for unified output. The variables in the class are detailed descriptions of vulnerabilities, from top to bottom: vulnerability ID, tool version, vulnerability writer, vulnerability release time, vulnerability writing tool time, vulnerability file latest update time, vulnerability source, vulnerability name, CMS link, CMS name, CMS version, vulnerability type file, vulnerability type, vulnerability principle, vulnerability repair, vulnerability hazard level No, a detailed description of the vulnerability. With these variables, at the end of vulnerability scanning, these information will be selectively written to the doc file of vulnerability results.
Among them, POC base / lib / poc_base.py file is a commonly used function for writing a payload file.
3.3.2 compilation of payload document
Because the process of writing payload files is the same, take ASP as an example. There are also CMS written in JSP, PHP, Java and other scripting languages. For example, the vulnerability: the latest version of keysioncms can directly break the password in the downloadable database, and the keysioncms is the CMS written by ASP. The cause of the vulnerability can be directly accessed to the path of / ks_data / keysioncms9.mdb, and the database file can be downloaded to the local. Open the file with easy access. See figure 3-3-2-1 for the table structure and data in KS admin
Figure 3-3-2-1 structure of database table
As shown in the figure, the user name is admin and the password is 469e80d32c0559f8. It can be seen from experience that the password is stored in the database after MD5 encryption. After MD5 decryption on the website http://pmd5.com/ ා, we get the password as Admin888, as shown in figure 3-3-2-2:
Figure 3-3-2-2 MD5 decryption diagram
After having the account user name and password, it's needless to say that we can find the back-end website through Yujian scanning or penetration experience, log in the user name and password, enter the back-end, and check whether the back-end has the right to upload webshell directly or indirectly, and then raise the right to control the server and so on. At present, there is a database of the website. You can get all the data of the website.
Next, try to write a payload and then find an environment to test whether the payload you write is successful. First, set up the ASP running environment locally, download the small whirlwind asp web server, and then open the software after installation. Try to download the corresponding version of keysioncms vulnerability to the local. After testing, it is the version of v9.5, and the local test vulnerability just exists. See figure 3-3-2-3 for the access link / ks_data / kesioncms9.mdb
Figure 3-3-2-3 access link diagram
Click Save here to download the file. If you download the file with text, you will find that there are standard jet dB in the mdb file. So when you write the payload, you can simulate a request to obtain the download file, read the file, and find out whether there is a keyword, standardjet dB. This is the principle of vulnerability writing.
Whether the operation is successful after writing. As shown in figure 3-3-2-4:
Figure 3-3-2-5 operation test diagram
This proves that our payload file is written correctly. In order to improve the accuracy of payload, we need to scan 50 websites in batches, check the scanning results, manually verify the successful websites, correct and repeat the process.
The compilation process of the payload file is as shown in the figure: find the source of the vulnerability and analyze the cause of the vulnerability - build the local environment or find the vulnerability environment on the network to test the vulnerability, write the payload file, use the tool to verify whether it is successful, run the payload file with a thousand websites to verify whether there is error, and if there is error, rewrite to continue the above process.
3.4 HTTP request
The principle of payload is to send HTTP requests through tool simulation, including get requests, post requests, put requests to obtain the source code of the web page, match specific characters, and verify the vulnerability.
HTTP is a protocol for communication between computer and network, which will give the server an illusion of browser access, that is, when requesting, simulate the browser request mechanism, plus the browser request header [14]. As shown in figure 3-4-1:
Figure 3-4-1 HTTP request flow chart
When the browser sends a request to the web server, it passes a data block to the server, that is, the request information. The HTTP request information consists of three parts: request method URI protocol / version, request header and request body. To verify the existence of the vulnerability, the following procedures simulate the request:
3.5 multithreading
Multithreading is realized by dividing time, that is to say, time is divided into pieces, each piece deals with a thread, and all threads are processed circularly, while multiprocessor can realize multithreading at the same time [15]. Multithreading is to complete multiple tasks synchronously to improve the efficiency of resource utilization and the efficiency of the system. Threads are implemented when multiple tasks need to be completed at the same time. In short, a project needs to be completed by 10 people in a day at the same time. A project is divided into two processes. The first process is divided into 10 similar small tasks. After all of them are completed, the second process is divided into 10 similar assignment small tasks to be carried out at the same time. As shown in Figure 4-5-1:
Figure 3-5-1 multi thread flow chart
Here is an example of using multithreading:
4.1 test environment
Environment requirements: Python 2.7.8
Python dependency package:
pocsuite==1.2.6
python-docx==0.7.4
python-memcached==1.57
redis==2.10.5
requests==2.8.1
chardet==2.3.0
As shown in Figure 4-1:
Figure 4-1 test environment
4.2 operation parameters of tools
sage: pocbase [options]
optional arguments:
-h,--help Show help message and exit
--version Show program'sversion number and exit
Target:
-u URL,--url URL Target URL (e.g."http://www.targetsite.com/")
-f URLFILE,--file URLFILE Scan multiple targetsgiven in a textual file
-rPOCFILE Load POC from a file(e.g. "_0001_cms_sql_inj.py") or directory (e.g."modules/")
Mode:
--verify Run poc withverify mode
--attack Run poc withattack mode
Request:
--timeoutTIMEOUT Seconds to wait before timeoutconnection (default 30)
--delayDELAY Delay between two request ofone thread
Params:
--extra-argumentsEXTRA_ARGUMENTS Extra arguments (e.g."{username: '***', password: '***'}")
optimization:
--threadsTHREADS Max number of concurrent HTTP(s)requests (default 1)
4.3 function test
4.3.1 multi CMS vulnerability corresponds to multi website scanning
The startup script, the entry file pocbase.py, the parameter r points to the path of the folder to be scanned, the parameter f is the path of the URL file to be scanned, and the parameter threads is the number of threads to be opened in this scan. As shown in figure 4-3-1-1:
Figure 4-3-1-1 startup script scan
This scan only scans SQL injection scan URL text url1.txt. The number of threads this time is 100, and the scan result is shown in figure 4-3-1-2:
Figure 4-3-1-2 actual scanning results
There are 23 vulnerabilities in 2419 times of this scan. The yellow one is the address of the vulnerability result generation file
Scanning time: 1 minute; 42 websites scanned; 60 vulnerabilities injected into CMS by SQL; scanning accuracy: 100%
Verify the successful SQL injection, as shown in figure 4-3-1-3:
Figure 4-3-1-3 verification vulnerability results
Among them, in the designed payload, is the character of ader duo after ASCII code conversion. In order to obtain the matching keyword of the source code. The matching success rate is 100%. Because there is no access connection in the payload, char% 2897% 29% 20% 2B% 20char% 28100% 29% 20% 2B% 20char% 28101% 29% 20% 2B% 20char% 28114% 29% 20% 2B% 20char% 2895% 29% 20% 2B% 20char% 28100% 29% 2B% 20char% 28117% 29% 2B% 20char% 28111% 29% 20% 2B% 20char% 2899% 29.
4.3.2 multiple CMS vulnerabilities correspond to one website scan
The startup script is shown in figure 4-3-2-1:
Figure 4-3-2-1 startup script scan
This scan only scans the SQL injection scan URL website http://www.xxx.cn. The number of threads this time is 150. As shown in figure 4-3-2-2:
Figure 4-3-2-2 startup script scan
There are 66 vulnerabilities in this scan. One yellow is the address of the vulnerability result generation file
Scanning time 6 seconds website number 1 SQL injection CMS vulnerability number 66 scanning accuracy 100%
If the verification is successful, the data construction needs to pass base64 encryption, and the authkey can be displayed directly. As shown in figure 4-3-2-3:
Figure 4-3-2-3 vulnerability results
4.3.3 one CMS vulnerability corresponds to multi website scanning
The startup script is shown in figure 4-3-3-1:
Figure 4-3-3-1 startup script scan
This scan only scans IIS parsing vulnerability. Scan URL file 11.txt. The number of threads this time is 150. As shown in figure 4-3-3-2:
Figure 4-3-3-2 actual scanning results
There are vulnerabilities in this scan 5 times. 4 yellow ones are the address of the vulnerability result generation file
Scanning time: 3 seconds; 5 websites scanned; 1 CMS vulnerability detected; scanning accuracy: 100%
4.3.4 a CMS vulnerability corresponds to a website scan
The startup script is shown in figure 4-3-4-1:
Figure 4-3-4-1 startup script scan
This scan only scans IIS parsing vulnerability. Scan URL website http://www.luohezx.gov.cn. The default number of threads is 1, as shown in figure 5-3-4-2
Figure 4-3-4-2 actual scanning results
There is a vulnerability in this scan. One yellow is the address of the vulnerability result generation file
Scanning time: 2 seconds; number of websites scanned: 1; number of CMS vulnerabilities detected: 1; scanning accuracy: 100%
If this verification is successful, the access connection proves that the vulnerability exists. As shown in figure 4-3-4-3:
Figure 4-3-4-3 vulnerability scanning results
4.3.5 vulnerability generation log
At the end of scanning, the log is generated. The log file address is displayed in yellow font on the command line
The log contents are as follows (for example, SQL injection vulnerability exists in xxx.xxxxx.gov.cn):
The file name is: [SZB. Zhengzhou. Gov.cn]. Doc
The content of the document is shown in figure 4-3-5-1:
Figure 4-3-5-1 vulnerability generation log
5. Test summary
It can realize the whole process of tool scanning, from scanning on, flexible scanning mode to multi-threaded scanning speed, and finally display the total number of scans and the number of vulnerabilities, write the scanning results to the log file, and output the log file address to end the whole scanning process. The scanning tool can run successfully and has strong scalability. There are certain rules for writing CMS vulnerability payload file. Integrating new vulnerabilities will not affect the operation of the whole tool.