pikachu shooting range experiment operation

---

foreword

Pikachu is a web application system with vulnerabilities, which contains various common web security vulnerabilities. Due to various practical factors, it is not practical to conduct penetration testing on the public network, so we can conduct targeted exercises at the pikachu shooting range (vulnerability practice platform).

The list of vulnerability types on Pikachu is as follows:

• Burt Force (brute force cracking vulnerability)
• XSS (Cross Site Scripting Vulnerability)
• CSRF (Cross Site Request Forgery)
• SQL-Inject (SQL injection vulnerability)
• RCE (Remote Command/Code Execution)
• Files Inclusion (files contain vulnerabilities)
• Unsafe file downloads (unsafe file downloads)
• Unsafe file uploads (unsafe file uploads)
• Over Permission (Over Permission Vulnerability)
• .../.../.../ (directory traversal)
• I can see your ABC (disclosure of sensitive information)
• PHP deserialization vulnerability
• XXE(XML External Entity attack)
• Insecure URL redirection
• SSRF(Server-Side Request Forgery)

---

1. Brute force cracking

1. Based on simple brute force cracking

• Use bp to open the packet capture state

• Log in to the experimental platform http://127.0.0.1/pikachu

• Return to bp, you can see the username and password you just entered
• Then click Action, continue to click to the attacker

• Click on the intruder to enter the intruder
• Switch attack type to cluster bomb

• First clear all variables
• Find the username (user name), double-click the value behind, and click Add to add
• Then find the password and add the same operation

• Switch to payloads
  to set the payload Payloads, and start the attack.

payload set 1:
load a dictionary of usernames

payload set 2:
dictionary to load passwords

• start attacking

  Click start attack

• Click Length to sort by length.
  admin 123456
  and test abc123 have been guessed

No other attempts here

• Return to the login interface, enter the password
  login success login success
  

---

2. Captcha bypass (on server)

• first try to log in
• An error is raised here, indicating that the verification code is still valid

• Turn on bp interception, enter the wrong account password, correct severity code, and check whether the information has been sent
• You can see that this vcode has been verified in the background
• Then send it to the Repeater, and let it go

• Go back to the login interface to refresh a verification code
• Click Repeater to change the refreshed verification code to vcode
• Run send multiple times to see that the same verification code is being used repeatedly, and then blast it

• The content of Raw is copied to Positions, and the same operation can be blasted.

---

2. Captcha bypass (on client)

1. on client local authentication
2. The verification code is an input box
   , open the bp to intercept it,
   send the click Action to the Response, and then let it go
   

Switch to Repeater

• Change the wrong verification code after vcode or do not change it
• If you run Red many times, you can see that it only prompts that the user password is wrong.
• So this vcode is not verified at the front end at all

You can continue blasting in the same way as before.

---

3. Token explosion-proof?

• The same operation, just enter the account password, np intercept

• send to intruder, then loose
• switch to intruder

• use a harpoon
• Add user, password and token

• Payloads set 1
• Payloads set 2
• load dictionary
• Same as before

• Payloads set 3

Find token

back to payload set 3

Run the crack
or sort by Length to get the account password

So far the test is over

Summarize

Theoretically speaking, most systems can be cracked by brute force, as long as the attacker has enough computing power and time, so it is not absolute to determine whether a system has a brute force cracking vulnerability. 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 policy, resulting in a higher "possibility" of its being cracked by violence. The authentication security policy here,