Hacking Book | Free Online Hacking Learning

 Home

from awvs plug-in to pseudo proxy scanning

Posted by truschel at 2020-03-03
all

0x00 Preface

0x01 introduction to awvs plug in

0x02 introduction to analyzed plug-ins

2.1 plug in process

2.2 classXSS

2.3 classSqlInjection.inc

2.4 Server_Side_Request_Forgery.script

0x03 summary

0x04 reference

Author: 71src

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;

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

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

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 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

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

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

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;

WebApps joomla drupal wordpress

This paper analyzes the implementation ideas of the following plug-ins

Blind_Sql_Injection.script

classSqlInjection.inc

classCRLFInjection.inc

ClassXSS.inc

Code_Execute.script

XXE_Folder.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,

Traverse the parameters and append different types of payloads,

Determine the content type returned

Content-Type

Use the thtmlquery class to search whether the corresponding payload generates the corresponding tag and content

THTMLQuery

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

dict key value key

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

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/)

[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)

© 2022