VPNFilter Malware

[dieter]

Can someone please explain WHY after a factory reset and installing the latest FW, I can't use my prior save config file??

If my config file was hacked, would I not be able to see this by reviewing the config settings?

Can the config space hold malware code?

 

[ColinTaylor]

Can someone please explain WHY after a factory reset and installing the latest FW, I can't use my prior save config file??

Just answered your question here.

 

[sfx2000]

The last Airport Extreme is VxWorks based.

The Airport Extreme AC is NetBSD based, just like the 802.11n models

 

[kfp]

The Airport Extreme AC is NetBSD based, just like the 802.11n models

Oops, seems like my information is dated, thanks. I’ve never poke at one myself and just knew that in passing. Probably one of the earlier models then.

 

[FreshJR]

I think a file-system/nvram snapshot might be a wonderful trigger for everything.

Send an email/notification/etc upon trigger

--> If it is a user made change then it is harmless

--

--> If it is an unknown change it is malware

 

[ColinTaylor]

I think a file-system/nvram snapshot might be a wonderful trigger for everything.

The difficult bit would be filtering out the parts that are constantly changing as part of the router's normal operation. But doing a check on the ROM/CFE parts should be do-able. You wouldn't even need to create a snapshot you could just compare the current and previous checksums.

 

[FreshJR]

The difficult bit would be filtering out the parts that are constantly changing as part of the router's normal operation. But doing a check on the ROM/CFE parts should be do-able. You wouldn't even need to create a snapshot you could just compare the current and previous checksums.

For regular users I agree! There would be too many emails for NVRAM/file system changes (Even if there were not excessive emails, typical users would not be able to discern authorized/unauthorized changes)

For the majority of the SNBFORUM community any UNATHORIZED (redundant) changes would be a nice welcome!

eg.

Make a change --> email expected
Unauthorized change --> email --> investigation procedure

--

The worst is the stage3 payload that bricks your router!!

--Stage1 --> nvram/cron infection
--Stage2 --> file system persistance
--Stage3 --> bricked router

--

Source

https://blog.talosintelligence.com/2018/05/VPNFilter.html

filesytem physical reported locations:

/var/run/vpnfilterm
/var/run/vpnfilterw

--

The email/report can explicitly list the NEW/CHANGED files. Anything expected/recent can be ignored,

 

[ColinTaylor]

I've just written a simple script that constantly monitors the NVRAM variables. You'd have to filter out at least login_timestamp because that is constantly being incremented all the time you are logged into the GUI. There may be others, time will tell. But this assumes they're using NVRAM in the conventional way (I wouldn't ).

I suspect they might be overwriting the CFE with their own code, so as I said earlier it would be simple enough to do an md5sum on that. You could check explicitly for files in tmpfs like /var/run/vpnfilterm, but at the moment those are the only two files mentioned, and that was on an Intel platform.

 

[ColinTaylor]

Edited 2018-06-09@23:52 for minor cosmetic changes.

@FreshJR Here's a couple of "ugly" scripts that I've been playing around with. They need to be run in background and they log their messages in syslog. They may not work properly on hardware/firmware combinations different from mine!

This one looks for changes to NVRAM variables (even if they haven't been committed yet).

# cat NVRAM_monitor.sh
#!/bin/sh

oldlist=/tmp/nvram.old
newlist=/tmp/nvram.new
difflist=/tmp/nvram.diff

nvram show 2>/dev/null | grep -v "login_timestamp" | sort > $oldlist
while sleep 300
do
    nvram show 2>/dev/null | grep -v "login_timestamp" | sort > $newlist
    diff $oldlist $newlist > $difflist
    if [ $? -ne 0 ]; then
        cat $difflist | grep -v "\--- " | grep -v "+++ " | grep -E "^\+|^-" | logger -t NVRAM_monitor
    fi
    mv $newlist $oldlist
done

This one checks for any changes anywhere in the flash memory, so that includes the CFE and operating system. Expect to see frequent hits on mtd1 (NVRAM) and mtd4 (JFFS). The md5sum will eat up all your CPU cycles so don't run it too frequently.

# cat MTD_check.sh
#!/bin/sh

oldlist=/tmp/mtdlist.old
newlist=/tmp/mtdlist.new
difflist=/tmp/mtdlist.diff
echo "These are the initial checksums:" > $oldlist    # Create a dummy file the first time through

while sleep 1800               # This is very CPU intensive so don't run it too often
do
    cat /proc/mtd | tail -n +2 | tr -d ":" | while read dev size erasesize name
    do
        echo $name $(md5sum /dev/$dev) >> $newlist
    done

    diff $oldlist $newlist > $difflist
    if [ $? -ne 0 ]; then
        cat $difflist | grep -v "\--- " | grep -v "+++ " | grep -E "^\+|^-" | logger -t MTD_check
    fi
    mv $newlist $oldlist
done

 

[Adamm]

Edited 2018-06-09@23:52 for minor cosmetic changes.

@FreshJR Here's a couple of "ugly" scripts that I've been playing around with. They need to be run in background and they log their messages in syslog. They may not work properly on hardware/firmware combinations different from mine!

This one looks for changes to NVRAM variables (even if they haven't been committed yet).

# cat NVRAM_monitor.sh
#!/bin/sh

oldlist=/tmp/nvram.old
newlist=/tmp/nvram.new
difflist=/tmp/nvram.diff

nvram show 2>/dev/null | grep -v "login_timestamp" | sort > $oldlist
while sleep 300
do
    nvram show 2>/dev/null | grep -v "login_timestamp" | sort > $newlist
    diff $oldlist $newlist > $difflist
    if [ $? -ne 0 ]; then
        cat $difflist | grep -v "\--- " | grep -v "+++ " | grep -E "^\+|^-" | logger -t NVRAM_monitor
    fi
    mv $newlist $oldlist
done

This one checks for any changes anywhere in the flash memory, so that includes the CFE and operating system. Expect to see frequent hits on mtd1 (NVRAM) and mtd4 (JFFS). The md5sum will eat up all your CPU cycles so don't run it too frequently.

# cat MTD_check.sh
#!/bin/sh

oldlist=/tmp/mtdlist.old
newlist=/tmp/mtdlist.new
difflist=/tmp/mtdlist.diff
echo "These are the initial checksums:" > $oldlist    # Create a dummy file the first time through

while sleep 1800               # This is very CPU intensive so don't run it too often
do
    cat /proc/mtd | tail -n +2 | tr -d ":" | while read dev size erasesize name
    do
        echo $name $(md5sum /dev/$dev) >> $newlist
    done

    diff $oldlist $newlist > $difflist
    if [ $? -ne 0 ]; then
        cat $difflist | grep -v "\--- " | grep -v "+++ " | grep -E "^\+|^-" | logger -t MTD_check
    fi
    mv $newlist $oldlist
done

Realistically while the idea has good intentions, putting it into practice shows many flaws.

For starters with the nvram, there's so many variables that constantly change, a user would be bombarded by alerts. Same goes for the filesystem, so many junk files like pid storage, everything in /proc and even the syslog would trigger it. There's just too many moving parts to monitor everything for changes.

Unfortunately until there is more information available, there's not much that can be done mitigation wise. At this point I don't even think there's been a documented case on an Asus router to work from, only the general information of C&C IP's/URLs/5 files that appeared on other systems.

 

[FreshJR]

Realistically while the idea has good intentions, putting it into practice shows many flaws.

For starters with the nvram, there's so many variables that constantly change, a user would be bombarded by alerts. Same goes for the filesystem, so many junk files like pid storage, everything in /proc and even the syslog would trigger it. There's just too many moving parts to monitor everything for changes.

Meh, you can work around it with more thinkering! Colin said that was a crude/ugly proof of concept. With more work it can be polished into something nice!!

Md5 of CFE ran daily <— GREAT IDEA
Nvram (with common variables whitelisted) <— GREAT IDEA
Monitoring iptables <— GREAT IDEA

I had a script that monitored for any file system changes when I was debugging my MyCloud NAS.

Spoiler

Rant incoming:
I found that a stupid WD implemented tons of logging that woke the hard drive from deep sleep once every logrotate (every 3-10hrs) and another check ran once daily from a cron task.

The kicker was that these logs were pointless stats that were not even accessible to the user or sent back to WD as telemetry data. Literally pointless logging for the ^{%€ of it.

This broken a sleep feature put tons of stress on the head and motor when it constantly had to park/unpark spinup/spindown.

I am convinced that leaving the disk running 24/7 was better for longetivity then their garbage programming!!

While on the topic they had a stupid file system scanner/thumbnail generator that would hammer the disk and kill the cpu more than norton on a pentium 4. It was literally a daily 2hour scan that only existed to calculate disk usuage by media type && thumbnails for their phone app. Oh, and since the block size was 4MB, I think each thumbnail was 4mb on disk !!!

And final tirade. A hard coded, hidden from the public, root username/password. (WHAT THE HELL!!!)

Love the little thing, but how can they have gotten so much wrong!!! I am not even a programmer and noticed all this crap!

I might look for the method I used to hook into filesystem access and repurpose it on non whitelisted directories.!!

Don’t get my wrong, your script is great but 0days are insane. I love reading the reverse engineering tear downs on w00tsec.

Edit for instance look at this crazy attack.

https://w00tsec.blogspot.com/2016/09/luabot-malware-targeting-cable-modems.html?m=1

On the outside it looks like a brute force username/password attack. In reality the fields used non sanitized input but the privledges were limited. The attacker spammed successive echo strings essentially the binary code of his executable to gain privledges!

Your script would catch this attack, but these hackers are VERY creative.

 

[ColinTaylor]

For starters with the nvram, there's so many variables that constantly change, a user would be bombarded by alerts.

That's exactly the same point I made in post #107, but having run those two scripts most of yesterday I was very surprised to see that the NVRAM rarely changed unless you were logged into the router. Very surprised.

Same goes for the filesystem, so many junk files like pid storage, everything in /proc and even the syslog would trigger it. There's just too many moving parts to monitor everything for changes.

Yes this is more problematic. I did create another script like the other that just monitored changes to the filesystem. For starters you wouldn't monitor everything, so not /proc. In fact my thinking was that the only writable part of the file structure is under /tmp so that's what you'd look at. The number for changes wouldn't be too bad if it weren't for the fact that the USB drives are also mounted there. And of course that's full of all sorts of user add-ons (entware, media, log files, etc.) so the number of changes is overwhelming. I could start filtering out my USB drives but then it would be difficult to make a script that was useful for anybody other than myself. (It would be a lot easier if there was a proper version of find built into the firmware )

 

[FreshJR]

Sorry Colin, this version of find does not exist

find -malware -delete

/s

 

[RMerlin]

Realistically while the idea has good intentions, putting it into practice shows many flaws.

For starters with the nvram, there's so many variables that constantly change, a user would be bombarded by alerts. Same goes for the filesystem, so many junk files like pid storage, everything in /proc and even the syslog would trigger it. There's just too many moving parts to monitor everything for changes.

Unfortunately until there is more information available, there's not much that can be done mitigation wise. At this point I don't even think there's been a documented case on an Asus router to work from, only the general information of C&C IP's/URLs/5 files that appeared on other systems.

More practical approaches as used by some Linux servers:

1) Monitoring the list of running processes, and reporting any change
2) Monitoring MD5 hashes for some key filesystem components, such as Busybox, openvpn/openssl, etc...
3) Monitoring listening tcp/udp ports (these should change very little, unless restarting a service that uses a random port such as miniupnpd)
4) Monitoring iptables rules (these should change very little, unless using UPnP)

 

[sfx2000]

Too bad somebody couldn't put something together like Tripwire or AIDE

 

[ColinTaylor]

@FreshJR Just for fun and completeness here is the final script that monitors file changes under /tmp but excludes mounted drives (/tmp/mnt). [Sooo much easier if there were a proper find command ]

# cat /jffs/scripts/file_monitor.sh
#!/bin/sh

oldlist=/tmp/files.old
newlist=/tmp/files.new
difflist=/tmp/files.diff
# Be carefull, these are regular expressions not filenames
cat <<EOF >/tmp/files.whitelist
 /tmp/mnt/
 /tmp$
 /tmp/syslog.log$
 /tmp/syslog.log-1$
 /tmp/files.old$
 /tmp/files.new$
 /tmp/files.diff$
 /tmp/files.whitelist$
 /tmp/nvram.old$
 /tmp/nvram.new$
 /tmp/nvram.diff$
EOF

find /tmp -exec ls -de {} \; | grep -vf /tmp/files.whitelist > $oldlist
while sleep 300
do
    find /tmp -exec ls -de {} \; | grep -vf /tmp/files.whitelist > $newlist
    diff $oldlist $newlist > $difflist
    if [ $? -ne 0 ]; then
        cat $difflist | grep -v "\--- " | grep -v "+++ " | grep -E "^\+|^-" | logger -t file_monitor
    fi
    mv $newlist $oldlist
done

 

[makksi]

I see ASUS at least for my router have released a new firmware just 10 days ago. The changelist includes lots of passwords/security access fixes. Do you think it is targetting the VPN filter malware and is there already a new merlin version aligned to it?

---


Versione 3.0.0.4.382.506242018/06/0139.86 MBytes

ASUS RT-AC56U Firmware version 3.0.0.4.382.50624
Security fixed
-Fixed password stored in plain text (CVE-2017-15656)
Special thanks for Blazej Adamczyk contribution.
-Fixed web GUI authorization vulnerabilities.
-Fixed Smart Sync Stored XSS vulnerabilities. Thanks to Guy Arazi's contribution.
-Fixed CVE-2018-5721 Stack-based buffer overflow.
-Fixed XSS vulnerability. Thanks to Yonghui Han of Fortinet's FortiGuard Labs.
-Fixed CVE-2018-8877, CVE-2018-8878, CVE-2018-8879
-Fixed plain text password vulnerability in lighthttpd
-Fixed information disclosure vulnerability. Thanks to Haitan Xiang and Fand Wang.
-Fixed CVE-2018-8826 remote code execution vulnerability. Thanks to Chris Wood.
- Improved system stability.
- Modified Quick Internet Setup wizard process.
- Main SSID and guest network can hide independently.
- Modified the EULA for DDNS, AiProtection, Adaptive QoS, Traffic Analyzer, Web history, Feedback.
- Added Privacy page in Advanced settings
- Fixed IPv6 bugs
- Modified USB 3.0 related strings.
- Added more protection mechanism for OpenVPN account.

 

[FreshJR]

Versione 3.0.0.4.382.506242018/06/0139.86 MBytes

WOW that is a lot of CVE's fixed in one go.

I wonder which ones were exposed just running DDNS/VPN and having everything else closed.

 

[RMerlin]

WOW that is a lot of CVE's fixed in one go.

I wonder which ones were exposed just running DDNS/VPN and having everything else closed.

That's because this is a 382 firmware, which isn't updated as frequently. Many of these CVEs were fixed weeks ago in the 384 firmware releases.

 

[Jerry12]

More practical approaches as used by some Linux servers:

1) Monitoring the list of running processes, and reporting any change
2) Monitoring MD5 hashes for some key filesystem components, such as Busybox, openvpn/openssl, etc...
3) Monitoring listening tcp/udp ports (these should change very little, unless restarting a service that uses a random port such as miniupnpd)
4) Monitoring iptables rules (these should change very little, unless using UPnP)

Great ideas.

More specific to VPNFilter, one could watch for the files and processes mentioned in the Cisco Talos blog under “'dstr' (device destruction module).” That lists "files and folders related to its own operation" like /var/run/vpnfilter that the device destruction module deletes and running processes like vpnfilter that it kills before overwriting everything and rebooting.