Architecture of MySQL security defense practices guide

I. machine architecture supported by MySQL

MySQL claims to be the most popular open-source database in the world today. It is released for free and can run on a variety of platforms. This is why hackers are eager for it. Compared with other large databases, the configuration is much easier and easier, and the performance is also mentioned. Although its usage is relatively simple, there is still a lot of work to do in terms of security configuration, which is also one of the reasons for many database security risks.

Generally, the MySQL database server is installed using a binary file package. In this case, it can be installed on the following system: linux x86, Linux IA64, Linux AMD64, Windows, Solaris, FreeBSD, Mac OS X, HP-UX, IBM AIX, QNX, Novell Netware, OpenBSD, SGI IRIX, and DEC OSF; if the source code is installed, more platforms are supported.

Ii. MySQL deployment

MySQL is so popular that it can be found almost anywhere on the network. In fact, it is not only installed on dedicated servers, but also common to desktop machines.

In normal configuration, the client connects to MySQL through TCP port 3306. For Windows platforms, MySQL can also be used through the famous pipeline, but this configuration is generally not recommended. By default, MySQL running in the famous Pipeline mode listens to both TCP port 3306 and a famous Pipeline named MySQL. Compared with database systems such as Oracle, MySQL uses a relatively simple network protocol, and uses plaintext communication by default. Of course, SSL can also be used to protect communication. After the SSL protocol is enabled, the database is still a TCP port 3306.

You can easily check the MySQL version running on a host. As long as you connect to the host, it returns the major and minor versions of the database, some versions also provide prompts for the operating system. Any TCP port scanner that can capture the flag can return the MySQL version.

The most common application of MySQL is to provide backend support for Dynamic web applications. When we scan the network, MySQL usually appears at the backend of the Apache/PHP application, sometimes it even runs on the same host as the web server. In some large organizations, it is often used as a log record server to store Intrusion Detection System logs, web logs, or other audit tasks. In some cases, especially in the development environment, MySQL is often installed on a desktop machine, so it is not surprising to scan it on a PC.

Because the MySQL communication protocol is plain text communication, people like to install an SSH server on the host where the MySQL server is located, and use port forwarding technology to connect to port 3306 through an encrypted tunnel. This method has several advantages: data is encrypted during transportation, an additional authentication step is forced, and additional audit records are provided for the database connection.

In addition, some people think that the MySQL server and the web server should be installed on the same machine, because this can avoid remote connection, but this configuration itself is not secure. This is because MySQL Data Tables are stored as files and are not usually locked. Once a Web application has a file leakage vulnerability, this allows attackers to download all the contents of the database. On the other hand, the SQL injection vulnerability in Web applications may also allow attackers to modify the script content on the web server. Proper file permissions can prevent such problems. However, placing the web server and database server on the same machine opens many other conveniences for attackers.

Iii. Introduction to WinMySQLAdmin

When MySQL is installed on Windows, the WinMySQLAdmin tool is usually provided. When the tool runs for the first time, it will add itself to the startup group where the user running it is located. When it runs, WinMySQLAdmin will automatically start MySQL, which will cause MySQL instances running on Windows hosts to be inadvertently run.

In addition, when WinMySQLAdmin runs on a host without a default MySQL user account, it requires the user to create a user name and password pair, these creden are stored in plain text in my. INI file. This file is usually readable to any user on the host.

Iv. Default user name and password

The default configuration of MySQL varies with the platform, deployment mode, release version (source code or binary file), and initial configuration, in some cases, the MySQL server may be attacked by remote attackers once installed-if the default configuration is incorrect. For example, in some default configurations of MySQL 4.0.20, the table mysql. user contains four default records, two for the root account and two for the anonymous account. In addition, a remote table item with root permission is provided to the root user on the host build. The specific meanings of the table items in these tables will be explained later. Now we only need to know:

If you are on a local host, you can pass authentication as the root user with an empty password and obtain full control of the database. If you are on a local host, you can use any user name to authenticate your identity and gain access to the database's guests. If you are on a remote host and can control server name resolution, it will make your host name look "build ", therefore, you can pass the authentication as a root user with an empty password to gain full control of the database. If you are on a remote host named build, you can use any user name to authenticate your identity and obtain database guest access permissions.

On a Windows host, the root account can lead to any local user to escalate their permissions to local system-level access permissions. By default, MySQL runs at the system permission level. Unfortunately, attackers simply name their machines as build, so they can easily gain remote system-level access to the machines running the MySQL service. Of course, attackers must be located in the same NetBIOS Name Domain of the target, or be able to forge a DNS response. The defense methods for this problem are:

Disable network connection when installing MySQL.
Delete all accounts except the root account of the local host in the mysql. user table immediately after installation.
Set a complex password for the root account of the local host.
5. Security Vulnerabilities in authentication protocols

MySQL uses a proprietary protocol for authentication and sending and receiving data. This Protocol is relatively simple, so you can easily compile a custom client for MySQL. In other words, serious vulnerabilities in various versions of the MySQL authentication protocol may cause the server to be attacked immediately. The following describes some of the previous vulnerabilities and their attack methods.

Before describing these attack methods, we will give a general introduction to the packet format and encryption mechanism related to the authentication protocol. When a client connects to the server, the server sends a greeting packet, which includes the following domains:

Packet Length (3 bytes)
Packet Number (1 byte)
Protocol Version (1 byte)
Server Version String (ending with null)
Server Thread ID (4 bytes)
Challenge String (ending with null)
Server Capabilities Flags (2 bytes)
Server Character Set (1 byte)
Server Status (2 bytes)
Padding (the rest of the data packet)
For the authentication Protocol, the relevant content is the Protocol Version and Challenge domains, but the Server Version String domain is very helpful for determining which Authentication Vulnerabilities the Server is vulnerable. The client then sends an authentication packet to the server:

Packet Length (3 bytes)
Packet Number (1 byte)
Client Capabilities (2 bytes)
Max packet size (3 bytes)
Username (end with null)
Password (the challenge response ends with null)
The following describes the security vulnerabilities in the authentication protocol. Many security vulnerabilities have been found in the MySQL authentication protocol.

Basic password vulnerabilities before Authentication Protocol 4.1

MySQL versions earlier than mysql 4.1 do not need to know the password, as long as you know the hash value of the password (included in MySQL. in the user table), you can pass the authentication. This means that the attacker does not need to write a code to crack the password, this is because it is much easier to modify the standard MySQL client to accept password mixing instead of password mixing. Of course, users tend to use the same password in multiple places, especially the root password. Therefore, cracking the hash value of any password is very likely to be used in multiple places.

Authentication Algorithm earlier than 3.23.11

MySQL earlier than version 3.23.11 has a serious flaw in its identity authentication mechanism, that is, an attacker can pass identity authentication by simply using a single character of the password after the miscellaneous. In fact, the pooled string consists of some characters of 32 characters, so attackers can log on with only a few guesses.

CHANGE_USER before 3.23.54

For MySQL versions earlier than 3.23.54, if the user can perform authentication, it has the opportunity to submit a super-long string (to trigger buffer overflow) or the CHANGE_USER command of a single-byte string to raise the permission.

Authentication algorithms in 4.1.1, 4.1.2, and 5.0.0

By submitting a specially crafted data group for identity authentication, attackers may bypass the password authentication mechanism in MySQL versions established earlier than 4.1.0 to 4.1.2 and 5.0. The following code is taken from the check_connection code of the SQL _parse.cpp file:

/*

The old client sends a string ending with null as the password. The new client uses the size (1 byte) + String (not null as the terminator) as the password. Therefore, if the password is empty, both of them will be sent.

*/

Uint passwd_len = thd-> client_capabilities & CLIENT_SECURE_CONNECTION?
* Passwd ++: strlen (passwd );

0x8000 is specified in the capability mark of the client. You can specify the selected passwd_len field. For this attack, we select 0x14 (20), which is the SHA1 length we expected.

Now we need to perform multiple checks to ensure that the user authenticates from the authorized host. After these checks, we arrived:

/* Check the password: it should be empty or correct */
If (passwd_len = acl_user_tmp-> salt_len)
{
If (acl_user_tmp-> salt_len = 0 |
Acl_user_tmp-> salt_len = SCRAMBLE_LENGTH &&
Check_scramble (passwd, thd-> scramble, acl_user_tmp-> salt) = 0 |
Check_scramble_323 (passwd, thd-> scramble,
(Ulong *) acl_user_tmp-> salt) = 0)
{
Acl_user = acl_user_tmp;
Res = 0;
}
}

The Check_scramble function fails, but within the check_scramble_323 function, we can see:

My_bool
Check_scramble_323 (const char * scrambled, const char * message,
Ulong * hash_pass)
{
Struct rand_struct rand_st;
Ulong hash_message [2];
Char buff [16], * to, extra;
Const char * pos;

Hash_password (hash_message, mess