Urgent security advisory

Wed Mar 28, 2018 3:44 pm

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).

Since all RouterOS devices offer free upgrades with just two clicks, we urge you to upgrade your devices with the "Check for updates" button, if you haven't done so within the last year.

Your devices are safe if the port 80 is firewalled, or if you have upgraded to v6.38.5 or newer. If you are using our home access point devices with default configuration, they are firewalled from the factory, and you should also be safe, but please upgrade never the less.

The vulnerability in question was fixed in March 2017:

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;

Currently this botnet only spreads and scans. It doesn't do anything else, but we still suggest to change your password and upgrade your firewall, just in case. Recommendations about securing your router: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

FAQ:

What is affected?

- Webfig with standard port 80 and no firewall rules
- Winbox has nothing to do with the vulnerability, Winbox port is only used by the scanners to identify MikroTik brand devices. Then it proceeds to exploit WEBFIG through port 80.

Am I safe?

- If you upgraded your router in the last ~12 months, you are safe
- If you had "ip service" "www" disabled: you are safe
- If you had firewall configured for port "80": you are safe
- If you only had Hotspot in your LAN, but Webfig was not available: you are safe.
- If you only had User Manager in your LAN, but Webfig was not available: you are safe.
- If you had other Winbox port before this: you are safe from the scan, but not from the infection.
- If you had "winbox" disabled, you are safe from the scan, not from the infection.

- If you had "ip service" "allowed-from" set to specific network: you are safe if that network was not infected.
- If you had "Webfig" visible to LAN network, you could be infected by an infected device in your LAN.

How to detect and cure?

- Upgrading to v6.38.5 or newer will remove the bad files, stop the infection and prevent anything similar in the future.
- If you upgrade device and you still see attempts to access Telnet from your network - run Tool/Torch and find out a source of the traffic. It will not be router itself, but another device in local network which also is affected and requires an upgrade.

P.S: some details about the operation of the botnet can be found here

anav · Wed Mar 28, 2018 4:28 pm

Thanks Normis, by the way suggest a small little toaster oven for your live-in red car. You can power it from the 12VDC receptacle for cigarette lighter.

(if you had a permanent address I would send a care package to include beard trimming kit and eyeglass wipes)

Being a new user, I thought that WINBOX was a proprietary encrypted connection method to be used really only from behind the Mikrotik. By the way can I add, winbox is one sweeeet concept for a person like me that easily self-destructs on access to routers due to rule changes. I just use the mac address of the interface and I can connect no matter what stupid move I made with rules
Safe mode is for kittens LOL (well its a lab environment for now, so no harm no foul)
Wouldn't one want to connect via Https or SSL or something to the mikrotik from the outside and then access Winbox? (I mean a way besides the complication of setting up a VPN which I find at the moment a bridge to far (intimidating). I want to get to the point of a standard encrypted method to access WINBOX remoteley, as eventually want to buy and setup a mikrotik for a family member in Spain and I live in Canada.

Wed Mar 28, 2018 4:30 pm

Winbox has nothing to do with this. The tool only used it to identify that a device runs RouterOS.

I suggest to set up IPsec VPN to your device for remote management, close all other ports. Setting up IPsec is easy even for a new user, just click "VPN" in the QuickSet menu. It will enable everything that is needed. The link I posted above includes more suggestions to secure your router.

m2c · Wed Mar 28, 2018 5:51 pm

I've noticed some strange behavior of my several hotspots with public ip.
Found the following log entry:

mar/24 16:33:09 smb,info created new share: pub
mar/24 16:33:21 script,error script error: no such item (4)
mar/24 16:39:29 info fetch: file ".i" downloaded
mar/24 16:43:15 script,error script error: no such item (4)

Now the hotspots are making lots of connections to outside ips on telnet and winbox ports.
The question is: how do I fix them? Is upgrade and password change enough?
Firmware is 6.38

Wed Mar 28, 2018 5:58 pm

Yes, upgrade and for security reasons change password, too.

changeip · Wed Mar 28, 2018 7:05 pm

is there a known 8291 vulnerability or just 80?

honzam · Wed Mar 28, 2018 7:16 pm

Since all RouterOS devices offer free upgrades with just two clicks

Normis thanks for fix. But this fix is only for actual devices. There is nothing for MIPSLE. Your statement: all RouterOS devices is not true.

random12 · Wed Mar 28, 2018 7:23 pm

Hi,

Seems that we are having strange processes even after upgrade to version 6.41.3.

Could you please post the complete instructions what to check in config or filesystem if we had malicious processes before the upgrade and after upgrade to 6.41.3?

Are there any kind of startup scripts what should be checked?

What is the purpose of /ram/history.console file? I can see a lot of passwords stored in plain text.

Thanks.

random12 · Wed Mar 28, 2018 7:26 pm

Not sure if you are aware but there is a complete instruction - https://github.com/BigNerd95/Chimay-Red

m2c · Wed Mar 28, 2018 7:32 pm

Upgraded and changed passwords. No more telnet spam.

Nando_lavras · Wed Mar 28, 2018 8:23 pm

Routers with http port disabled and winbox port limited in "IP Service List" using the option "Available From" are protected? Or a additional firewall is necessary is this case?

Thanks.

msatter · Wed Mar 28, 2018 8:39 pm

Thanks for the security advisory and it much appreciated!

agenovez · Wed Mar 28, 2018 9:01 pm

I confirm that this Chimay-Red Exploit is effective (tested on my own security lab), even though it is no easy to make it work (you need a lot of GNU/Linux/Programming Skills) to make it work, I am working on a security tool to update every Mikrotik Routerboard, for now I only have this code in Perl script, it basically extracts the Ip addresses from the CSV file then tries to connect to ftp with the credentials, upload the "activador.auto.rsc" you have to work on your own script to block or allow your Administration subnet, I know it is a rough script that need a lot of work, but it will work as a starting point(idea):


#MWIRELESS V01
#SCRIPT PARA ACTIVACION DE SNMP Y API PARA (CONFIDENTIAL)
#POR: ANDRES GENOVEZ (Bitfrost) para CONFIDENTIAL
#Script solo para uso autorizado sin responsabilidad - 03-2015
#Basado en Ejemplos de: http://perlenespanol.com/tutoriales/modulos/usando_el_modulo_netftp.html y harto v220

use Net::Netmask;
#use strict;
use Net::FTP;

my $username = "admin";
my $pwd = "mypasswd";

open (FILE, '27-05-2015.csv');
 while ($line = <FILE>) {
 chomp;

$ip = $line;
chomp $ip;
$ip =~ s/\s+//g;

if($ip ne "") {
if (my $ftp = Net::FTP->new($ip)) {
$ftp->login($username,$pwd);
#ACCIONES QUE QUEREMOS EJECUTAR EN EL MK
$ftp->put("activador.auto.rsc","activador.auto.rsc");
$ftp->quit or die("No se puedo desconectar del servidor: $!");

}else
{

print "Error: $ip\n";
}

}



}

Wed Mar 28, 2018 10:18 pm

That is correct - all RouterOS devices offer free upgrade until RouterBOARD platform is EOL. You should Netinstall your MIPSLE devices since Netinstall will put a fresh installation on your device and protect it by firewall right away, before putting router on public network.

If you upgrade device and you still see attempts to access Telnet from your network - run Tool/Torch and find out a source of the traffic. It will not be router itself, but another device in local network which also is affected and requires an upgrade.

kobuki · Wed Mar 28, 2018 10:40 pm

Just to make it clear: only devices running a not up-to-date RouterOS version are affected, whose HTTP port (TCP/80) are open and provides the login facility and management GUI, right?

I never allow unencrypted connections and always disable the HTTP and HTTPS interfaces. Only SSH and Winbox is enabled. It would be really nice to state the accurate state of affairs instead of us playing guess game. I understand the importance of upgrading, but scripts work fast and we can't update all affected devices in an instant.

hknet · Wed Mar 28, 2018 11:11 pm

Just to make it clear: only devices running a not up-to-date RouterOS version are affected, whose HTTP port (TCP/80) are open and provides the login facility and management GUI, right?

I never allow unencrypted connections and always disable the HTTP and HTTPS interfaces. Only SSH and Winbox is enabled. It would be really nice to state the accurate state of affairs instead of us playing guess game. I understand the importance of upgrading, but scripts work fast and we can't update all affected devices in an instant.

Pardon me, but the statement was quite clear:
"to exploit a vulnerability in the RouterOS www server"
anyway, it might be a good idea to keep up with updates at least on the "bugfix" level,but ymmv.

regards
hk

kobuki · Wed Mar 28, 2018 11:18 pm

Pardon me, but specifying "www server" is not clear, at all. A serious security vulnerability merits more than vague statements about services. Do the scripts only scan port 80? Are we safe behind HTTPS (which still fall under the "www server" category) or not? Etc. You're obviously not very familiar with CVE notices and the like. Anyway I hope someone will link or create one. This error must be very severe to warrant a mass email from Mikrotik (that's where I was notified of it in the first place) so some due diligence is in order.

warn1ng · Wed Mar 28, 2018 11:30 pm

I have 2 Questions :

1 - If the HTTP Port was OPEN (8880) but it was already configured with "Available From" and only allowing a some range of Public IPs and Private IPs, can be affected ?
2 - How we check if the Mikrotik is already been infected ?

Thanks

random12 · Thu Mar 29, 2018 12:06 am

Hi again,

We have a bunch of Mikrotiks with OS version higher than vulnerable one but all of them are still infected.

Even after "update FW" -> "reboot" -> "change password".

\

So even with the 6.41.3 all our devices are still infected.

Please respond ASAP and provide us instructions on how to remove all this shit from our Mikrotiks.

I can upload this /rw/info file if you need it, virustotal analysis shows nothing.

ubikrotik · Thu Mar 29, 2018 2:29 am

hi all,

We are running our main router on 6.37.1 (stable). This is a CCR1009. What happens if I upgrade to the current? I know master port will be disabled and A bridge will be created. And also P2P in firewall will no longer work.

Anything else?

warn1ng · Thu Mar 29, 2018 2:47 am

hi all,

We are running our main router on 6.37.1 (stable). This is a CCR1009. What happens if I upgrade to the current? I know master port will be disabled and A bridge will be created. And also P2P in firewall will no longer work.

Anything else?

I will go just to 6.37.5 witch is know to be fixed, and you will have no problem with the Bridge changes.

ccp421 · Thu Mar 29, 2018 2:48 am

We just change our winbox port to something else besides default. We do this with everything.

So to log in to the new port in winbox ip:new port

And flush firewall connections or reboot router.

Thu Mar 29, 2018 8:38 am

Chek first post for updated info ...

reverged · Thu Mar 29, 2018 9:06 am

@normis

Can you answer 2 items for the FAQ:

1. Is there a simple test to know if a router is infected?
2. Upgrading to 6.37.5+ cures an infection or it only prevents infection?

Thu Mar 29, 2018 9:12 am

@normis

Can you answer 2 items for the FAQ:

1. Is there a simple test to know if a router is infected?
2. Upgrading to 6.37.5+ cures an infection or it only prevents infection?

done

eworm · Thu Mar 29, 2018 9:19 am

And a FAQ entry about webfig from https (www-ssl) may be reasonable.

djmuk · Thu Mar 29, 2018 11:41 am

I'm intrigued - those posts look like you're running ps on the mikrotik - hos do you get a 'proper' shell / bash connection?

Or are they grabs from something like a sysinfo file?

David

Hi again,

We have a bunch of Mikrotiks with OS version higher than vulnerable one but all of them are still infected.

Even after "update FW" -> "reboot" -> "change password".

I can upload this /rw/info file if you need it, virustotal analysis shows nothing.

gocosf2 · Thu Mar 29, 2018 12:50 pm

we have a RouterOS v6.38.5 router that has been hacked today and deleted to the default settings. Also via the winbox port ... We think there is a circular second exploit that works in a similar way to this.

Thu Mar 29, 2018 1:02 pm

we have a RouterOS v6.38.5 router that has been hacked today and deleted to the default settings. Also via the winbox port ... We think there is a circular second exploit that works in a similar way to this.

It is not related to this topic. You probably had an easy to guess password.

Thu Mar 29, 2018 1:04 pm

I can upload this /rw/info file if you need it, virustotal analysis shows nothing.

These are leftover files. They don't do anything. This is not the program itself, only some remaining things it created. You can delete those if you like, but the device is no longer "infected" as you say

amt · Thu Mar 29, 2018 1:15 pm

maybe our problem in the following address could be related to this topic.

viewtopic.php?f=2&t=132160

lomayani · Thu Mar 29, 2018 1:35 pm

I have seen these from last Friday. I saw anything below 3.38.5 is compromised. Also i have seen 6.39.2 and below in series is affected. I have not seen anything from 6.39.3 and above which is compromised
I upgrade most of the routers to 6.41.3. Not seeing any problem in 6.41.3

Thu Mar 29, 2018 1:36 pm

@Normis
How "random12" user could show us results of "ps", "ls" etc ... Is he cracking his own router or uses some Mikrotik's debug/special module?

Simple question: How?

Thu Mar 29, 2018 1:37 pm

@Normis
How "random12" user could show us results of "ps", "ls" etc ... Is he cracking his own router or uses some Mikrotik's debug/special module?

Simple question: How?

There exists a special NPK package that you can install and gain access to shell. This is not public. This user must have gotten it from MikroTik support. Sometimes this package is installed by MikroTik support when debuging a live installation, but is usually removed. Don't ask, we will not share it

Thu Mar 29, 2018 1:39 pm

I have seen these from last Friday. I saw anything below 3.38.5 is compromised. Also i have seen 6.39.2 and below in series is affected. I have not seen anything from 6.39.3 and above which is compromised
I upgrade most of the routers to 6.41.3. Not seeing any problem in 6.41.3

Not possible. Maybe you had another router behind that one, then you would see some traffic as if it was coming from this one.

random12 · Thu Mar 29, 2018 1:41 pm

These are leftover files. They don't do anything. This is not the program itself, only some remaining things it created. You can delete those if you like, but the device is no longer "infected" as you say

Really? How can you understand it? What's inside this "/rw/info" file?

What's about those "/ram/.info" processes that is currently running in memory?

random12 · Thu Mar 29, 2018 1:51 pm

This screen clearly shows me version 6.40.5 (that is not vulnerable as you say us) with "/rw/info" and "/ram/.info" processes in memory.

Are you telling me that it's all safe now?

Thu Mar 29, 2018 1:58 pm

...
There exists a special NPK package that you can install and gain access to shell. This is not public. This user must have gotten it from MikroTik support. Sometimes this package is installed by MikroTik support when debuging a live installation, but is usually removed. Don't ask, we will not share it

I know about the "special" module ... not asking "for" ... just asking "how"

kobuki · Thu Mar 29, 2018 2:28 pm

(post Removed as others have answered my question)

Thu Mar 29, 2018 3:46 pm

This screen clearly shows me version 6.40.5 (that is not vulnerable as you say us) with "/rw/info" and "/ram/.info" processes in memory.
Are you telling me that it's all safe now?

You are right, this is some other tool. We fixed this one in v6.41 only. This is why upgrading to LATEST version is important. Your scanner has been stopped, but the .info process was not deleted. Upgrade to LATEST should fix also that one.

tkotek001 · Thu Mar 29, 2018 3:49 pm

This screen clearly shows me version 6.40.5 (that is not vulnerable as you say us) with "/rw/info" and "/ram/.info" processes in memory.

Are you telling me that it's all safe now?

not really - go for latest 6.41. due to smb exploit for 6.40.x https://github.com/BigNerd95/Chimay-Blue
original "chimay red" exploit had persistence option - check wikileaks files.

paulojrandrade · Thu Mar 29, 2018 4:34 pm

Hello, good morning, in case of mass update, more than 320 equipments, is there any script?

Thank you

avantwireless · Thu Mar 29, 2018 4:47 pm

@normis... Ok so now I am really confused... People above point out how to see infection via a simple "ls" on the /rw directory but the ability to perform the "ls" is not available. So how the heck are we supposed to check to see if a machine is infected? And please don't point at another post because I looked at all the other posts and nothing was pointed out as "Here this is what you see if you are infected" EXCEPT the results of a tool we can't have. And yes all my ports are filtered, but that is not good enough to verify not infected... And upgrading some of these machines may not work due to legacy hardware.

Thu Mar 29, 2018 4:49 pm

@normis... Ok so now I am really confused... People above point out how to see infection via a simple "ls" on the /rw directory but the ability to perform the "ls" is not available. So how the heck are we supposed to check to see if a machine is infected? And please don't point at another post because I looked at all the other posts and nothing was pointed out as "Here this is what you see if you are infected" EXCEPT the results of a tool we can't have. And yes all my ports are filtered, but that is not good enough to verify not infected... And upgrading some of these machines may not work due to legacy hardware.

Those are not "people" but one person who has already hacked his device himself. You can ignore him, his instructions can't be done by others.
There is only one thing needed to determine if you are vulnerable = upgrade RouterOS. Read the first post, the questions are answered there.

"Here this is what you see if you are infected"

There is no such test. Upgrade is mandatory. There is no other way to clean this tool from your device.

random12 · Thu Mar 29, 2018 4:57 pm

You are right, this is some other tool. We fixed this one in v6.41 only. This is why upgrading to LATEST version is important. Your scanner has been stopped, but the .info process was not deleted. Upgrade to LATEST should fix also that one.

I suggest you edit the very first message in the thread and write that only 6.41.X has all required fixes.

> This is why upgrading to LATEST version is important.

What is the "LATEST version". Do you mean LATEST released version of maybe LATEST RC versions?
We are on the internet, as you may notice, use https links to point the version what you are talking about.

> Currently this botnet only spreads and scans

Why do you think so? The vulnerability allows to load some random code to Mikrotik and run it, why you are sure that it "only spreads and scans"?

I can see completely different picture here: ESTABLISHED ssh connections to some hosts from our Mikrotik, attempts to connect over ssh to internal hosts.

Sometimes nmap utility shows Mikrotik devices on the other side, sometimes not.

Thu Mar 29, 2018 5:06 pm

Please at least read carefully before spreading your misleading things. Even your own posts are conflicting!

carefully compare these sentences:

> Currently this botnet only spreads and scans

> Why do you think so? The vulnerability allows

You are mixing up two different topics! Botnet is discussed here. Your device shows unrelated file, possibly injected by the SMB vulnerability that was closed in v6.41 like I said before. This has nothing to do with the botnet. Also, if you have installed command line shell access, who can know where you got this package from, what other stuff you accidentally installed and what other intrusion points you opened by installing this stuff

My personal recommendation to you is reinstall your device with Netinstall.

random12 · Thu Mar 29, 2018 5:19 pm

Those are not "people" but one person who has already hacked his device himself. You can ignore him, his instructions can't be done by others.

As you may understand it was done because we could get a proper answer from support.

There is only one thing needed to determine if you are vulnerable = upgrade RouterOS. Read the first post, the questions are answered there.

You are changing clothes on the go. Now you say that upgrade to 6.41.3 is mandatory.

There is no such test. Upgrade is mandatory. There is no other way to clean this tool from your device.

We tried to perform an upgrade from 6.40.5 to 6.41.3 for 2 infected devices remotely.
Both upgrades were unsuccessful (one device was reset to defaults, another one is not responding and we are waiting for someone in the remote office to have a look at the device).

pe1chl · Thu Mar 29, 2018 5:19 pm

Hello, good morning, in case of mass update, more than 320 equipments, is there any script?

There is this page with some info on how to do that:
https://wiki.mikrotik.com/wiki/Manual:U ... to-upgrade

However, it still is something that could have further clarification.
There is the "/system package update" command which has the same functionality as in the system->packages screen,
i.e. check for upgrades on the MikroTik servers and decide to install them and reboot.

There is also the "/system upgrade" command which allows downloads from local location, but it is not clear to me if
this is a recommended mechanism for new use, as it is mentioned very little. Is it part of the Dude update mechanism?

It would be nice when a mechanism can be established and configured by default in our routers to automatically update
to minimally some pre-established version. I.e on some central server a version could be stored for different architectures
and all routers will make sure their software version is at least that version. It would be possible to individually upgrade
routers to higher versions and they would not downgrade themselves to that centrally stored version, but when a router
has a lower version it would auto-upgrade itself, e.g. once a day.

Such a config would allow us to keep the network safe (e.g. in cases like this worm), without all routers automatically
tracking whatever MikroTik releases in current or bug-fix. So testing can be done and tested versions put on that
central server. In this case, the routers could use some predetermined password of the central service, but it should
not be obligatory that the central service knows all the admin passwords of the routers (as is the case with Dude).

Would it be advisable to build something like this using "/system upgrade" and a scheduled job? Is there an example?

random12 · Thu Mar 29, 2018 5:32 pm

You are mixing up two different topics! Botnet is discussed here.

Keep calm and don't use exclamation signs while talking to the customer.

It's more than related: since "the botnet issue" has started we detected malicious activity on our Mikrotiks.

Thu Mar 29, 2018 5:41 pm

@random12

Not judging anyone ... but how do you have access to internals of Mikrotik? Is it official way or not?

If not, then I should agrre with Normis that you device is not the representative example for the problem.
I could agree that maybe you have example of other malicious activity but are you sure that you are not responsible for opening any "door" to your device?

random12 · Thu Mar 29, 2018 5:53 pm

but how do you have access to internals of Mikrotik? Is it official way or not?

It's 100% official. No hacking at all. That's all that I can say for now.

If not, then I should agrre with Normis that you device is not the representative example for the problem.
I could agree that maybe you have example of other malicious activity but are you sure that you are not responsible for opening any "door" to your device?

Seems that you are trying to tell me that if shell access is unofficial - then it leads to "all doors open" issue?

I really think that Mikrotik should publish an extended post with details and explanations of what was fixed and how to be sure that my device is not affected.

simvirus · Thu Mar 29, 2018 6:12 pm

@Normis
How "random12" user could show us results of "ps", "ls" etc ... Is he cracking his own router or uses some Mikrotik's debug/special module?

Simple question: How?
There exists a special NPK package that you can install and gain access to shell. This is not public. This user must have gotten it from MikroTik support. Sometimes this package is installed by MikroTik support when debuging a live installation, but is usually removed. Don't ask, we will not share it

Hello!
How we can check if the MKT is compromised and the running processes?
As reported by other users also newer versions may be affected!

Thu Mar 29, 2018 8:09 pm

Seems that you are trying to tell me that if shell access is unofficial

Yes, that is what I am saying. There is no official way to do it, sorry, this is again misinformation.

You are changing clothes on the go. Now you say that upgrade to 6.41.3 is mandatory.

OK, maybe I can say it in some other way.

1) Upgrade to 6.38.5 fixes the botnet scanner and removes it.
2) Upgrade to 6.41.3 fixes SMB vulnerability.

This topic is about #1, but you don't seem to have this issue at all, you have some other files in your system. Since you have shell access, I can't say how you got those files in your system. I suggested clean Netinstall to restore system to defaults.

djdrastic · Thu Mar 29, 2018 8:35 pm

Normis thanks for this thread.

We have been dillgently upgrading all devices to 6.40.6 , locking down all http/winbox access for time being both from internal and external networks.SSH Access is only allowed from management IT management subnets for time being.
Will the 6.41.3 fixes for the SMB vulnerability be backported to the BugFix only code base any time soon ?

We'd have to do a mountain of tests before we are able to move to the Current stable.

lcrhea25 · Thu Mar 29, 2018 9:12 pm

We had a DOS attack last night for the first time in awhile. I have some firewall rules that normally shuts these attacks down but didn't last night for some reason. Could this have been the cause of this? When I was touching the interface I saw all the traffic from different IPs but no ports were showing with them.

walid2010 · Thu Mar 29, 2018 10:14 pm

Hello,

I followed the instructions , but how I can find I my routers affected with this vulnerability.

Thank you

macsrwe · Thu Mar 29, 2018 10:37 pm

There is also the "/system upgrade" command which allows downloads from local location, but it is not clear to me if
this is a recommended mechanism for new use, as it is mentioned very little.

It dates from before the Internet-enabled /system package update facility. MikroTik would much rather you always update to their newest releases to make it easier on their support staff, so the newer one is the one they promote heaviest. Conversely, their customers who run networks and are interested in testing and certification often prefer the older one because they can test a specific release and then ensure that only that release gets distributed to their network devices.

It would be nice when a mechanism can be established and configured by default in our routers to automatically update
to minimally some pre-established version. I.e on some central server a version could be stored for different architectures
and all routers will make sure their software version is at least that version. It would be possible to individually upgrade
routers to higher versions and they would not downgrade themselves to that centrally stored version, but when a router
has a lower version it would auto-upgrade itself, e.g. once a day.

Such a config would allow us to keep the network safe (e.g. in cases like this worm), without all routers automatically
tracking whatever MikroTik releases in current or bug-fix. So testing can be done and tested versions put on that
central server...

Would it be advisable to build something like this using "/system upgrade" and a scheduled job? Is there an example?

We have done precisely what you describe. It’s a rather complicated script, because the MikroTik-supplied facility breaks down when the connection fails for any reason in mid transfer, etc., but the scripts we have written take care of all that and do run nightly. If you contact me off list, I’ll send you a copy that you can work from.

butche · Thu Mar 29, 2018 11:07 pm

Hello, good morning, in case of mass update, more than 320 equipments, is there any script?

I wrote one in perl that can do this sort of thing. There are some example methods on the wiki for how to automate a bunch of this as well.

paulojrandrade · Thu Mar 29, 2018 11:56 pm

Thanks for replying, I could make it available because WIKI has nothing specific, API ports, API-SSL, Telnet, SSH and 80 clients are deactivated, I need to bulk update via Mac-Telnet.

paulojrandrade · Thu Mar 29, 2018 11:56 pm

I wrote one in perl that can do this sort of thing. There are some example methods on the wiki for how to automate a bunch of this as well.
[/quote]

Thanks for replying, I could make it available because WIKI has nothing specific, API ports, API-SSL, Telnet, SSH and 80 clients are deactivated, I need to bulk update via Mac-Telnet.

loveman · Fri Mar 30, 2018 12:42 am

1/If i change winbox port from 8291 to others port number? Am on safe or no?
2/My version 6.40.x? Should upgrade?

R1CH · Fri Mar 30, 2018 12:55 am

@Normis
How "random12" user could show us results of "ps", "ls" etc ... Is he cracking his own router or uses some Mikrotik's debug/special module?

Simple question: How?
There exists a special NPK package that you can install and gain access to shell. This is not public. This user must have gotten it from MikroTik support. Sometimes this package is installed by MikroTik support when debuging a live installation, but is usually removed. Don't ask, we will not share it

Why isn't this NPK available for everyone? If winbox, webfig, etc can't show proper indicators of compromise then it's important that we can use CLI tools to verify there are no rogue binaries, especially as the screenshots seem to demonstrate that the updated RouterOS doesn't actually remove persistent malware.

butche · Fri Mar 30, 2018 5:00 am

Why isn't this NPK available for everyone? If winbox, webfig, etc can't show proper indicators of compromise then it's important that we can use CLI tools to verify there are no rogue binaries, especially as the screenshots seem to demonstrate that the updated RouterOS doesn't actually remove persistent malware.

It isn't available because MikroTik has decided that they do not want it available. As for verification, there are NUMEROUS examples in this thread of people saying how to tell you are infected and how to remove the infection.

1. If you have outbound traffic from the router on telnet (and maybe more) with no other explanation, then that router is infected.
2. To fix it, upgrade the router to the latest routeros (this fixes all known attacks)

To keep it from happening again, you should do what SHOULD be done BEFORE it is put on the internet and protect these ports.

Fri Mar 30, 2018 9:16 am

Seems that you are trying to tell me that if shell access is unofficial - then it leads to "all doors open" issue?

Kind of .. if you have enabled filesystem for r/w operations, if any (if there are some) preventive locks are released with enabling "internals", if worm has access to bigger part of system files ... who knows what could happen. Even it happens then your example is not representative as car crash during WRC race is not representative example of common car crash for "average" driver.

BTW ... I'm waiting when you publish this "100% official" access to Mikrotiks internals.

doneware · Fri Mar 30, 2018 10:54 am

Thanks for replying, I could make it available because WIKI has nothing specific, API ports, API-SSL, Telnet, SSH and 80 clients are deactivated, I need to bulk update via Mac-Telnet.

RoMoN's mac based SSH is the real tool for cases like this.

pe1chl · Fri Mar 30, 2018 10:57 am

There is also the "/system upgrade" command which allows downloads from local location, but it is not clear to me if
this is a recommended mechanism for new use, as it is mentioned very little.
It dates from before the Internet-enabled /system package update facility. MikroTik would much rather you always update to their newest releases to make it easier on their support staff, so the newer one is the one they promote heaviest. Conversely, their customers who run networks and are interested in testing and certification often prefer the older one because they can test a specific release and then ensure that only that release gets distributed to their network devices.

That is right, this is why I raise this. I would not like the entire network to reboot whenever a new release is made that may not even be important (e.g. it just introduces new features outside the scope of our network), but conversely I would like to offer the service to keep those that do not pay attention uptodate to a major version that is not known to be vulnerable.
So the version on the local server would be updated when a security advisory occurs and whenever a newer version is stable and desirable to have.

I would be happy to let it retrieve it from the MikroTik servers if only we got a capability to have some "custom channel" where a local server determines what is the target version.
(e.g. define a custom channel by specifying a server or router that has a file or variable holding the target version, and only upgrade, not downgrade, to that version)

We have done precisely what you describe. It’s a rather complicated script, because the MikroTik-supplied facility breaks down when the connection fails for any reason in mid transfer, etc., but the scripts we have written take care of all that and do run nightly. If you contact me off list, I’ll send you a copy that you can work from.

Ah, and breaking connections is of course a common occurrence when all routers in the network decide at 03:00 to fetch and upgrade their RouterOS....
I already thought of that problem. There should be some randomness in the schedule time, probably. And indeed a recovery when a transfer fails.
Off-list contact is disabled on this board. I would appreciate it when you mail me your script at my username @ amsat.org

pe1chl · Fri Mar 30, 2018 11:01 am

Thanks for replying, I could make it available because WIKI has nothing specific, API ports, API-SSL, Telnet, SSH and 80 clients are deactivated, I need to bulk update via Mac-Telnet.

There is a Posix (Linux/freebsd/etc) mactelnet tool available on the internet and with the "expect" tool it should be possible to make it connect to a list of routers and issue the required commands:

/system package update check-for-updates
:delay 10
/system package update install

pe1chl · Fri Mar 30, 2018 11:57 am

@Normis
How "random12" user could show us results of "ps", "ls" etc ... Is he cracking his own router or uses some Mikrotik's debug/special module?

Simple question: How?
There exists a special NPK package that you can install and gain access to shell. This is not public. This user must have gotten it from MikroTik support. Sometimes this package is installed by MikroTik support when debuging a live installation, but is usually removed. Don't ask, we will not share it

Of course it could be considered to offer some read-only commands like ps and ls via RouterOS commands. I have seen other embedded-linux deviced that have this.
Or, they could be made part of the supout (they probably already are...) and displayed in the supout viewer tool.

Fri Mar 30, 2018 12:15 pm

Each "pros" has it's "cons" ... making such information visible makes cracking easier.

pe1chl · Fri Mar 30, 2018 12:27 pm

Each "pros" has it's "cons" ... making such information visible makes cracking easier.

There is no difference. A cracker is not held back by obscurity.

random12 · Fri Mar 30, 2018 12:28 pm

OK, maybe I can say it in some other way.

1) Upgrade to 6.38.5 fixes the botnet scanner and removes it.
2) Upgrade to 6.41.3 fixes SMB vulnerability.

This topic is about #1, but you don't seem to have this issue at all, you have some other files in your system.

Let me tell you how I see if from the customer perspective.

Imagine that something (like mail notification) or someone (a colleague of mine) told me about "Urgent security advisory" that Mikrotik have published on their website/forum.
And for some reasons, I have a version that it lower than v6.38.5 on my device. After reading your first post in this thread I am installing "v6.38.5" and this let me think that I am safe.
But I am not. Because you did not mention that there was an even worse vulnerability (SMB or some other) that was discovered later and I have to install 6.41.3 to fix this latter issue as well.

Seems that that was exactly our case. We did install 6.40.5 when we discovered that our mikrotiks made ssh connections to our internal network and also there were established connections from mikrotiks to some other machines on the internet (may be it was a tunnel through mikrotik, I don't know).

You are not publishing details about discovered vulnerabilities, even brief description and what your customers told you and what your support engineers discovered during their investigations of vulnerable devices.

You just telling us - upgrade to some version and you are safe.

For me, it seems that your very first fix was not complete and did not fully fix the issue.
That's why we could see malicious processes even when we upgraded to 6.40.5.
And you solved this issue only when you released a subsequent fix (in the next version of firmware).

Since you have shell access, I can't say how you got those files in your system.

This sounds funny: you blame me on everything just because I have this "shell access" on my device.

macsrwe · Fri Mar 30, 2018 12:47 pm

Ah, and breaking connections is of course a common occurrence when all routers in the network decide at 03:00 to fetch and upgrade their RouterOS....
I already thought of that problem. There should be some randomness in the schedule time, probably. And indeed a recovery when a transfer fails.
Off-list contact is disabled on this board. I would appreciate it when you mail me your script at my username @ amsat.org

The scripts we have already randomize by the last nibble of the MAC address snd it works well. Link radios, CPEs, and core routers all have different time blocks. Mostly the interruptions are caused by storm activity or power outages.

Also, the MikroTik standard process doesn’t load NPKs in a safe order. Nothing is as much fun as when a CPE loads the system package first, then gets interrupted before downloading wireless. When it next comes up, it’s running the new system, but nobody can talk to It and you have to send out a truck.

I will ship you the script sometime before Monday. I have a full schedule for the next two days.

Fri Mar 30, 2018 1:37 pm

Will the 6.41.3 fixes for the SMB vulnerability be backported to the BugFix only code base any time soon ?

Under no circumstances should your device have unfirewalled and open SMB shares on the internet. If you don't, this issue should not worry you.
We will put the fix into Bugfix once it is tested enough, the Bugfix versions must be highly stable before they are released, we don't rush them.

HaQs · Fri Mar 30, 2018 2:13 pm

Hello

Normis. Please MT to do , ROS mass update tool. do: upgrade, execute script

example.
login to all MT via winbox port to all ROS devices from ip class/range, and do update or prepared command: example ip service www disable

pe1chl · Fri Mar 30, 2018 2:21 pm

Also, the MikroTik standard process doesn’t load NPKs in a safe order. Nothing is as much fun as when a CPE loads the system package first, then gets interrupted before downloading wireless. When it next comes up, it’s running the new system, but nobody can talk to It and you have to send out a truck.

Ah I thought the procedure was to first download all the packages, then install them all upon reboot... maybe this is different for that method.
Usually our devices run the bundle package, plus sometimes an optional package like ntp, So this should not be an issue.
And our network is sufficiently meshed to allow access to a device from wireless and ethernet in most cases.

juliokato · Fri Mar 30, 2018 7:29 pm

Hello

Normis. Please MT to do , ROS mass update tool. do: upgrade, execute script

example.
login to all MT via winbox port to all ROS devices from ip class/range, and do update or prepared command: example ip service www disable

The Dude?

macsrwe · Sat Mar 31, 2018 12:22 am

Also, the MikroTik standard process doesn’t load NPKs in a safe order. Nothing is as much fun as when a CPE loads the system package first, then gets interrupted before downloading wireless. When it next comes up, it’s running the new system, but nobody can talk to It and you have to send out a truck.
Ah I thought the procedure was to first download all the packages, then install them all upon reboot... maybe this is different for that method.
Usually our devices run the bundle package, plus sometimes an optional package like ntp, So this should not be an issue.
And our network is sufficiently meshed to allow access to a device from wireless and ethernet in most cases.

Upon reviewing my code, I remembered what the problem was. There is a bug in /system upgrade where if you choose download-and-reboot, it will begin downloading packages – then if for some reason it doesn’t complete (like a network disconnection), it will timeout the download, but then will reboot anyway! This means that you end up with a machine that doesn’t have all the packages it needs, and if it’s a CPE and one of the missing packages is wireless, it’s off the network until you can drive out to it. Like you, we maintain redundant paths to almost all of our transport units, but CPEs are dead-ended by their nature.

We don’t use the consolidated NPK – to optimize resources, we load only the six or seven individual packages that we need.

doush · Sat Mar 31, 2018 4:17 am

It is actually quite ironic that hackers and botnets have shell access to our devices but we dont

)

avantwireless · Sat Mar 31, 2018 4:48 am

Ironic wouldn't be the word I would choose... Not having shell access in routeros has always been a serious flaw in a great product. And that this access is there without Mikrotik for the black hats now, pretty much invalidates any reason that we shouldn't. Strange files were the easiest way of determining if UBNT products were hacked. Just telling us Upgrade and pray is completely the wrong tact to take. "Trust us we are on this" did not work for UBNT..

eXS · Sat Mar 31, 2018 8:31 am

Assign cases, not "that's the other problem"

1) Upgrade to 6.38.5 fixes the botnet scanner and removes it. <cite specific article>
2) Upgrade to 6.41.3 fixes SMB vulnerability. <cite specific article>

Sat Mar 31, 2018 11:00 am

I recommend that you re-read all the posts from "normis". Seems that we are going into circles.

1) Winbox port is used only to find out that this is RouterOS powered device (Winbox is not affected by vulnerabilities that we know of);
2) WWW service ("/ip service") is used in order to "hack" your router if Firewall did not drop connections to this port (affected service was Webfig which by default is running on port 80, but you can change port under "/ip service" menu and then this other port must be protected). For example, "/ip firewall filter add chain=input action=drop in-interface=WAN connection-state=new";
3) Issue with SMB is completely another thing but the same rules apply. If device (in this case SMB port) is protected by firewall, then no one can use this issue in order to mess up with your router. Usually attacks come to your router from public Internet (not from LAN) and in normal situation SMB access is not open for public Internet;
4) There is not and will not be an official way to gain access to routers shell.

You will be safe from both of these issues if you upgrade your routers (6.38.5 for WWW issue and 6.41.3 for SMB). In order to upgrade many devices at the same time - you can use MikroTik tool called The Dude or use scripts.

pe1chl · Sat Mar 31, 2018 12:15 pm

strods,

I hope you understand that the "NAT router to internet" scenario is not the only application of MikroTik routers, and that in fact
a lot of these routers are used in a scenario where there are many users (of which it is not certain that all can be trusted) interconnected
by (wireless) links.
Of course one would not deploy (IMHO useless) services like SMB on such routers, but it is quite common that the WWW service
is available at least to some local subnet.
Also, those networks are not always managed by one single entity. Users connect to a friendly neighbor, but there is no place
where an update of all devices can be performed, nobody has all the access and all the passwords.

On most routers we have a separate admin network so the users cannot connect it, and we also use address lists with trusted
addresses that are allowed to access the router admin interfaces, but this is not completely reliable (addresses can be spoofed)
and it is also not easy to manage (the use of DNS-based address lists is considered to fragile fo this purpose, and RouterOS lacks
a mechanism for central management of a large number of routers without custom programming). So on access points we normally
don't have this address list and only the "block from outside our network range".

So the generic solution of "assume all the bad guys are on the internet so firewall that and you are safe" is a little bit too limited.
We need good security for the built-in services, and foremost we need more openness from your side about security issues.
Not those vague "improved the reliability" on change notices when there is in fact a security issue being fixed.
And preferably some separate forum area or place on your website where security related info can be easily found, including
any known issues that have been fixed and in what version.

Don't tell us that disclosing such information would potentially help the bad guys; we all know that it does not work like that anymore!
The information will get around anyway, except that it will be only in the hands of the abd guys and those that want to keep their
networks secure are left in the dark.

HaQs · Sat Mar 31, 2018 3:21 pm

In order to upgrade many devices at the same time - you can use MikroTik tool called The Dude or use scripts.

Dude ok , it is ok for update network (added to dude), but how upgrade clients not add to dude ?
I do not intend to add or monitor a few thousand clients in dude.

is there any way for dude to upgrade automatically without adding devices to the map / dude?
I do not want these devices in dude.

Only something on the basis of the range ip or class and does the upgrade.
Or it runs a script on each turn.

nishadul · Sat Mar 31, 2018 3:58 pm

Thanks for advise of security purpose

srosen · Sat Mar 31, 2018 6:54 pm

I can upload this /rw/info file if you need it, virustotal analysis shows nothing.
These are leftover files. They don't do anything. This is not the program itself, only some remaining things it created. You can delete those if you like, but the device is no longer "infected" as you say

Normis - It's somewhat comforting that Mikrotik is confident that the upgrade to 6.41.3 "cures" the infection. But, I have to say that random12's posts have me very nervous. I understand that he has used an unofficial (or unsupported) shell to observe what's running on his box, and that could be the source of his additional problem. But, I don't think we have any clear evidence that the ram.info file, etc. running in memory on his 6.41.3 machine is not the norm after an attack by this botnet.

Can I suggest that it would be prudent of Mikrotik to review a number of previously infected machines (maybe 20 samples or so) and use your tools to verify that there are NOT any unusual files running in memory after a 6.41.3 upgrade (I understand that the files may left be on disk)? Then, assuming that it is true that a 6.41.3 upgrade does restore the machine to normal status, you can post that you have actually tested and analyzed 6.41.3 upgraded routers and confirm that an infected machine is absolutely clean after?

I am very concerned that random12's process list is the same type of thing that I may have on a handful of infected machines. If that's the case, we could all be sitting on a much, much bigger time bomb than what began last week.

Scott

mrtester · Sat Mar 31, 2018 7:45 pm

I would never run a massive upgrade on my network. What if something goes wrong? I think that massive router upgrade is not a very smart idea.

eddieb · Sat Mar 31, 2018 7:48 pm

I fully agree, upgrading is part of general maintenance and should always be done in a controlled matter ...
Maintenance takes time and cost money.

Sat Mar 31, 2018 7:51 pm

If you have upgraded your router to the latest RouterOS version and you still have doubts that your router might be infected (we have not seen such case so far), then please contact support@mikrotik.com. If you have additional questions or concerns, then please send a message to support@mikrotik.com

mrtester · Sat Mar 31, 2018 7:57 pm

Also I would never leave an open access for anyone besides me or other administrators for particular services. Had some of the MIPSLE units running on old version at the clients office - all of them were affected. Fixed them with Netinstall. Problem was - do not trust particular IP addresses. There was an open access for an IP which most likely was affected too and infected my route as well.

pe1chl · Sat Mar 31, 2018 9:19 pm

I would never run a massive upgrade on my network. What if something goes wrong? I think that massive router upgrade is not a very smart idea.

As this incident shows, massively not upgrading is an even worse idea.

What I suggested is a method of keeping a minimal version on routers configured to retrieve that from a configured location.
Upgrades can start manually, tested, and only when confident that the version to be installed is OK and the migration is smooth, it will
be made available for the others. Depending on the frequency at which the routers check if there is an update, the updates can still
be spread over time.

Note that not all networks are centrally managed. The internet isn't, but some other networks aren't either. So "pushing" updates is
not always realistic, but voluntarily pulling updates can be. However, there is no existing mechanism to do that, it can only be scripted.

hknet · Sat Mar 31, 2018 9:46 pm

We see a development (and others too) port scanning for winbox 8291 is dropping while port 2000 (bandwidth-test-service) is going strong.
Also telnet ist still highly active with those hijacked mikrotiks.

schadom · Sat Mar 31, 2018 11:28 pm

We see a development (and others too) port scanning for winbox 8291 is dropping while port 2000 (bandwidth-test-service) is going strong.
Also telnet ist still highly active with those hijacked mikrotiks.

Can confirm this. Although no clue yet if port 2000 is used just for probing or if there is another vulnerability.

edit: https://twitter.com/360Netlab/status/980078343738535936

doneware · Sun Apr 01, 2018 12:25 am

Can confirm this. Although no clue yet if port 2000 is used just for probing or if there is another vulnerability.

edit: https://twitter.com/360Netlab/status/980078343738535936

seems kinda logical. open tcp/2000 port can hint Mikrotik device as well, so the exploit against it can be launched.
as you have the credentials for a router, bandwidth-test is a great (built-in) way to launch ddos attacks.

tippenring · Sun Apr 01, 2018 9:13 am

You are mixing up two different topics! Botnet is discussed here.
It's more than related: since "the botnet issue" has started we detected malicious activity on our Mikrotiks.

I tend to think that you have detected malicious activity unrelated to the botnet issue discussed in this post.

An SMB vuln was resolved in 6.41.3. Perhaps that is your issue.

Release 6.41.3 2018-03-12
What's new in 6.41.3 (2018-Mar-08 11:55):

!) smb - fixed vulnerability, everyone using this feature is urged to upgrade;

Given, I'd like to know more about this new SMB vulnerability, but there is a tough balancing act between the generic "SMB vulnerability" announcement, and providing details that might unintentionally make it easier for attackers to take advantage of the vulnerability before people have the opportunity to update. I don't have SMB open, nor have I ever exposed port 80 to public sources. Not exposing services to any network unnecessarily is best practice. Discovering that after a successful attack is hardly Mikrotik's fault. The security of devices we are managing which are connected to other networks are our responsibility to secure. May as well start with the basics like not exposing unnecessary services to the world.

Ximi87 · Sun Apr 01, 2018 9:45 am

Thanks for advisory.

In my router i have disable port telnet and ssh.
I have set up a firewall role that detect and block all ip that scan my network.

I think i am save.

Thanks Normin.

pe1chl · Sun Apr 01, 2018 12:01 pm

Given, I'd like to know more about this new SMB vulnerability, but there is a tough balancing act between the generic "SMB vulnerability" announcement, and providing details that might unintentionally make it easier for attackers to take advantage of the vulnerability before people have the opportunity to update.

That is just hogwash. The attackers do not use this information to know what devices they can attack, they have their own channels for that.
So keeping back details is just going to hurt the legitimate users, not the attackers.

The current "!) smb - fixed vulnerability, everyone using this feature is urged to upgrade; " is of course the very mininum that should be there in
the release notes, in earlier versions it was something like "!) smb - improved reliability of pathname scanner" and that not the info we as the users need.

However, it still can be improved. Like mentioning the CVE ID for each vulnerability that has been fixed, making it easier for users to evaluate
if this vulnerability is a problem for them. Often a vulnerability is mainly a DoS and in that case one could postpone upgrading a bit more than
in case it allows elevation of privilege or execution of code in highly privileged context.

(which is an area in which MikroTik apparently need to improve - a remote code execution vulnerability in SMB should be not so harmful when
the SMB software is running as a lower privileged user that has no filesystem access outside the user visible file area and there are no known
local privilege escalation attacks)

Sun Apr 01, 2018 3:45 pm

The automatic script spreading around the World uses Winbox port to determine a RouterOS powered device. You are not protected against the vulnerability from any other automated script or hacker attacking your device by protecting Winbox (or, for example, BTest server) port. You are safe only if you upgrade your device - this is the only permanent solution. You can protect your device by firewall - you will be safe from the attack only if you drop access for WWW service (since attacker can be also on your local network - we can not provide precise example how to protect yourself 100%. To put it in another words - WWW service must be allowed only for trusted devices).

Please note that we are providing an examples for you. Previously mentioned ways how to protect yourself, how to upgrade devices, etc. If you want to figure out the best solution for your particular case - please write to support. We will be happy to help you. We can not in single forum post provide an example of anything which would satisfy everyone and everyones network.

juliokato · Sun Apr 01, 2018 4:23 pm

Dose not have smb correction for bugfix version?
Why exist the bugfix version?
Does The bugfix not have smb vulnerability?

mrtester · Sun Apr 01, 2018 5:55 pm

With massive upgrade I did mean many devices at the same time. I have upgraded all of mine as soon as I heard about the problem. But I always perform an upgrade one device by one. I have learned that from release topics where people are complaining that all of the devices have to be reinstalled due to the version. Why would you upgrade all of them right away.... I never do that - one by one only!
Seems that TLDR applies sometimes in this forum. Answer for your question juliokato is right here viewtopic.php?f=21&t=132499&start=50#p651331

msatter · Sun Apr 01, 2018 6:44 pm

Dose not have smb correction for bugfix version?
Why exist the bugfix version?
Does The bugfix not have smb vulnerability?

No SMB fix, yet in the bugfix.
More stable version.
The bugfix has the SMB vulnerability. See answer answer one.

PMTech · Sun Apr 01, 2018 11:32 pm

Nothing is safe!

Whether you're Cisco, Juniper, Mikrotik, Microsoft or Apple - Humans are writing code and we all get it wrong. I've read the topic through and I do think Mikrotik could do more (later) but I think some posters have taken a base config of a Mikrotik device, put it in production (possibly across their entire estate) and then carried on with their next task and not really paid much attention to keeping that estate 'live' and current. Acknowledge Mikrotik - once these disclosures hit they're not scrambling to release fixes - they're already done, there are so many vendors out there who don't even have patches for vulnerabilities or that will charge you the earth to stay subscribed just so you can download patches for stuff you paid for in the first place.

Anyway
1. Always change the default password
2. Change the default username
3. Stop services you don't use (SSH, Telnet, API, API-SSL) etc. IP->Services
3a. Neighbors
3b. Bandwidth Test
3c DNS remote requests
3d etc.
4. For the services you do use, move them to a non-standard ports : HTTP : 20080, Winbox 20081, etc
5. Consider stopping anything that is insecure (http, API, FTP, etc)
6. Put some default rules in for input->block, forward->block and then work back from there with allow rules
7. Implement a port-knocking system for the ports you do use
8. Don't treat this as an exhaustive list!
9. Once you've got a great config then do an 'Export file=MyDefaultConfig' and apply it to everything going forwards, improving as you go

There are lots of resources out there for hardening *all* firewalls and they start off like the above. There are further resources out there for Mikrotik.

I think if you're going to have a lot of devices out there that you manage then you need to have started with some of the above in mind. If you want a good starter document then look at the PCI compliance SAQ D form - this is a big long list of things you would do to harden your network against credit card theft but a lot of it is good practice if you want to secure your network in general.

Mikrotik have offered : if you're unsure about activity on your device, email them, they'll look into it. I bet you they'll do that whether you have proof of ownership or not, how many other vendors will do that for you.

@Mikrotik - Netinstall is hard work. Pressing that stiff button on 500 devices and uploading a default config can be hit and miss. Lots of tutorials out there bout disabling network cards and such just to make it work, can we improve this ?
@Mikrotik - A custom repository option for upgrades would be great.
@Mikrotik - If you don't already list CVEs addressed in the changelog files then that would help us

I know that's probably not a massive help but security is a never-ending process these days!

squeeze · Mon Apr 02, 2018 12:40 am

TL;DR. Centralization in security information helps Mikrotik every bit as it does its existing customers, prospective customers and the broader community.

Mikrotik need to be much more direct and centralized about even the very basics, like what specific vulnerabilities have been fixed and when (we can only hope for mitigation and workaround info).

This is just one of the reasons centralized and dated databases like CVE numbers, and why many other software and networking vendors numbered and versioned security update lists, exist. So, that they are trivially accessible, can be referenced directly, remove massive confusion from different sources and minimize both customer anxiety and broader concerns right now, let alone in future.

At the moment any precise security information is in a forum post, very often not even in changelogs. Yet internally you must keep a log of security fixes?

For example, in almost the same period of time, remote access security issues have blown up in the media around:

SMB service/NetBIOS messages
unsecured external web services
web service vulnerabilities
aggressive port scanning against Winbox ports
Hajime IoT botnet/worm
Slingshot malware and spyware - one of the most sophisticated spyware platforms ever discovered in the wild (meaning it must be a state actor) and to date it only affects Mikrotik devices

These are not necessarily the same underlying security issues, but due to widespread reporting confusion - all in different languages too - and, unsurprisingly, some actual hysteria abounds!

On top of that, there are even more risks. Existing known attackers are often only using older vulnerabilities yet have the potential to upgrade to use new ones, e.g. Slingshot or variants have not been seen attempting to use the SMB vulnerability.

It is notable that there can be more specific information about Mikrotik device security in some journalist articles than there is from Mikrotik itself, e.g. the the one from VirusGuides.

All of this now or in future could even constitute a directed or careful attack against Mikrotik with no real indication of how further it could scale. How best to defend yourself?

No matter how small an organisation, a simple static HTML page and references to CVE or security update IDs in changelogs, for example, cannot be that hard to maintain since you already have all that information.

jabberd · Mon Apr 02, 2018 1:26 am

In addition, there's a new Mirai variant available spreading over. Dropbear ssh server listens at port 62508/tcp, an instance of busybox+tcpdump+libpcap and a startup script for dropbear are in the file system.

finalcutroot · Mon Apr 02, 2018 2:05 am

this will block the winbox bruteforce attempt

add action=drop chain=input comment="drop winbox brute forcers" dst-port=8291 protocol=tcp src-address-list=winbox_blacklist
add action=add-src-to-address-list address-list=winbox_blacklist address-list-timeout=1w3d chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=\
ssh_stage3
add action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=1m chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=ssh_stage2
add action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=ssh_stage1
add action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m chain=input comment="drop winbox brute forcers" connection-state=new dst-port=8291 \
protocol=tcp

macsrwe · Mon Apr 02, 2018 4:17 am

@Mikrotik - Netinstall is hard work. Pressing that stiff button on 500 devices and uploading a default config can be hit and miss. Lots of tutorials out there bout disabling network cards and such just to make it work, can we improve this ?

Hopefully, you are aware that on a working router you can trigger netinstall with /system routerboard settings set boot-device=try-ethernet-once-then-nand; then rebooting. Much easier than pushing button, especially if router is located up a tower.

The disabling network cards issue has to do with treatment of Windows OS to any BOOTP protocol server when multiple interfaces are active, not under MikroTik's control.

minelli · Mon Apr 02, 2018 1:45 pm

Hi again,

We have a bunch of Mikrotiks with OS version higher than vulnerable one but all of them are still infected.

Even after "update FW" -> "reboot" -> "change password".

\

So even with the 6.41.3 all our devices are still infected.

Please respond ASAP and provide us instructions on how to remove all this shit from our Mikrotiks.

I can upload this /rw/info file if you need it, virustotal analysis shows nothing.

Good morning random12, could you make the package or access the console of RouterOS?
I would also like to verify this in my own.
Please email me the procedures.

Thank you very much in advance.

amt · Mon Apr 02, 2018 2:54 pm

what happen when device infected ? I read post's but cant see what this infection does to the equipment.

Darryl · Mon Apr 02, 2018 3:35 pm

Normis,

Is it also true to say that using net install with any version will also remove the bad files? Obviously reinfection is possible below 6.38.5, but files that were mentioned from the console output with special npk package, would those be removed using net install specifically ?

How to detect and cure?

- Upgrading to v6.38.5 or newer will remove the bad files, stop the infection and prevent anything similar in the future.

pe1chl · Mon Apr 02, 2018 4:35 pm

what happen when device infected ? I read post's but cant see what this infection does to the equipment.

The infection makes the device part of a botnet that will infect other devices and also can receive instructions
from the creator to do whatever he likes.

brandaoeb · Mon Apr 02, 2018 6:13 pm

Hi:
I use vpn (ipsec or sstp) and i can only access after vpn enabled.

Tue Apr 03, 2018 9:58 am

Thank you very much for the concerns!
To avoid countless topics that are partially related to the original problem, we decided to lock the topic.

Checkup list to make sure you are safe:
* MikroTik RouterOS version after (2017-Mar-09), 6.37.5/6.38.5 and higher.
* Firewall for "www" service (default port 80).

More information about the issue in the original post,
viewtopic.php?f=21&t=132499#p650812

If you have any issues, contact MikroTik support for help (support@mikrotik.com).

Who is online