VPNFilter malware infecting 500K devices is worse than was thought | Hacker News Reader

VPNFilter malware infecting 500K devices is worse than was thought

arstechnica.com

48 pointsjoewee44 comments

> To accommodate for this limitation, stage 1 relies on a sophisticated mechanism to locate servers where stage 2 and stage 3 payloads were available. The primary method involved downloading images stored on Photobucket.com and extracting an IP address from six integer values used for GPS latitude and longitude stored in the EXIF field of the image. When Photobucket removed those images, VPNFilter used a backup method that relied on a server located at ToKnowAll.com.

That sounds as sophisticated as a drug dealer calling their pills “beans” or “almonds”. Like, it’s intelligent, but it’s just 1 step removed from just coding in the IP directly.

In this space (journalism) any previously unknown (by the journalist) method of obfuscation is, almost by definition "sophisticated"

Personally, I'd have said "clever" and "probably indicative of a trend, which is going to continue" and "don't assume wiping EXIF headers stops this, because a bunch of meta data is out there in ways you don't yet understand"

hiding things in meta data, is why IP over ICMP works.

In the paytv hacking world, users would install a switch on the EEPROM’s WriteEnable line.

That way, destructive updates could be blocked for as long as possible. Or save you from having to re-flash your receiver through desoldering a TSOP.

Perhaps we need the same thing on routers.

Or a group to run a “honeypot” of routers with a sensor on this EEPROM pin to identify when unauthorized updates have been installed and need investigation.

This won’t work for non-persistent hacks. But for anything that wants to last longer than a reboot...

A switch wouldn't work on a serial EEPROM or serial Flash chip, you'd need a microcontroller-in-the-middle that proxies or virtualizes the EEPROM and ignores writes. This sort of thing would also break partitioned storage, where persistent state and the system image are located on different partitions within the same Flash chip.

I do recall 24 series 8-pin serial EEPROMs having a write enable line as well that could be locked via a switch.

Looking quickly on a random manuacturer’s 93 series, I don’t see such a line, BUT, programming operations are blocked when the voltage is below a certain level. A couple diodes on the Voltage line could be put in séries (via switch) to prevent writes unless desired.

Of course, if writes are required at some level for normal operation, your chip firewall strategy works much better.

The paytv providers actually implemented a flash writeability check (without trIggerinf a write) upon bootup. One of my ideas was to emulate the 24-series eeprom entirely. For the bigger “TSOP” chips, someone devised a high-speed logic gate that was fast enough to allow the check to pass, but still prevent actual writes.

And oh ya, a JTAG interface could provide interesting real-time analysis of what’s going on.

Depends on the device. Some do have *WE pins.

And some weird ones have a WE pin that only impacts half the memory space. In that case, sub in a chip that blocks it all-or-nothing, but some firmwares may not like that.

The most concerning aspect of this is the lack of details surrounding the initial attack vector and the fact that the IoC list is effectively useless to anyone downstream of these devices which sit at the perimeter of your network.

Anyone else having fun with the minor panic attacks incited by slow page-loads?

My speculation is that the attack vector was only in stream for a short period of time...

So unless you were capturing incoming packets at that time, we may not know.

In this URL, https://blog.talosintelligence.com/2018/05/VPNFilter.html?m=...

it mentions snort rules for detection and protection for VPNFilter and ClamAV Signatures.

But it didn't explain how to use them.

The way I understand SNORT after googling it, I need to able captures the traffic (wan port) and feed that to SNORT for analysis, is that correct?

Also for ClamAV, do I need to clone/mount the rootfs from the wifi router to Linux and use ClamAV to scan that rootfs for those signatures?

The URL mentions the infested device have /var/run/vpnfilterm, /var/run/vpnfilterw. I checked they are not in my wifi router's fs.

The URL also mentions it modified/insert entry the crontab, but I can't find what exe name, possible file locations I should search in my router. Do anyone else know such info?

The details on this are very vague. No one knows or is sharing the initial attack vector. It could be a browser spear phishing attack that then attempts to use known default passwords for these routers and uploads a custom firmware image or backdoor script. The only thing that I don't get is why rebooting resolves the issue. This can't be accurate, if the compromise was via a user, its only a temporary resolution, and if the backdoor is as sophisticated as they say, it should definitely have persistence that last beyond reboot.

Rebooting removes later stages, the first stage is persistent but one of the AV companies took down the domain that the later stages are retrieved from, effectively cutting it off from those stages.

Thanks for the clarification!

Per the last thread: https://news.ycombinator.com/item?id=17162245

This is a multi-vector, multi-architecture attack, and while we know some of the vectors, we don't know them all.

Some were due to vulnerabilities in the router's web admin. Mikrotik routers were compromised in this way. In this case, it was not a default password issue (as their is no default password on Mikrotiks), but an attack that would work regardless of credentials. Anyone running firmware older than March 2018 who was not smart enough to block port 80 on their public interface likely got owned. Mikrotik is not a consumer router, but they are cheap and powerful, and thus attractive to end users, many of whom don't know what they are doing. Thankfully, the Mikrotiks are easily fixable. Upgrade the firmware, and stage 1 gets wiped out.

But most consumer routers, by default, do not expose the web admin in this way, and were compromised by some other vector, and we have yet to get to the bottom of all of them. Many of these routers, due to their architecture, cannot be fixed with a firmware upgrade.

How about routers (and IoT devices for that matter) that have a ROM image, with a user intitiated ability to actually obliterate the entire contents of NVRAM and flash? i.e. the firmware (which is made up of various parts, multiple stage bootloader, kernel, initrd, root, NVRAM, maybe proprietary radio firmware and/or baseband files) would be wiped out. The ROM would have a very limited ability to "phone home" only via wired connection, and get an updated firmware payload.

Obviously the idea is to make sure the image in ROM is simple enough that it's really damn unlikely that it can be attacked, or attacked before the correct and intended firmware is downloaded and installed.

Sorry to sound like a broken record on this post, but Mikrotik does this. Everything can be flashed. Bootloader and OS. You can even get into a bricked unit via MAC address and their Netinstall utility, and wipe the whole thing with a clean image.

Dumb question about this malware... with so many infected routers, why was this not noticed sooner? Just monitoring incoming/outgoing data should reveal that the routers are "calling home" at some point, yes?

No one was looking? It looks like the deployment was fairly sophisticated, these typically use things like twitter, instagram to send commands to compromised devices. These tend to only be discovered when they are used to attack a target or when someone happens upon a C&C machine.

IIRC, previous articles (a few weeks ago) stated that Cisco (at least, and possibly others) have known about and been “tracking” this for months but they finally announced it publicly because $someEvent was approaching and they were afraid this botnet would be used to disrupt it.

(I’m on my phone or else I’d look into this more and give you more specific info instead of vague recollections but, if you (or anyone else here) are interested, this should at least give you somewhere to start.)

It was noticed by some vendors. They just didn't know what it was. Mikrotik, for example, posted a warning on their forums months ago, when their users noticed a sudden uptick in attempt to get at ports 80 and 8291. In this case the attack was scanning for the existence of port 8291 to identify these routers, and then attempting an exploit on port 80. It was only months later that we all learned the VPNFilter was the culprit.

Any startup writing router firmware in Rust?

ARM/MIPS are Tier 2 platforms for Rust: https://forge.rust-lang.org/platform-support.html

I don’t heard of anyone rewriting the Linux kernel and network drivers — which is 90% of what all this “router firmware” is, plus a (sometimes) slick web interface to manage it, along with uboot — in Rust yet so I’m gonna say no.

It’s almost like no one considers it worth the effort.

Any suggestions for a good router that is immune from this nonsense?

As in another post, I’d suggest buying any router, taking it apart, identifying the flash chip, find the write-enable line in the data-sheet and MITM that line with a flip switch to block updates at all times.

That's actually a really good idea! I would love to see this built-in to future router models after something widespread like this. It's fairly reasonable to force users to be physically present to update. Plus, you could force them to flip the switch back by not working until the write-enable line is disconnected again.

BIOS updates used to be like that. You would have to switch a jumper to do the update.

Then they got rid of that, even though most people that bothered with BIOS updates could be directed to switch a jumper around...

It could have the unintended side effect of making people even less likely to upgrade firmware.

Ain't nobody got time for that.

Buy a small cheap computer with two ethernet ports and run debian.

And most importantly: keep it updated.

About the only thing I would trust without updates is a bsd box. And even that, may eventually fall victim.

which BSD? And how is hardware support these days?

Ok, but what if you are very busy and you don't have time for that.

https://openwrt.org/

You could build your own with pfSense.

What if you are too busy for that?

An updated one, with sane defaults.

Can we assume that dd-wrt and tomato are safe(r) from this?

I wouldn't trust DD-WRT with security further than I can throw it [1] [2]. Please migrate to OpenWRT or something else that's modern and maintained by more than one person.

[1] https://github.com/mirror/dd-wrt/blob/master/src/router/http...

[2] https://github.com/mirror/dd-wrt/blob/master/src/router/http...

Noted. Weekend project!!!

You just reminded me that some of the more obscure dd-wrt bins (for not so popular routers) and might be dangerous stuff.

Fuzzing it should be cool and fruitful. Have fun :).

According to the article, no.

> Williams said he has seen no evidence VPNFilter has infected devices running Tomato, Merlin WRT, and DD-WRT firmware, but that he can't rule out that possibility.

Reply on news.ycombinator.com