No Password Attack required for Microsoft SQL Server

No Password Attack required for Microsoft SQL Server

In a recent penetration test, some unencrypted Microsoft SQL Server (MSSQL) traffic was found in some of the packets we captured. At first, we thought that we could sniff the authentication credential directly. However, MSSQL encrypts the authentication traffic, which means that we need to decrypt it before obtaining the authentication credential. If a self-signed certificate is installed, it is easy to crack.

Unfortunately, cracking MSSQL encryption is not within the scope of authorization, so we have to put aside our curiosity to complete penetration testing for our customers. However, because I always think about one thing that cannot continue to work normally, can we attack SQL Server without user creden? We started the experiment with questions.

In the end, we found that man-in-the-middle attacks can be used to directly control Microsoft SQL Server without user creden.

Man-in-the-middle attack

Back to the lab, we started more research. The experimental environment is to run MSSQL Server 2012 on Windows Server 2014 R2, the workstation is to run MSSQL Management Studio 2014 on Windows 10, and the attacker is the new version of Kali 2.0 Linux. All systems are in the same subnet to simulate Intranet attacks. These settings are almost the same as those of my customers.

This attack is called a man-in-the-middle (MITM) attack. A typical attack method is to perform some redirection. For example, ARP cache poisoning attacks force the communication between two systems to be redirected to the attacker's machine, this allows the attacker to not only view the communication between the attackers, but also tamper with the communication traffic. This is exactly what we want to do below.

Understanding data

The first thing we need to do is to view the traffic generated by the MSSQL query operation. To make the experiment more interesting, we use "SA" to log on. The SA account is the system administrator account of SQL Server and can perform any operations. If the test is successful, we can use the permissions of the SA account to perform many interesting things.

 

 

After logging on to the server, we enable Wireshark 2.0 to capture packets. We configured Wireshark to display and filter "tds. query ", so that data packets other than the TDS query data packets can be filtered (by the way, we noticed that there is no" tds "on the Wireshark of earlier versions. query ).

As we started to capture packets, we switched back to the workstation and executed the query statement in the specially prepared database. The database named testdb contains a table named Products, the Products table has two columns: ProductID and ProductName. There is no actual data in the table for testing only, so don't worry. The purpose of the query operation is to display all data in the table.

 

 

After the query is executed successfully, an empty table is returned to me. You can see it in the following figure. Back to Wireshark, we stopped packet capture and started to analyze the data packet. We found a data packet queried by TDS. After we clicked the data packet, we found that it contained all the information, this indicates that MSSQL Server 2014 Express does not encrypt data by default, which means data can be easily obtained.

 

 

After carefully viewing the decoded data below, we can easily identify the query operation, which even contains carriage returns and line breaks. Interestingly, each character has a Unicode Null Byte (0 × 00). This is especially evident when viewing the hexadecimal view, which means Wireshark periodically displays these bytes, they are not really empty, so we cannot directly look for a simple string, such as "select ". We need to consider these Unicode NULL bytes for data search.

Interesting Ettercap Filters

We have learned how the data looks. We should operate on the data below. Here we decided to use Ettercap. Ettercap is a tool dedicated to MITM attacks. It has a built-in function named Ettercap filters, which allows us to search for characteristic data packets and then process the data. We can write a filter in Ettercap, so that Ettercap will automatically replace data for each matching. This feature is slightly limited, but it is enough for our POC.

The main function we intend to use in the filtering code is the search and replacement function. The search function searches for the specified data in the data packet. The replacement function is to search for the specified data and then replace it with other data, this is also the key point of the entire project.

Since the data in the TDS query contains NULL bytes and non-printable bytes, this means that we cannot simply search for a string and replace it with another string. We need a method to search for non-empty and non-printable characters, but we cannot input them through the keyboard. Therefore, we need other methods. Fortunately, Ettercap filtering supports hexadecimal encoding. For example, you can use "\ x73" to search for letters 's' and "\ x00" to search for empty bytes ″. There is a program named hexdump in Kali that can convert the string to hexadecimal. We use this program to convert the string "select" to hexadecimal.

 

 

After we have the data we need, I wrote the first filter code named "mssql. filter" below:

 

 

The first line of code does filter the TCP traffic that runs only on port 1433. If the matching succeeds, the filter will output debugging information to the console to let us know that it has detected SQL traffic. The next "if" statement is used to search for hexadecimal data, which is translated as "select ". If the filter locates this string, the debugging information is output to the console.

Finally, the command is replaced with another string "ssssss ". This is only a test to check whether the script works normally. However, you must replace the same number of bytes when replacing the data in TCP, if the packet size is changed, the TCP connection is disconnected.

After filtering the code, remember to compile it. You can easily compile it using the etterfilter command.

 

 

No error is reported, so our filter is ready for testing. First, we start the Ettercap graphical interface and initiate an ARP spoofing attack on the MSSQL server and client. When Wireshark is enabled, we verify whether the traffic is sent between the two targets. Then, select our filter from the "Filters-> Load a filter" menu in Ettercap. Then, we get a "Content filters loaded" message in the console. We received the "SQL Traffic Discovered" message almost immediately after it was turned on. Everything looks the same as we expected.

The next step is to switch back to the workstation and try to perform the query operation. If everything is normal, the "select" string will be replaced with "ssssss" and cause query failure. After the query operation is performed, no empty table result is received this time. On the contrary, an error is returned.

 

 

"Incorrect syntax near 'sssssss'." very good. The filter works as expected. Replace the "select" string with "ssssss ". The MSSQL Server does not know that an error is returned if it is processed. This is the first step to success. The next step is to replace the entire query string for better attack.

Create an account

We decided to add an account on the server. This is a common operation for attackers, especially when the target login account is "SA, to create an account, run the following query on the MSSQL Server:

CREATE LOGIN anitian WITH PASSWORD='YouGotHacked1#';

In this case, a new account named "anitian" and "YouGotHacked1 #" will be created on the MSSQL Server. After converting all the data to hexadecimal, we updated the mssql. filter to include new data.

 

 

This filter will find the string"select ProductID, ProductName from Products where ProductID=1;"And replace the string with"CREATE LOGIN anitian with PASSWORD=’YouGotHacked1#". Previously, I specifically reminded you to replace the same amount of TCP data. What if the new query data is shorter than the source data? You only need to add spaces at the end of the query statement. Then, recompile the filter and load it to Ettercap as before, and we can submit the query from the workstation.

 

 

What is the difference between the response before and after using the Ettercap filter? An empty table is returned before, and the server returns a message of "Command (s) completed successfully. If the Database Administrator sees this, they may classify it as a strange error and ignore it directly. Unfortunately, everything is late. We have added our account to the database system. Now, the real Hack is about to begin.

Log out of the SA account on the Windows 10 workstation first, and then try to log in with the anitian account we just created.

 

 

 

 

Login successful! We have logged on to our account, but unfortunately the current account does not have much permissions and we cannot do much. However, this is not the case. The next step is to use the Ettercap filter for the next attack to increase the permissions of the current account.

Here we can easily do this, But manual hexadecimal conversion and adding NULL bytes are boring. Who would like to do this? Is this a good POC?

No way. We don't want to give up so soon. So, why can't we use an automated script to complete all these tasks.

Automated attacks

The SQLinject. sh script can be downloaded here to: http://pastebin.com/Nge9rx7g

This script automatically converts SQL queries to hexadecimal, performs ARP attacks, and loads Ettercap filters. This makes the entire attack process very simple.

The script requires the following information:

1. IP address of the MSSQL Server

2. IP address of the MSSQL Client

3. original query statement to be replaced

4. New query statements to be injected

Generally, we already know all the SQL query statements to be injected. We want to grant anitian sysadmin permission. After quickly viewing the SQL command, we can obtain the following query statements:

ALTER SERVER ROLE sysadmin ADD MEMBER anitian;

In this way, our new account anitian obtains the sysadmin permission, and then obtains the permission for anything we want to do. Now we know all four pieces of information. We can execute the script as follows:

./SQLInject.sh –o “select ProductID, ProductName from Products where ProductID=1;” –i “ALTER SERVER ROLE sysadmin ADD MEMBER anitian;” –s 192.168.1.114 –c 192.168.1.100 –f mssql.filter

With this script, we don't have to worry about annoying hexadecimal conversion or empty bytes. The script will help us handle this. We will first generate conversion and then output an Ettercap filter to mssql. filter (the file name is based on the-f parameter ). Then, etterfilter is run to compile the filter mssql. filter. ef. Finally, Ettercap on the script execution command line interface performs ARP spoofing attacks on servers and clients. This script even compares the length of the New and Old queries and reminds you whether the length of the new query is too long. If the length of a new query is short, some spaces will be filled to keep the length consistent. All of this requires only one line of command.

After the script is executed, we switch to the workstation. After executing the same query statement, we again received the message "Command (s) completed successfully. This is a good thing for us to attack. We just canceled the SA account and used the anitian account to log in again.

 

 

Now, you can find that the anitian account has changed to a sysadmin user. With this permission, users can access any system they want to access and provide us with a good springboard to attack other systems. Of course, it is assumed that the database does not contain any information we want, such as a bank card or personal ID card.

However, the biggest problem with this script is that you need to know the SQL statement to be executed in advance. Fortunately, the SQL Server often has batch processing or scheduled tasks to execute queries. To view the packet capture results of Wireshark for a period of time, we can always catch a target statement. Of course, we can also launch a more thorough attack to directly launch a man-in-the-middle attack proxy for all network traffic, search for the TDS query data packets, and automatically replace the data without having to know the original query statement in advance, but this is another project.

Defend against SQL man-in-the-middle attacks

The threats posed by man-in-the-middle attacks are devastating. As you can see, attackers can gain full access to the target system, some other dedicated hackers may not follow this operation. In addition, they can also run scripts automatically day after day to only wait for the emergence of suitable attack targets.

The simplest way to resist is to encrypt communication data. However, encryption is not enough. Make sure that a valid and trusted digital certificate is used. Attackers can easily forge a self-signed certificate.

Another defense method is to ensure that remote users are not allowed to log on with privileged accounts, such as SA accounts. All database query operations, especially query operations from programs, should be performed using only one account with a minimum access volume. To ensure that even if attackers can establish connections, they cannot use forged accounts to log on, as in this example.

Finally, make sure that your infrastructure is installed with patches on a regular basis. In addition, it is the best practice to isolate the database system from the Enterprise Intranet, which makes it difficult for man-in-the-middle attacks to work.