VPNFilter: a global threat beyond routers

When first publicly announced on May 23, the threat dubbed VPNFilter was thought to only infect some brands of home routers and Network Attached Storage devices. While it was known that the list of router brands was probably not complete, little did we know that the malware has the ability to infect the very computers sitting behind those routers and firewalls.

Continuing on their initial investigation of this threat, Cisco Talos shared with the Cyber Threat Alliance, of which Juniper Networks is an affiliate member, additional malware samples and analysis gathered since the initial reports on this threat. Several key findings emerge:

1. The list of affected router brands continues to grow, but is still limited to brands covering the small office / home office segment of the market. No enterprise brands are affected. Juniper Networks routers are not believed to be affected.
2. The malware can infect devices behind an infected router by injecting content into web traffic and attempting to exploit the endpoints. This does not mean it will be successful at the exploitation attempt. It solely means that the exploit is attempted without a user having to visit a compromised site, click on a malicious link or open a malicious email attachment.
3. The malware has a stage 3 module that can render the infected device inoperable. This was initially thought to only exist in a stage 2 malware, but it seems some stage 3 module provides the same ability. This leads us to believe that in earlier times of this campaign, the stage 2 malware did not have this capability and was only introduced more recently. So to cover the early infection, this stage 3 module capability was added.

Let’s review these findings in more detail.

Affected edge devices

The initial list of targeted routers included MicroTik, Linksys, NetGear and TPLink. It is now expanded to include devices from ASUS, D-Link, Huawei, Ubiquiti, UPVEL and ZTE. We still do not believe this list is complete as more infected devices are being discovered. There is still no sign of any zero day vulnerability being exploited, so it is likely that known vulnerabilities and weak passwords are the main vector of infection.

Endpoint infection

This new stage 3 module dubbed 'ssler' has the ability to intercept all network traffic destined for port 80 and selectively inject exploits for the endpoint via JavaScript. This man-in-the-middle attack is based on the following variables:

• Source IP: this is the endpoint IP that is making the http request. The fact that the source IP is an option means the threat actor has potentially profiled endpoints behind the firewall and knows which endpoint to target with the exploits.
• Destination IP: this allows the threat actor to focus on certain communications of interest, for example with your bank or your cloud email service, and siphon off the credentials that are used to authenticate.
• Visited sites: this is similar to the destination IP above, except that it uses the domain name instead of its IP, which allows targeting of services distributed around the world.

The injected script itself is highly customizable since it is downloaded from a remote location. It can therefore be updated at any time to tailor its activity to a particular need.

This malware module also accepts a ‘dump’ parameter which specifies some websites as where the threat actor wants to dump all the connection parameters into a local file, like the full URL, the port, all request headers, presumably for the purpose of exfiltrating it to a C2 server. Additionally, even if the website is not specifically listed in the dump parameters but the communication contains interesting strings, such as authorization in the headers or some keywords related to passwords in the URL (like assword, sername, ogin), the dump of the connection parameter will take place. Notice the missing first letter. This is a way to avoid dealing with uppercase and lowercase parameter names.

To accomplish persistence of the injection module, the technique of routing all traffic from port 80 to the malware’s own listening service is deleted and recreated every four minutes. This is because any reconfiguration on the router by its owner tends to rewrite the entire configuration from an in-memory previous configuration, which would remove any routes the malware has added. Furthermore, some routers use counters on the routes, query them every few minutes and clear these counters, which is also done by rewriting the configuration. Therefore, this malware module found it easier to deal with this uncertainty by running the man-in-the-middle attack every few minutes.

One interesting feature of the malware is the fact that it turns any secure HTTPS into an insecure HTTP connection on the fly. This will allow it to peek into the contents of all connections. Most web sites today will redirect HTTP to HTTPS connections, but it is enough sometimes to catch the very first request as it may already contain credentials and other POST form elements. As a matter of fact, this malware will only perform this operation once per web site every 4 days, after which HTTPS connection to those “whitelisted” web sites are left alone. Four domains are explicitly excluded from this inspection: google.com, youtube.com, facebook.com and twitter.com.

In order to keep the parsing of the HTTP protocol as simple as possible, the malware module changes any connection parameter - connection:keep-alive to connection:close. It also changes any accept-encoding request header to not contain a gzip parameter. This allows the malware to inspect content without having to decompress it, which keeps the size of the malware module to a minimum.

Destructive capability

New insight into the destructive capability of this new stage 3 module shows that the threat actors went to a great length to make sure the destruction is successful and irreversible. We can now see that the module:

• Deletes itself from memory
• Stops execution of its stage 2 parent process
• Stops execution of any process with a name containing vpnfilter, tor or security
• Deletes a list of files related to its own operation
• Overwrites the flash memory with a 0xFF byte, which is something similar to what the stage 2 destroyer does based on our previous post on this topic.
• Deletes all files on the router’s file systems by issuing a rm /* command.
• Triggers a reboot of the device, which after everything above will certainly fail permanently.

Conclusion

It is obvious that the scope of this campaign is far bigger than initially thought. The ability to infect endpoints introduces a new variable and the clean up process is more involved than just rebooting routers. Any exploit could have been used by the threat actors to target the computers behind infected routers.

At this point, it is important for people who had routers in the list of affected devices to make sure they have the following mitigations in place:

1. Make sure you have an updated anti-virus software running on your endpoints.
2. Make sure your systems are up-to-date with any security patches.
3. Enable two factor authentication on all online accounts that support it.

As our research progresses, we will publish any additional guidance to thwart this infection. In the meantime, Juniper SRX firewall devices are updated to detect any infection attempt from VPNfilter based on the IOCs known to the Cyber Threat Alliance.

 By Mounir Hahad

Published with permission from forums.juniper.net/t5/Blogs/ct-p/blogs