I think whitelist firewall by default together with replacing user+pass by private key on WAN (on other port) should be safe enough for big portion of exploits… For me weakest chain is always Wifi.
How do we know if it is affected or not?
Whilst the OpenWRT forum is offline since a couple of days the question has been raised in the LEDE project forum but not received a conclusive answer.
The original Talos advisory is stating post infection technicalities but seems to be scarce on how the devices get infected in the first place.
At the time of this publication, we do not have definitive proof on how the threat actor is exploiting the affected devices. However, all of the affected makes/models that we have uncovered had well-known, public vulnerabilities.
VPNFilter’s stage 1 malware infects devices running firmware based on Busybox and Linux, and is compiled for several CPU architectures.
Suppose it is difficult to make an assessment of whether TO is affected until it is known of how the initial malicious payload is actually making its way into the router’s OS.
Perhaps the TO team will respond in due time, albeit for instance this security matter UPnProxy via NAT Injections - SW bugs discussion - Turris forum has not received any reply (yet) - not that TO users appear much interested either.
It is not apparent of how TO is dealing with CVE pertaining to OpenWRT, e.g. NVD - CVE-2017-17867, or the Linux kernel and userland applications.
Meanwhile snort is available in the TO repo
Talos has released protections for this threat from multiple angles, to try to take advantage of the limited options that exist. We developed and deployed more than 100 Snort signatures for the publicly known vulnerabilities for the devices that are associated with this threat. These rules have been deployed in the public Snort set, and can be used by anyone to help defend their devices. In addition, we have done the usual blacklisting of domains/IPs as appropriate and convicting of the hashes associated with this threat to cover those who are protected by the Cisco Security ecosystem.
I posted this to get a reply/response from the Turris Team, but the silence on this topic is deafening…
Sadly not just on this particular security related matter
Hi,
our team didn’t get any message from Talos group so right now we think Omnia/Turris were not affected.
<personal_view>
I think that reason for that is, that Omnia/Turris is not so spread like others router brands and that there are much more low-hanging fruits see https://securelist.com/backdoors-in-d-links-backyard/85530/ or https://github.com/threat9/routersploit/tree/master/routersploit/modules/exploits
</personal_view>
We want to add some packages which would help to audit router.
Right now I’m preparing Yara, hashdeep and ssdeep packages but I will welcome recomendation for other tools
Note
This program is obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr.
This would help auditing/investigating unexplained sockets, e.g. Purpose of RxRPC? - #2 by anon50890781 - SW help - Turris forum
albeit not an auditing tool but adding a protective layer by advancing the firewall’s WAN with ipset of revolving ip blacklists such as
DSHIELD|14400|0|http://www.dshield.org/block.txt
BOGON|86400|0|http://www.cymru.com/Documents/bogon-bn-agg.txt
HONEYPOT|14400|0|Dictionary Attacker IPs | By Last Bad Event | Project Honey Pot
CIARMY|14400|0|http://www.ciarmy.com/list/ci-badguys.txt
BFB|14400|0|http://danger.rulez.sk/projects/bruteforceblocker/blist.php
BDE|3600|0|https://api.blocklist.de/getlast.php?time=3600
BDEALL|14400|0|http://lists.blocklist.de/lists/all.txt
GREENSNOW|14400|0|https://blocklist.greensnow.co/greensnow.txt
TALOS|14400|0|http://talosintel.com/feeds/ip-filter.blf
Add to that some transparency of how TO is applying backported security patches to the kernel and userland applications and how TO is monitoring CVE for kernel, userland apps in general and OpenWRT in particular.
Since the FBI has seized the command and control domain it recommends a router reboot which would help them to assess which devices are infected. Hopefully there will be no TO/OpenWRT amongst it
Hi,
we didn’t receive any information from Talos,FBI etc.
If you have TurrisOS version 3.10.1 you can scan for sign of infection with yara util.
opkg update && opkg install yara
wget https://raw.githubusercontent.com/Neo23x0/signature-base/master/yara/apt_vpnfilter.yar
yara -r apt_vpnfilter.yar <dir_name>
My apologies for this stupid question…
What will be “<dir_name>”???
I would suggest replace <dir_name> with every directory in root / except /dev, /sys and /proc
I was like why not f**k that lets scan everything… just confirming if you use / it will hang.
Thank you for the code.
There is an update from Talos on the subject VPNFilter Update - VPNFilter exploits endpoints, targets new devices
One intersting new information
The first action taken by the ssler module is to configure the device’s iptables to redirect all traffic destined for port 80 to its local service listening on port 8888. It starts by using the insmod command to insert three iptables modules into the kernel (ip_tables.ko, iptable_filter.ko, iptable_nat.ko) and then executes the following shell commands:
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8888 Example: ./ssler logs src:192.168.201.0/24 dst:10.0.0.0/16-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 do not get removed, ssler deletes them and then adds them back approximately every four minutes.
Checking for port 8888 should be indicative of a potential infection.
Also explains why I have seen on my other boxes an increase of scanning traffic on port 8888
I got this…
root@turris:~# yara -r apt_vpnfilter.yar /usr
SUSP_ELF_Tor_Client /usr/sbin/tor
What to do next???
It is probably no worry if you installed TOR at some point via Foris or LuCI, which you can check on eiher gui and remove and afterwards run the check again.
Hi,
it looks like false positive, but to be sure I would suggest upload /usr/sbin/tor to https://www.virustotal.com and if you see something like this, https://www.virustotal.com/#/file/50ac4fcd3fbc8abcaa766449841b3a0a684b3e217fc40935f1ac22c34c58a9ec/detection you should contact tech.support@turris.cz.
I had the same and I have tor installed from the repositories that turrisos provides.
Does openwrt provide some kind of checksumming like rpm? Something like rpm -Va?