That’s why normis wrote in his original post...Apparently VPNFilter is now scanning for port 2000 (btest server) on Mikrotik routers. Another exploit? Not many admins are aware that this service runs by default.
To be safe against any kinds of attacks, make sure you secure access to your devices:
https://wiki.mikrotik.com/wiki/Manual:S ... our_Router
https://www.bleepingcomputer.com/news/s ... -comeback/Apparently VPNFilter is now scanning for port 2000 (btest server) on Mikrotik routers. Another exploit? Not many admins are aware that this service runs by default.
There's a big difference between random port scans and targeted traffic to a specific port. MT devices without a firewall are trivial to identify due to service banners, I doubt attackers are trying to "identify the brand", most will just send any exploit to any device. Given that VPNFilter is supposedly created by a nation state attacker, it's a little more concerning to see it targeting a specific Mikrotik service.Again and again ... it seems be kind of sport nowadays to ask "Is Mikrotik volunerable because someone is scanning particular port?"
If you disable or limit sources's IPs for all new incoming connections then there should be no problem at all.
If you not secure your router then offenders will try to identify the brand and then try to attack.
Scanning ports is not an attack. I have some routers with IP range where some addresses are not used yet but I see on WAN ports traffic to unsed IPs.
Should I ask: "Are my Mikrotik's routers volunerable as they see and could accept traffic for nonexistient IP?"
Actually I have always found it ridiculous that MikroTik people made remarks on this forum that RouterOS is safe because there were no known security problems and there had been no major problems in the past.If we/they have no proof that something is "broken" then they always could say "YES, it is safe".
Unfortunately that is not true at all. You are safe from the exploits as they are seen now. You could still have problems e.g. when there turns out to be a problem in some obscure firewall rule type like L7 matching or when there is a problem in some client that you have to run (e.g. DHCP client).If your have no open ports on your WAN interface, then you are completely safe from remote wired exploits of any kind.
No more devices affected, just an updated announcement after the announcers better researched the MikroTik product gamma.now are more mikrotik devices affected.....
Of course. Just like those people that post "I am locked out of my router and I don't have a backup". Just bad practices.The fact that Mikrotik is still on the list due to them seeing Mikrotik routers still being hit by this means one thing only for Mikrotik users. They have failed to keep their routers current and are still running over a YEAR OLD (plus) version of ROS. Regardless of this virus attack, that is just bad practices all around.
It's also bad practice on the part of Mikrotik when it comes to information, it took them over a year to email about the httpd vulnerability, and I still have not yet received an email advisory about the winbox vulnerability. You cannot expect all Mikrotik users to be checking forum and changelog constantly.The fact that Mikrotik is still on the list due to them seeing Mikrotik routers still being hit by this means one thing only for Mikrotik users. They have failed to keep their routers current and are still running over a YEAR OLD (plus) version of ROS. Regardless of this virus attack, that is just bad practices all around.
There is unfortunately no easy way to tell, 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, advanced malware could easily persist after an upgrade. If you think a device may be infected, netinstall is by far the safest option.how to determine if my router is infected?
There is a "check installation" feature but unfortunately it does not check if there are files on the router that are unaccounted for, even though this has been claimed.There is unfortunately no easy way to tell, since Mikrotik doesn't allow us shell access to our routers to perform this kind of examination.
Back in the Urgent security advisory, it was said that upgrading your RouterOS version would remove "the bad files" on the device.how to determine if my router is infected?
- Upgrading to v6.38.5 or newer will remove the bad files, stop the infection and prevent anything similar in the future.
If the malware is already on the device with root level privileges, it can easily hide itself from a filesystem check.There is a "check installation" feature but unfortunately it does not check if there are files on the router that are unaccounted for, even though this has been claimed.There is unfortunately no easy way to tell, since Mikrotik doesn't allow us shell access to our routers to perform this kind of examination.
But in reality the upgrading of RouterOS does not even detect the unwanted/temporary files it creates itself!Back in the Urgent security advisory, it was said that upgrading your RouterOS version would remove "the bad files" on the device.
What's new in 6.38.5 (2017-Mar-09 11:32):It's also bad practice on the part of Mikrotik when it comes to information, it took them over a year to email about the httpd vulnerability, and I still have not yet received an email advisory about the winbox vulnerability. You cannot expect all Mikrotik users to be checking forum and changelog constantly.The fact that Mikrotik is still on the list due to them seeing Mikrotik routers still being hit by this means one thing only for Mikrotik users. They have failed to keep their routers current and are still running over a YEAR OLD (plus) version of ROS. Regardless of this virus attack, that is just bad practices all around.
They are able to release single purpose tool.Mikrotik doesn't allow us shell access to our routers to perform this kind of examination.
I don't think so, we secure our network pretty heavily. But if we ought to find out we are infected, that means our security is not as good as we think it is.If you think a device may be infected, netinstall is by far the safest option.
Mikrotik is our edge device and as you pointed out, if it is infected, we can't trust it's tools.For now the best indicator of compromise would be to watch your outbound traffic at an upstream device
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.Just upgrade your routers to RouterOS bugfix >6.40.8 or stable >6.42.1
Unlikely. It would need to exploit multiple vulnerabilities, some of them yet unknown.If the malware is already on the device with root level privileges
The winbox exploit was a 0-day - meaning it was being exploited in the wild before a patch appeared. If you weren't paying close attention to forums / changelog you were probably compromised within a week or two.Just for the record, I don't think people need to check changelogs "constantly" but probably at least once a year might be cool. Maybe even every six months? Might be a stretch but just actually *looking* would be a start for most.
This is definitely possible, you should be able to netboot to a different Linux distribution then mount and examine the flash memory, but this obviously involves a lot of work and of course downtime for the device compared to simply opening a terminal!
So , anybody got some ideas on how to do this and what can be found/checked/modified/fixed/enhanced/expanded ?
I would guess the bad guys already do something like this all of the time when looking for possible exploits on Internet connected devices.
I have that for some time. As that router is used as a VPN/Tunnel router it required some more rules but indeed it is a potentially good measure.One thing I have started doing as a preventative measure - block everything in the OUTPUT chain except necessary services (eg dhcp client, sntp client, etc).
Change that src-port with dst-port ...Rich/Pe1chi do you mean something like?
/ip firewall filter
add chain=output action=drop protocol=tcp src-port=80
To mkx WHY?Change that src-port with dst-port ...Rich/Pe1chi do you mean something like?
/ip firewall filter
add chain=output action=drop protocol=tcp src-port=80
That'll stop the check for upgrades of RouterOS from working, so not very clever.
You should at least add a white-list item for upgrade.mikrotik.com first.
Remember chain=output affects traffic generated by router itself.To WHY?Change that src-port with dst-port ...Rich/Pe1chi do you mean something like?
/ip firewall filter
add chain=output action=drop protocol=tcp src-port=80
That'll stop the check for upgrades of RouterOS from working, so not very clever.
You should at least add a white-list item for upgrade.mikrotik.com first.
What is the functional difference or outcome of
a. src-port=80 What is prevented, what are the outcomes positive and negative?
vice
dst-port=80 What is prevented, what are the outcomes positive and negative?
If you don't even know the difference between source and destination ports, then you need to stop polluting this thread and go and read up about some networking basics.What is the functional difference or outcome of
a. src-port=80 What is prevented, what are the outcomes positive and negative?
vice
dst-port=80 What is prevented, what are the outcomes positive and negative?
Who cares what IP it is? Just add an Address List item for the aforementioned name and then use the List name in the filter rule (dest. address list, not source address list!!!).So what IP is that? LOL, I don't know which domain or IP mikrotik uses when checking for updates LOL. I suppose I could add an exception!
The winbox exploit was a 0-day - meaning it was being exploited in the wild before a patch appeared. If you weren't paying close attention to forums / changelog you were probably compromised within a week or two.
Got it mounted and now I can cd into the ROS filesystem(s)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 ...
There is no point in doing this for an already compromised router!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 ...
It is pointless to post this list, it was made by people who do not know MikroTik and do not know that all routersFull list of affected RouterBoards since now
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.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).
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.Are they supposed to be there or is this Mikrotik ROS system VPNfilter compromised ?
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.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.Just upgrade your routers to RouterOS bugfix >6.40.8 or stable >6.42.1
Thanks for posting thisIn 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 ?
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.What architecture is your potentially compromised system?
InterestingThis 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.What architecture is your potentially compromised system?
FWIW, I use the following related best practices when I set up a router that has a public-facing interface: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.
- 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
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.
Try to change user's password - AFAIR, password history is also saved in user.datI 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
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.@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.
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.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.
Re: ...vulnerabilities...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.
I'm sure it's written somewhere, however would you kindly tell me how can I get my e-mail address to said database?Security advisory emails were sent to all users that are in our database.
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.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.
The only e-mail I received was on 31st of March, with:Security advisory emails were sent to all users that are in our database.
Tough I find myself now with a 6.41.3 that was recently Hacked. Luckily I have a backup config, but...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).
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?
No. And the purpose of this change has been explained here on the forum somewhere, and it has nothing with preventing MITM attacks.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.
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.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 so what?I am not convinced that in the current stable and bugfix versions there are no such bugs.
Any proven evidence? If so, can you please share? Probably any links to a forum post that I may have missed?Apparently there are still users who have current software but unwise firewall configurations that get hacked.
You are talking about obvious things, but, frankly, the world is not ideal, and is unlikely to ever be.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.
I wasn't even aware of the 0-day exploit from APRIL.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]
Maybe you are right, but changelog says otherwise:No. And the purpose of this change has been explained here on the forum somewhere, and it has nothing with preventing MITM attacks.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.
*) winbox - improved authentication process excluding man-in-the-middle possibility (Winbox v3.14 required);
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.RouterOS used to store local user credentials in plain-text (or using reversible crypto), and that's what changed in 6.43rc.
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.Even if you are right with this one it is still vulnerability which is known and is not applied in current/bugfix.
There apparently is no fix ready yet. It is being tested in RC.How is it possible that actual bugfix version does not solve long time well known security issue?
It probably is time to disable telnet on newly loaded default and move from there.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?
Where do I register to get this advisorys?Security advisory emails were sent to all users that are in our database.
At the bottom of https://mikrotik.com/, I believeWhere do I register to get this advisorys?
We are talking about this: viewtopic.php?t=121039#p595087What are you talking about?
v6.40.8 includes patches to fix known vulnerabilities including latest winbox port vulnerability.
Well, the point was "Will those changes be back-ported to 'bugfix' and 'current' versions prior to 6.43?"Hopefully this a pointless discussion as with the new SRP authentication system it should protect from MITM
/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.Code: Select all/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
Well, https cert on this host covers "ssl894059.cloudflaressl.com", "toknowall.com" and "*.toknowall.com" - doesn't look like there are tons of other websitesYou still block CloudFlare and tons of other websites.
You know that the server can use different certificates based on SNI extension?Well, https cert on this host covers "ssl894059.cloudflaressl.com", "toknowall.com" and "*.toknowall.com" - doesn't look like there are tons of other websitesYou still block CloudFlare and 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.Well, https cert on this host covers "ssl894059.cloudflaressl.com", "toknowall.com" and "*.toknowall.com" - doesn't look like there are tons of other websitesYou still block CloudFlare and tons of other websites.
Well, my website still uses the same CF IPs as many months agoCF 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.
It's not my method, I just suggested how to make TomjNorthIdaho's rules shorter.Your suggested method is just wrong.
English suck. I didn't mean you as in singular. I meant you as in plural. You and Tom.It's not my method, I just suggested how to make TomjNorthIdaho's rules shorter.
# 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"
"Lol the whole forum topic for nothing." ???Lol the whole forum topic for nothing.
That's the function of an anti virus.
It doesn't work that way.Hello guys, is there any way to have a conflict between VPNfilter and avast? It doesn't run properly...