https://blog.talosintelligence.com/2018/05/VPNFilter.html
While the list may not be complete, the known devices affected by VPNFilter are Linksys, MikroTik, NETGEAR and TP-Link networking equipment in the small and home office (SOHO) space, as well at QNAP network-attached storage (NAS) devices.
Comments from MikroTik?
MRZ, I assume you’re indicating this vulnerability was patched in 6.38.5? Can you confirm?
This thread was locked a couple months ago, but what dvm links is from hours ago. Are you positive sure that we’re talking about the same threat?
The Talos blog indicates they reached out to Mikrotik about the problem, so I’m confident that mrz would be aware of any and all developments related to this exploit.
Cisco informed us on May 22nd of 2018, that a malicious tool was found on several manufacturer devices, including three devices made by MikroTik. We are highly certain that this malware was installed on these devices through a vulnerability in MikroTik RouterOS software, which was already patched by MikroTik in March 2017. Simply upgrading RouterOS software deletes the malware, any other 3rd party files and closes the vulnerability. Let us know if you need more details. Upgrading RouterOS is done by a few clicks and takes only a minute.
To be safe against any kinds of attacks, make sure you secure access to your devices:
https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
Statement discussion topic:
http://forum.mikrotik.com/t/vpnfilter-official-statement/119763/1
We have a CCR 1036 running 6.40.5 - and has been for some months
Today we got an abuse report for this router
So clearly there is a problem at least up to 6.40.5
Can Mikrotik please respond here?
Yes, that is to be expected, there was a vulnerability locked down in 6.40.8
“What’s new in 6.40.8 (2018-Apr-23 11:34):
!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;”
I wonder how that worked, and what “unsecured” means.
As a rule I tend to have the following config
/ip firewall filter
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=accept chain=input protocol=icmp
add action=drop chain=input in-interface=wan-interface
/tool mac-server
set [ find default=yes ] disabled=yes
add interface=lan-bridge-1
add interface=lan-bridge-2
/tool mac-server mac-winbox
set [ find default=yes ] disabled=yes
add interface=lan-bridge-1
add interface=lan-bridge-2
Then add extra input rules if needed (e.g. allow ssh on the wan port from a given management address-list), which I believe secures things enough to not be a major concern if I can’t keep a given router uptodate (I’ve got some in horrendous places that are 3 days travel away at best, really don’t like risking bricking them!)
Of course it only takes 1 infected box internally to bypass that. I’ve locked down access to only specific management address ranges in the past, but have been burnt when I’ve had routing protocols break, and the only way to get in is to ssh from the next hop, which I neglected to put in the config. I wonder if a “allow TTL=254 on wan” would do the trick as a template.
With those precautions, the risk from zero-day exploits is significantly minimized.