VPNfilter official statement

Fri Jun 08, 2018 4:39 am

Re: ... since Mikrotik doesn't allow us shell access to our routers to perform this kind of examination. Lack of shell access also makes it hard to tell if upgrading a compromised device actually removes the compromise ... VPNfilte ...

Re: ... A thought on how to possibly examine a Mikrotik x86/CHR file system. ... Then just cd /mnt/"Mikrotiks-x86-CHR-file-system ... I would guess the bad guys already do something like this all of the time when looking for possible exploits on Internet connected devices ...

Got it mounted and now I can cd into the ROS filesystem(s)
*Please don't ask me how to do this - I assume any decent Linux admin can already probably do the same thing*

So a question to me is what is supposed to be in the /dev/sda /rw/store/user.dat file -and- ??? (take a look yourself if you know how to). Any security concerns here ?
I am by no means a Linux internals person , but I can't help but ask myself a question "What other methods/accounts might be built-in that we don't have normal access to see or manage?"
Part of the reason I ask myself is way back in the late 1980s I did find some hidden access (non-documented) systems in another very popular operating system which was in all distributions.

North Idaho Tom Jones

ingdaka · Fri Jun 08, 2018 8:38 am

Full list of affected RouterBoards since now:
MIKROTIK DEVICES:
CCR1009 (new)
CCR1016
CCR1036
CCR1072
CRS109 (new)
CRS112 (new)
CRS125 (new)
RB411 (new)
RB450 (new)
RB750 (new)
RB911 (new)
RB921 (new)
RB941 (new)
RB951 (new)
RB952 (new)
RB960 (new)
RB962 (new)
RB1100 (new)
RB1200 (new)
RB2011 (new)
RB3011 (new)
RB Groove (new)
RB Omnitik (new)
STX5 (new)
If you have any of them backup and export configuration! And save it in a secured place!

pe1chl · Fri Jun 08, 2018 11:05 am

Once your device is compromised it can do anything. What actual value is there in changing user-level rules within a compromised router for what it can do? It has already been compromised, by no less than one of the most sophisticated state-level malwares seen to date ...

There is no point in doing this for an already compromised router!
The value could be to add it to routers that are still unaffected, to avoid that it will become compromised.
Usually in malware like this, the attack can insert only a small amount of code e.g. the size of a buffer somewhere, and the code is used to "bootstrap" the actual
malware into the device by making it do an outside connect to a server or an already affected router to download the malware code.
That step is prevented by the output rule, and at that time the malware is not yet in full control of the router.
Sure, once the attackers know this they could first add an accept rule at the top of the output table but until they know and do that (and even assuming they can
do that in this part of the attack) it works. And with some logging attached it also serves as a journal of what happened.

It is similar to the way that works well to protect Windows machines from malware: add an AppLocker policy that forbids executing code from a location inside
the user profile (normally under C:\Users). The majority of malware introduced via webpages, infected office documents, etc. will first download some program
into the user's Downloads or Temp directories and run it. The AppLocker policy forbids that and that is where it ends. It also protects against users clicking on links
to .exe (and similar) files and clicking away the warnings that this will give. E.g. when "a Microsoft employee" calls and tells the user to visit some site to start
something like Teamviewer to enable them to help removing a virus. Like the above, this is not a perfect measure but it works 99.9% of the time to protect naive users.

pe1chl · Fri Jun 08, 2018 11:06 am

Full list of affected RouterBoards since now

It is pointless to post this list, it was made by people who do not know MikroTik and do not know that all routers
are running the same firmware. You can safely assume that any device running RouterOS is affected.

R1CH · Fri Jun 08, 2018 5:23 pm

Thanks, so other than the microtik update service there is really no need for port 80 traffic on the output chain (from the router either with a source port of 80 or with a destination port 0f 80).

Be aware that compromised devices could serve 2nd stage payloads from any port - blocking OUTPUT port 80 will help a little bit but ideally you should block everything and use a whitelist approach to open up legitimate IPs / ports. Port 443 (HTTPS) is a popular port for web hosting too if you still prefer to only block web traffic.

Fri Jun 08, 2018 6:15 pm

In looking into one of my possible compromised Mikrotik ROS systems, I see in the underlying vmlinuz (compressed Linux kernel) user dat file what appears to be two additional user accounts which are not visible in the Mikrotik user manager system.
The two accounts in question are:
adminb (as in admin Backdoor)
adminr (as in admin Remote -or- admin Recovery)

Are they supposed to be there or is this Mikrotik ROS system VPNfilter compromised ?

Modestas · Fri Jun 08, 2018 7:46 pm

Are they supposed to be there or is this Mikrotik ROS system VPNfilter compromised ?

Do you have another clean router with up to date OS to compare? Actually, it should be possible to flash clean router with older SW.

Modestas · Fri Jun 08, 2018 8:04 pm

Just upgrade your routers to RouterOS bugfix >6.40.8 or stable >6.42.1
As I said, doing that I would lose opportunity to find out if our otherwise heavily secured network has been breached. So I would really appreciate to know, i mean really know, not only guess if we were infected.

No one asked me for advice, but I would restore normal network operation first while suspected device could go to the lab for forensic analysis. That is, perimeter router would be replaced asap with another, upgraded to the latest OS and configured from factory default settings.
But it's also valid option to wait for evidence of some fancy bears wandering in the internal network.

eXS · Sat Jun 09, 2018 2:02 am

It was less than a month between the increased botnet http vuln (03/28) & the discovery of the winbox vuln (04/23)

Can someone confirm VPNfilter exclusively utilizing the http vuln ?

A post in the http vuln (03/28) thread: "Also via the winbox port ... We think there is a circular second exploit that works in a similar way to this."

- It was repeatedly stated the winbox port was getting hit only to identify the device as MT.

I don't have a ton of time for forum searches, but i believe there were a few winbox vuln posts floating around between the http & winbox discoveries. The timeline feels fuzzy.

- Sorry about the edits

m4t7e0 · Mon Jun 11, 2018 1:50 pm

Hi All,
yesterday my Router RB750UPr2 with latest BugFix version was attached from something... Apparently just a DNS default server Change..
The device was opened to public ip *80 *8291 *21 *22 (i need to do leave it for see what this attack do to my router), so i get the first attack. After this change i make the upgrade to latest Stable Version 6.42.3, and changed the defaut port with *8000 *8019 *8021 *8022.
After one night i can axess to my router via any service ssh telnet web winbox and with MAC-Telnet after the password prompt the client close the connection (like if sent wrong password)...

next friday i wil make a netinstall setup for clean the device...

I hope my experience can help you.

pwuk · Mon Jun 11, 2018 10:36 pm

In looking into one of my possible compromised Mikrotik ROS systems, I see in the underlying vmlinuz (compressed Linux kernel) user dat file what appears to be two additional user accounts which are not visible in the Mikrotik user manager system.
The two accounts in question are:
adminb (as in admin Backdoor)
adminr (as in admin Remote -or- admin Recovery)

Are they supposed to be there or is this Mikrotik ROS system VPNfilter compromised ?

Thanks for posting this

Looking at a vanilla mikrotik x86 install - version 6.37.5, and CHR version 6.42.3, the only user mentioned is "admin"

When I create new ones, I see them appear in user.dat, but no entry for "adminb" or "adminr"

What architecture is your potentially compromised system?

Benjamin9 · Tue Jun 12, 2018 10:03 am

I understand ... but we need assume that Mikrotik is doing their best and try to deliver software without bugs. If we/they have no proof that something is "broken" then they always could say "YES, it is safe". gclub

Tue Jun 12, 2018 6:00 pm

What architecture is your potentially compromised system?

This was a in-house lab x86 system (non-production - but live Internet connected) system we sometimes used to ping to and btest to. Because it was not production and stand-alone , it had no firewalls on it.

pwuk · Tue Jun 12, 2018 9:52 pm

What architecture is your potentially compromised system?
This was a in-house lab x86 system (non-production - but live Internet connected) system we sometimes used to ping to and btest to. Because it was not production and stand-alone , it had no firewalls on it.

Interesting

I have a similar box, created a user called "theboss". This appeared in user.dat. I backed up user.dat first as user-old.dat
I then deleted that user, however the line didn't vanish from user.dat

I did an upgrade -- the line still didn't vanish, however concerningly the user-old.dat file didn't vanish either.

Perhaps a firmware upgrade would do the trick, but clearly cant' do that on an x86 instance.

jp · Wed Jun 13, 2018 3:53 am

Add the bandwidth test ports and this is what we do and it works. Good post.

FWIW, I use the following related best practices when I set up a router that has a public-facing interface:
reset all configuration settings, uncheck 'keep default settings'

Disable all non-essential services:
telnet

http

https

ftp

api

secure api

Create a whitelist of admin IP addresses/netmasks

Add the following firewall filter rules to the beginning of the list

Allow all admin whitelisted ips access to tcp 20,21,22,23,80,161,443,8291,8728,8729 on the input chain

Block all access to tcp 20,21,22,23,80,161,443,8291,8728,8729 on the input chain

Allow all admin whitelisted ips access to udp 161 on the input chain

Block all access to udp 161 on the input chain

Allow all established and related traffic (state) for both input and forward chains

The effect of this is that if a firmware upgrade accidentally clobbers one of these settings or one of my admins mistakenly deletes or disables a rule, I still have the other to fall back on.

For reference:
port 20 = ftp data port
port 21 = ftp control port
port 22 = ssh
port 23 = telnet
port 80 = http
port 161 = snmp
port 443 = https, sstp (do not block if you need to create an sstp connection to the box)
port 8291 = winbox
port 8728 = api
port 8729 = secured api

Set up the rest of your firewall as needed for your application.

Add a drop all rule to the input chain on the filter tab.

After an hour, make sure that you're getting packet counts on the drop all rule. If you're not, you've got another rule before it preventing packets from getting to it, and it's probably a misconfigured rule. It's pretty much a sure thing that you'll be getting traffic coming on the router's WAN interface that is unwanted traffic.

Chupaka · Wed Jun 13, 2018 1:43 pm

I have a similar box, created a user called "theboss". This appeared in user.dat. I backed up user.dat first as user-old.dat
I then deleted that user, however the line didn't vanish from user.dat

Try to change user's password - AFAIR, password history is also saved in user.dat

pe1chl · Wed Jun 13, 2018 2:09 pm

Of course it is quite typical (and to be expected) that a record in a user file is not completely wiped when the user is deleted, but instead there is some field that indicates active/inactive or there is a length field for the file, one of which is adjusted when you delete something. Looking in the raw disk image or even in the file itself you still see the old username.

pwuk · Wed Jun 13, 2018 6:23 pm

Certainly not the unix way
{code}
~$ grep testu /etc/passwd
testuser:x :1003:1003:,,,:/home/testuser:/bin/bash
~$ sudo userdel testuser
~$ grep testu /etc/passwd
{code}

But that's fine.

The way the underlying file system isn't wiped on an upgrade does make me slightly more concerned about how the internals work, if there's an exploit that exposed that internal file system

pe1chl · Wed Jun 13, 2018 6:37 pm

Unix uses the method of 1 line per user and a defined length of the file. When you add a user at the end and then delete it, the length of the file is decreased. But when you would look in the disk block directly, the entry for your deleted user would probably still be there. (depends on how the new file is written, directly over the old one or as a new file and then renamed over the old one)

Wed Jun 13, 2018 9:57 pm

What is Mikrotik's plan for everybody in the past that purchased Mikrotik-Crossroads and/or Mikrotik-RB500 series of wireless products ?
Are those long-time older Mikrotik owners just sh!t outta Luck & to bad & throw it in the trash can because there are no Mikrotik versions that are not vulnerable ???

In the past , I've sold and installed lots of them - grrrrrrr

North Idaho Tom Jones

Sob · Wed Jun 13, 2018 10:16 pm

@TomjNorthIdaho: I guess it's still the same (and unlikely to change) as last year, when the http server vulnerability was fixed, i.e. tough luck, use firewall.

Wed Jun 13, 2018 10:38 pm

@TomjNorthIdaho: I guess it's still the same (and unlikely to change) as last year, when the http server vulnerability was fixed, i.e. tough luck, use firewall.

Well I can make work-arounds , but most residential home users who have purchased Mikrotik WiFi routers probably have no idea that Mikrotik dropped all support for the older Mikrotik products.
Hey Mikrotik - how about making a fixed version for all of your older original customers so they are protected also. Or is this to be the new norm, that a few years after a purchase to assume that Mikrotik products migh have zero support and may have lots of severe known vulnerabilities later. There was no EOL with these products - they were just suddenly dopped without any advance planned EOL notices from Mikrotik.

Sob · Wed Jun 13, 2018 11:00 pm

I don't think there are too many residential users with surviving mipsle devices. But yeah, it would be a nice gesture to make fixed versions for them (at least two, for 5.x and 6.x). Then again, probably only few would appreciate it.

And yes, mipsle EOL was sudden and unexpected. If I remember correctly, there was even newer RC version in the works, but it had some problem on mipsle, and it felt like MikroTik just thought "oh screw it!" and dropped the whole platform rather than fixing it. It was a pity, because at least RB5xx were still good enough devices at that time.

Wed Jun 13, 2018 11:20 pm

I don't think there are too many residential users with surviving mipsle devices. But yeah, it would be a nice gesture to make fixed versions for them (at least two, for 5.x and 6.x). Then again, probably only few would appreciate it.

And yes, mipsle EOL was sudden and unexpected. If I remember correctly, there was even newer RC version in the works, but it had some problem on mipsle, and it felt like MikroTik just thought "oh screw it!" and dropped the whole platform rather than fixing it. It was a pity, because at least RB5xx were still good enough devices at that time.

I still happen to have some of both (Crossroads & RB-500 series) in production use - on those I've done what is possible to protect them via network attacks , but on the wireless vulnerabilities there are no solutions.
And I have several long-time customers who purchases these products for thier business/home use - and on those I have no admin management ability.

pe1chl · Thu Jun 14, 2018 11:22 am

The wireless vulnerabilities are mostly theoretical, it is not something that will go wrong just because it is there.
You need someone to go into the coverage area of your wireless and actively attacking it to then attack one of your users,
something that is not very likely to happen when looking at one particular installation.
The talk about those wireless vulnerabilities is mostly there to provide a newsfeed to IT news sites and for the ego
of those who discovered it, not really about the day-to-day risk they introduce to your or your customer's security,
especially when the wireless is only used as an access to internet, and another layer of secure communication (such as https)
is used on top of most communication.

This is of course different for the type of vulnerability in te admin interface that can be exploited over the internet and/or
using a worm, and which will eventually find its way to every vulnerable device. That is the type of thing you want to watch
out for, not those "we can hack your wireless" things.

Thu Jun 14, 2018 6:31 pm

The wireless vulnerabilities are mostly theoretical, it is not something that will go wrong just because it is there.
You need someone to go into the coverage area of your wireless and actively attacking it to then attack one of your users,
something that is not very likely to happen when looking at one particular installation.
The talk about those wireless vulnerabilities is mostly there to provide a newsfeed to IT news sites and for the ego
of those who discovered it, not really about the day-to-day risk they introduce to your or your customer's security,
especially when the wireless is only used as an access to internet, and another layer of secure communication (such as https)
is used on top of most communication.

This is of course different for the type of vulnerability in te admin interface that can be exploited over the internet and/or
using a worm, and which will eventually find its way to every vulnerable device. That is the type of thing you want to watch
out for, not those "we can hack your wireless" things.

Re: ...vulnerabilities...
All older ROS systems that are not updated and have IP services open to the Internet are totally vulnerable. I recently tested one tool that will scan IP networks then show the login name and password. I used it to scan my entire inside and outside IP networks and easily identified a dozen older ROS systems I have forgotten about or did not directly manage (some belonging to and managed by my customers). What bothers me the most is how fast and easy it was to gain full admin access to any Mikrotik ROS device that was not the latest version. Well - I did update and/or firewall what I could find on my network.
At this point in time, I think that all Mikrotik admins should be made aware just how fast and easy it is for anybody to gain full admin access to any Mikrotik ROS device that is running on a slightly older ROS version that also has IP services exposed to the Internet. ((( Lets put it this way --- It takes only seconds to scan a full Class C network an ISP might have and come up with a list of login and password for Mikrotik ROS devices ))) So all Mikrotik admins - please upgrade your ROS and also examine your firewall rules.

R1CH · Fri Jun 15, 2018 6:37 pm

For vulnerabilities that allow remote code execution or bypassing of authentication, Mikrotik should really be sending out a security advisory emails to every registered customer / active forum user. The winbox exploit for example is much worse than the httpd bug, and that was deserving of an email. A one line changelog entry that barely registers as a being a major security patch is not OK.

Fri Jun 15, 2018 6:42 pm

Security advisory emails were sent to all users that are in our database.

R1CH · Fri Jun 15, 2018 6:49 pm

The only email I got was about the old httpd exploit (below). Maybe something went wrong with the sending of the emails?

Subject: MikroTik: URGENT security advisory

"It has come to our attention that a rogue botnet is currently scanning random public IP addresses to find open Winbox (8291) and WWW (80) ports, to exploit a vulnerability in the RouterOS www server that was patched more than a year ago (in RouterOS v6.38.5, march 2017)."

mkx · Sat Jun 16, 2018 2:11 pm

Security advisory emails were sent to all users that are in our database.

I'm sure it's written somewhere, however would you kindly tell me how can I get my e-mail address to said database?

dlynes · Sat Jun 16, 2018 3:38 pm

I can confirm it was probably mailed out to everyone that was on the list. I had received it.

I have not, however received any updates from MikroTik on the subsequent updates to VPNFilter status where essentially all devices running RouterOS were added to the original four cloud core router devices.

To get added to the list (AFAIK), just create an account on mikrotik.com and during the signup process, make sure you check any checkboxes asking for updates from MikroTik.

pe1chl · Sat Jun 16, 2018 7:37 pm

I have not, however received any updates from MikroTik on the subsequent updates to VPNFilter status where essentially all devices running RouterOS were added to the original four cloud core router devices.

Of course those "updates" were not from MikroTik but from an external party who did not understand the matter and therefore published an incorrect advisory at first.
Over here on the forum it was always clear that the issue was not related to device type, and MikroTik have never mailed that it was.

Znuff · Sun Jun 17, 2018 12:30 am

Security advisory emails were sent to all users that are in our database.

The only e-mail I received was on 31st of March, with:

It has come to our attention that a rogue botnet is currently scanning random public IP addresses to find open Winbox (8291) and WWW (80) ports, to exploit a vulnerability in the RouterOS www server that was patched more than a year ago (in RouterOS v6.38.5, march 2017).

Tough I find myself now with a 6.41.3 that was recently Hacked. Luckily I have a backup config, but...

Can someone clarify what the "new" e-mail was supposed to say?

EDIT:

Also, this has been a constant issue with Mikrotik's e-mails. They arrive way to late. The GDPR notification arrived on 1st of June for me. Not sure if it was send before that, but it's usually like that. E-mails arrive weeks later. You should work on fixing that.

In other news, if I understand this correctly, ALL versions pre-6.43 (which is still in Release Candidate stage) are vulnerable to this 0-day WinBox exploit?

squeeze · Sun Jun 17, 2018 3:22 am

In other news, if I understand this correctly, ALL versions pre-6.43 (which is still in Release Candidate stage) are vulnerable to this 0-day WinBox exploit?

What are you talking about? What 0-day?

There hasn't been a public 0-day since Bugfix 6.40.8, Release 6.42.1, Release Candidate 6.43rc4, all back in April.

You do also realize the version numbers for each branch have no direct relationship with each other, right? They are probably only organized with the major version "6." so everyone doesn't lose their minds trying to track different version numbers over a decade.

vecernik87 · Sun Jun 17, 2018 8:04 am

ad zero-day - Technically, in 6.43rc17, something was changed in winbox service (thats why every RC since then has to use Winbox 3.14) to prevent MITM attack.
This change was not implemented in current/bugfix and is still related to release-candidate channel only. That means the attack vendor (even just theoretical) must be known at least to Mikrotik staff otherwise they would not come with such change. Knowing that, it is easy to conclude that current/bugfix channels are still vulnerable to this MITM attack.

I understand this is not related to VPNfilter, but it kind of fits the zero-day definition

Sun Jun 17, 2018 1:50 pm

in 6.43rc17, something was changed in winbox service (thats why every RC since then has to use Winbox 3.14) to prevent MITM attack.

No. And the purpose of this change has been explained here on the forum somewhere, and it has nothing with preventing MITM attacks.

RouterOS used to store local user credentials in plain-text (or using reversible crypto), and that's what changed in 6.43rc. It just happens that pre-existing authentication schemes cannot work without a plain-text password available on the server side, and that's why WinBox, BTest, MAC-telnet clients, API clients, etc. all suddenly became incompatible and had to be updated.

pe1chl · Sun Jun 17, 2018 2:24 pm

But that was done because there were bugs that allowed the retrieval of the unencrypted passwords (and thus the quick retrieval of valid user/password combinations as shown), and I am not convinced that in the current stable and bugfix versions there are no such bugs. Apparently there are still users who have current software but unwise firewall configurations that get hacked.

After this change has been implemented, it will be more difficult to obtain passwords once another bug has been found that allows a remote attacker to retrieve the authentication database, but frankly I think it would be safer when there was some more compartmentation in RouterOS.
After all, even when there is a bug in the webserver, the webserver has no business reading the authentication database directly, so in a correctly designed system (where the webserver runs under a less privileged user ID) even a bug in the webserver would not have leaked this info.

Sun Jun 17, 2018 2:41 pm

But that was done because there were bugs that allowed the retrieval of the unencrypted passwords (and thus the quick retrieval of valid user/password combinations as shown)

That's correct. And I must admit this change had to be implemented years ago without waiting for bugs like this one to pop up.

I am not convinced that in the current stable and bugfix versions there are no such bugs.

And so what?

Apparently there are still users who have current software but unwise firewall configurations that get hacked.

Any proven evidence? If so, can you please share? Probably any links to a forum post that I may have missed?

After this change has been implemented, it will be more difficult to obtain passwords once another bug has been found that allows a remote attacker to retrieve the authentication database, but frankly I think it would be safer when there was some more compartmentation in RouterOS.
After all, even when there is a bug in the webserver, the webserver has no business reading the authentication database directly, so in a correctly designed system (where the webserver runs under a less privileged user ID) even a bug in the webserver would not have leaked this info.

You are talking about obvious things, but, frankly, the world is not ideal, and is unlikely to ever be.

squeeze · Sun Jun 17, 2018 3:57 pm

The recent large security redesigns flowed from the April 0-day. Normis even explicitly stated it, so you are discussing nothing new: Advisory: Vulnerability exploiting the Winbox port [SOLVED]

Znuff · Sun Jun 17, 2018 4:59 pm

The recent large security redesigns flowed from the April 0-day. Normis even explicitly stated it, so you are discussing nothing new: Advisory: Vulnerability exploiting the Winbox port [SOLVED]

I wasn't even aware of the 0-day exploit from APRIL.

I only received the e-mail from MARCH stating that a vulnerability was fixed over a year ago, the vulnerability was exploited by VPNFilter.

You have our e-mail addresses. I can't believe to begin to understand why you didn't use the same means of communication regarding the APRIL vulnerability as you used in the past.

vecernik87 · Mon Jun 18, 2018 2:01 am

in 6.43rc17, something was changed in winbox service (thats why every RC since then has to use Winbox 3.14) to prevent MITM attack.
No. And the purpose of this change has been explained here on the forum somewhere, and it has nothing with preventing MITM attacks.

Maybe you are right, but changelog says otherwise:

*) winbox - improved authentication process excluding man-in-the-middle possibility (Winbox v3.14 required);

RouterOS used to store local user credentials in plain-text (or using reversible crypto), and that's what changed in 6.43rc.

Even if you are right with this one it is still vulnerability which is known and is not applied in current/bugfix. This is very close to zero-day definition because fix was not released in general. Despite being big fan of Mikrotik, I can still see some flaws and I appreciate all their hard work to fix these.

Mon Jun 18, 2018 9:46 am

Even if you are right with this one it is still vulnerability which is known and is not applied in current/bugfix.

Well, the fact that the previous versions of WinBox (even in secure mode) were susceptible to MITM attacks was well-known for years. Many users were concerned and raised questions here on the forum asking how secure the connection is provided it does not use any certificates nor asks for fingerprint confirmation in order to prove the server's identity, and eventually it was confirmed (at least once) by someone from MikroTik stuff that WinBox does not do server identity validation and is thus subject to MITM attacks. This should probably have been properly/better documented, but, to be honest, the fact that WinBox secure connection mode is not quite secure was rather apparent to any professional who takes security serious.

Mon Jun 18, 2018 9:52 am

Is 6.40.8 from this point of view safe or not?

Mon Jun 18, 2018 10:08 am

No, it is not.

Mon Jun 18, 2018 10:25 am

How is it possible that actual bugfix version does not solve long time well known security issue?

Chupaka · Mon Jun 18, 2018 10:46 am

Well, Telnet is vulnerable to MitM (in addition to usage of unencrypted plaintext password), and it cannot be fixed. Should they forbid Telnet in 'bugfix' versions?

pe1chl · Mon Jun 18, 2018 12:03 pm

How is it possible that actual bugfix version does not solve long time well known security issue?

There apparently is no fix ready yet. It is being tested in RC.
I would think it is too big of a change to be backported to bugfix without rigorous testing so likely it will first be only in current for a while.

pe1chl · Mon Jun 18, 2018 12:06 pm

Well, Telnet is vulnerable to MitM (in addition to usage of unencrypted plaintext password), and it cannot be fixed. Should they forbid Telnet in 'bugfix' versions?

It probably is time to disable telnet on newly loaded default and move from there.
(issue warning when telnet enabled and recommend disabling it, print warning in telnet session recommending ssh, etc)

Mon Jun 18, 2018 12:14 pm

What are you talking about?
v6.40.8 includes patches to fix known vulnerabilities including latest winbox port vulnerability.

JimmyNyholm · Mon Jun 18, 2018 12:16 pm

Security advisory emails were sent to all users that are in our database.

Where do I register to get this advisorys?

Chupaka · Mon Jun 18, 2018 12:23 pm

Where do I register to get this advisorys?

At the bottom of https://mikrotik.com/, I believe

Mon Jun 18, 2018 12:39 pm

What are you talking about?
v6.40.8 includes patches to fix known vulnerabilities including latest winbox port vulnerability.

We are talking about this: viewtopic.php?t=121039#p595087

Chupaka · Mon Jun 18, 2018 2:04 pm

So, is fixing Telnet MitM possibility a vulnerability fixing or protocol enhancement? The same question is about WinBox.

R1CH · Mon Jun 18, 2018 4:57 pm

Telnet is well known to be insecure, SSH is the replacement for it (although why telnet is still provided and enabled by default is another question...)

Winbox is a proprietary protocol that claims to be "secure" but is vulnerable to MITM, so the fault lies with it. Hopefully this a pointless discussion as with the new SRP authentication system it should protect from MITM, as long as it is correctly implemented.

Chupaka · Mon Jun 18, 2018 5:06 pm

Hopefully this a pointless discussion as with the new SRP authentication system it should protect from MITM

Well, the point was "Will those changes be back-ported to 'bugfix' and 'current' versions prior to 6.43?"
I think, the answer is 'no', because changes are too big to call them 'a bug fix'.

Thu Jun 21, 2018 4:26 am

VPNfilter infected device detection

I just wrote up a VPNfilter fw block & log on one of my core Mikrotik routers.
Please review and make any suggestions

Here is the configuration I added to my core Mikrotik CHR:

/ip firewall filter
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.37.0/24 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.41.0/24 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.39.0/24 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.38.0/24 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.40.0/24 log=yes
add action=drop chain=forward comment="VPNfilter photobucket.com" dst-address=209.17.68.0/24 log=yes

I discovered 11 customers devices on my customer network that are trying to make a VPNfilter stage-2 connection

Note - this FW rule(s) does not prevent VPNfilter infections , but it may help detect already infected devices.

North Idaho Tom Jones

vecernik87 · Thu Jun 21, 2018 5:54 am

dropping photobucket.com is terrible thing - you are blocking entire popular picture sharing website!
Also approach of blocking whole /24 ranges for all potentially malicious IP's not really good idea.

With this approach, you are gonna block not just infected traffic but also genuine traffic to normal websites which may be hosted on any IP of those blocked ranges. (that also means your log is meaningless as it does not necessarily mean those devices are accessing Stage 2)

If you decide to block IP or whole range despite my warning, wouldn't it be better to create ONE rule with dst-address-list instead of 6 rules with separate dst-address ?

Chupaka · Thu Jun 21, 2018 8:45 am

Well... Are you sure that blocking 1280 ip addresses of Cloudflare won't block some of thousands legit websites on those addresses?..

R1CH · Thu Jun 21, 2018 12:40 pm

toknowall.com is a sinkhole, nothing bad will come from hosts contacting it. Cloudflare IPs rotate often, you are probably blocking hundreds or thousands of legitimate sites with such wide rules.

You should instead redirect toknowall.com locally and monitor / block hosts that way.

Thu Jun 21, 2018 6:35 pm

Re my VPNfilter ROS fw configuration
- This is/was my first attempt to try to detect VPNfilter infected devices travesing through my network (this is why I am asking for comments).
- My ROS log shows 11 customer devices that keep trying to connect over and over again (like a heart beat)
- I can narrow down the /24 blocks to individual IP address that are blocked
- I possibly could change the block & log to a pass & log (so that valid legimit customer traffic still passwd (but also some VPNfilter stage-2 traffic will now also pass)

Any thoughts ?

North Idaho Tom Jones

Thu Jun 21, 2018 9:05 pm

Here is my slightly updated VPNfilter ROS fw configuration
I changed from /24 to individual /32 IP addresses

/ip firewall filter
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.37.155 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.41.155 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.39.155 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.38.155 log=yes
add action=drop chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.40.155 log=yes
add action=drop chain=forward comment="VPNfilter photobucket.com" dst-address=209.17.68.100 log=yes

The above is a block and log. One potential problem with the above configuration is that I don't know what possible valid traffic to these IPs is also being blocked.

If you do not want to block these IPs, and instead want to allow/pass & log , then try this instead:

/ip firewall filter
add action=accept chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.37.155 log=yes
add action=accept chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.41.155 log=yes
add action=accept chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.39.155 log=yes
add action=accept chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.38.155 log=yes
add action=accept chain=forward comment="VPNfilter toknowall.com" dst-address=104.16.40.155 log=yes
add action=accept chain=forward comment="VPNfilter photobucket.com" dst-address=209.17.68.100 log=yes

The above is a pass and log

Again - any comments and or ideas on how to help detect VPNfilter stage-2 traffic is welcome.

North Idaho Tom Jones

Chupaka · Mon Jun 25, 2018 11:20 am

/ip firewall
address-list add list=toknowall.com address=toknowall.com
filter add chain=forward comment="VPNfilter toknowall.com" \
  dst-address-list=toknowall.com action=drop log=yes

Cha0s · Mon Jun 25, 2018 4:22 pm

/ip firewall
address-list add list=toknowall.com address=toknowall.com
filter add chain=forward comment="VPNfilter toknowall.com" \
  dst-address-list=toknowall.com action=drop log=yes

What difference does this make? You still block CloudFlare and tons of other websites.

These are just bad suggestions. I am sorry for those that will copy those rules and don't understand why random websites don't work anymore.

Chupaka · Mon Jun 25, 2018 5:07 pm

You still block CloudFlare and tons of other websites.

Well, https cert on this host covers "ssl894059.cloudflaressl.com", "toknowall.com" and "*.toknowall.com" - doesn't look like there are tons of other websites

eworm · Mon Jun 25, 2018 5:10 pm

You still block CloudFlare and tons of other websites.
Well, https cert on this host covers "ssl894059.cloudflaressl.com", "toknowall.com" and "*.toknowall.com" - doesn't look like there are tons of other websites

You know that the server can use different certificates based on SNI extension?

Cha0s · Mon Jun 25, 2018 5:24 pm

You still block CloudFlare and tons of other websites.
Well, https cert on this host covers "ssl894059.cloudflaressl.com", "toknowall.com" and "*.toknowall.com" - doesn't look like there are tons of other websites

Which means absolutely nothing. CF is not a static thing. It is a dynamic system that shifts workloads around depending on laod, attacks, etc.
Now you see these domains, tomorrow will be other domains.
Or today toknowall.com resolves to these IPs and tomorrow CF will migrate the site other IPs.
Or today (due to anycast) you reach your local CF mirror that happens to only host this domain and tomorrow you reach CF via another country that happens to server way more domains.

Your suggested method is just wrong.

Chupaka · Tue Jun 26, 2018 2:20 pm

CF is not a static thing. It is a dynamic system that shifts workloads around depending on laod, attacks, etc.
Now you see these domains, tomorrow will be other domains.
Or today toknowall.com resolves to these IPs and tomorrow CF will migrate the site other IPs.
Or today (due to anycast) you reach your local CF mirror that happens to only host this domain and tomorrow you reach CF via another country that happens to server way more domains.

Well, my website still uses the same CF IPs as many months ago

Your suggested method is just wrong.

It's not my method, I just suggested how to make TomjNorthIdaho's rules shorter.

Cha0s · Tue Jun 26, 2018 3:58 pm

It's not my method, I just suggested how to make TomjNorthIdaho's rules shorter.

English suck. I didn't mean you as in singular. I meant you as in plural. You and Tom.

I am not gonna argue with you. Believe what you want about CF.

Tue Jun 26, 2018 5:43 pm

Well - in my fw rules , I made two suggestions.
One is block and log
-the other is , pass and log

If there are an estimated 1/2 million VPNfilter infected routers , I wonder how many PCs, servers & networks may actually be effected ?

Tue Jun 26, 2018 5:46 pm

Hey Mikrotik - do you have any suggestions for how to detect VPNfilter infected devices/traffic passing through a core router?

BRMateus2 · Thu Jun 28, 2018 7:07 am

Actually the second stage is, if this reference is correct (https://blog.securityevaluators.com/vpn ... df74fee92a), just detecting specific hardcoded destination IPs (supposing all VPNFilter code has the same IPs)

# Address list
/ip firewall address-list add address=91.121.109.209/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=217.12.202.40/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=94.242.222.68/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=82.118.242.124/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=46.151.209.33/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=217.79.179.14/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=91.214.203.144/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=95.211.198.231/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=195.154.180.60/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=5.149.250.54/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=91.200.13.76/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=94.185.80.82/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=62.210.180.229/32 comment="|abuse VPNFilter" list=|abuse_VPNFilter
/ip firewall address-list add address=toknowall.com comment="Domain that VPNFilter used, now its FBI Sinkhole" list=|abuse_VPNFilter
# Firewall
/ip firewall filter add chain=forward action=reject reject-with=icmp-host-prohibited dst-address-list=|abuse_VPNFilter connection-state=new log-prefix="Filter possible VPNFilter" disabled=yes comment="ICMP-Rej-Host possible VPNFilter hardcoded destination IP"

For those who will use the rules above, read @vecernik87 post below which contains important information - such as this detection does not count for the permanent first stage script - so take care. For first stage, shall use layer 7 detection which is not my knowledge.

vecernik87 · Thu Jun 28, 2018 12:03 pm

BRMateus2 - It is important to distinct between
"second stage trying to download" = infected by first stage which is permanent, trying to download second non-permanent stage
and
"second stage indicator" = infected by first and second stage, trying to download third stage or other commands

due to the fact that both sources of second stage infection (photobucket galleries and toknowall domain) were disabled, we can expect that not many people will get newly infected by second stage. Also we can expect that second stage penetration will slowly decrease as it is non-permanent and theoretically simple restart or power-outage should remove it.
Therefore filtering second stage stuff is not really helpful and can cause false feeling of security. You may have no devices infected by second stage but still have plenty of devices infected by permanent first stage. That is the main issue which we should focus on.

BRMateus2 · Thu Jun 28, 2018 8:09 pm

Many thanks @vecernik87 for such information, I've updated the original post tasking the reader to create layer 7 rules which is not my knowledge for all case scenario.

Zwe · Fri Jun 29, 2018 3:37 pm

Thanks for the heads-up.

Is there a specific version from which this malware is able to infect a mikrotik?
How about RouterOS 5.22 for example or 6.27?

Fri Jun 29, 2018 3:43 pm

Like the first topic says, anything older than these versions is vulnerable, if you have not configured a firewall:

Current release chain:
What's new in 6.38.5 (2017-Mar-09 11:32):
!) www - fixed http server vulnerability;
And also Bugfix release chain:
What's new in 6.37.5 (2017-Mar-09 11:54):
!) www - fixed http server vulnerability;

Fri Jun 29, 2018 6:08 pm

VPNfilter stage 2

If you are not concerned about VPNfilter infected Mikrotiks trying to make stage 2 connections (because you feel the government shut down the stage 2 servers) , think again !!!

A VPNfilter infected device does the following stage 2 actions:
1st - try Photobucket
2nd - if Photobucket fails , then try Toknowall
3rd - if Toknowall fails , then open a listener and wait for an actor to send a trigger packet for a direct connection

Soooo, even if the 3rd party Command-and-Control servers for VPNfilter are shutdown , you may still have a VPNfilter infected device with an open port just waiting for another actor to send a trigger packet to it --- which could possibly allow somebody else to sieze admin control over your VPNfilter devices/networks.

Thus there is a strong justified reason to attempt to detect VPNfilter stage 2 traffic.

North Idaho Tom Jones

Chupaka · Fri Jul 06, 2018 10:14 am

http://www.symantec.com/filtercheck/

R1CH · Fri Jul 06, 2018 6:06 pm

I made a checking tool like that as soon as it was announced, but realized it's probably useless as this ssler module is very likely targeted to high profile victims and won't be enabled on most infections.

Asyouwanto · Fri Jul 20, 2018 5:41 pm

Hello guys, is there any way to have a conflict between VPNfilter and avast? It doesn't run properly...

BRMateus2 · Sat Jul 21, 2018 4:25 am

Lol the whole forum topic for nothing.
That's the function of an anti virus.

Tue Jul 24, 2018 5:49 pm

Lol the whole forum topic for nothing.
That's the function of an anti virus.

"Lol the whole forum topic for nothing." ???

Soooo , are you stating all of your devices such as firewalls, wireless routers and NAS are running anti virus on them ?
Whoa , Are you also saying that out of an estimated 1/2 million VPNfilter infected network devices, that it is impossible any of your network devices are VPNfilter infected ?

lewin · Thu Jul 26, 2018 6:37 pm

Hello guys, is there any way to have a conflict between VPNfilter and avast? It doesn't run properly...

It doesn't work that way.

Thu Jul 26, 2018 11:52 pm

re VPNfilter

Although the government has shutdown the command-and-control servers (I think), there still remains a very serious issue. VPNfilter infected devices also have a back-door installed. So although the C&C servers are no longer sending & receiving stage-1 VPNfilter connections, the back-door that was installed by VPNfilter is still running and waiting for special packet connects which could then allow a remote attacker admin access.

So, I suspect we will sometime see an updated version of of VPNfilter which will spread and take control of VPNfilter infected devices by using the back-door ports that were opened-up with round one of VPNfilter infections.

Sooo it is still very important to detect and fix existing VPNfilter devices , otherwise your network is just sitting there waiting for a new round of VPNfilter related vulnerabilities to happen again.

msatter · Thu Sep 27, 2018 1:02 pm

Update on VPNfilter:

https://blog.talosintelligence.com/2018 ... art-3.html

msatter · Mon Oct 08, 2018 3:12 pm

And the saga continues and this time by Tenable:

https://github.com/tenable/routeros

These are already patched so check if you are using a safe RouterOS.

Mon Oct 08, 2018 3:28 pm

Congratulations to Tenable !!! They should also send list of affected routers. - it is SARCASM.

IMHO it is totally irresponsible.

msatter · Mon Oct 08, 2018 3:42 pm

[sarcasm]Mikrotik patched RouterOS so all is safe now....[/sarcasm]

If it is possible to retake compromised routers, then the correct correct RouterOS can be installed and clean out the bad stuff. I a one leaves it's router open to attacks from the outside why not 'attack' it to make it safe again.

Or if not cleanable put a schedule in with a warning to update using Netinstall.

This continuing story is bad for Mikrotik and for us. If you are a reseller or installer and you recommend a Mikrotik then you have to come up with strong arguments because of the strain of negative publications.

Mon Oct 08, 2018 5:49 pm

Tenable story is different ... they mounted ROS filesystem system to other Linux, made changes to files and then explored RouterOS. You have to have physical access to such system you want to break in.

All Linuxes without encrypted filesystem are volunerable ... you can just mount root partition, remove one char from /etc/password and voila ... root access is ready.

PS. I'm not an advocate of Miktorik but each system is breakable ... even trusted ones as .... we can enumerate some here.
Simple Telnet, restart and you are in.

Thu Oct 18, 2018 5:53 pm

Has anybody else noticed that about half of all remote Internet connections to the Mikrotik winbox port (port # 8291) are coming from China and the other half is coming from the Netherlands ?

On average , I have a sustained 6 to 15 per-minute attemted remote Internet connections to port 8291 (winbox) on my my networks. Who else is seeing large scale attempted remote connections to the winbox port on their networks ?

Thank goodness for multiple firewalls , I just hope they are all working correctly and that I'm not missing some important FW settings.

North Idaho Tom Jones

Thu Oct 18, 2018 6:07 pm

It is log for 25 days since reboot so this router drops circa 15k connections per day. Most of them are for 22,23,8291 ports.

MM.PNG

Thu Oct 25, 2018 6:43 pm

More impressive statisctic for 42 days of up-time.
RAW2 registers IPs which "revisist" router and are still registered with RAW1 rule.

Firewall.PNG

Who is online