In-depth exploration of ms SQL Server 2000 network connection security issues

In-depth exploration of ms SQL Server 2000 network connection security issues

Creation Time:
Article attributes: original
Source: refdom
Article submission: refdom (refdom_at_263.net)

What we will talk about below is not a vulnerability in SQL Server, but some security defects and some problems. Of course these problems exist when SQL Server is generated.

1. Microsoft SQL server password plaintext transmission Defect

Unfortunately, I did not perform the following analysis when Microsoft released SQL Server. When I was surprised to find that SQL server uses plain text for password transmission, I immediately checked whether there was such information. Unfortunately, someone has proposed to use sniffer to obtain the SQL server password. However, since Microsoft is so bold, let's take a look and analyze this defect.

Of course, the SQL server connection process is still three-way handshake of TCP connection. After the connection is established with the server, the data of the table data stream protocol is communicated, unfortunately, I have never found a specific description of the TDS protocol. There are only some fragments, so I can only analyze the datagram a little bit. The specific description of who has the TDS protocol (SQL sevrer) must be sent to me.

Go directly to the login package and you will find that your username is in plain text, but the password is not. When you change the password, you can see that the same character encoding is the same, and the same character is used to separate "A5 ". Haha. So the most silly way is to change the password with one character, and then get the corresponding encoding of all characters (I will not decrypt it ).
I am using SQL Server 2000. I will list some of the corresponding codes here. You can easily get the complete character encoding.
"A" -- B3 "A" -- B1
"B" -- 83 "B" -- 81
"C" -- 93 "C" -- 91
"D" -- E3 "D" -- E1
"E" -- F3 "E" -- F1
And so on.

By the way, you cannot use ', ", and so on as passwords in SQL server. If you are using these characters as passwords, it will be terrible and you will never be able to log on, unless you change the password.
In the header of the TDS datagram, a byte is specified to indicate the type of the datagram. I have detected 0x10, and the data I obtained is that 0x02 is used to represent the login datagram, it may be that ms SQL Server has some changes in the Protocol. Because Sybase is also using the TDS protocol, Sybase may also use plain text transmission. I don't have Sybase in my hand. Unfortunately, there is no complete description of the TDS protocol, so I am also lazy did not write specifically get SQL Server account and password sniffer program, who can give me a detailed description of the TDS protocol, please email: refdom@263.net.

However, Ms still provides encryption for SQL Server transmission. You can use SSL for encryption. So I also tried it. You can select forced protocol encryption in the network configuration of the Instance attribute, and then ask you to restart SQL Server. What then, have you started it? Haha, I suffered a loss. Because there is no SSL certificate, an error occurs when you start it. The event log does not provide a valid certificate. Reinstall it. Don't remind me when I choose the damn Ms.

What does it mean to find a database account through sniffing? What if I can get the SA account? Haha. If you are interested, please refer to "switch from IIS to SQL database security" I wrote a few days ago.

2. plaintext data transmission Defects
If the encrypted protocol is not used, the network data of the entire database is not encrypted and transmitted in plaintext. Whether the command is sent from the client or the result is obtained from the server, it is transmitted in plaintext. It seems that if you use an encrypted protocol, Microsoft will not provide any security protection for you. I think almost all the SQL Server databases used in China are not encrypted using SSL. It seems that there are many things available on the network.

3. Mysterious 1434 port and server information plaintext transmission Defects

For SQL Server, open the SQL Server client to prepare a connection. When the server list is opened, all SQL Server servers in the LAN are listed. So I found that the UDP packet was broadcast from port 1434 (192.168.0.255) on my machine (192.168.0.1), and then the SQL Server server in the LAN began to respond to the UDP packet, in this case, my client can obtain all server information.

This is the client connection process: when the client connects to the server, the application requests to connect to the remote computer, dbnetlib. dll will open the connection to UDP port 1434 on the computer network name specified in the connection. All computers running SQL Server 2000 listen to this port. When a client dbnetlib. dll is connected to this port, the server returns a packet from all instances running on the listening server. For each instance, this packet reports the Server Net-library and network address that the instance is listening. Dbnetlib on the Application computer. after the DLL receives the data packet, it selects the net-library enabled on the Application computer and the SQL server instance, and then connects to the address listed in the net-library of the data packet.

Transmit a specific UDP packet through port 1434, and then the server starts to respond. All these are transmitted in plaintext. We can easily detect port 1434 of an IP address, obtain information about the SQL server running on the IP address. The information includes host name, Instance name, version, MPs queue name, and port used. This port is used by Microsoft itself, and cannot be changed as the default port 1433 is. 1434 cannot be changed. What can we do to change this port 1433 for security?

We can capture these datagram data. We can find that the data through port 1434 is very simple, and the client simply sends 02 bytes. However, after multiple captures, it is found that sometimes 03 is sent. So I used the following program to test and send other data one by one. However, only 02, 03, and 04 responded. It seems that these three bytes are used for SQL Server Detection. In addition, you can send 02 00 00 or 02 00 00 00 to receive the SQL server response, but you cannot send 02 03.

The following is a program that uses 1434 for detection. It can detect a single IP address or the database server of the entire LAN.
//////////////////////////////////////// ////////////////////
//
// Sqlping by refdom
//
// Author: refdom. From chip Andrews
// Email: refdom@263.net
//
//////////////////////////////////////// ////////////////////

# Include "stdafx. H"
# Include <string. h>
# Include <stdio. h>
# Include <winsock2.h>

Void decode_recv (char * Buf, int size)
{
Int index;
Int counter = 0;

For (Index = 3; index <size; index ++)
{
If (BUF [Index] = ';') & (BUF [index + 1]! = ';'))
{
// Look for a semi-colon and check for end of record (;;)
If (counter % 2) = 0)
{
Printf (":");
Counter ++;
}
Else
{
Printf ("/N ");
Counter ++;
}
}
Else
{
If (BUF [Index]! = ';')
{
// If an end of record (;), then double-space for next instance
Printf ("% C", Buf [Index]);
}
Else
{
Printf ("/N ");
}
}
}

Printf ("/N ");
}

Void listen (void * V)
{
Static const unsigned int buffersize = 64000;
Static char buffer [buffersize];

Socket S = (socket) V;

For (;;)
{
Struct sockaddr_in udpfrom;
Int udpfromlen = sizeof (udpfrom );
Int n = recvfrom (S, buffer, sizeof (buffer), 0, (struct sockaddr *) & udpfrom, & udpfromlen );
Int e = wsagetlasterror ();

If (n> 0 & E = 0)
Decode_recv (buffer, N );

}
}

Void useage ()
{
Printf ("************************************* */N ");
Printf ("sqlping/N ");
Printf ("/T written by refdom/N ");
Printf ("/T Email: refdom@263.net/N ");
Printf ("useage: sqlping.exe target_ip/N ");
Printf ("************************************* * *****/N ");
}

Int main (INT argc, char * argv [])
{
Wsadata;
Socket sock;
Sockaddr_in addr_in;
Char Buf [5] = {'/x02 '};
Handle listener;

Useage ();

If (argc <2)
{
Return false;
}

If (wsastartup (makeword (2, 0), & wsadata )! = 0)
{
Printf ("wsastartup error. Error: % d/N", wsagetlasterror ());
Return false;
}

If (sock = socket (af_inet, sock_dgram, ipproto_udp) = invalid_socket)
{
Printf ("socket failed. Error: % d/N", wsagetlasterror ());
Return false;
}

Addr_in.sin_family = af_inet;
Addr_in.sin_port = htons (0, 1434 );
Addr_in.sin_addr.s_un.s_addr = inet_addr (argv [1]);

Const int sndbuf = 0;
Const int tcpnodelay = true;
Const int broadcast = true;

If (setsockopt (sock, sol_socket, so_sndbuf, (const char *) & sndbuf, sizeof (sndbuf) = socket_error)
{
Printf ("set so_sndbuf failed. Error: % d", wsagetlasterror ());
Return false;
}
If (setsockopt (sock, sol_socket, tcp_nodelay, (const char *) & tcpnodelay, sizeof (tcpnodelay) = socket_error)
{
Printf ("set tcp_nodelay failed. Error: % d", wsagetlasterror ());
Return false;
}
If (setsockopt (sock, sol_socket, so_broadcast, (const char *) & Broadcast, sizeof (broadcast) = socket_error)
{
Printf ("set so_broadcast failed. Error: % d", wsagetlasterror ());
Return false;
}

Listener = (handle) _ beginthread (Listen, 0, (void *) sock );

// E = sendto (S, "/08", 1, 0, (sockaddr *) & hostaddr, sizeof (hostaddr ));
If (sendto (sock, Buf, sizeof (BUF), 0, (sockaddr *) & addr_in, sizeof (addr_in) = socket_error)
{
Printf ("Send failed. Error: % d/N", wsagetlasterror ());
Return false;
}

Printf ("listening.../n ");

// Wait a little while for listener thread
Waitforsingleobject (listener, 5000 );

Wsacleanup ();

Printf ("sqlping complete./N ");
Return 0;
}

The above program only has a probe function and has no destructive effect. Haha

Thanks to hectic for providing me with help. Limited by my own level, it is inevitable that there are errors. please correct me more. If you have a specific description manual for the TDS protocol (applied on SQL Server), please email me and thank you. Email: zj.wj@163.com