VPNFilter malware vulnerability

Discussion in 'Tomato Firmware' started by srouquette, May 26, 2018.

  1. srouquette

    srouquette Network Guru Member

    m972214940 likes this.
  2. jerrm

    jerrm Network Guru Member

    Where do you see Tomato is vulnerable?
     
  3. m972214940

    m972214940 New Member Member

  4. jerrm

    jerrm Network Guru Member

    So far I see little to be concerned about.

    What is published implies access is gained through known vulnerabilities and the only one mentioned is default credential exposures.

    I don't know of any such issues with Tomato, but am happy to be corrected.

    It's not a vulnerability if someone enables remote access with default credentials - it's stupidity. As the comedian Ron White says - you can't fix stupid.

    The only things that appear special about VPNFilter is it seems well engineered and the authors realized most of these devices have some sort of crontab stored in nvram they could modify to enable reboot persistence once access was gained.
     
  5. Hogwild

    Hogwild LI Guru Member

    Does this apply to older versions of Tomato?

    I'm running an Asus RT-N12 with firmware v1.28.0506 MIPSR2Toastman-RT-N K26 Mini.

    Am I at risk of VPNFilter problems with this firmware version, or is going to be a similar situation with current versions of Tomato?
     
    Last edited: Jun 7, 2018
  6. Monk E. Boy

    Monk E. Boy Network Guru Member

    At this point they haven't seen a version of the software infecting Tomato, DD-WRT, or WRT-Merlin. That doesn't mean it can't attack it.

    https://arstechnica.com/information...cting-50000-devices-is-worse-than-we-thought/
    To my knowledge VPNFilter is using exploits for components that have patches available. It infects routers running busybox on MIPS CPUs. This does not mean that all routers running busybox on MIPS CPUs are infected with VPNFilter, or even that they all can be infected.

    At this point we have to wait and see. In an ideal world we should reboot our routers, reset NVRAM to defaults, reload the firmware with the latest version available from a trusted source (be sure to check md5 and sha256 signatures), and set them up from scratch.

    I'm really, really, really hoping that stage 1 didn't modify the CFE. Because that would suck. Probably still fixable but more problematic to fix.

    Right now reboot your device is the best option. Set it up to reboot once a day. Surely there's a 15 minute period where you don't need internet every 24 hours.
     
  7. RMerlin

    RMerlin Network Guru Member

    Not just MIPS, the Netgear R7000 has an ARM bcm4709.

    Sent from my Nexus 5X using Tapatalk
     
    Monk E. Boy likes this.
  8. Monk E. Boy

    Monk E. Boy Network Guru Member

    Good point, that was added to the list in the last update from Cisco. Obviously I missed the significance.

    I always :\ when I see someone describe the kill switch as rm -Rf /* when it's some variety of mtderase or mtdwrite...
     
  9. btaroli

    btaroli Networkin' Nut Member

    So is it just a matter of the usual hygiene to avoid this? No web UI access from WAN. No default creds. Avoid password based auth (esp SSH).

    Or do we fully understand yet the vector used to get the initial payload on the device? It’s beginning to sound even nastier now, with pluggable modules in stage 3.
     
  10. Monk E. Boy

    Monk E. Boy Network Guru Member

    To my knowledge the only people who know the initial infection vector aren't telling anyone (e.g. security researchers, TLA - three letter agency - employees, malware authors). There's lots of discussions about the layer 2 payloads and their variety but I haven't seen much of anything on the persistent infection.

    Practicing safe computing is always a good practice to follow, no matter whether there's malware running around or not. Running with defaults and exposing the management interface to the outside world is asking for trouble (which is why so many cable ISPs got whacked upside the head a couple years ago, they had their equipment exposed for remote management and surprise surprise someone figured out how to access it). If anything is exposed to the internet it needs to be hardened and isolated, which you're not going to be able to adequately do with consumer hardware (so don't expose it).
     
  11. btaroli

    btaroli Networkin' Nut Member

    Yeah especially when they have hardcoded logins or other backdoors. OK. I was just making sure I hadn’t missed some important posting on the subject. I follow the usual practices for my network, especially for outward facing bits.

    It scares me that so many people just plug these things in and then them on without doing /anything/ else. Sigh.
     
  12. Monk E. Boy

    Monk E. Boy Network Guru Member

    The really scary things are IoT devices - cameras, "smart" tvs, appliances, etc. They're on your network, they even open holes to be access from the internet, but they routinely have hard-coded default passwords for accessing them via telnet/ssh and rarely, if ever, get updated. Some "security" cameras don't even use flash for their firmware, meaning they can't be updated short of desoldering a chip and soldering on a new one. They're already widely attacked by multiple exploits like Mirai and its children to launch DDoS attacks. People buy these things and put them on their network and refuse to be held accountable for their misuse. God forbid their ISP block traffic to or from their poorly engineered cameras, its lawsuit city.
     
  13. btaroli

    btaroli Networkin' Nut Member

    Yeah, I think people should really be thinking about access isolation not only from the Internet but within their networks. Whether that’s done with VLAN and access controls in a single router or nested routers that created rings of permission.

    In my case, I use VLAN that span between a router and WiFi AP. Each VLAN has isolated SSIDs. WiFi and wired devices don’t share VLAN.

    One fully untrusted network has nothing but IoT WiFi crap. Allowed slow internet access and can be accessed from trusted devices.

    One mostly untrusted guest network for visitors and untrusted phones and tablets. Allowed slow internet access.

    One WiFi for very small number of semi-trusted devices that get pinholes access on certain ports to certain trusted services (similar to the WAN NAT/PAT filters). Allowed normal bandwidth to internet as well.

    Powerline network for small number of semi-trusted devices (more limited pinhole access) that need a little extra juice than WiFi can do. Allowed normal bandwidth to internet as well. Accessible from more trusted zones.

    Fully wired network for servers and desktops. Haven’t elected to split these apart yet, but that might be coming. Can access our to everything but very constrained inward access, if any.

    Is it overkill? Maybe. But for the peace of mind knowing that I have proper isolation of devices based on trust level (and varying bandwidth assignments), it doesn’t hurt.

    But none of that help if the network devices at the heart of it become compromised. So I’m keeping a close eye on a (never ending) variety of stories like this one to try and ensure that the baddies aren’t being bad on my stuff. It’d sure be nice if someone made this easy, but it’s not a simple threat landscape.
     
  14. ruggerof

    ruggerof Network Guru Member

  15. ruggerof

    ruggerof Network Guru Member

  16. btaroli

    btaroli Networkin' Nut Member

    Thanks for those. It’s a bit squishy on the subject of the initial vector. Some form of web vuln or other backdoors is presumed? And one that grants root auth so to they can modify config and flash MTD.

    It’s also curious about the types of devices. Routers, routers with “NAS” function, and proper NASes. A bit confusing, though, since most NAS’es wouldn’t really rely upon MTD for startup and config, as most routers would.

    This does seem to support my pondering whether general hygiene is a defense against this. Don’t expose anything administrative to WAN, always change login creds (including admin user name if possible), and always always have everything behind a firewall (no DMZ!). And if you’re going to expose sshd, insist on certs only (no password auth)... though VPN would be preferred.

    Whatever the details it’s nasty! D:
     
  17. Monk E. Boy

    Monk E. Boy Network Guru Member

    Yes and no. Yes, its detailed, although I think the Cisco stuff is also detailed. However it doesn't detail the 1st stage infection vector. How does it get onto the router? They even state
    Without knowing how it gets onto the router it's impossible to prevent it from getting onto the router.

    It does detail what happens after it gets onto the device. I suppose one could create directories in the folders its creating files and then try to chmod 000 the directories. Creating directories where it expects to create a file (or vice versa) is an old trick that sometimes trips up hastily written executables. Though it tends to work better on Windows.

    Now, the problem here is that nothing about what's detailed is actually permanent on Tomato (or the busybox flavors I'm familiar with). The contents of /var get wiped on reboot, which would make this a non-persistent infection. Since it is persistent that means they're writing to someplace that survives reboots. In fact I can't create /update/test since the root filesystem is read-only. I'm going to guess this particular variant is intended to infect an x86 NAS running a customized Linux install.

    That being said, VPNFilter seems to be in active development by the state actor. The vectors they used for the initial infections may not be the same vector they're using now. And without actually seeing an infection take place in a controlled environment, which most malware tries to detect, it's hard to know how it happens.

    I guess my point after all of this is it's too early to even suggest that Tomato developers do something about VPNFilter. The details just aren't out there yet.
     
  18. eibgrad

    eibgrad Network Guru Member

    State sponsored malware should be considered an act of war. (just sayin') :)
     
  19. RMerlin

    RMerlin Network Guru Member

    Then I guess we're in the middle of World War 3 already, because every major nations are doing it, including the US.
     
  20. Monk E. Boy

    Monk E. Boy Network Guru Member

    There's a line between trying to destroy a nation's uranium centrifuges and trying to destroy a nation's power grid.
     
  21. RMerlin

    RMerlin Network Guru Member

    It's still an act of war.
     
  22. kille72

    kille72 LI Guru Member

    Last edited: Jul 4, 2018
    nisarg86 likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice