Pikachu vulnerability range series brute force cracking

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:

  1. Whether to require users to set complex passwords;
  2. 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;
  3. Whether to judge and restrict attempts to log in (such as five consecutive incorrect logins, account locking or IP address locking, etc.);
  4. 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 or FoxyProxy
  • Dictionary: users.txt and pwd.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.

img

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 and token as variables, and select Pitchfork for the attack type, because every The password and token need to be replaced at the same time and cannot be used in combination.

img

  • Set macro definition. Click the option option, scroll down to find the Grep Extract column, click Add, and click Refetch response in the pop-up window to send Complete the package once and obtain the returned data. Enter token in the input field below to find the returned token value.

img

  • Select the token value and copy it, and click OK when selected. Then set the number of threads to 1, and in the bottom Redirections redirection column, select Always

img

img

  • Finally, set Payload. For the first Payload, just select the corresponding dictionary as before. For the second variable, token, select Recursive grep to search recursively, and finally paste the token value copied earlier into the text box below.

img

  • Finally, start the attack and judge whether the explosion is successful based on the return length.

img

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