Linux / Cdorked.A: Chronicles of the New Apache Backdoor
Last week, colleagues from Sucuri sent us a modified version of the Apache web server binary file, which redirected some requests addressed to it to the Blackhole Exploit Kit exploit kit. An analysis conducted by experts of our anti-virus laboratory showed that this Linux threat, dubbed Linux / Cdorked.A , is intended to redirect traffic to malicious sites. Sucuri information about this incident .
During the analysis, we concluded that Linux / Cdorked.A is the most complex Linux backdoor we’ve seen before. With the help of our ESET Live Grid cloud technology, we received statistics on hundreds of compromised web servers. Unlike other similar threats, the backdoor does not leave any traces of its activity on the compromised host’s hard disk, which makes it much more difficult to detect. Instead, it stores all the information it uses in memory, without using a hard disk. In addition, attackers use obfuscated HTTP requests to transfer service information to malicious code, which are not recorded in the Apache log file. Thus, traces of the interaction of malicious code with the C & C server are also absent.
')
The Linux / Cdorked binary file contains all the important strings in an encrypted form, using the well-known XOR scheme with a static key. The version of Linux / Cdorked we analyzed contains about 70 such lines, using the key indicated below in the screenshot (27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F).
Fig. String decode code.
Fig. Key to decrypt.
As mentioned above, the backdoor does not use files on disk for service purposes. Instead, it allocates about 6 MB of shared memory for storing its data and configuration information. This block of memory, called POSIX Shared Memory, is used by all Apache child processes; it can also be accessed by any other process in the system, since the authors of the malicious code do not restrict its use using access rights. The screenshot below shows the access rights to this shared memory region (read and write for all).
Fig. Gaining access to a shared memory block.
There are two ways in which an attacker can control the behavior of a compromised server: through a reverse connection using the command line and using special commands. Both of these methods are activated via HTTP requests. The first method using the command line is invoked via the GET HTTP protocol request. It is executed when a request for a special path occurs, and the string has a specific format and contains the host name and port for the connection. The client IP address is used as a key to decrypt the transmitted string, that is, a 4-byte XOR key. Additionally, the IP address specified in the X-Present_IP or X-Redirected_ packet headers will replace the client IP as the decryption key. This means that we can make a header for X-Present_IP, which will act as the key "\ x00 \ x00 \ x00 \ x00". The query string must be in hex format before being sent.
Fig. Example of command execution.
As long as the attacker has access to the command line, the active HTTP connection will not be terminated. This means that the activity of the malicious code can be seen by checking the time-consuming HTTP connections. On the other hand, the Apache log does not provide any information about this connection, since the malicious code controls the appearance of this information.
The compromised web server redirects the client to malicious web pages, for this the backdoor code adds a base64 encoded query string that contains information about the original URL and whether the request was addressed to a js file so that the server can provide the correct load.
An example of such a line:
hxxp: // dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw ==
In decrypted form, we see the following parameters:
js = 1 & nvcbimuf = ccvckqju & time = 1304161827-360453650 & src = 232 & surl = www.infectedserver.com & sport = 80 & key = 13D90950 & suri = / forum / wcf / js / 3rdParty / protoaculous.1.8.2.min.js
The parameter “surl” indicates a compromised (infected) host, and “suri” indicates the original request.
After the redirection, a cookie is set for the client’s browser, so that later, its re-redirection is excluded. This cookie is also set if a web page similar to the server administration page is requested. Malicious code checks such arguments as the URL, server name, referrer field to match the following lines: "* adm *", "* webmaster *", "* submit *", "* stat *", "* mrtg *", "* webmin * "," * cpanel * "," * memb * "," * bucks * "," * bill * "," * host * "," * secur * "," * support * ". Perhaps such checks are done in order to avoid sending malicious content to the website administrators, thus it will be more difficult to detect the fact of compromise. The screenshot below shows the part of the code responsible for handling cookies.
For successful redirection, the malicious code also checks some other request arguments, for example, the presence of the Accept-Language, Accept-Encoding, Referrer fields is checked.
We found 23 commands that Linux / Cdorked.A can send to the server via an HTTP POST request using a specially generated URL. The request must contain a cookie field that starts with the " SECID = " token. The query string must have two hex-bytes, which are values ​​encrypted with the client's IP address. The SECID parameter is also used as an argument in some other commands. We believe that URLs used by backdoor to redirect visitors use this particular method. Information about these addresses will be stored in encrypted form, using shared memory. It is also obvious that the conditions for redirection are set as follows: a white list of user agents for whom redirects can be pre-configured and a black list of IP addresses for which no redirection is performed.
A complete list of commands that supports backdoor "DU", "ST", "T1", "L1", "D1", "L2", "D2", "L3", "D3", "L4", "D4" , "L5", "D5", "L6", "D6", "L7", "D7", "L8", "D8", "L9", "D9", "LA", "DA".
The backdoor maintains its status using the HTTP header's ETag parameter, as shown in the screenshot below. We are still investigating the purpose of each of these teams and will publish them as soon as our analysis is complete. In short, all of them are intended either to add the contents of the configuration to a block of shared memory, or to remove it from there.
As mentioned earlier, access rights to a shared memory block allow access to any process running on the system. We have developed a free tool ( dump_cdorked_config.py ) that will help system administrators check the availability of such a block of memory and save it to a file. Our specialists also recommend using the debsums tool for Debian and Ubuntu systems, as well as the “rpm –verify” command for RPM-based Linux systems, which will allow you to check the integrity of your Apache server modules. Checking for the presence of a block of shared memory is the recommended way to make sure that you are not infected. Our anti-virus laboratory is interested in obtaining such memory dumps for further analysis.
At the time of this writing, the ESET Live Grid Threat Tracking System shows hundreds of web servers that have been compromised by this backdoor. At the same time thousands of visitors to these servers were redirected to malicious content. In the near future, we will publish more information about the situation with Linux / Cdorked.A.
During the analysis, we concluded that Linux / Cdorked.A is the most complex Linux backdoor we’ve seen before. With the help of our ESET Live Grid cloud technology, we received statistics on hundreds of compromised web servers. Unlike other similar threats, the backdoor does not leave any traces of its activity on the compromised host’s hard disk, which makes it much more difficult to detect. Instead, it stores all the information it uses in memory, without using a hard disk. In addition, attackers use obfuscated HTTP requests to transfer service information to malicious code, which are not recorded in the Apache log file. Thus, traces of the interaction of malicious code with the C & C server are also absent.
')
The Linux / Cdorked binary file contains all the important strings in an encrypted form, using the well-known XOR scheme with a static key. The version of Linux / Cdorked we analyzed contains about 70 such lines, using the key indicated below in the screenshot (27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F).
Fig. String decode code.
Fig. Key to decrypt.
As mentioned above, the backdoor does not use files on disk for service purposes. Instead, it allocates about 6 MB of shared memory for storing its data and configuration information. This block of memory, called POSIX Shared Memory, is used by all Apache child processes; it can also be accessed by any other process in the system, since the authors of the malicious code do not restrict its use using access rights. The screenshot below shows the access rights to this shared memory region (read and write for all).
Fig. Gaining access to a shared memory block.
There are two ways in which an attacker can control the behavior of a compromised server: through a reverse connection using the command line and using special commands. Both of these methods are activated via HTTP requests. The first method using the command line is invoked via the GET HTTP protocol request. It is executed when a request for a special path occurs, and the string has a specific format and contains the host name and port for the connection. The client IP address is used as a key to decrypt the transmitted string, that is, a 4-byte XOR key. Additionally, the IP address specified in the X-Present_IP or X-Redirected_ packet headers will replace the client IP as the decryption key. This means that we can make a header for X-Present_IP, which will act as the key "\ x00 \ x00 \ x00 \ x00". The query string must be in hex format before being sent.
Fig. Example of command execution.
As long as the attacker has access to the command line, the active HTTP connection will not be terminated. This means that the activity of the malicious code can be seen by checking the time-consuming HTTP connections. On the other hand, the Apache log does not provide any information about this connection, since the malicious code controls the appearance of this information.
The compromised web server redirects the client to malicious web pages, for this the backdoor code adds a base64 encoded query string that contains information about the original URL and whether the request was addressed to a js file so that the server can provide the correct load.
An example of such a line:
hxxp: // dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw ==
In decrypted form, we see the following parameters:
js = 1 & nvcbimuf = ccvckqju & time = 1304161827-360453650 & src = 232 & surl = www.infectedserver.com & sport = 80 & key = 13D90950 & suri = / forum / wcf / js / 3rdParty / protoaculous.1.8.2.min.js
The parameter “surl” indicates a compromised (infected) host, and “suri” indicates the original request.
After the redirection, a cookie is set for the client’s browser, so that later, its re-redirection is excluded. This cookie is also set if a web page similar to the server administration page is requested. Malicious code checks such arguments as the URL, server name, referrer field to match the following lines: "* adm *", "* webmaster *", "* submit *", "* stat *", "* mrtg *", "* webmin * "," * cpanel * "," * memb * "," * bucks * "," * bill * "," * host * "," * secur * "," * support * ". Perhaps such checks are done in order to avoid sending malicious content to the website administrators, thus it will be more difficult to detect the fact of compromise. The screenshot below shows the part of the code responsible for handling cookies.
For successful redirection, the malicious code also checks some other request arguments, for example, the presence of the Accept-Language, Accept-Encoding, Referrer fields is checked.
We found 23 commands that Linux / Cdorked.A can send to the server via an HTTP POST request using a specially generated URL. The request must contain a cookie field that starts with the " SECID = " token. The query string must have two hex-bytes, which are values ​​encrypted with the client's IP address. The SECID parameter is also used as an argument in some other commands. We believe that URLs used by backdoor to redirect visitors use this particular method. Information about these addresses will be stored in encrypted form, using shared memory. It is also obvious that the conditions for redirection are set as follows: a white list of user agents for whom redirects can be pre-configured and a black list of IP addresses for which no redirection is performed.
A complete list of commands that supports backdoor "DU", "ST", "T1", "L1", "D1", "L2", "D2", "L3", "D3", "L4", "D4" , "L5", "D5", "L6", "D6", "L7", "D7", "L8", "D8", "L9", "D9", "LA", "DA".
The backdoor maintains its status using the HTTP header's ETag parameter, as shown in the screenshot below. We are still investigating the purpose of each of these teams and will publish them as soon as our analysis is complete. In short, all of them are intended either to add the contents of the configuration to a block of shared memory, or to remove it from there.
As mentioned earlier, access rights to a shared memory block allow access to any process running on the system. We have developed a free tool ( dump_cdorked_config.py ) that will help system administrators check the availability of such a block of memory and save it to a file. Our specialists also recommend using the debsums tool for Debian and Ubuntu systems, as well as the “rpm –verify” command for RPM-based Linux systems, which will allow you to check the integrity of your Apache server modules. Checking for the presence of a block of shared memory is the recommended way to make sure that you are not infected. Our anti-virus laboratory is interested in obtaining such memory dumps for further analysis.
At the time of this writing, the ESET Live Grid Threat Tracking System shows hundreds of web servers that have been compromised by this backdoor. At the same time thousands of visitors to these servers were redirected to malicious content. In the near future, we will publish more information about the situation with Linux / Cdorked.A.
Source: https://habr.com/ru/post/178197/
All Articles