Geekly Articles each Day

New information about VPNFilter: conducting an attack on user devices, expanded list of network equipment

image

Introduction


Analytical division of Cisco Talos, together with technology partners, revealed additional details related to malware "VPNFilter". Since the first publication on this topic, we have discovered that the VPNFilter malware has targeted more device models and expanded the list of companies whose products may be infected. In addition, we found that malware possesses additional functions, including the ability to launch attacks on user terminals. A recent Talos blog posting looked at a large-scale campaign to spread VPNFilter to network devices for home or small offices, as well as to a number of networked storage systems. In the same publication it was mentioned that the investigation of the threat continues. After the release of the first publication, several industry partners provided us with additional information that helped us advance in the investigation. As part of this publication, we present the results of this investigation received during the last week.
First, we found that the list of manufacturers of equipment whose products are the goal of a malicious campaign must be supplemented by new participants. This equipment companies ASUS, D-Link, Huawei, Ubiquiti, UPVEL and ZTE. Also, additional models of devices released by Linksys, MikroTik, Netgear and TP-Link were exposed to this attack. At the present time, our investigation did not reveal any evidence of the vulnerability of network devices released by Cisco. An updated list of devices is shown below.

In addition, we discovered a new malicious module that functions in step 3, which ensures that malicious content is added to web traffic when such traffic is transmitted through an infected device. At the time of the first publication, we did not have all the information about the modules operating in stage 3. The new module allows initiators of a malicious campaign to implement exploits aimed at users' end devices using the “attack-in-the-middle” approach (i.e., intercept network traffic and injection of malicious code into traffic without the user's knowledge). Thanks to the new results of the investigation, we can confirm that the threat capabilities are beyond the network device, and the threat can spread further into the network, which includes the compromised network device. Technical information about this module, called “ssler”, is presented below.

In addition, we found an additional module that functions in step 3, which provides any module that functions in step 2 and does not support “kill”, the ability to disable the device. When launched, this module removes all traces of the presence of malicious VPNFilter on the device and puts the device into an inoperable state. The results of the analysis of this module, called “dstr”, are also presented below.

Finally, we continued the study of the packet sniffer operating at stage 3, including a detailed analysis of Modbus traffic detection methods.

Technical Information


New modules operating in phase 3


'ssler' (terminal device hacking module - javascript injection)

The ssler module (we pronounce this name “Esler”) provides opportunities for data theft and injection of JavaScript code by intercepting all traffic destined for port 80 and transmitted through the device. This module maintains a list of parameters that determine the behavior of the module and those websites for which traffic will be intercepted. The first parameter defines the directory on the device in which the stolen data will be stored. The purpose of the other parameters is described below:


The first action performed by the ssler module is to configure the iptables device to redirect all traffic addressed to port 80 to the local service that operates on port 8888. It is started using the insmod command to insert three iptables modules into the core (ip_tables.ko, iptable_filter .ko, iptable_nat.ko) and then executes the following shell commands:


-A PREROUTING -s 192.168.201.0/24 -d 10.0.0.0/16 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8888

Note. To ensure that these rules are not deleted, ssler deletes them and immediately adds them back about every four minutes.

Any outgoing web requests to port 80 will be intercepted by the ssler module, they can be analyzed and modified before sending to the legitimate HTTP service. All HTTP requests are translated from https to http. Before sending requests to legitimate HTTP servers, the following changes are made to them:


If the host is specified as the value of the dump: parameter, the details of the request are saved to disk for subsequent collection by the attacker, including the URL, port, and all request headers. If the host is not specified as the value of the dump: parameter, then only requests with the Authorization header or URLs containing credentials will be saved. URLs that contain credentials are determined by the following criteria — they must contain the string “assword =” or “ass =” and one of the following lines:


All POST requests to accounts.google.com containing the string “signin” will also be saved for later collection.

After all the above modifications, the ssler module initiates a connection to a legitimate HTTP server and sends a modified request to port 80. Then the ssler module receives a response from the HTTP server and makes the following changes to the response before sending the response to the victim:

Source: https://habr.com/ru/post/413619/

More articles:


All Articles