- 0x00 Preface
0x00 Preface
- 0x01 introduction to awvs plug in
0x01 introduction to awvs plug in
- 0x02 introduction to analyzed plug-ins
0x02 introduction to analyzed plug-ins
- 2.1 plug in process
2.1 plug in process
- 2.2 classXSS
2.2 classXSS
- 2.3 classSqlInjection.inc
2.3 classSqlInjection.inc
- 2.4 Server_Side_Request_Forgery.script
2.4 Server_Side_Request_Forgery.script
- 0x03 summary
0x03 summary
- 0x04 reference
0x04 reference
- Author: 71src
Author: 71src
- Time: June 5, 2018
Time: June 5, 2018
As a very powerful web vulnerability scanner, awvs is no stranger to us. However, awvs must run in the windows environment. For Linux users, there is an extra layer of trouble using virtual machines. In view of this, we have made some simple analysis of awvs and tried to Python several plug-ins. In this process, we can better recognize the advantages and disadvantages of awvs.
How to write awvs plug-ins and the functions of plug-ins under each directory are described in the article "writing your own Acunetix WVS vulnerability script"
Network: the script files in this directory are executed after the scanner completes the port scanning module. These scripts can detect the opening of TCP port, such as whether the 21 port of FTP is open and whether anonymous login is allowed;
Perfile: the script in this directory is executed when the scanner crawler crawls to the file. For example, you can check whether there is a backup file in the current test file and the content of the current test file;
Perfolder: the script in this directory is executed when the scanner crawled to the directory. For example, you can check whether the current test directory has a column directory vulnerability;
Perscheme: the script in this directory will check the get and post structure parameters of each URL. The parameters defined by awvs include HTTP header, cookies, get / post parameters, multipart / form data For example, you can test XSS, SQL injection and other application tests;
Perserver: scripts in this directory are executed only once at the beginning of scanning. For example, you can check the type of web server middleware;
Postscan: scripts in this directory can only be executed once after scanning. For example, you can detect storage XSS, storage SQL injection, storage file inclusion, storage directory traversal, storage code execution, storage file tampering, storage PHP code execution, etc;
XML: a detailed description of the vulnerability is here.
- First of all, XML folders are used to store the details of different types of vulnerabilities and the ways to repair them. I believe that the used partners have seen the details of the vulnerabilities on the right, so we will not analyze them here;
First of all, XML folders are used to store the details of different types of vulnerabilities and the ways to repair them. I believe that the used partners have seen the details of the vulnerabilities on the right, so we will not analyze them here;
XML
- Next is the network folder, which stores some vulnerability detection and information discovery on the network port. For example, the DNS [zone] transfer.script in it also knows that the name is the detection of the domain transfer vulnerability, and other anonymous FTP login. Because this series of chapters are from plug-in analysis to agent scanning, So this part will not be introduced in detail. However, it is recommended to take a look at the script related to proxy * series. After all, every company may open some proxy ports, and this series of vulnerabilities are also introduced in wooyun
Next is the network folder, which stores some vulnerability detection and information discovery on the network port. For example, the DNS [zone] transfer.script in it also knows that the name is the detection of the domain transfer vulnerability, and other anonymous FTP login. Because this series of chapters are from plug-in analysis to agent scanning, So this part will not be introduced in detail. However, it is recommended to take a look at the script related to proxy * series. After all, every company may open some proxy ports, and this series of vulnerabilities are also introduced in wooyun
NetWork
dns_zone_transfer.script
proxy*
- Then there is the perfile folder, including backup file.script, bash rce.script, and XSS in uri.script. At this time, XSS is detected. We will analyze it later
Then there is the perfile folder, including backup file.script, bash rce.script, and XSS in uri.script. At this time, XSS is detected. We will analyze it later
PerFile
Backup_File.script
Bash_RCE.script
XSS_in_URI.script
- Perfolder folder, including access control allow origin script and directory listing script, as well as SQL injection in basic.script, which is used to detect SQL injection. Similarly, we will also test the injection
Perfolder folder, including access control allow origin script and directory listing script, as well as SQL injection in basic.script, which is used to detect SQL injection. Similarly, we will also test the injection
PerFolder
Access_Control_Allow_Origin.script
Directory_Listing.script
SQL_Injection_In_Basic.script
- The perscheme folder will be the focus, as in the quote, common vulnerabilities include XSS / sqli / xxE / SSRF, etc
The perscheme folder will be the focus, as in the quote, common vulnerabilities include XSS / sqli / xxE / SSRF, etc
PerScheme
- Next is the percerver folder: it is used to detect different middleware, such as Apache proxy connect enable.script, which is used to detect Apache proxy, Solr, flask debug and other middleware. If you are interested, you can see that JMX RMI service.script also provides a detection plug-in
Next is the percerver folder: it is used to detect different middleware, such as Apache proxy connect enable.script, which is used to detect Apache proxy, Solr, flask debug and other middleware. If you are interested, you can see that JMX RMI service.script also provides a detection plug-in
PerServer
Apache_Proxy_CONNECT_Enable.script
solr
Flask Debug
JMX_RMI_service.script
- Postcrawl, to tell the truth without looking into it, is just a misleading narrative;
Postcrawl, to tell the truth without looking into it, is just a misleading narrative;
PostCrawl
- There are only a few plug-ins in the folder postscan. You can look at the names: stored ﹣ XSS, stored ﹣ SQL ﹣ injection, stored ﹣ file ﹣ inclusion, stored ﹣ code ﹣ execution, stored ﹣ file ﹣ tampering. One of them is high-risk comrades;
There are only a few plug-ins in the folder postscan. You can look at the names: stored ﹣ XSS, stored ﹣ SQL ﹣ injection, stored ﹣ file ﹣ inclusion, stored ﹣ code ﹣ execution, stored ﹣ file ﹣ tampering. One of them is high-risk comrades;
PostScan
Stored_XSS
Stored_SQL_Injection
Stored_File_Inclusion
Stored_Code_Execution
Stored_File_Tampering
- The last one is vulnerability detection of some common CMS such as Joomla, Drupal, WordPress;
The last one is vulnerability detection of some common CMS such as Joomla, Drupal, WordPress;
WebApps
joomla
drupal
wordpress
This paper analyzes the implementation ideas of the following plug-ins
- Blind_Sql_Injection.script
Blind_Sql_Injection.script
- classSqlInjection.inc
classSqlInjection.inc
- classCRLFInjection.inc
classCRLFInjection.inc
- ClassXSS.inc
ClassXSS.inc
- Code_Execute.script
Code_Execute.script
- XXE_Folder.script
XXE_Folder.script
- Server_Side_Request_Forgery.script
Server_Side_Request_Forgery.script
In order to better understand the plug-in of awvs, we need to first understand its several classes: tURL, treportitem, thttpjob, and a scheme variable. The first three classes are also easy to understand in terms of class names. They are the classes dealing with URL, report and HTTP requests, but scheme doesn't understand much. At present, we can't find relevant information, Please contact me if you have any known partners. Although these are not related to the plug-in process, they are very helpful for us to plan our own tools
TURL
TReportItem
THTTPJob,
scheme
scheme
2.1 plug in process
Through the analysis of several plug-ins, it is found that there are generally several functions: starttesting as an entry, similar to the main function in Python, but some plug-ins do not have this one; alert function, as a function of loading xml files and treportitem, can be implemented without much ado, such as request function and instance implementation of thttpjob
startTesting
main
alert
xml
TReportItem
request
THTTPJob
Let's start to analyze the first plug-in. Let's start with classxss
classXSS
2.2 classXSS
In classxss.inc, awvs defines three document types: HTML, XML, invalid. All content types that are not HTML and XML types are defined as invalid. At the same time, it also defines a thtmlquery class, which is used to find XSS in non browser models such as casperjs. For example:
classXSS.inc
html
xml
Content-Type
THTMLQuery
casperjs
As you can see, when the inputvalue is script_start_tag, that is, < script >, use tag = | textwhithin = to determine whether the incoming value generates a tag instead of content, but the implementation of this class has not found the file where its definition is located. However, we can use the beasutiflsoup class to implement, such as the upper class JS code can be converted to the lower Python code
inputValue
script_start_tag
<ScRiPt >
tag=|textwithin=
content
BeasutifulSoup
In classxss.inc, awvs uses many types of payloads. I have filtered the test * function in it. For what I want to know about a function, I can refer to it further
classXSS.inc
test*
In particular, serversidetemplateinjection is a function of server template injection. In Python or JSP, the function is not only XSS. In awvs, the payload for testing SSTI is: VAR inputvalue = "{" + num1 + "*" + num2 + "}}"; at the same time, the value of num1 * num2 is detected in the returned body, This can also be a successful test in the future. For more information, please refer to burpsutie's official blog introduction: server side template injection to unlock more postures
ServerSideTemplateInjection
XSS
var inputValue = "{{" + num1 + "*" + num2 + "}}";
num1*num2
burpsutie
Therefore, there is a direct understanding of how awvs detects reflection XSS:
- Extract parameters,
Extract parameters,
- Traverse the parameters and append different types of payloads,
Traverse the parameters and append different types of payloads,
- Determine the content type returned
Determine the content type returned
Content-Type
- Use the thtmlquery class to search whether the corresponding payload generates the corresponding tag and content
Use the thtmlquery class to search whether the corresponding payload generates the corresponding tag and content
THTMLQuery
- Return to alert Report
Return to alert Report
But it's too tired to write a function for each type of payload. If you want to use it simply, you can try the following two postures:
- Establish a dict, the original code of each payload is the key, its different variants are the value, use the value as the payload request, and detect the key in the returned response, which is simple and crude
Establish a dict, the original code of each payload is the key, its different variants are the value, use the value as the payload request, and detect the key in the returned response, which is simple and crude
dict
key
value
key
- Use casperjs, a headless browser, to load the returned response content and check whether there is alert's own randstr
Use casperjs, a headless browser, to load the returned response content and check whether there is alert's own randstr
casperjs
2.3 classSqlInjection.inc
In classsqlinjection.inc, the most common error reporting injection is detected. Similarly, the entry function is starttest, and then different types of detection and verification are performed. The following code can be seen:
classSqlInjection.inc
startTest
First of all, test for error is used to detect whether there is any error message in the original request. If there is, the next parameter is detected. Otherwise, different payloads are used to detect the error injection respectively. Note that the second parameter is needed to repeat the verification only when using payload: 1 '"
testForError
1'"
Next, take a look at the testeinjection function. Its flow is as follows:
- Check whether there is a matching ErrorMessage in the return value, if not, continue
Check whether there is a matching ErrorMessage in the return value, if not, continue
- If it exists and has confirm value, that is, the second parameter of the function, use MySQL and MSSQL error statements to retest
If it exists and has confirm value, that is, the second parameter of the function, use MySQL and MSSQL error statements to retest
From the above part of the code, we can see that for MySQL and MSSQL, different string connectors are used to connect characters in the form of char (), | + and then error reporting statements in MySQL are used respectively: 'and (select 1 from (select count (*), concat (' + markerencodedmysql + ') from information_schema. Tables limit 0,1), Floor (rand (0 * 2)) x from information ﹣ schema. Tables group by x) a) and ', and then add characters to check whether the response contains the value of markerplain. For payloads other than 1', you only need to check whether the response contains SQL error statements
CHAR(),|+
'and(select 1 from(select count(*),concat((select concat(' + markerEncodedMYSQL + ') from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)and'
markerPlain
1'"
2.4. Request page server Forgery.script
Server_Side_Request_Forgery.script
Similarly, we need to use dnslog from the start test function. Of course, there are also paid cloudeye or free ceye. However, awvs is not the same because it is not only a dnslog platform, but also a site of its own, bxss.me, by requesting its secondary domain name, Use the interface http://bxss.s3.amazon aws.com/hits/ {secondary domain name} to verify whether you have visited the secondary domain name. Of course, if you don't want to build another dnslog and use the responsible and free platform, you can also use this directly
startTest
http://bxss.s3.amazonaws.com/hits/{二级域名}
In server ﹣ side ﹣ request ﹣ forge.script, first, send the request by using a "http: / / hit" + rndtoken + '. Bxss. Me /' random secondary domain name as a payload to replace the original parameter value. There is no specific understanding of the parameters of thttpjob here. Here, we can only guess that in the verification of SSRF, it should not be allowed to jump, Otherwise, it can't be accurately judged whether to jump to the secondary domain name or to the server. In addition, when analyzing the plug-in, we found that it's not only so simple, in other words, the plug-in is not simple
Server_Side_Request_Forgery.script
"http://hit" + rndToken + '.bxss.me/'
THTTPJob
SSRF
It not only contains the detection of SSRF, but also detects a wave of xxE problems and File Protocol redirection problems along the way
SSRF
In the random secondary domain name we mentioned in the above paragraph, if we visit the secondary domain name`
'http: / / hit' + {rndtoken} + '. Bxss. Me /' '. This URL will return an XML format similar to the following
In the XML return value above, we can see such a paragraph
It is believed that all cousins who have known about the xxE vulnerability should know that this is a payload of xxE. Therefore, in the script server side request forgery.script, we have also detected whether there is a xxE vulnerability. At the same time, for code analysis, there is also a URL as follows: http://bxss.me/redirtofile, for request, we can see the following return
Server_Side_Request_Forgery.script
http://bxss.me/redirToFile
Its location points to file: / / / etc / passwd. It can detect a file redirection conveniently. This gesture is really OK
file:///etc/passwd
In addition, it is found in this script that the URL 'http://bxss.me/xslt? T =' + rndtoken 'is a kind of use of the markup language, but the content of this block is not familiar, so it is not analyzed here
'http://bxss.me/xslt?t=' + rndToken
These three scripts don't seem to be complicated, but in the process of analysis, there are still many class implementation mechanisms that are not well understood, such as tURL, thttpjob, thtmlquery, etc., but precisely because of this lack of understanding, this analysis can also promote the preparation of their own tools, such as trying to implement a class to simulate the implementation mechanism of one class, to realize the relevant interfaces of classes in awvs, Besides analyzing these plug-ins, you can also start your own plug-in transformation plan. According to the classification of awvs, plug-ins can be divided into several parts. Different folders such as port and schedule correspond to different plug-ins. More importantly, the analysis of awvs plug-ins can improve your confidence in writing plug-ins... Because at first glance, it is not too difficult to plug-ins (orz)
PORT
SCHEME
The next chapter will analyze the blind note of awvs, to be continued
- [a simple analysis of awvs] (http://blog.wils0n.cn/archives/145/)
[a simple analysis of awvs] (http://blog.wils0n.cn/archives/145/)
- [write your own Acunetix WVS vulnerability Script] (http://drops.xmd5.com/static/drops/tips-2498. HTML)
[write your own Acunetix WVS vulnerability Script] (http://drops.xmd5.com/static/drops/tips-2498. HTML)
- [awvs decryption script PWD: jntw] (https://pan.baidu.com/s/1wst3c8ay9k2ltyhirundo)
[awvs decryption script PWD: jntw] (https://pan.baidu.com/s/1wst3c8ay9k2ltyhirundo)