April 27, 2013 at 17:42Linux / Cdorked.A: chronicles of the new Apache backdoor
Last week, colleagues from Sucuri sent us a modified version of the binary file for the Apache web server, which redirected some requests addressed to it to the Blackhole Exploit Kit. An analysis by experts at our antivirus lab showed that this Linux threat, called Linux / Cdorked.A , is designed to redirect traffic to malicious sites. Sucuri information about this incident .
In the process of analysis, we came to the conclusion that Linux / Cdorked.A is the most complex Linux backdoor of all that we have seen before. Using our ESET Live Grid cloud technology, we've got statistics on hundreds of compromised web servers. Unlike other similar threats, the backdoor does not leave any traces of its activities on the hard drive of a compromised host, which significantly complicates its detection. Instead, it stores all the information it uses in memory, without involving a hard drive. In addition, attackers use obfuscated HTTP requests to transfer service information to malicious code, which are not recorded in the Apache log file. Thus, there are also no traces of malicious code interacting with the C&C server.
The Linux / Cdorked binary file contains all the important lines in encrypted form, using the well-known XOR scheme with a static key. The Linux / Cdorked version that we analyzed contains about 70 such lines, using the key shown in the screenshot below (27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F).
Fig. String decryption code.
Fig. The decryption key.
As mentioned above, the backdoor does not use files on the disk for official purposes. Instead, it allocates about 6 MB of total memory.(shared memory) to store your data and configuration information. This memory block, called POSIX Shared Memory, is used by all Apache child processes, and it can 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 region of shared memory (read and write for everyone).
Fig. Gaining access to the 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 through HTTP requests. The first method using the command line is called via the GET HTTP protocol request. It is executed when a special path is requested, 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, i.e. a 4-byte XOR key. Additionally, the IP address specified in the packet headers X-Real_IP or X-Redirected_on will replace the client IP as the decryption key. This means that we can make a header for X-Real_IP, which will act as a key "
Fig. Command execution example.
As long as the attacker has access to the command line, an active HTTP-connection will not be disconnected. This means that malicious code activity can be noticed if you check HTTP connections that are long in time. On the other hand, the Apache log does not provide any information about this connection, since malicious code controls the appearance of this information.
A compromised web server redirects the client to malicious web pages, for this the backdoor code adds a base64 encoded request string that contains information about the original URL and whether the request was addressed to the js file so that the server can provide the correct useful load.
An example of such a line:
hxxp: // dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw ==
Decoded, we see the following options:
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, cookies are set for the client’s browser, so that in the future, it will not be redirected again. This cookie is also set if a web page similar to the server administration page is requested. Malicious code checks such arguments as URL, server name, referrer field for 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 administrators of the website, so the fact of compromise will be more difficult to detect. The screenshot below shows part of the code,
To successfully redirect, the malicious code also checks some other request arguments, for example, checks for the presence of Accept-Language, Accept-Encoding, Referrer fields.
We discovered 23 commands that Linux / Cdorked.A can send to the server through an HTTP POST request using a specially crafted URL. The request must contain a cookie field that begins with the " SECID =". The request string should have two hex bytes, which are values encrypted using the client IP address. The SECID parameter is also used as an argument in some other commands. We believe that the URLs that the backdoor uses to redirect visitors use it is this 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: white list of user agents for which redirects can be pre-configured and a blacklist of IP addresses for which redirection is not carried out.
A complete list of commands that the backdoor “DU”, “ST”, “T1”, “L1”, “D1”, “L2”, “D2”, “L3”, “D3”, “L4”, “D4” Support , “L5”, “D5”, “L6”, “D6”, “L7”, “D7”, “L8”, “D8”, “L9”, “D9”, “LA”, “DA”.
The backdoor maintains its status using the ETag parameter of the HTTP header, as shown in the screenshot below. We are still researching 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 the shared memory block, or to remove it from there.
As previously mentioned, access rights to the shared memory unit allow access it anyone working in the process system. We developed a free tool ( dump_cdorked_config.py), which will help system administrators verify the existence of such a memory block and save it to a file. Our experts 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 check the integrity of the modules of your Apache server. Checking for a shared memory block is the recommended way to ensure that you are not infected. Our anti-virus laboratory is interested in receiving such memory dumps for further analysis.
At the time of writing, ESET Live Grid's 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.
In the process of analysis, we came to the conclusion that Linux / Cdorked.A is the most complex Linux backdoor of all that we have seen before. Using our ESET Live Grid cloud technology, we've got statistics on hundreds of compromised web servers. Unlike other similar threats, the backdoor does not leave any traces of its activities on the hard drive of a compromised host, which significantly complicates its detection. Instead, it stores all the information it uses in memory, without involving a hard drive. In addition, attackers use obfuscated HTTP requests to transfer service information to malicious code, which are not recorded in the Apache log file. Thus, there are also no traces of malicious code interacting with the C&C server.
The Linux / Cdorked binary file contains all the important lines in encrypted form, using the well-known XOR scheme with a static key. The Linux / Cdorked version that we analyzed contains about 70 such lines, using the key shown in the screenshot below (27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F).
Fig. String decryption code.
Fig. The decryption key.
As mentioned above, the backdoor does not use files on the disk for official purposes. Instead, it allocates about 6 MB of total memory.(shared memory) to store your data and configuration information. This memory block, called POSIX Shared Memory, is used by all Apache child processes, and it can 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 region of shared memory (read and write for everyone).
Fig. Gaining access to the 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 through HTTP requests. The first method using the command line is called via the GET HTTP protocol request. It is executed when a special path is requested, 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, i.e. a 4-byte XOR key. Additionally, the IP address specified in the packet headers X-Real_IP or X-Redirected_on will replace the client IP as the decryption key. This means that we can make a header for X-Real_IP, which will act as a key "
Fig. Command execution example.
As long as the attacker has access to the command line, an active HTTP-connection will not be disconnected. This means that malicious code activity can be noticed if you check HTTP connections that are long in time. On the other hand, the Apache log does not provide any information about this connection, since malicious code controls the appearance of this information.
A compromised web server redirects the client to malicious web pages, for this the backdoor code adds a base64 encoded request string that contains information about the original URL and whether the request was addressed to the js file so that the server can provide the correct useful load.
An example of such a line:
hxxp: // dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw ==
Decoded, we see the following options:
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, cookies are set for the client’s browser, so that in the future, it will not be redirected again. This cookie is also set if a web page similar to the server administration page is requested. Malicious code checks such arguments as URL, server name, referrer field for 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 administrators of the website, so the fact of compromise will be more difficult to detect. The screenshot below shows part of the code,
To successfully redirect, the malicious code also checks some other request arguments, for example, checks for the presence of Accept-Language, Accept-Encoding, Referrer fields.
We discovered 23 commands that Linux / Cdorked.A can send to the server through an HTTP POST request using a specially crafted URL. The request must contain a cookie field that begins with the " SECID =". The request string should have two hex bytes, which are values encrypted using the client IP address. The SECID parameter is also used as an argument in some other commands. We believe that the URLs that the backdoor uses to redirect visitors use it is this 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: white list of user agents for which redirects can be pre-configured and a blacklist of IP addresses for which redirection is not carried out.
A complete list of commands that the backdoor “DU”, “ST”, “T1”, “L1”, “D1”, “L2”, “D2”, “L3”, “D3”, “L4”, “D4” Support , “L5”, “D5”, “L6”, “D6”, “L7”, “D7”, “L8”, “D8”, “L9”, “D9”, “LA”, “DA”.
The backdoor maintains its status using the ETag parameter of the HTTP header, as shown in the screenshot below. We are still researching 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 the shared memory block, or to remove it from there.
As previously mentioned, access rights to the shared memory unit allow access it anyone working in the process system. We developed a free tool ( dump_cdorked_config.py), which will help system administrators verify the existence of such a memory block and save it to a file. Our experts 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 check the integrity of the modules of your Apache server. Checking for a shared memory block is the recommended way to ensure that you are not infected. Our anti-virus laboratory is interested in receiving such memory dumps for further analysis.
At the time of writing, ESET Live Grid's 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.