Foreword
This is the first article in the Pikachu vulnerability shooting range series~~ (it should be serialized)~~. First, let’s briefly introduce the Pikachu shooting range. This shooting range was developed by Chinese people and is purely in Chinese. If you encounter difficulties during practice, you can check the tips. There are also supporting learning videos. Under Windows, it can be installed directly in integrated environments such as Wamp
/phpStudy
. In contrast, DVWA, which is recommended by many people, is very unfriendly to newcomers due to its pure English environment. They may not know where to start after deployment, and it is easy to persuade them to quit. Therefore, the Pikachu recommended here is more suitable for friends who are just getting started with Web penetration and are looking for a shooting range.
Overview
Never before have hackers been as keen on guessing passwords as they are today – Ostrovsky
“Brute force cracking” is an attack method. In web attacks, this method is generally used to obtain the authentication information of the application system. The process is to use a large amount of authentication information to try to log in on the authentication interface until the correct result is obtained. In order to improve efficiency, brute force cracking generally uses tools with dictionaries to automate operations.
Theoretically, most systems can be cracked by brute force, as long as the attacker has enough computing power and time, so the conditions for determining whether a system has a brute force cracking vulnerability are not absolute. When we say that a web application system has a brute-force cracking vulnerability, it generally means that the web application system does not adopt or adopts a relatively weak authentication security strategy, resulting in a relatively high “possibility” of being brute-force cracked. The authentication security policy here includes:
- Whether to require users to set complex passwords;
- Whether to use a secure verification code for each authentication (think of the verification code you lost when buying a train ticket~) or mobile phone OTP;
- Whether to judge and restrict attempts to log in (such as five consecutive incorrect logins, account locking or IP address locking, etc.);
- Whether two-factor authentication is used;
Don’t underestimate brute force cracking vulnerabilities, often the effects of this simple and crude attack method are beyond expectations!
Preliminary preparation
- Packet capture tool:
Burp Suite
- Browser proxy plug-in:
SwitchOmega
orFoxyProxy
- Dictionary:
users.txt
andpwd.txt
. Since it is an experimental environment, you can fill in the dictionary as you like. Note that it needs to contain any set of correct account passwords:admin/123456
,pikachu/000000
,test/abc123
# users.txt test root admin #pwd.txt 88888888 password 123456
copy
Form-based brute force cracking
There is no verification code here, just capture the packet and blast it.
- Fill in the form and submit it, use Burp to capture the data packet, and send the data packet to the
Intruder
module - Select
Clusterbomb
for the blast type, clear redundant variables, and only select the account password. - Select
Runtime file
for the Payload type, and select the corresponding dictionary below to start the attack.
Verification code bypass (on server)
After filling in the form and the correct verification code, submit and capture the packet, and send the data packet to the Repeater
module. After sending the packet multiple times, it is found that only username or password is not exists
is prompted instead of It prompts that there is an error in the verification code and learns that the verification code can be reused. So you only need to manually fill in the correct verification code to blast
- To fill in the form manually, you need to enter the correct verification code. The account and password can be arbitrary.
- Capture packets, set variables and
Payload
, and start the attack
Verification code bypass (on client)
The verification code here is only verified locally. Just enter the correct verification code manually and capture the packet as above.
Token explosion-proof
token
is a string of characters generated by the server, which serves as an identifier for the client to request from the server. The front-end uses the username/password to send a request for authentication to the server. If the server-side authentication is successful, the server will return the token to the front-end. The front-end will bring the token sent by the server with each request to prove its legitimacy. .
This level is a little more difficult than the previous one
- The previous steps are similar to the previous ones. First, manually fill in the form, submit and capture the packet, and then send it to the
Intruder
module. - Set variables. In order to reduce the number of attacks, you can change the account to
admin
, set only the password andtoken
as variables, and selectPitchfork
for the attack type, because every The password andtoken
need to be replaced at the same time and cannot be used in combination.
- Set macro definition. Click the
option
option, scroll down to find theGrep Extract
column, clickAdd
, and clickRefetch response
in the pop-up window to send Complete the package once and obtain the returned data. Entertoken
in the input field below to find the returnedtoken
value.
- Select the
token
value and copy it, and click OK when selected. Then set the number of threads to1
, and in the bottomRedirections
redirection column, selectAlways
- Finally, set
Payload
. For the firstPayload
, just select the corresponding dictionary as before. For the second variable,token
, selectRecursive grep
to search recursively, and finally paste thetoken
value copied earlier into the text box below.
- Finally, start the attack and judge whether the explosion is successful based on the return length.
Summary
Burp blast type
Brute force cracking generally uses the Intruder module in BurpSuite. This module can customize parameters in the form of variables for the HTTP Request data packet, and then automatically replay according to the corresponding policy.
Sniper
: Only one Payload is set, and each variable is tested using the Payload in turn. Assume that two variables are set, first use the Payload to test the first variable, and then test the second variable using the Payload after all tests are completed.
username=user & amp;password=222 & amp;submit=Login username=root &password=222&submit=Login username=admin & amp;password=222 & amp;submit=Login username=111 &password=user &submit=Login username=111 &password=root &submit=Login username=111 & amp;password=admin & amp;submit=Login
copy
Battering ram
: Set only one Payload, all variables are replaced by Payload at the same time, and then try together
username=user & amp;password=user & amp;submit=Login username=root &password=root&submit=Login username=admin & amp;password=admin & amp;submit=Login
copy
Pickfork
: Set a Payload for each variable, and use the Payload to replace the variables at the same time.
username=user & amp;password=111111 & amp;submit=Login username=root &password=888888 &submit=Login username=admin & amp;password=123456 & amp;submit=Login
copy
Clusterbomb
: Set a Payload for each variable, and use the Payload combination to replace the variables.
username=user & amp;password=111111 & amp;submit=Login username=root &password=111111 &submit=Login username=admin & amp;password=111111 & amp;submit=Login username=user &password=888888 &submit=Login username=root &password=888888 &submit=Login username=admin & amp;password=888888 & amp;submit=Login username=user &password=123456 &submit=Login username=root &password=123456 &submit=Login username=admin & amp;password=123456 & amp;submit=Login
copy
Verification code bypass
- Verification code authentication process
- Client Request login page, verification code generated in the background
- The background uses an algorithm to generate pictures and responds to the client.
- At the same time, the values generated by the algorithm are globally copied to the Session.
- Verify verification code
- The client submits the authentication information and verification code together
- The background compares the submitted verification code with the value in the Session
- The client refreshes the page and generates the verification code again
- The verification code algorithm generally contains a random function, which will change every time it is refreshed.
- Client Request login page, verification code generated in the background
- Client Authentication FAQ
- Use front-end JS to implement verification code. If there is no secondary verification in the background, you can directly change the package in Burp to bypass it.
- The verification code is stored in Cookie. can be obtained
- The verification code is stored in the front-end source code. can be obtained
- Server-side verification FAQ
- The verification code does not expire in the background. Can be reused and should be used once
- The verification code is designed to be too simple and regular, making it easy to guess.
- The verification code is not strict and there is a problem with the logic.
About explosion prevention
- Designing secure verification codes: Secure process + complex and usable graphics
- Count submissions of authentication errors and give limits, such as locking the IP for a certain period of time if the password is incorrect five times
- Use two-factor authentication when necessary
Not expired. Can be reused and should be used once- The verification code is designed to be too simple and regular, making it easy to guess.
- The verification code is not strict and there is a problem with the logic.
About explosion prevention
- Designing secure verification codes: Secure process + complex and usable graphics
- Count submissions of authentication errors and give limits, such as locking the IP for a certain period of time if the password is incorrect five times
- Use two-factor authentication when necessary
- Token explosion prevention: The general approach is to output the token in the form in the form of
type="hidden"
, submit it together when submitting for authentication, and verify it in the background. However, since the token value is output in the front-end source code and is easy to obtain, it loses the meaning of preventing brute force cracking.