February 15, 2013 at 13:09Linux at gunpoint
In this post we want to talk about the recently discovered threats to the Linux OS and about attacks on it. It is known that this operating system is more often used on servers than on user computers. Thus, the goals pursued by cybercriminals during attacks on Linux have their own specifics that are different from ordinary attacks on Windows systems.
In the first part we will talk about Linux / SSHDoor.A - a threat that is used by cybercriminals to gain hidden access to a compromised server and to steal information. The second part of the article is devoted to the study of attacks against Linux servers that use Apache as a web server.
Linux / SSHDoor.A
Recently, an interesting sample for analysis was received by our anti-virus laboratory. It is a malicious version of the SSH daemon for Linux. This daemon contains backdoor functionality and gives attackers access to a compromised server.
Recall that Secure Shell Protocol (SSH) is a very popular protocol used for secure data exchange. It is widely used in the Unix world to transfer files, manage remote servers, etc. The modified SSH daemon described here is designed to steal usernames and passwords, and also allows you to open access to the server either through a password that is hard-coded into malicious code, or through a special SSH key.
Lines that compromise a legitimate binary file, thereby allowing its covert or malicious behavior to be detected, are encrypted using the usual XOR algorithm. We found 16 such lines. The figure below shows the part of the code responsible for decrypting this hidden data (using the constant 0x23 for decryption).
Fig. The code of the decryptor of strings that malicious code uses.
The HTTP protocol is used to send the stolen data to a remote server. The data is encrypted using a 1024-bit RSA key, which is stored in a binary file, then again encrypted using Base64 and sent to the server through a POST request for the HTTP protocol.
Fig. An example of a POST HTTP request through which stolen data is sent to the server.
The binary file that we analyzed contains two domain addresses of the servers used to collect data: openssh.info, linuxrepository.org. Probably both of these names were chosen specifically to avoid suspicions on the part of administrators of compromised servers. At the time of analysis, these names pointed to a server located in Iceland with IP 82.221.99.69.
When the daemon is running, the malicious code sends to the remote server the IP address and port number under which it works, as well as the host name of the server.
Fig. Service data sent by the backdoor.
Whenever a user successfully logs into a hacked server, the username and password are also sent to the remote server. In addition to identity theft, a backdoor provides an attacker with control over a compromised server in two different ways. Firstly, it has a built-in password, a hard-wired password. If a user tries to log in using this password, he automatically gains access to the compromised server. The figure below shows the code that is responsible for comparing passwords between the code that was wired into the code and the one that the user typed in when trying to log in.
Fig. Malicious password comparison code.
Secondly, the modified binary file contains an SSH key. If a user logs on to the server using a private key corresponding to the public key that is wired into the code of the threat file, he is automatically granted access.
The backdoor can also get configuration data from the /var/run/.options file. If such a file exists, the malicious code uses the host name, password and SSH key stored in this file.
Attack on Linux using Linux / Chapro.A
Below we will talk about an attack on Linux servers that use the Apache web server (more than half of those on the network). We were seriously worried to discover a specialized Apache malware module. This module is used to inject malicious content into web pages.displayed by a compromised web server. We also found that this malicious code was used in a scheme to steal confidential data related to credit cards and online banking .
The analyzed Apache malware module was added by us as Linux / Chapro.A. Its main task is to inject malicious content into web pages that are managed by this compromised server. During the study, it turned out that through the introduction of a special iframe, attackers redirect the user to the hidden installation of one of the modifications of the famous Win32 / Zbot banking trojan, which is usually used to steal bank secret information from infected machines.
Fig. Attack scheme using Linux / Chapro.A.
We also found that this module has a number of interesting features that successfully hide it from system administrators. In addition to the analysis of this malicious Apache module, we will present an analysis of the malicious content that he was involved in introducing and an overview of the main payload - the Win32 / Zbot Trojan.
Linux / Chapro.A Web Page Infector
Malicious code is a special Apache module - x64 binary file. He uses the technique of obfuscating his lines using the XOR algorithm and a 12-byte key. It also contains a number of features aimed at hiding its presence from system administrators - for this, before passing the user a web page with malicious content, the module performs a number of checks.
Firstly, it checks the user agent of the browser for the presence of known bots and browsers that are not vulnerable to the exploit set used when the client system is infected. If the client’s browser that accesses this web page has a user agent that is recognized by the malicious code as a web crawler, then the malicious content (iframe) is hidden from the client.
Fig. A list of user agents from which malicious code hides embedded content.
Secondly, Linux / Chapro.A checks all active SSH sessions on the Linux system in which it is running to determine the IP addresses involved in this connection. If a visitor views a page from a system that has an IP address from the list of SSH connections, he will also not redirect the client to malicious content. This technique helps to hide this content from system administrators or web developers who might be working on this web server.
Thirdly, before embedding a malicious iframe in the contents of the Linux / Chapro.A web page, it sets cookies in the client’s web browser environment. No malicious content will be transmitted to the client if the client browser already contains similar cookies. With this approach, the same visitor will not receive malicious content every time they access the web server, which also complicates the investigation of the causes and methods of infection.
And finally, fourthly, Linux / Chapro.A stores a list of IP addresses that have already received malicious content. If a user visits an infected website twice from the same IP address, he will receive such content only once. It also creates additional difficulties to identify the causes of infection of the client.
Content implemented using Linux / Chapro.A
As we mentioned, the main task of Linux / Chapro.A is to inject malicious iframes into web pages served by the Apache web server. To receive such iframes, the malware sends an HTTP POST request to its command C&C server with a frequency of 10 minutes. The following figure shows one of these queries.
Fig. Request for C&C server from Linux / Chapro.A.
At the time of our analysis, this C&C was located in Germany. The request sent to the server is quite simple and includes the version of the malware, as well as the version of the OS in which it runs. The command server responds to these requests with an iframe, which must be implemented using a malicious Apache module. This transmitted iframe is encrypted using base64 and XOR. If the visitor of a compromised server does not fit into any of the lists that we talked about in the previous section, he receives a copy of the web page with the embedded iframe, which was downloaded from the C&C server.
The image below shows the HTML code for an iframe that compromises a web page. Interestingly, in order to avoid attention from the user, this malicious iframe is located outside the area displayed by the browser.
Fig. Malicious iframe.
A set of exploits used in the attack
In our analysis, we found that the iframe, which is deployed using Linux / Chapro.A, redirects the user to the “Sweet Orange” exploit set. At the time of our analysis, the page (server) that contained this exploit pack (landing page) was located in Lithuania. These exploits attempt to exploit the following vulnerabilities in modern browsers and plug-ins:
● CVE-2012-5076: Java JAX-WS Class Handling
●CVE-2012-4681: Java getField Method Class Invocation Privilege Escalation
● CVE-2006-0003: Internet Explorer MDAC
● CVE-2010-0188: Adobe Reader LibTiff Integer Overflow
If the exploit set is able to exploit one of these vulnerabilities, it executes a malicious useful load on the victim’s car.
Attack payload
The ultimate goal of the attack is to install one of the modifications of the Win32 / Zbot banking Trojan (commonly known as Zeus). In our case, Win32 / Zbot is aimed at European and Russian banking institutions. The screenshot below shows the form used by one of the banks to provide customers with online access to a bank account.
Fig. The original web form used to enter the user into the online banking system.
As we see, the banking system warns the user that the online banking system will never ask for additional, strictly confidential information in the form of a PIN code, CVC / CVV code or other data directly associated with a bank card and belonging only to its owner . However, when a user visits this page from a Zeus infected computer, this warning is successfully removed from the displayed form. The screenshot below shows just such a case.
Fig. A web form on a compromised web page that does not contain additional warnings for the user.
As soon as the user successfully logs into the banking system under his account, the malicious code displays a pop-up window in which he will be asked to enter the card's CVV code. It is precisely about the inadmissibility of this that the information in the original, non-compromised web form warns. Next, the malicious code will try to send the credentials of the user and his CVV to the attackers.
In the first part we will talk about Linux / SSHDoor.A - a threat that is used by cybercriminals to gain hidden access to a compromised server and to steal information. The second part of the article is devoted to the study of attacks against Linux servers that use Apache as a web server.
Linux / SSHDoor.A
Recently, an interesting sample for analysis was received by our anti-virus laboratory. It is a malicious version of the SSH daemon for Linux. This daemon contains backdoor functionality and gives attackers access to a compromised server.
Recall that Secure Shell Protocol (SSH) is a very popular protocol used for secure data exchange. It is widely used in the Unix world to transfer files, manage remote servers, etc. The modified SSH daemon described here is designed to steal usernames and passwords, and also allows you to open access to the server either through a password that is hard-coded into malicious code, or through a special SSH key.
Lines that compromise a legitimate binary file, thereby allowing its covert or malicious behavior to be detected, are encrypted using the usual XOR algorithm. We found 16 such lines. The figure below shows the part of the code responsible for decrypting this hidden data (using the constant 0x23 for decryption).
Fig. The code of the decryptor of strings that malicious code uses.
The HTTP protocol is used to send the stolen data to a remote server. The data is encrypted using a 1024-bit RSA key, which is stored in a binary file, then again encrypted using Base64 and sent to the server through a POST request for the HTTP protocol.
Fig. An example of a POST HTTP request through which stolen data is sent to the server.
The binary file that we analyzed contains two domain addresses of the servers used to collect data: openssh.info, linuxrepository.org. Probably both of these names were chosen specifically to avoid suspicions on the part of administrators of compromised servers. At the time of analysis, these names pointed to a server located in Iceland with IP 82.221.99.69.
When the daemon is running, the malicious code sends to the remote server the IP address and port number under which it works, as well as the host name of the server.
Fig. Service data sent by the backdoor.
Whenever a user successfully logs into a hacked server, the username and password are also sent to the remote server. In addition to identity theft, a backdoor provides an attacker with control over a compromised server in two different ways. Firstly, it has a built-in password, a hard-wired password. If a user tries to log in using this password, he automatically gains access to the compromised server. The figure below shows the code that is responsible for comparing passwords between the code that was wired into the code and the one that the user typed in when trying to log in.
Fig. Malicious password comparison code.
Secondly, the modified binary file contains an SSH key. If a user logs on to the server using a private key corresponding to the public key that is wired into the code of the threat file, he is automatically granted access.
The backdoor can also get configuration data from the /var/run/.options file. If such a file exists, the malicious code uses the host name, password and SSH key stored in this file.
Attack on Linux using Linux / Chapro.A
Below we will talk about an attack on Linux servers that use the Apache web server (more than half of those on the network). We were seriously worried to discover a specialized Apache malware module. This module is used to inject malicious content into web pages.displayed by a compromised web server. We also found that this malicious code was used in a scheme to steal confidential data related to credit cards and online banking .
The analyzed Apache malware module was added by us as Linux / Chapro.A. Its main task is to inject malicious content into web pages that are managed by this compromised server. During the study, it turned out that through the introduction of a special iframe, attackers redirect the user to the hidden installation of one of the modifications of the famous Win32 / Zbot banking trojan, which is usually used to steal bank secret information from infected machines.
Fig. Attack scheme using Linux / Chapro.A.
We also found that this module has a number of interesting features that successfully hide it from system administrators. In addition to the analysis of this malicious Apache module, we will present an analysis of the malicious content that he was involved in introducing and an overview of the main payload - the Win32 / Zbot Trojan.
Linux / Chapro.A Web Page Infector
Malicious code is a special Apache module - x64 binary file. He uses the technique of obfuscating his lines using the XOR algorithm and a 12-byte key. It also contains a number of features aimed at hiding its presence from system administrators - for this, before passing the user a web page with malicious content, the module performs a number of checks.
Firstly, it checks the user agent of the browser for the presence of known bots and browsers that are not vulnerable to the exploit set used when the client system is infected. If the client’s browser that accesses this web page has a user agent that is recognized by the malicious code as a web crawler, then the malicious content (iframe) is hidden from the client.
Fig. A list of user agents from which malicious code hides embedded content.
Secondly, Linux / Chapro.A checks all active SSH sessions on the Linux system in which it is running to determine the IP addresses involved in this connection. If a visitor views a page from a system that has an IP address from the list of SSH connections, he will also not redirect the client to malicious content. This technique helps to hide this content from system administrators or web developers who might be working on this web server.
Thirdly, before embedding a malicious iframe in the contents of the Linux / Chapro.A web page, it sets cookies in the client’s web browser environment. No malicious content will be transmitted to the client if the client browser already contains similar cookies. With this approach, the same visitor will not receive malicious content every time they access the web server, which also complicates the investigation of the causes and methods of infection.
And finally, fourthly, Linux / Chapro.A stores a list of IP addresses that have already received malicious content. If a user visits an infected website twice from the same IP address, he will receive such content only once. It also creates additional difficulties to identify the causes of infection of the client.
Content implemented using Linux / Chapro.A
As we mentioned, the main task of Linux / Chapro.A is to inject malicious iframes into web pages served by the Apache web server. To receive such iframes, the malware sends an HTTP POST request to its command C&C server with a frequency of 10 minutes. The following figure shows one of these queries.
Fig. Request for C&C server from Linux / Chapro.A.
At the time of our analysis, this C&C was located in Germany. The request sent to the server is quite simple and includes the version of the malware, as well as the version of the OS in which it runs. The command server responds to these requests with an iframe, which must be implemented using a malicious Apache module. This transmitted iframe is encrypted using base64 and XOR. If the visitor of a compromised server does not fit into any of the lists that we talked about in the previous section, he receives a copy of the web page with the embedded iframe, which was downloaded from the C&C server.
The image below shows the HTML code for an iframe that compromises a web page. Interestingly, in order to avoid attention from the user, this malicious iframe is located outside the area displayed by the browser.
Fig. Malicious iframe.
A set of exploits used in the attack
In our analysis, we found that the iframe, which is deployed using Linux / Chapro.A, redirects the user to the “Sweet Orange” exploit set. At the time of our analysis, the page (server) that contained this exploit pack (landing page) was located in Lithuania. These exploits attempt to exploit the following vulnerabilities in modern browsers and plug-ins:
● CVE-2012-5076: Java JAX-WS Class Handling
●CVE-2012-4681: Java getField Method Class Invocation Privilege Escalation
● CVE-2006-0003: Internet Explorer MDAC
● CVE-2010-0188: Adobe Reader LibTiff Integer Overflow
If the exploit set is able to exploit one of these vulnerabilities, it executes a malicious useful load on the victim’s car.
Attack payload
The ultimate goal of the attack is to install one of the modifications of the Win32 / Zbot banking Trojan (commonly known as Zeus). In our case, Win32 / Zbot is aimed at European and Russian banking institutions. The screenshot below shows the form used by one of the banks to provide customers with online access to a bank account.
Fig. The original web form used to enter the user into the online banking system.
As we see, the banking system warns the user that the online banking system will never ask for additional, strictly confidential information in the form of a PIN code, CVC / CVV code or other data directly associated with a bank card and belonging only to its owner . However, when a user visits this page from a Zeus infected computer, this warning is successfully removed from the displayed form. The screenshot below shows just such a case.
Fig. A web form on a compromised web page that does not contain additional warnings for the user.
As soon as the user successfully logs into the banking system under his account, the malicious code displays a pop-up window in which he will be asked to enter the card's CVV code. It is precisely about the inadmissibility of this that the information in the original, non-compromised web form warns. Next, the malicious code will try to send the credentials of the user and his CVV to the attackers.