GBounty Profiles Designer
Last updated
Last updated
GBounty Profiles Designer gives you the ability to create your own vulnerability profiles through a easy graphical interface. With this tool you will be able to create new vulnerability profiles in a simple and fast way, which will allow you to integrate new web vulnerabilities into your tests in a few seconds.
It has a unique customization capacity, with new insertion points and new search types. Through the design of passive and active vulnerability profiles, you will be able to carry out a complete review of the web application.
Step 1 (Required): The name and author of the profile are first set.
Step 2 (Required): Here you can choose the request type:
Original Request: The extension get the original request that is sended to the scanner, extract insertion points, put the payloads in the selected insertion points, makes the necessary modifications and sends it to the server.
Raw Request: You specify a new request, inheriting fields from the original request.
Step 2.1 (Required)- Original Request -> Payloads: It sets the payload or payloads that will be sent in the selected request insertion points.
You can add the Payload by click on the “add” button and modifying the value, or by pasting it directly with the “Paste” button if you already have it in the clipboard.
You can also load a payloads file (one per line) with the “Load file” button.
Step 2.2 (Required)- Original Request -> Payload Position:
The Payload position field is to specify where each of the payloads defined in the profiles will be established. For example in a request:
Suppose that we have specified the Insertion point type is Param url value (123456). If we have the ‘-alert(1)-‘ as a payload, the Payload position can be the following:
Replace: the original value is replaced.
Append: The value of the payload is added to the original value.
Insert: The value of the payload is inserted in the middle of the original value.
Step 2.4 (Required)- Original Request -> Insertion Point Type:
Here you can select the insertion points where you want the payloads to be sent.
The insertion points are the zones of the HTTP request where the specified payload will be placed. For example in this HTTP request:
If the payload <script>alert (1)</script> is specified and the insertion point “Param body value” is selected, the HTTP requests that GBounty will make will be:
Change “test” value for the payload:
Change “go” value, for the payload:
Below you can see in detail each insertion point type.
Param body value.
Param body name.
Param URL value.
Param URL name.
Entire body.
User provided: Defined by the user in the Intruder tab.
Cookie value.
Cookie name.
Param json value.
Param json name.
Entire body json.
Param XML value.
Param XML name.
Param XML attr value.
Param XML attr name.
Param multipart attr value.
Param multipart attr name.
Multiple Path discovery: These insertions point type are added to the requests to discover hidden files and directories:
GET /dir1/dir2/file.php?param=value HTTP/1.1
Generate three new Insertion points:
1- GET {HERE} HTTP/1.1 2- GET /dir1{HERE} HTTP/1.1 3- GET /dir1/dir2{HERE} HTTP/1.1
Then, if you put in payload /.git/HEAD, the three new request are:
1- GET /.git/HEAD HTTP/1.1 2- GET /dir1/.git/HEAD HTTP/1.1 3- GET /dir1/dir2/.git/HEAD HTTP/1.1
without param=value.
Multiple Path discovery 1.
Multiple Path discovery 2.
Multiple Path discovery 3.
Single Path discovery.
Url path folder.
Url path filename.
Entire body xml.
Entire body multipart.
HTTP Headers: Host
HTTP Headers: User agent
HTTP Headers: Accept
HTTP Headers: Accept Language
HTTP Headers: Accept Encoding
HTTP Headers: Content Type
HTTP Headers: Origin
HTTP Headers: Referer
New HTTP Headers: X-Forwarded-For (or whichever that you specify)
Step 2.5 (Optional)- Original Request -> Match and Replace:
In this section you can replace values in the payload/request or you can insert new fields in the HTTP request.
Step 2.6 (Optional)- Original Request -> Payload encoding:
In this section you can use one or more encodings that will be applied to the payloads before being sent in the HTTP request. You can choose between:
URL-encode key characters
URL-encode all characters
URL-encode all characters (Unicode)
HTML-encode key characters
HTML-encode all characters
Base64-encode
In this section, you can also encode in “URL encode” only the payload characters that you choose:
Step 3 (Required if you choose raw request option)- Raw Request:
You have the possibility of sending Raw requests inheriting attributes of the request that is being scanned.
This means that when a HTTP request or domain is scanned, this custom RAW Request will be sent to the system that you are attacking.
You can insert these attributes wherever you want in the Raw Request. The available attributes are:
Step 4 (Required)- Response->Match Type: In this section we must specify how we will look for the pattern in the HTTP response.
Simple string: Search for a simple string in the HTTP Response that you specify in the “Grep” section.
Regex: Search for a regular expression in the HTTP Response that you specify in the “Grep” section.
Payload: Search for a Payload (that have been specified in the Original Request->Payloads section) in the HTTP response.
Payload encode: If you have encoded the payload with the original request functionalities, here you look for the value of the payload before it’s encoded, in the HTTP response. In this case you look for “Payload 1…Payload N” in the HTTP Response.
Invariations: This option looks for the NO difference in the attributes marked in the “Attributes” section between the response of the original HTTP request and the responses of the HTTP requests modified with the payloads.
Variations: This option looks for the difference in the attributes marked in the “Attributes” section between the response of the original HTTP request and the responses of the requests modified with the payloads.
Content length difference: This option finds the difference between the content length (in bytes) of the response of the original HTTP request and the responses of the requests modified with the payloads.
HTTP Response codes: This option looks for the HTTP response codes. The following example will search for:
HTTP 200 OK
HTTP 403 Forbidden
HTTP 302 Found
Timeout between: This option searches in the HTTP responses for a time delay in seconds in a range that can be specified. The following example looks for a HTTP response to take between 15 seconds and 25 seconds to respond.
Step 5 (Required if you choose Simple string or Regex match type)- Response->Grep: In this section we must specify what we will look for in the HTTP response.
Simple String: What “Simple string” we will look for in the response. In this case we will look for three simple strings, “Simple String searched in the response 1”, “Simple String searched in the response 2”, “Simple String searched in the response N”.
Regex: What regular expression we will look for in the response. In this case we will look for three regular expressions, “Regular expression searched in the response 1”, “Regular expression searched in the response 2”, “Regular expression searched in the response N”.
Step 6 (Optional)- Response->Grep Options: In this section you can specify more options to create more accurate profiles and obtain fewer false positives. This options only are disponible for the Match types:
Simple string
Regex
Payload
Payload Encode
Each of the options will be detailed below:
Negative match: It will show you the alert, if the pattern you have set is not present in the HTTP response.
Case sensitive: The pattern will be searched in the HTTP response considering that it’s case sensitive.
Exclude HTTP headers: The pattern will NOT be searched in the HTTP headers. (Only in the body of the HTTP response)
Only in HTTP header: The pattern will ONLY be searched in the HTTP headers.
Content type: The pattern will only be searched in the HTTP response if the content type of the HTTP response is equal to the “content type” field. You can specify multiple content types separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the content type is NOT equal to this field, marking the “negative match” checkbox.
Status code: The pattern will only be searched in the HTTP response if the Status code of the HTTP response is equal to the “status code” field. You can specify multiple status code separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the status code is NOT equal to this field, marking the “negative match” checkbox.
URL Extension: It will only search for patterns if the extension of the URL to which the request is made, matches the extension or extensions specified in this field (for example, php or jsp, etc) or if it doesn’t match (negative match checkbox)
Step 7 (Optional)- Response->Redirections: In this section you can specify the redirection options. This options only are disponible for the Match types:
Simple string
Regex
Payload
Payload Encode
Each of the options will be detailed below:
Never: As the name suggests, no redirect will be followed.
On-site only: It will only follow the redirects that lead to the same site of origin.
In-scope only: It will only follow redirects that lead to a domain that is in scope.
Always: As the name suggests, it will follow all redirects.
Max redirections: In this field the maximum number of redirects that will follow is indicated.
Step 8 (Required)- Issue: It specifies the name that will appear in the alert and the criticality of that alert.
It’s necessary for the issue to appear, give it a “Issue Name” and complete the two fields, both the “severity” and the “confidence”. The issue descriptions are optional.
If you check the option “Don’t show this issue alert” the alert will not be shown in the dashboard, it will only be used for the Smart Scan.
Step 9 (Optional): A tag is created and assigned to the profile. These tags can be used to launch the “Scan Tags” scanner.
GBounty Profiles Designer gives you the ability to create your own vulnerability profiles to the passive scanner.
Passive Request Scanner: Look for strings/regex (or the absence of them) in HTTP requests.
Next let’s see how passive request profiles are created to look for something (or the absence of it) in the HTTP request.
Step 1 (Required): The name and author of the profile are first set.
Step 2 (Required): Specifies the pattern or patterns to search in the request.
You can add the pattern by click on the “add” button and modifying the value, or by pasting it directly with the “Paste” button if you already have it in the clipboard.
You can also load a patterns file (one per line) with the “Load file” button.
In this section you can choose in which insertion point you want to search for the pattern.
At the same time, the logical AND operator can be used when searching for a value. This allows us to further refine the profile and avoid false positives.
Step 4 (Required): Specifies which type of pattern to search in the insertion point.
Simple string
Regular expression
In this section you specify, if in the insertion point you want to search for a simple string or a regular expression.
Step 5 (Optional): Grep options are specified.
Negative match: It will show you the alert, if the pattern you have set is not present in the insertion point that you have chosen.
Case sensitive: The pattern will be searched in the insertion point considering that it’s case sensitive.
URL Extension: It will only search for patterns if the extension of the URL to which the request is made, matches the extension or extensions specified in this field (for example, php or jsp, etc) or if it doesn’t match (negative match checkbox)
Step 6 (Required): It specifies the name that will appear in the alert and the criticality of that alert.
It’s necessary for the issue to appear, give it a “Issue Name” and complete the two fields, both the “severity” and the “confidence”. The issue descriptions are optional.
Step 7 (Optional): A tag is created and assigned to the profile. This is useful for better organization of profiles.
GBounty Profiles Designer gives you the ability to create your own vulnerability profiles to the passive scanner.
Passive Response Scanner: Look for strings/regex (or the absence of them) in HTTP response
Next let’s see how passive response profiles are created to look for something (or the absence of it) in the HTTP response.
Step 1 (Required): The name and author of the profile are first set.
Step 2 (Required): It specifies the pattern or patterns to look for in the HTTP response.
You can add the pattern by click on the “add” button and modifying the value, or by pasting it directly with the “Paste” button if you already have it in the clipboard.
You can also load a patterns file (one per line) with the “Load file” button.
At the same time, the logical AND operator can be used when searching for a value. This allows us to further refine the profile and avoid false positives.
Step 3 (Required): Specifies which type of pattern to search in the response.
Simple string
Regular expression
In this section you specify, if in the insertion point you want to search for a simple string or a regular expression.
Step 4 (Optional): Specify how many times this issue will be displayed for one domain.
Only once per domain: Only once time for all HTTP responses in one domain.
All times in a domain: Every time that the pattern is detected in the domain HTTP responses.
Step 5 (Optional): Grep options are specified.
Negative match: It will show you the alert, if the pattern you have set is not present in the HTTP response.
Case sensitive: The pattern will be searched in the HTTP response considering that it’s case sensitive.
Exclude HTTP headers: The pattern will NOT be searched in the HTTP headers. (Only in the body of the HTTP response)
Only in HTTP header: The pattern will ONLY be searched in the HTTP headers.
Content type: The pattern will only be searched in the HTTP response if the content type of the HTTP response is equal to the “content type” field. You can specify multiple content types separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the content type is NOT equal to this field, marking the “negative match” checkbox.
Status code: The pattern will only be searched in the HTTP response if the Status code of the HTTP response is equal to the “status code” field. You can specify multiple status code separated by commas. You can also specify that ONLY look for the pattern in the HTTP response if the status code is NOT equal to this field, marking the “negative match” checkbox.
URL Extension: It will only search for patterns if the extension of the URL to which the request is made, matches the extension or extensions specified in this field (for example, php or jsp, etc) or if it doesn’t match (negative match checkbox)
Step 6 (Optional): Redirection options are specified. You can choose between the following options:
Never: As the name suggests, no redirect will be followed.
On-site only: It will only follow the redirects that lead to the same site of origin.
In-scope only: It will only follow redirects that lead to a domain that is in scope.
Always: As the name suggests, it will follow all redirects.
Max redirections: In this field the maximum number of redirects that will follow is indicated.
Step 7 (Required): It specifies the name that will appear in the alert and the criticality of that alert.
It’s necessary for the issue to appear, give it a “Issue Name” and complete the two fields, both the “severity” and the “confidence”. The issue descriptions are optional.
If you check the option “Don’t show this issue alert” the alert will not be shown in the dashboard, it will only be used for the Smart Scan.
Step 8 (Optional): A tag is created and assigned to the profile. This is useful for better organization of profiles.
