WEB Service CGI interface Vulnerability Analysis

After analyzing CGI interfaces for a period of time, I feel that various WEB interfaces have been analyzed for a period of time. I feel that various WEB servers are not very uniform with some variables and do not understand some security requirements, this section briefly analyzes some security vulnerabilities. Because it is based on some personal understanding and analysis, errors are inevitable. I hope you can correct them.

The main problem is the inconsistent processing of several variables PATH_INFO, PATH_TRANSLATED, and SCRIPT_NAME. The following describes the variables in MSDN. To be clear, the two variables are listed together, and the other two variables are correctly handled by the WEB servers.

PATH_INFO Additional path information, as given by the client. This comprises the trailing part of the URL after the script name but before the query string (if any ).
PATH_TRANSLATED This is the value of PATH_INFO, but with any virtual path name expanded into a directory specification.
QUERY_STRING The information which follows? In the URL that referenced this script.
REQUEST_METHOD The HTTP request method.
SCRIPT_NAME The name of the script program being executed.

Let's take a look at a specific example to see what these variables actually mean. For example, if there is a ing. php, the request is:

"GET/test. php/aaa/bbb? Cgivartest HTTP/1.1 ", REQUEST_METHOD = GET; QUERY_STRING = cgivartest; this is not to be questioned. What are the other three variables? I personally think the definitions in MSDN are more accurate, that is, the above definitions. In this case, SCRIPT_NAME = test. php. This is the program to be executed (or possibly interpreted by other programs). Before "query string" after "script name", PATH_INFO =/aaa/bbb, if the main WEB directory is "d: inetpubwwwroot", PATH_TRANSLATED = d: inetpubwwwrootaaabb.

But what is the actual situation? Let's take a look. Use two common WEB servers to build two environments for comparison. Let's take a look at the processing of these two WEB servers.
Environment:
1. win2000 + apache1.3.14 + php4;
2. win2000 + iis5.0 + php4;
I won't talk about the specific configuration. I believe everyone is a configuration master, so I don't have to pay too much for it here.
Create a file test. php In each WEB service. The file content is as follows:
<?
Phpinfo ();
?>
You can see what it is. simply create such a file so that you can view some WEB variables.

1. directly use php.exe to load apache;
Http: // 192.168.8.48/php/php.exe/abcde. php/aa/... % 5c ../test. php? Cgivartest

Get:
Environment
Variable Value

SCRIPT_FILENAME d:/php4/php.exe
GATEWAY_INTERFACE CGI/1.1
SERVER_PROTOCOL HTTP/1.1
REQUEST_METHOD GET
QUERY_STRING cgivartest
REQUEST_URI/php/php.exe/abcde. php/aa/... % 5c ../test. php? Cgivartest
SCRIPT_NAME/php/php.exe/abcde. php/aa /....
PATH_INFO/abcde. php/aa/.../../test. php
PATH_TRANSLATED d: program filesapache groupapachehtdocs est. php

2. Load with ing in apache:
Http: // 192.168.8.48/AB. PHP/AA/... % 5C.../test. php? Cgivartest

Get:
Environment
Variable Value

SCRIPT_FILENAME d:/php4/php.exe
GATEWAY_INTERFACE CGI/1.1
SERVER_PROTOCOL HTTP/1.1
REQUEST_METHOD GET
QUERY_STRING cgivartest
REQUEST_URI/AB. PHP/AA/... % 5C ../test. php? Cgivartest
SCRIPT_NAME/php/php.exe/AB. PHP/AA /....
PATH_INFO/AB. PHP/AA/.../../test. php
PATH_TRANSLATED d: program filesapache groupapachehtdocs est. php

3. Load cgi interface under iis:
Http: // 192.168.8.48: 81/abc. php/aa/... % c1 % 1c ../test. php? Cgivartest

Get:

Environment
Variable Value

GATEWAY_INTERFACE CGI/1.1
PATH_INFO/abc. php/aa/.../test. php
PATH_TRANSLATED d: inetpubwwwrootabc. phpaa... est. php
QUERY_STRING cgivartest
REQUEST_METHOD GET
SCRIPT_NAME/abc. php
SERVER_PROTOCOL HTTP/1.1

4. Loading isapi Interfaces under iis: (ing. php4)
Http: // 192.168.8.48: 81/abc. php4/aa/... % c1 % 1c ../test. php? Cgivartest

Get:

ISAPI
Server Variable Value
PATH_INFO/abc. php4/aa/.../test. php
PATH_TRANSLATED d: inetpubwwwrootabc. php4aa... est. php
QUERY_STRING cgivartest
REQUEST_METHOD GET
SCRIPT_NAME/abc. php4
SERVER_PROTOCOL HTTP/1.1
URL/abc. php4

Let's take a look. apache and iis are not the SCRIPT_NAME for execution, but the PATH_TRANSLATED for execution. My personal understanding is that PATH_INFO is just a path, not a file. The WEB Service itself should be said to have the chroot nature, so the variable PATH_INFO should limit the rfc "/... /", this is done by iis. The encoding requirements in rfc % 5c are not acceptable. The decoding of % c1 % 1c is due to another vulnerability. However, apache can directly use % 5c, which is obviously a vulnerability. Suppose we want to execute PATH_TRANSLATED, then we try to replace test. php with another name, for example, test. pl, another ing name, which is also executed in php. What does that mean? That is to say, I can execute an image file using any interpreter, which obviously does not comply with the security requirements of such mappings, this vulnerability can easily cause source code leakage. If "/../" in PATH_INFO is restricted, the parent directory cannot be returned, so that a ing file cannot be interpreted by any interpreter. But if there are several variables SCRIPT_NAME, PATH_INFO, and PATH_TRANSLATED in this way, isn't there any meaning at all? In my personal understanding, the SCRIPT_NAME program is executed. The PATH_INFO variable only provides an additional path information for SCRIPT_NAME, such as reading some configuration files in this path. The SCRIPT_NAME variable in apache removes the file name.

We can conclude that:

1. PATH_INFO should limit "/../" in rfc encoding requirements. This vulnerability exists in apache. This may cause source code leakage and even allow access to arbitrary files.
2. The execution files are unclear, such as PATH_TRANSLATED, PATH_INFO, and SCRIPT_NAME. Apache and iis both have vulnerabilities. This can easily cause source code leakage. In fact, we found that the vulnerability cannot be separated from this vulnerability. It may take some time for IIS to leak the source code vulnerability patch. The same method is also available on apache, although the root cause of this vulnerability is not this, however, this vulnerability provides a performance opportunity. The attack mainly exploits this vulnerability and the half-character truncation Processing Vulnerability at the end of the file name for windows File Operations. You can view some source code such as asp and php. After a while, you will be able to see it.

If you are interested, you can perform experiments on your own based on this experiment to check the handling and understanding of these variables in various environments. It is very likely that you can easily find some new vulnerabilities on your own.

 

Appendix 1: MSDN documentation on CGI and ISAPI interfaces.

EXTENSION_CONTROL_BLOCK Structure
The EXTENSION_CONTROL_BLOCK structure has the following form:

Typedef struct _ EXTENSION_CONTROL_BLOCK {

DWORD cbSize; // IN
DWORD dwVersion // IN
HCONN ConnID; // IN
DWORD dwHttpStatusCode; // OUT
CHAR lpszLogData [HSE_LOG_BUFFER_LEN]; // OUT
LPSTR lpszMethod; // IN
LPSTR lpszQueryString; // IN
LPSTR lpszPathInfo; // IN
LPSTR lpszPathTranslated; // IN
DWORD cbTotalBytes; // IN
DWORD cbAvailable; // IN
LPBYTE lpbData; // IN
LPSTR lpszContentType; // IN

BOOL (WINAPI * GetServerVariable)
(HCONN hConn,
LPSTR lpszVariableName,
LPVOID lpvBuffer,
LPDWORD lpdwSize );

BOOL (WINAPI * WriteClient)
(HCONN ConnID,
LPVOID Buffer,
LPDWORD lpdwBytes,
DWORD dwReserved );

BOOL (WINAPI * ReadClient)
(HCONN ConnID,
LPVOID lpvBuffer,
LPDWORD lpdwSize );

BOOL (WINAPI * ServerSupportFunction)
(HCONN hConn,
DWORD dwHSERRequest,
LPVOID lpvBuffer,
LPDWORD lpdwSize,
LPDWORD lpdwDataType );

} EXTENSION_CONTROL_BLOCK, * LPEXTENSION_CONTROL_BLOCK;

The server communicates with the ISA via the EXTENSION_CONTROL_BLOCK.

The references to IN and OUT abve indicates whether the member applies to messages to the extension (IN) or from the extension (OUT ).

Members

The EXTENSION_CONTROL_BLOCK structure contains the following fields:

CbSize

The size of this structure.

DwVersion

The version information of HTTP_FILTER_REVISION. The HIWORD has the major version number and the LOWORD has the minor version number.

ConnID

A unique number assigned by the HTTP server. It must not be modified.

DwHttpStatusCode

The status of the current transaction when the request is completed. Can be one of the following:

HTTP_STATUS_BAD_REQUEST

HTTP_STATUS_AUTH_REQUIRED

HTTP_STATUS_FORBIDDEN

HTTP_STATUS_NOT_FOUND

HTTP_STATUS_SERVER_ERROR

HTTP_STATUS_NOT_IMPLEMENTED
LpszLogData

Buffer