Evasion & Chaining
Evasion
Evasion Techniques
Often times security controls like web applications firewalls (WAFs) and rate-limiting can block your attacks. These can be triggered by a wide variety of things, like:
Too many requests for resources that do not exist.
Too many requests within a certain amount of time
Common attack attempts, like SQL injection and XSS attacks
Abnormal behavior, like tests for authorization vulnerabilities
Below are some techniques that can help bypassing these controls.
String Terminators
# Payloads
%00
0x00
//
;
%
!
?
[]
%5B%5D
%09
%0a
%0b
%0c
%0e# Example POST request
POST /api/v1/user/profile/update
[…]
{
“uname”: “hapihacker”
“pass”: "%00'OR 1=1"
}Case Switching
# Example POST request
POST /api/myprofile
[…]
{uid=§0001§} An API may leverage rate-limiting to only allow 100 requests per minute. Based on the length of the uid value, you know that to brute force it you’ll need to send 10,000 requests to exhaust all possibilities. To bypass rate-limiting or other WAF controls you may be able to simply alter the URL path by switching upper- and lower-case letters in the path:
POST /api/myProfile
POST /api/MyProfile
POST /aPi/MypRoFiLe
Each of these path iterations could cause the API provider to handle the request differently, potentially bypassing the rate limit. In some cases, a control like rate-limiting may disappear completely with a different spelling or the new spelling may have its own renewed rate limit. In the case where rate-limiting is renewed, you could use the BurpSuite Pitchfork attack to pair a certain number of attacks to a certain number of brute-force attempts. For example:
POST /api/myprofile paired with uid 001 - 100
POST /api/Myprofile paired with uid 101 - 200
POST /api/mYprofile paired with uid 201 - 300
If you were using Burp Suite’s Intruder for this attack, you could set the Attack Type to Pitchfork and use the same value for both payload positions. This tactic allows you to use the smallest number of requests required to brute force the uid.
Encoding (or double-encoding)
Encoded payloads can often trick WAFs while still being processed by the target application or database. Even if the WAF or an input-validation measure blocks certain characters or strings, they might miss encoded versions of those characters. Alternatively, you could also try double encoding your attacks.
Burp Payload Processing
All the above options can be applied automatically on Burp.
Each rule will be applied in order, so the payload order matters.
Wfuzz
# List encoders
$ wfuzz -e encoders
Available encoders:
Category | Name | Summary
------------------------------------------------------------------------------------------------------------------------
hashes | base64 | Encodes the given string using base64
url | doble_nibble_hex | Replaces ALL characters in string using the %%dd%dd escape
url_safe, url | double_urlencode | Applies a double encode to special characters in string using the %25xx escape.
| | Letters, digits, and the characters '_.-' are never quoted.
url | first_nibble_hex | Replaces ALL characters in string using the %%dd? escape
default | hexlify | Every byte of data is converted into the corresponding 2-digit hex representatio
| | n.
html | html_decimal | Replaces ALL characters in string using the &#dd; escape
html | html_escape | Convert the characters &<>" in string to HTML-safe sequences.
html | html_hexadecimal | Replaces ALL characters in string using the &#xx; escape
hashes | md5 | Applies a md5 hash to the given string
db | mssql_char | Converts ALL characters to MsSQL's char(xx)
db | mysql_char | Converts ALL characters to MySQL's char(xx)
default | none | Returns string without changes
db | oracle_char | Converts ALL characters to Oracle's chr(xx)
default | random_upper | Replaces random characters in string with its capitals letters
url | second_nibble_hex | Replaces ALL characters in string using the %?%dd escape
hashes | sha1 | Applies a sha1 hash to the given string
hashes | sha256 | Applies a sha256 hash to the given string
hashes | sha512 | Applies a sha512 hash to the given string
url | uri_double_hex | Encodes ALL charachers using the %25xx escape.
url | uri_hex | Encodes ALL charachers using the %xx escape.
url | uri_triple_hex | Encodes ALL charachers using the %25%xx%xx escape.
url | uri_unicode | Replaces ALL characters in string using the %u00xx escape
url_safe, url | urlencode | Replace special characters in string using the %xx escape. Letters, digits, and
| | the characters '_.-' are never quoted.
url | utf8 | Replaces ALL characters in string using the \u00xx escape
url | utf8_binary | Replaces ALL characters in string using the \uxx escape# Encoding a payload
wfuzz -z file,wordlist/api/common.txt,base64 http://hapihacker.com/FUZZ
# Using multiple encoders separately (1 encoding scheme per request)
wfuzz -z file,wordlist/api/common.txt,base64-md5-none http://hapihacker.com/FUZZ
# Using multiple encoders at the same time (2 encoding schemes per request)
wfuzz -z file,wordlist/api/common.txt,base64@md5 http://hapihacker.com/FUZZVulnerabilities Chaining
Excessive Data Exposure and Improper Assets Management are both API weaknesses that stand out above the others to combine in order to escalate the impact of your attacks.
Excessive data exposure can be a great source of information about users and administrators. Make sure that you take note of all parameters leaked in exposure as they can be leveraged in authentication and authorization attacks.
Improper Assets Management implies that a version of the API may not be as supported as the current version and thus it may not be as protected. Perform all of the other attacks against the unmanaged endpoint.
If you are testing a file upload function, attempt to use the directory traversal fuzzing attack along with the file upload to manipulate where the file is stored. Upload files that lead to a shell and attempt to execute the uploaded file with the corresponding web application.
Perhaps you have discovered a BFLA or Mass Assignment weakness that has given you access to administrative functionality. You could then use this new level of access to search for Improper Assets Management, injection weaknesses, or BOLA flaws.
If you are able to perform a mass assignment, then there is a chance that the parameter or parameters that you can alter may not be protected from injection attacks and/or SSRF. When you have discovered mass assignment fuzz the parameter for other weaknesses.
If you are able to update to perform a BFLA attack and update another user’s profile information perhaps you could combine this with an XSS attack.
Combine Injection attacks with most other vulnerabilities. For example, if you are able to manipulate a JSON Web Token. Consider including various different types of injection attacks into the JSON Web Token.
Consider ways to fully leverage BOLA findings. Use the information that you are able to access to gain access elsewhere. Always test to see if your BOLA discovery can be used in a BFLA attack. In other words, if you find a BOLA vulnerability that provides you with other users’ bank account information check to see if you are also able to exploit a BFLA vulnerability to transfer funds.
If you are up against API security controls like a WAF or rate-limiting, make sure to apply evasion techniques to your attacks. Encode your attacks and attempt to find ways to bypass these security measures. If you have exhausted your testing efforts, return to fuzzing wide with encoded and obfuscated attacks.
Last updated