Investigation of information security in Yandex. Rdomn - hidden threat
In this post we want to talk about one of the most difficult cases of infection of users, which we happened to investigate and in which many of the popular techniques were used.
Malefactors constantly improve methods of introducing malicious code on the web pages of infected sites. If earlier it was a modification of static content or php-scripts of CMS, now they resort to using more complex techniques.
')
Nowadays, a web server is most often infected: malicious modules are installed, malicious shared objects are installed, or the executable file is recompiled with malicious functionality. For the introduction of malicious JavaScript is actively used, for example, Flash .
At the end of 2013, our robot began to detect a large number of malicious sites, on the pages of which a malicious Flash object was introduced. On the page there was such a code.
NB: All the malicious code in the post is given in the form of screenshots so that robots do not even consider this page infected.
This flash movie was loaded into the site visitor's browser and executed ActionScript, which sent a request to the following addresses:
hxxp: //rdomn1394028305.hopto.me/gray-bg.png? img = <random_number>,
eg:
hxxp: //rdomn1394089507.hopto.me/gray-bg.png? img = 0.28730966709554195
In response to this request, data was transmitted:
They were encrypted javascript code that is decrypted and executed by the eval operator. As a result, the flash- rabbit formed an iframe with a URL like zzbdbqs.podzone.net/ytydhdy9.html .
A frameset was loaded into the iframe , loading the Neutrino Exploit Kit's landing page into the user's browser:
Next landing page worked as follows. The script fshciym.js is a jQuery framework version 1.9.1. He actively participated in the deobfuscation process, which was carried out in the compact body of the main script subroutine:
The wdb () function returned various js-operators depending on the input parameters. Thus, the main routine was converted to code:
This code loaded the amnjzvktkqdbj document from the exploit pack and transferred it to the input of the ijvb function, which performed the decodeURIComponent and the subsequent decryption of the document. As a result, a complex script was formed from the PluginDetect and code:
This code determined which programs were installed by the user ( MS Office, VLC Player, Java, Flash ), and, depending on the results, loaded the page with suitable exploits. In addition to the interesting structure of malicious code running in the user's browser, this case is interesting in the way that the server is infected.
Several webmasters who contacted our tech support agreed to give us root access to those servers that were infected. We found out that a malicious module for Apache was used for this. It is a separate .so (usually named mod_status.so ), which is written into the configuration of the Apache web server. To make it harder to detect and remove, attackers have registered the loading of a module into configuration scripts of other modules (for example, perl.conf ). Modified configuration files using the chattr utility set attributes that prohibit changes to these files. The chattr utility itself was deleted after use. Instead, an empty file was recorded with the same name and attributes that prohibit its deletion.
During initialization, the module installed several hooks by calling functions:
ap_hook_log_transaction,
ap_hook_post_config,
ap_hook_insert_filter,
ap_register_output_filter
When the post_config_hook procedure was called (set by ap_hook_post_config ), the module configuration was decrypted and loaded. Also created file mapping , which was later used for interprocess communication. After this stage, the privileges of the process were checked and, if he had root rights, he fork and an infinite loop started. In it, the module checked for the presence of a user session in the system with root rights and prohibited processes, and, if necessary, produced backconnect to a remote server, giving attackers the possibility of remote control.
The introduction of malicious code into the HTTP responses of the server took place in a function that is set as the output filter of the Apache web server. Immediately prior to deployment, the malicious module checked whether the HTTP request was a manager, whether remote control of the module is allowed at all and whether its configuration needs to be updated. Then a series of checks took place: whether the time of the introduction of the malicious code had expired and whether it was contained in the configuration.
If the results were positive, then flags were checked that signal an active user session with root rights or a prohibited process in the system. After checking the parameters of the request and response - User-Agent, Content-Type, Referer , the presence of substrings, before or after which the introduction of malicious code. If all these checks were successful, then the malicious code was injected into the HTTP response.
The malicious module also allowed attackers to remotely control the server. To do this, it was necessary to send an HTTP request that contains the “Pragma” header with a special meaning. During the processing of such a request, this value was decoded using the Base64 algorithm, the first 8 bytes of the value were decoded and the first 4 bytes were checked for equality to the constant 0xDEADBEEF. The second 4 bytes of this 8-byte block was a command. The types of commands and their description in the table:
The rest of the Pragma value is the payload for the command. The data was transmitted in open form with the exception of a packet with a configuration update, which is encrypted using the XTEA algorithm (11 rounds) in ECB mode .
In addition, the malicious module contained functions for monitoring processes running on the system and having a user session with root rights.
In the process of monitoring unwanted processes, the module read the contents of the / proc / directory and received the command line of the running processes by reading
Similarly, the user session was checked in as root . The malicious module received the ID of the running processes, and for each process its status by reading
Initial configuration of the malware module
Updated configuration of the malicious module (malicious code can be seen inside for HTTP responses)
To introduce malicious code, attackers invent new and new methods and move from initiating individual pages and scripts to using web server executables, which makes it difficult to detect malicious code using traditional methods. If your server has undergone a similar infection, then scanning for all Apache modules using the VirusTotal service will help identify the malicious module.
Watch your web servers and their sites to avoid infection, loss of attendance, and in the case of hosting - a massive outflow of customers. Watch the layout of the sites at issue - for this you can register the sites in Yandex.Webmaster, as well as read the infection letters, which we send to standard email-addresses. If your company is hosting or developing appropriate software, it may be more convenient to use the Safe Browsing API , for which we recently released a new PHP SDK, or the “virused” parameter in the Webmasters API .
Take care of your users, sites and servers!
Malefactors constantly improve methods of introducing malicious code on the web pages of infected sites. If earlier it was a modification of static content or php-scripts of CMS, now they resort to using more complex techniques.
')
Nowadays, a web server is most often infected: malicious modules are installed, malicious shared objects are installed, or the executable file is recompiled with malicious functionality. For the introduction of malicious JavaScript is actively used, for example, Flash .
At the end of 2013, our robot began to detect a large number of malicious sites, on the pages of which a malicious Flash object was introduced. On the page there was such a code.
NB: All the malicious code in the post is given in the form of screenshots so that robots do not even consider this page infected.
This flash movie was loaded into the site visitor's browser and executed ActionScript, which sent a request to the following addresses:
hxxp: //rdomn1394028305.hopto.me/gray-bg.png? img = <random_number>,
eg:
hxxp: //rdomn1394089507.hopto.me/gray-bg.png? img = 0.28730966709554195
In response to this request, data was transmitted:
They were encrypted javascript code that is decrypted and executed by the eval operator. As a result, the flash- rabbit formed an iframe with a URL like zzbdbqs.podzone.net/ytydhdy9.html .
A frameset was loaded into the iframe , loading the Neutrino Exploit Kit's landing page into the user's browser:
Next landing page worked as follows. The script fshciym.js is a jQuery framework version 1.9.1. He actively participated in the deobfuscation process, which was carried out in the compact body of the main script subroutine:
The wdb () function returned various js-operators depending on the input parameters. Thus, the main routine was converted to code:
This code loaded the amnjzvktkqdbj document from the exploit pack and transferred it to the input of the ijvb function, which performed the decodeURIComponent and the subsequent decryption of the document. As a result, a complex script was formed from the PluginDetect and code:
This code determined which programs were installed by the user ( MS Office, VLC Player, Java, Flash ), and, depending on the results, loaded the page with suitable exploits. In addition to the interesting structure of malicious code running in the user's browser, this case is interesting in the way that the server is infected.
Several webmasters who contacted our tech support agreed to give us root access to those servers that were infected. We found out that a malicious module for Apache was used for this. It is a separate .so (usually named mod_status.so ), which is written into the configuration of the Apache web server. To make it harder to detect and remove, attackers have registered the loading of a module into configuration scripts of other modules (for example, perl.conf ). Modified configuration files using the chattr utility set attributes that prohibit changes to these files. The chattr utility itself was deleted after use. Instead, an empty file was recorded with the same name and attributes that prohibit its deletion.
During initialization, the module installed several hooks by calling functions:
ap_hook_log_transaction,
ap_hook_post_config,
ap_hook_insert_filter,
ap_register_output_filter
When the post_config_hook procedure was called (set by ap_hook_post_config ), the module configuration was decrypted and loaded. Also created file mapping , which was later used for interprocess communication. After this stage, the privileges of the process were checked and, if he had root rights, he fork and an infinite loop started. In it, the module checked for the presence of a user session in the system with root rights and prohibited processes, and, if necessary, produced backconnect to a remote server, giving attackers the possibility of remote control.
The introduction of malicious code into the HTTP responses of the server took place in a function that is set as the output filter of the Apache web server. Immediately prior to deployment, the malicious module checked whether the HTTP request was a manager, whether remote control of the module is allowed at all and whether its configuration needs to be updated. Then a series of checks took place: whether the time of the introduction of the malicious code had expired and whether it was contained in the configuration.
If the results were positive, then flags were checked that signal an active user session with root rights or a prohibited process in the system. After checking the parameters of the request and response - User-Agent, Content-Type, Referer , the presence of substrings, before or after which the introduction of malicious code. If all these checks were successful, then the malicious code was injected into the HTTP response.
The malicious module also allowed attackers to remotely control the server. To do this, it was necessary to send an HTTP request that contains the “Pragma” header with a special meaning. During the processing of such a request, this value was decoded using the Base64 algorithm, the first 8 bytes of the value were decoded and the first 4 bytes were checked for equality to the constant 0xDEADBEEF. The second 4 bytes of this 8-byte block was a command. The types of commands and their description in the table:
| Command value | Description |
|---|---|
| 10001h | Get status |
| 10002h | Update configuration |
| 10003h | Resume code injection in HTTP responses |
| 10004h | Suspend code injection in HTTP responses |
| 10005h | Make backconnect to remote server |
The rest of the Pragma value is the payload for the command. The data was transmitted in open form with the exception of a packet with a configuration update, which is encrypted using the XTEA algorithm (11 rounds) in ECB mode .
In addition, the malicious module contained functions for monitoring processes running on the system and having a user session with root rights.
In the process of monitoring unwanted processes, the module read the contents of the / proc / directory and received the command line of the running processes by reading
/proc/%d/cmdline . The obtained command line values ​​were checked for the names of prohibited processes that are listed in the configuration of the malicious module. If an undesirable process was detected, the introduction of malicious code into the HTTP responses of the server was temporarily stopped.Similarly, the user session was checked in as root . The malicious module received the ID of the running processes, and for each process its status by reading
/proc/%d/status . Further, the module received UIDs from the received data and compared them with 0. In case the process satisfied this condition, the module looked at its /proc/%d/fd and looked for the substring pts . For those file descriptors for which this substring was found, the last modification time was obtained. If the difference between the current time and the received value is less than the value defined in the configuration, the module considered that the system has a root user session and also temporarily stopped the introduction of malicious code.Initial configuration of the malware module
Updated configuration of the malicious module (malicious code can be seen inside for HTTP responses)
To introduce malicious code, attackers invent new and new methods and move from initiating individual pages and scripts to using web server executables, which makes it difficult to detect malicious code using traditional methods. If your server has undergone a similar infection, then scanning for all Apache modules using the VirusTotal service will help identify the malicious module.
Watch your web servers and their sites to avoid infection, loss of attendance, and in the case of hosting - a massive outflow of customers. Watch the layout of the sites at issue - for this you can register the sites in Yandex.Webmaster, as well as read the infection letters, which we send to standard email-addresses. If your company is hosting or developing appropriate software, it may be more convenient to use the Safe Browsing API , for which we recently released a new PHP SDK, or the “virused” parameter in the Webmasters API .
Take care of your users, sites and servers!
Source: https://habr.com/ru/post/218143/
All Articles