Edit: 18.04.25
Please upgrade to MikroTik RouterOS 6.40.8 [bugfix] or 6.42.1 [current], the issue was addressed and fixed there,
https://mikrotik.com/download

We have discovered a new RouterOS vulnerability affecting all RouterOS versions since v6.29.

How it works: The vulnerability allowed a special tool to connect to the Winbox port, and request the system user database file.

Versions affected: 6.29 to 6.43rc3 (included). Updated versions in all release chains coming ASAP. Edit: v6.42.1 and v6.43rc4 have been released!

Am I affected? Currently there is no sure way to see if you were affected. If your Winbox port is open to untrusted networks, assume that you are affected and upgrade + change password + add firewall. Make sure that you change password after an upgrade. The log may show unsuccessful login attempt, followed by a succefful login attempt from unknown IP addresses.

What do do: 1) Firewall the Winbox port from the public interface, and from untrusted networks. It is best, if you only allow known IP addresses to connect to your router to any services, not just Winbox. We suggest this to become common practice. As an alternative, possibly easier, use the "IP -> Services" menu to specify "Allowed From" addresses. Include your LAN, and the public IP that you will be accessing the device from. 2) Change your passwords.

What to expect in the coming hours/days: Updated RouterOS versions coming ASAP. RouterOS user database security will be hardened, and deciphering will no longer be possible in the same manner.

EXAMPLE how to protect yourself:

WOW. That is really scary.

Maybe having port-knocking needed for connection and then lifetime as long as established. Also implement this in Winbox and the Android APP.

Web interface is a no no from external.

A unique TCP/UDP port sequence printed on the router label is needed to reach that router from external. This sequence can be changed by the admin but can be not disabled.

Once logged in, with Winbox, the admin can regenerate a new sequence in the router for the Winbox profile for that specific account. This new sequence is visible in the router and in the profile in Winbox. This can also be forced totally hidden so that a reset of the router is needed to go back to the sequence on the router label.
A new sequence is enforced from the next time connecting.

A problem with sequence portknocking is, that ports also can be used by the router. One way is not to use different ports but different times in the sequence for the packets.

Maybe easier is to have port 8291 as attention port for knocking and any knock on a port from the same source IP is not for normal firewall processing but for gaining access.

Example: TCP-8291 UDP-1234 TCP-8291 TCP-2341......

Change the service port can resolve the problem?
The problem with allow from is that not always we have static ip address
Suggestions could be that field accept dns names, or allow to read from addressing list

Sent from my XT1580 using Tapatalk

I use firewall rules which will kick an IP address if login fails after three attempts. Will this method be sufficient to be protected from this vulnerability?

By the way, thank you for letting us know about it.

I use firewall rules which will kick an IP address if login fails after three attempts. Will this method be sufficient to be protected from this vulnerability?

Does not appear so looking at the other posts. One failed attempt was in the logs...

This is really scary. Can you explain how this happened in a more technical manner? Why is authentication not the first thing that is required before downloading files etc is possible? Why is the user database even made available over the winbox port prior to establishment of an authenticated connection?

All these security bugs appearing lately in Mikrotik daemons are really shaking my trust in RouterOS. It's clear that a lot of Mikrotik code is not hardened against exploit attempts. What steps are Mikrotik taking to ensure this doesn't continue to happen? Have you considered hiring an external company to do a security audit of your code? This really can't keep happening.

EDIT: Please don't tell me this is related to the old 2012 exploit that lets you request files before login...

So is this it https://www.securityweek.com/remotely-e ... s-routeros ?

As its over month old post..

How it works: The vulnerability allowed a special tool to connect to the Winbox port, and request the system user database file.

They gain access on a file within the router, right? What kind of information is stored in there?

So is this it https://www.securityweek.com/remotely-e ... s-routeros ?

As its over month old post..

No, that's a different vulnerability in the SMB service.

Is this vulnerability exploitable if the Winbox service is not running?

@raffav If you are not using static IP's, use something like DYNDNS to set up aliases. Then, resolve the aliases in a script which will give you the IP addresses of the remote stations which are permitted access. Add these to the list of allowed IP's (Available From field in picture) and you have solved the problem.

As an alternative, possibly easier, use the "IP -> Services" menu to specify "Allowed From" addresses. Include your LAN, and the public IP that you will be accessing the device from.[/b]

Normis, it seems this not help.
On Czech forum is user which have winbox in IP services allowed only for his private range and is hacked
https://ispforum.cz/viewtopic.php?p=228863#p228863

How it works: The vulnerability allowed a special tool to connect to the Winbox port, and request the system user database file.

They gain access on a file within the router, right? What kind of information is stored in there?

You don't know what is stored in the system user database file ????

How it works: The vulnerability allowed a special tool to connect to the Winbox port, and request the system user database file.

They gain access on a file within the router, right? What kind of information is stored in there?

You don't know what is stored in the system user database file ????

No, do you? I f so let me know

The security issues are happening too frequent on MikroTik recently...

No, do you? I f so let me know

the file contains RouterOS system usernames and passwords.

How it works: The vulnerability allowed a special tool to connect to the Winbox port, and request the system user database file.

They gain access on a file within the router, right? What kind of information is stored in there?

You don't know what is stored in the system user database file ????

No, do you? I f so let me know

well, if I had to do some thinking, the system user database file contains the database with users and their password......

So is this it https://www.securityweek.com/remotely-e ... s-routeros ?

As its over month old post..

That is a completely different vulnerability that relates only to the SMB service, which by default is not even enabled (hence why you didn't hear much about this vulnerability).

This new one is a far scarier one. Somehow an attacker is not only able to remotely download the user database file, which bypasses all normal user authentication methods, but on top of that are trivially - within a couple of seconds - able to use the strongest of passwords to then log into the router using the Winbox port.

This implies at minimum that the user database file not only contains actual passwords (instead of hashes) but keeps those passwords in the clear or very close to it. Both practices are almost unheard of in modern security practices!

This means no matter what version of RouterOS, you are uncommonly at risk for the above reason.

While we await the vulnerability fix and basic RouterOS hardening, it is recommended to allow no direct public access to any external services on a RouterOS device, unless it is either IP-filtered or uses port knocking.

After the hardened RouterOS, all passwords should be changed as a basic security precaution, since any past compromise of the router (known or unknown) and by anyone, including insiders, means they may have access to all of the passwords.

On Czech forum is user which have winbox in IP services allowed only for his private range and is hacked
https://ispforum.cz/viewtopic.php?p=228863#p228863

It's possible the attack came from his LAN

The security issues are happening too frequent on MikroTik recently...

It is just that with Mikrotik's increasing popularity, hackers are now targeting RouterOS. Exploits exist on all equipment, just look at Cisco and Fortinet if you want an example...

On Czech forum is user which have winbox in IP services allowed only for his private range and is hacked
https://ispforum.cz/viewtopic.php?p=228863#p228863

It's possible the attack came from his LAN

I would also tend to agree. If you firewall all services on your WAN unless it comes from trusted IP's/ranges, then it would be very difficult to hack the tik from the WAN
I always firewall everything incoming to the tik and only allow access from specific ranges/ip's

It's possible the attack came from his LAN

It looks like the exploit is again of the "worm" type so if there is one leak into the LAN it can infect other MikroTik devices from the inside.

On Czech forum is user which have winbox in IP services allowed only for his private range and is hacked
https://ispforum.cz/viewtopic.php?p=228863#p228863

It's possible the attack came from his LAN

It is possible, but unlikely. All attacks have IP 103.1.221.39.
His screen attack - https://ispforum.cz/download/file.php?id=7933
More info send to support@mikrotik.com

it looks like a wan attack and IP services does not protect the login

What do do: 1) Firewall the Winbox port from the public interface, and from untrusted networks. It is best, if you only allow known IP addresses to connect to your router to any services, not just Winbox. We suggest this to become common practice. As an alternative, possibly easier, use the "IP -> Services" menu to specify "Allowed From" addresses. Include your LAN, and the public IP that you will be accessing the device from. 2) Change your passwords.

In addition to what was written :
set first in firewall filter "Drop port scanners rules" like this https://wiki.mikrotik.com/wiki/Drop_port_scanners but drop the scanners with RAW and finaly change the number of service port too !

it looks like a wan attack and IP services does not protect the login

Supout.rif will be useful, thanks. The Screenshot doesn't show if the "allowed from" was correctly set.

On Czech forum is user which have winbox in IP services allowed only for his private range and is hacked
https://ispforum.cz/viewtopic.php?p=228863#p228863

It's possible the attack came from his LAN

Hi Normis,

the Czech case contained the same IP in the log like the others I have seen yet. The IP is 103.1.221.39 (some network from Taiwan). Either someone tries to test some proof of concept (and runs the attack from only one station) or the IP in the log is faked one and the attack source was different IP. Maybe the attack vector causes the IP source is logged improperly? I have analysed data for last days and I can say that there was no communication with the IP 103.1.221.0/24 and our network (big amount of public IPs so I would expect a scan should hit us)...

Normis, could you explain if it is possible that the logged IP is not the real one? Or confirm that it really is the source of the attack?

Screenshot from Czech forum:
https://ispforum.cz/download/file.php?id=7933

If the Winbox server is the one doing the IP filtering, then an IP Services "Available From" restriction may not prevent the attacker from using the exploit against the Winbox server because the vulnerability is in the Winbox server ...

To be safe for now, only put IP restrictions on the IP Firewall itself.

How do we know if our router is infected what are the symptoms for this vulnerability ???

How do we know if our router is infected what are the symptoms for this vulnerability ???

Currently there is no sure way to see if you were affected. If your Winbox port is open to untrusted networks, assume that you are affected and upgrade + change password + add firewall. The log may show unsuccessful login attempt, followed by a succefful login attempt from unknown IP addresses.

What do do: 1) Firewall the Winbox port from the public interface, and from untrusted networks. It is best, if you only allow known IP addresses to connect to your router to any services, not just Winbox. We suggest this to become common practice. As an alternative, possibly easier, use the "IP -> Services" menu to specify "Allowed From" addresses. Include your LAN, and the public IP that you will be accessing the device from. 2) Change your passwords.

In addition to what was written :
set first in firewall filter "Drop port scanners rules" like this https://wiki.mikrotik.com/wiki/Drop_port_scanners but drop the scanners with RAW and finaly change the number of service port too !

This doesnt seam to work for me very good, i set the rules on top of my firewall list, also blocked via RAW but for example if i run port scanner from http://en.dnstools.ch/port-scan.html, it works and blocks access to it immediately as it runs.

But if i run it from https://mxtoolbox.com/SuperTool.aspx?action=scan, it finishes every time and shows my open ports on router without blocking it..

Try for your self.

It has loooooong been known that ROS stores passwords using reversible encryption instead of hashes, and I'm surprised it has taken this long for this to get changed: http://manio.skyboo.net/mikrotik/

On the other hand, when you are the one that set the password and you can't log in to your own router, even though you could just reset to defaults or Netinstall to fix it, it's sometimes nice to be able to recover it so that the question of "what on EARTH could I have possibly set the password to?" doesn't constantly nag you.

-- Nathan

To be safe for now, only put IP restrictions on the IP Firewall itself.

We can only imagine what problems there will be when a vulnerability in the firewall is found...
And at the rate that they are found lately, how long will that take?

On the other hand, when you are the one that set the password and you can't log in to your own router, even though you could just reset to defaults or Netinstall to fix it, it's sometimes nice to be able to recover it so that the question of "what on EARTH could I have possibly set the password to?" doesn't constantly nag you.

Remember that normis has told us time after time that it is not possible to recover a password from a MikroTik device, you would have to reset and netinstall it.
Was that really true? Or is what is now called a "vulnerability" in fact really a backdoor to retrieve the passwords from a seized device?
It is a bit too obvious that you can download the user database, something you normally cannot even do from winbox as an authenticated user, over the winbox port, without being authenticated.

What do do: 1) Firewall the Winbox port from the public interface, and from untrusted networks. It is best, if you only allow known IP addresses to connect to your router to any services, not just Winbox. We suggest this to become common practice. As an alternative, possibly easier, use the "IP -> Services" menu to specify "Allowed From" addresses. Include your LAN, and the public IP that you will be accessing the device from. 2) Change your passwords.

In addition to what was written :
set first in firewall filter "Drop port scanners rules" like this https://wiki.mikrotik.com/wiki/Drop_port_scanners but drop the scanners with RAW and finaly change the number of service port too !

This doesnt seam to work for me very good, i set the rules on top of my firewall list, also blocked via RAW but for example if i run port scanner from http://en.dnstools.ch/port-scan.html, it works and blocks access to it immediately as it runs.

But if i run it from https://mxtoolbox.com/SuperTool.aspx?action=scan, it finishes every time and shows my open ports on router without blocking it..

Try for your self.

I try and my router block scan instantly.

RouterOS doesn't have backdoors. This is a bug that was introduced in 6.29.

The fact that password encryption was considered "weak" is not news. The file was previously hard to get. We are also improving the encryption of the user password file now.

Here's a simple port-knocking firewall + address list for anyone who wants to implement it in the interim for access to the default winbox port (8291)

First add any custom IP address ranges (known safe networks) you need like so: Then paste the following - make sure to update the port knocking rules to something random that you can remember.. the easiest way is to hit these sequentially using a web-browser if you're coming from a new IP address and need access.
A set of private addresses are added by default so you don't get locked out of your router from internally.

But if i run it from https://mxtoolbox.com/SuperTool.aspx?action=scan, it finishes every time and shows my open ports on router without blocking it..
Try for your self.

OK, try this :
ip fi fi add action=add-src-to-address-list address-list=Port_Scanner address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=21,3s,3,1

We have discovered a new RouterOS vulnerability affecting all RouterOS versions since v6.29.

How it works: The vulnerability allowed a special tool to connect to the Winbox port, and request the system user database file.

Versions affected: 6.29 to 6.43rc3 (included). Updated versions in all release chains coming ASAP.

Am I affected? Currently there is no sure way to see if you were affected. If your Winbox port is open to untrusted networks, assume that you are affected and upgrade + change password + add firewall. The log may show unsuccessful login attempt, followed by a succefful login attempt from unknown IP addresses.

What do do: 1) Firewall the Winbox port from the public interface, and from untrusted networks. It is best, if you only allow known IP addresses to connect to your router to any services, not just Winbox. We suggest this to become common practice. As an alternative, possibly easier, use the "IP -> Services" menu to specify "Allowed From" addresses. Include your LAN, and the public IP that you will be accessing the device from. 2) Change your passwords.

What to expect in the coming hours/days: Updated RouterOS versions coming ASAP. RouterOS user database security will be hardened, and deciphering will no longer be possible in the same manner.

EXAMPLE how to protect yourself:

Screen Shot 2018-04-23 at 13.01.48.png

Change:
We have discovered a new RouterOS vulnerability affecting all RouterOS versions since v6.29.
By:
We have discovered, thanks to our customers, a new RouterOS vulnerability that affects all versions of RouterOS since v6.29.

Do you have a problem with the ssh daemon?
import to store: 1
STORE /nova/store/ssh-forwarding: openIdx failed: 2 No such file or directory
password:

On the other hand, when you are the one that set the password and you can't log in to your own router, even though you could just reset to defaults or Netinstall to fix it, it's sometimes nice to be able to recover it so that the question of "what on EARTH could I have possibly set the password to?" doesn't constantly nag you.

Remember that normis has told us time after time that it is not possible to recover a password from a MikroTik device, you would have to reset and netinstall it.
Was that really true? Or is what is now called a "vulnerability" in fact really a backdoor to retrieve the passwords from a seized device?
It is a bit too obvious that you can download the user database, something you normally cannot even do from winbox as an authenticated user, over the winbox port, without being authenticated.

Even with the later versions or ROS, you can download a backup, restore it on a virtual machine running same software version, downgrade to an earlier software version, take a new backup and feed that to the reverse engineer tool which will spew out the passwords for every user in the database.
This has been known for quite a few years. In part it is why they implemented the restore password, but if you downgrade to a version which does not require a password for the backup you're all set for recovery.
It would mean that you need to have access to the device, but with bugs like this one, that could become very trivial in the near future

But if i run it from https://mxtoolbox.com/SuperTool.aspx?action=scan, it finishes every time and shows my open ports on router without blocking it..
Try for your self.

OK, try this :
ip fi fi add action=add-src-to-address-list address-list=Port_Scanner address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=21,3s,3,1

Actualy i just realized i does work good in theory, but this site alternates ip address, so it took me 3-4 runs to block all 3 IPs and now it returns zero ports and blocks it properly.

But that whats the point of this, i ran it 3 times and got all my ports listed 3 times before mikrotik blocked it, "attacker" already have all it needs.

But that whats the point of this, i ran it 3 times and got all my ports listed 3 times before mikrotik blocked it, "attacker" already have all it needs.

Scan this 93.155.148.98 - my IP address and tell me the open ports please!

But that whats the point of this, i ran it 3 times and got all my ports listed 3 times before mikrotik blocked it, "attacker" already have all it needs.

Scan this 93.155.148.98 - my IP address and tell me the open ports please!

It shows none now, but is this site already on your block list?Try clearing the blocked ip list before running it.Also, try actually for test put some port open like 80, i have that one and it shows it as open when i run this scan for 3 times, and firewall rule catches 3 different ip addresses from this site scaner. After that it blocks scan and shows all ports CLOSED.

Even with the later versions or ROS, you can download a backup, restore it on a virtual machine running same software version

As a user without insight in the internals, you can download a backup only from a router when you know the password already, right?
What is happening here is downloading files from a router without the password. Over a port that normally doesn't even allow downloading those files.
I find it hard to believe that this is simply "a bug". There must be base functionality of downloading, and the bug is only that it can be done without authentication.
But the downloading functionality shouldn't even be there in the first place, in the model of "we keep all internals secret and the user can only use the config interfaces and API".
To me, it sounds more like a debugging feature accidentally left enabled, or a requirement from law enforcement they are not allowed to tell us about.

It is a bug though, very specific check was broken for a very specific feature.
I don't want to give ideas to other people, as the fixed versions are not out yet, and it will take a while until most people upgrade.
This is why I don't want to give too many details away.

Concur this is a serious issue and glad Mikrotik is addressing it promptly. However it appears, (not 100% sure) that the failure by an admin to ensure WINBOX is not accessible from the outside is what allows this exploit to be used. Most experienced admins would use vpn to access the router and then muck about. It would be folks like me, ordinary users, or perhaps lazy admins that would attempt to use Winbox to gain remote access. My own personal feelings on the matter is that we should be using rolling code devices with Winbox for external access (home owner) and you experienced chaps can use VPN. I only intend to use WINBOX internally in the current scheme.

Concur this is a serious issue and glad Mikrotik is addressing it promptly. However it appears, (not 100% sure) that the failure by an admin to ensure WINBOX is not accessible from the outside is what allows this exploit to be used. Most experienced admins would use vpn to access the router and then muck about. It would be folks like me, ordinary users, or perhaps lazy admins that would attempt to use Winbox to gain remote access. My own personal feelings on the matter is that we should be using rolling code devices with Winbox for external access (home owner) and you experienced chaps can use VPN. I only intend to use WINBOX internally in the current scheme.

You are right. RouterBOARD devices come with default configuration that is immune to this kind of attack. The vulnerability can only be exploited, if you specifically opened Winbox to untrusted networks.

Even with the later versions or ROS, you can download a backup, restore it on a virtual machine running same software version

As a user without insight in the internals, you can download a backup only from a router when you know the password already, right?
What is happening here is downloading files from a router without the password. Over a port that normally doesn't even allow downloading those files.
I find it hard to believe that this is simply "a bug". There must be base functionality of downloading, and the bug is only that it can be done without authentication.
But the downloading functionality shouldn't even be there in the first place, in the model of "we keep all internals secret and the user can only use the config interfaces and API".
To me, it sounds more like a debugging feature accidentally left enabled, or a requirement from law enforcement they are not allowed to tell us about.

As a user without insight in the internals, you can download a backup only from a router when you know the password already, right?
What is happening here is downloading files from a router without the password. Over a port that normally doesn't even allow downloading those files.
I find it hard to believe that this is simply "a bug". There must be base functionality of downloading, and the bug is only that it can be done without authentication.
But the downloading functionality shouldn't even be there in the first place, in the model of "we keep all internals secret and the user can only use the config interfaces and API".
To me, it sounds more like a debugging feature accidentally left enabled, or a requirement from law enforcement they are not allowed to tell us about.
[/quote]
that is indeed with having access to the router, but as I said, "but with bugs like this one, that could become very trivial in the near future".

What is happening here is downloading files from a router without the password. Over a port that normally doesn't even allow downloading those files.
I find it hard to believe that this is simply "a bug". There must be base functionality of downloading, and the bug is only that it can be done without authentication.
But the downloading functionality shouldn't even be there in the first place, in the model of "we keep all internals secret and the user can only use the config interfaces and API".
To me, it sounds more like a debugging feature accidentally left enabled, or a requirement from law enforcement they are not allowed to tell us about.

Don't attribute to malice what can be easily explained by incompetence. Even a basic buffer overflow or injection bug can allow full control of any networked device on the planet remotely. Security is hard.

Also, like normis said, it would be irresponsible for the manufacturer themselves to release further details of the exploit without a fix, especially when they themselves only discovered it from their customers a few days ago (who btw, they have unusually not acknowledged).

The only problem here is a startling lack of defense in depth for security in the very core of RouterOS. The normal security assumption is that outer layers of security can always be penetrated, so further layers need to be present, and are normally even stronger. Instead of a good onion, Mikrotik have a coconut - great outer protection, but once you're in, you're IN.

Concur this is a serious issue and glad Mikrotik is addressing it promptly. However it appears, (not 100% sure) that the failure by an admin to ensure WINBOX is not accessible from the outside is what allows this exploit to be used. Most experienced admins would use vpn to access the router and then muck about. It would be folks like me, ordinary users, or perhaps lazy admins that would attempt to use Winbox to gain remote access. My own personal feelings on the matter is that we should be using rolling code devices with Winbox for external access (home owner) and you experienced chaps can use VPN. I only intend to use WINBOX internally in the current scheme.

You are right. RouterBOARD devices come with default configuration that is immune to this kind of attack. The vulnerability can only be exploited, if you specifically opened Winbox to untrusted networks.

or if you started your config from an old ROS version. Upgrades don't put new firewall rules in place, so if one had an old config that did not include these security measures and just upgraded, they would still be vulnerable

That is true, yes.
We have a nice article on how to make your device secure, I suggest everyone read it, as it contains most of the basics:

https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

What is happening here is downloading files from a router without the password. Over a port that normally doesn't even allow downloading those files.
I find it hard to believe that this is simply "a bug". There must be base functionality of downloading, and the bug is only that it can be done without authentication.
But the downloading functionality shouldn't even be there in the first place, in the model of "we keep all internals secret and the user can only use the config interfaces and API".
To me, it sounds more like a debugging feature accidentally left enabled, or a requirement from law enforcement they are not allowed to tell us about.

Don't attribute to malice what can be easily explained by incompetence. Even a basic buffer overflow or injection bug can allow full control of any networked device on the planet remotely. Security is hard.

Also, like normis said, it would be irresponsible for the manufacturer themselves to release further details of the exploit without a fix, especially when they themselves only discovered it from their customers (who btw, they have unusually not acknowledged) a few days ago.

The only problem here is a startling lack of defense in depth for security in the very core of RouterOS. The normal security assumption is that outer layers of security can always be penetrated, so further layers need to be present, and are normally even stronger. Instead of a good onion, Mikrotik have a coconut - great outer protection, but once you're in, you're IN.

this still is the device users/maintainers fault imo. THEY should implement basic security and best practices. Don't attribute to the vendor what the user should do.
indeed, newer ros version have some basic firewalling in place to prevent access like this, but still, security is everyone's problem, not only the manufacturer's imo

Is it enough by changing the winbox port and password?

Changing the Winbox port only protects your device from being found. If the attacker finds the new port, he can still gain access.
Firewall and the new RouterOS version is the best way to protect your device.

I just added to input specific src address who can access to winbox. I hope it's enough.
+ Rest input ports will be dropped

v6.42.1 and v6.43rc4 have been released! They fix the vulnerability.

Bugfix coming soon as well.

Don't attribute to malice what can be easily explained by incompetence. Even a basic buffer overflow or injection bug can allow full control of any networked device on the planet remotely. Security is hard.

Incompetence by MikroTik, yes. Recently it was already revealed that the webserver is running as root, now it looks like the same is true for the winbox service.
This really cannot be defended. It has to change.

The only problem here is a startling lack of defense in depth for security in the very core of RouterOS. The normal security assumption is that outer layers of security can always be penetrated, so further layers need to be present, and are normally even stronger. Instead of a good onion, Mikrotik have a coconut - great outer protection, but once you're in, you're IN.

Right. Services running on external ports should not have access to data that is considered secret.
In a standard Linux system, processes running at user privileges cannot access password hashes, and setuid-root programs are used to validate passwords.
That already is considered a weak system with opportunities for attacking those "trusted" programs (which have been proven faulty in the past), but nobody would consider running services as root under Linux. Why does MikroTik still do it?

I just added to input specific src address who can access to winbox. I hope it's enough.
+ Rest input ports will be dropped

If one does not have a specific FW rule ALLOWING EXTERNAL to INTERNAL access for the Winbox, then one should not be concerned as the default rules block WAN to LAN traffic, as they do for unsolicited traffic for every port. Nothing wrong for limiting access to WINBOX from the internal network as you have done and readily available in the settings.

I think Normis is saying ensure you have the basic default and recommended FW rules in place, and good practice to limit WINBOX to specific IPs in the internal network and wait for the upcoming firmware update.
If one has been using WINBOX for remote access to the WINBOX, I suggest delete the FW rule allowing this, that had to be specifically made by the admin, and learn VPN for remote access.

I still would like a rolling code type apparatus for the 'intimidated by VPN crowd', as remote can mean from any IP. Consider passwords in such scenarios as vulnerable but a rolling code is only of value for a very short period of time. There are good reasons why industry standard uses them and heck Ive used one for my paypal for at least 10 years.

Here's a simple port-knocking firewall + address list for anyone who wants to implement it in the interim for access to the default winbox port (8291)

First add any custom IP address ranges (known safe networks) you need like so:

/ip firewall address-list add address=123.123.123.123 list=Winbox_Admin comment="Custom";
SNIP
A set of private addresses are added by default so you don't get locked out of your router from internally.

In my posting above. I suggested to Mikrotik to integrate port-knocking in Winbox, Android APP and the router self so that external access is not possible if you don't have the right knock sequence. The sequence can be managed in router and synced to the at that time connected Winbox and Android APP.

If a other session is setup from a Winbox or Android APP that is not synced than the sequence has to be provided by the admin that synced his/her Winbox/APP with that box. The label on the router will only be valid when the router is reset or fresh from the box.

Layered security is needed good. The user database was retrievable and one point of failure made it posible and that was that the user believed that an good password was enough to keep others out. So essential files like the database have to be save even when leaked and an audit has to made to look at other weakpoints of which Mikrotik think that they can't be reached now.

A extra layer(s) of protection of even reaching the control interface of the router have to be implemented so that users who need external access can do that in a save an controlled way.
Password not enough and IP filtering is neglected or not possible due to dynamic source addresses. So an integrated Port-Knocking is in my opinion a good way so that we don't have to go the way of using certificates.

Hi,

virus seems to download binary files (marchdom4.com/mikrotik/x86_64 marchdom4.com/mikrotik/powerpc marchdom4.com/mikrotik/mips)
Anyone knows what these binaries do and are they removed after RouterOS Update?

Kind Regards
Manuel Ritter

Just FYI,

in logs I saw login attemps, but they all seems to failed, not one of them is successfull.

Just FYI,

in logs I saw login attemps, but they all seems to failed, not one of them is successfull.

This is from Web. Most likely unrelated.

Just FYI,

in logs I saw login attemps, but they all seems to failed, not one of them is successfull.

This is from Web. Most likely unrelated.

but should still be firewalled

Correct me if I'm wrong, but isn't something missing here? Now we know how they got passwords to log in, but what about those files (script and binary) uploaded to router and (probably) executed by RouterOS? Is it some other hidden functionality of WinBox we know nothing about?

Correct me if I'm wrong, but isn't something missing here? Now we know how they got passwords to log in, but what about those files (script and binary) uploaded to router and (probably) executed by RouterOS? Is it some other hidden functionality of WinBox we know nothing about?

When the tool gets your password, it has full access and installs some kind of tools. This is secondary. Most importantly is to close access to your device so this is impossible.

Just FYI,

in logs I saw login attemps, but they all seems to failed, not one of them is successfull.

This is from Web. Most likely unrelated.

Maybe, but this is strange. Web interface indeed is available from Internet, but I changed default port from 80 to something else, and there was 5 attemps in 2 seconds, possible attack ?

Although I understand the decission not to make the vulnerability information public, we need to know if a exposed winbox port with "Available From" address list is vulnerable or not.

We've some devices with disabled conntrack, so we can't protect it by firewall. For now we've completely disabled winbox service.

By the way, as it uses the same user database... can BTest Server be vulnerable? We've also deactivated it in all the routers...

Regards

Any Informations on how to use this exploit?
I've inherited a wide-range setup with unknown password and resetting will need a crane or something like this

Just FYI,

in logs I saw login attemps, but they all seems to failed, not one of them is successfull.

This is from Web. Most likely unrelated.

Maybe, but this is strange. Web interface indeed is available from Internet, but I changed default port from 80 to something else, and there was 5 attemps in 2 seconds, possible attack ?

scanning for the new port isn't hard to do.
firewalling that port (and others) will make sure they can't try to brute force it

When the tool gets your password, it has full access and installs some kind of tools.

That is kind of strange, because when I know the password of my router I still cannot install that kind of tools!
So there are multiple faults here.

Correct me if I'm wrong, but isn't something missing here? Now we know how they got passwords to log in, but what about those files (script and binary) uploaded to router and (probably) executed by RouterOS? Is it some other hidden functionality of WinBox we know nothing about?

When the tool gets your password, it has full access and installs some kind of tools. This is secondary. Most importantly is to close access to your device so this is impossible.

I have the admin password of my own router, how can I upload shell scripts and ELF binaries to be executed?

Like I said, this issue is secondary. It exists yes.

When the tool gets your password, it has full access and installs some kind of tools.

That is kind of strange, because when I know the password of my router I still cannot install that kind of tools!
So there are multiple faults here.

On MT specific hardware and using WINBOX -- winbox -- gains root access and if a vulnerability exists in Winbox code then root access can be had once that code is exploited but no one has yet proven that Winbox has that vulnerability .. so are there multiple faults here ---- like a special provision for Auctoritas?

When the tool gets your password, it has full access and installs some kind of tools.

That is kind of strange, because when I know the password of my router I still cannot install that kind of tools!
So there are multiple faults here.

On MT specific hardware and using WINBOX -- winbox -- gains root access and if a vulnerability exists in Winbox code then root access can be had once that code is exploited but no one has yet proven that Winbox has that vulnerability ..

I just installed it again with netinstall ... I do not want hidden visitors in my system....

Like I said, this issue is secondary. It exists yes.

Is that now fixed in the latest release? Or are we waiting for an exploit for that one once a new way to enter access has been discovered?

Like I said, this issue is secondary. It exists yes.

Is that now fixed in the latest release? Or are we waiting for an exploit for that one once a new way to enter access has been discovered?

Like a special provision for Auctoritas?

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

Shifting of the blame onto users... what else are we supposed to use for remote management?

The point being is that it appears there are folks out there that seem to understand how this router is coded from the ground up. So either the entire code has been compromised (stolen) or a former employee is disgruntled and is enacting revenge or a current employee is a criminal. I favour the latter scenario seeing as its based on recent work of 6.39..............
However, as I noted before for the Wireless Issues, a lack of communication strategy will lead to speculation which I am quite guilty of.................

To state hey don't worry (its just a secondary issue) about super sophisticated tools, that allow the hacker more granularity than you do as an admin, is the wrong approach with this group.
As for Auctoritas-what? Mozerd. Is this the title of the next book in the Dan Brown's Robert Langdon Series? ;-P

Just finished moving the entire network to 6.40.7 on Sunday and I was so proud
And this now


Hopefully a new Bugfix will be rolled out very soon

Normis (or other MikroTik people here) - can you, please, share the very important info: Is there a known attack / exploit you were informed about? Did you learn about this vulnerability from your own studies or from a "friendly" user? Or was someone already attacked, and it came during the analysis?
Or - simpler - is there a known exploit scanning the internet right now? Is there a group of people having detailed knowledge about this vulnerability? Or was it caught in advance, before anyone started exploiting it?

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

Shifting of the blame onto users... what else are we supposed to use for remote management?

Where do you see shifting blame on the users? It is information for users to know that routers are safe against this vulnerability if winbox port was protected.

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

Shifting of the blame onto users... what else are we supposed to use for remote management?

I can't understand how you have come to such a poorly devised conclusion so I wrote you a haiku.

MikroTik secures
You remove config, bad idea
Now act like boof head

Normis (or other MikroTik people here) - can you, please, share the very important info: Is there a known attack / exploit you were informed about? Did you learn about this vulnerability from your own studies or from a "friendly" user? Or was someone already attacked, and it came during the analysis?
Or - simpler - is there a known exploit scanning the internet right now? Is there a group of people having detailed knowledge about this vulnerability? Or was it caught in advance, before anyone started exploiting it?

It started here: viewtopic.php?f=2&t=133438

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

Shifting of the blame onto users... what else are we supposed to use for remote management?

Where do you see shifting blame on the users? It is information for users to know that routers are safe against this vulnerability if winbox port was protected.

Calling it "unsecured" makes it sound like the router was exposed to internet with no firewall or passwords. My router was secured with firewall and strong passwords, and yes, it had the management port open to the WAN. Does opening up any port to the WAN make the router "unsecured"?

I would much prefer if it were written such as:

!) winbox - fixed vulnerability that allowed to gain access to a router with an exposed winbox port

Only closing winbox port is enough?
what about api and api-ssl ports?

When is the first known exploit of this so we can browse the logs. And have exploit rewritten the log file ?

Only closing winbox port is enough?
what about api and api-ssl ports?

Disable any service you really really don't need. If you don't know what's it about, then you don't need it. Whatever remains (either winbox, https or ssh), protect with firewall as much as possible. Leave it open from only a few locations you can physically get to in due time, not to half of the country (just in case you're on the road). Getting hacked due to too wide open ports will give you more headache than occasional drive a few (hundred) kilometres (past experience will help you minimize number of rides after a while).

Thank You for the info

I've implemented the configuration

When is the first known exploit of this so we can browse the logs. And have exploit rewritten the log file ?

The exploit may not appear in the logs. It can download system passwords without logging in, so even if there appears no successful or failed logins, you should consider your passwords compromised and change them. As it's apparently possible to run arbitrary code after compromise, system log files could be tampered to remove any traces of exploitation. If you are really paranoid the only safe way would be to netinstall.

So far I have seen very few connection attempts to winbox port via mass internet scanning so it's unlikely you are compromised unless specifically targeted.

As for Auctoritas-what? Mozerd. Is this the title of the next book in the Dan Brown's Robert Langdon Series? ;-P

Auctoritas is a Latin word and is the origin of English "authority". While historically its use in English was restricted to discussions of the political history of Rome, the beginning of phenomenological philosophy in the 20th century expanded the use of the word.

Many "governments/police/invistigative arms" are requiring access to tech -- sometimes its mandated in a very secret way --- something that the Chinese [China] are doing which is one reason that I no longer will purchase Chinese made routers or switches that can act as routers plus a lot of other tech made in China

I have the admin password of my own router, how can I upload shell scripts and ELF binaries to be executed?

Now that the feature is officially confirmed (*), I think it won't take long to be documented by some good soul. The question is, how much MikroTik depends on having it in WinBox server, if they can easily block it or not.

(*) It wasn't my plan when I asked. I assumed WinBox used only some secure protocol to read/write options, not to have unlimited access to system internals.

That is true, yes.
We have a nice article on how to make your device secure, I suggest everyone read it, as it contains most of the basics:

https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

normis some of the commands in this article works only in old versions.

Like mac-server now uses an interface-list instead of disabled=yes

Just as an aside.Would a MAC-Winbox sessions also be vulnerable ?


Thinking of disabling Winbox service on all Routers/Bridges/Switches/Wap's etc.

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

Shifting of the blame onto users... what else are we supposed to use for remote management?

Where do you see shifting blame on the users? It is information for users to know that routers are safe against this vulnerability if winbox port was protected.

Better would be "...gain acces to router accessible from the internet'

The blame is shared between Mikrotik and the owner of the router.

Only closing winbox port is enough?
what about api and api-ssl ports?

Disable any service you really really don't need. If you don't know what's it about, then you don't need it. Whatever remains (either winbox, https or ssh), protect with firewall as much as possible. Leave it open from only a few locations you can physically get to in due time, not to half of the country (just in case you're on the road). Getting hacked due to too wide open ports will give you more headache than occasional drive a few (hundred) kilometres (past experience will help you minimize number of rides after a while).

If i don't use api's why i ask this???

del

v6.42.1 and v6.43rc4 have been released! They fix the vulnerability.

Bugfix coming soon as well.

hi Normis,

is bugfix only 6.40.7 -- we need to use for breach fix?

v6.42.1 and v6.43rc4 have been released! They fix the vulnerability.

Bugfix coming soon as well.

hi Normis,

is bugfix only 6.40.7 -- we need to use for breach fix?

Bugfix with fix for this issue has not been released just yet. Only Current and RC channels.

sorry for my english. Let's say the files save.sh and dnstest hit the router. By changing the password and limiting access from outside through winbox, is there a guarantee that there will be no outgoing connection from my infected router and the new password will not be transferred to the attackers in this way?

sorry for my english. Let's say the files save.sh and dnstest hit the router. By changing the password and limiting access from outside through winbox, is there a guarantee that there will be no outgoing connection from my infected router and the new password will not be transferred to the attackers in this way?

No. Outgoing connection are not that much or even not limited by the default rules.

You have to clean or restore before hooking the router to the wild wide west (internet) and don't forget to learn from and imlement the tios given in the first posting of this thread.

v6.42.1 and v6.43rc4 have been released! They fix the vulnerability.

Bugfix coming soon as well.

hi Normis,

is bugfix only 6.40.7 -- we need to use for breach fix?

Even with the fix in place you will still have to implement the limiting of access to the router. See first posting of this thread.

Is it enough by changing the winbox port and password?

Not if they can just request that new user and password because the vulnerability is still there. Also limit access as subscribed in the fist posting in this thread.

ok, so it seems that the proper firewall rules, dropping winbox and ssh connections from outside my trusted network - saves me for now from big f*up?

ok, so it seems that the proper firewall rules, dropping winbox and ssh connections from outside my trusted network - saves me for now from big f*up?

Not necessarily. If you had left your router open previously how do you know your device is not full of crapware. In other words, the correct thing to do is if the router was wide open previously to do some sort of reset to defaults PLUS PLUS. Mikrotik SHOULD PUBLISH a how to scrub the unit clean so it gets rid of whatever that virus planted or send you a new unit.

still waiting for the bugfix only update

Mikrotik SHOULD PUBLISH a how to scrub the unit clean so it gets rid of whatever that virus planted or send you a new unit.

netinstall without previous configuration ....

Hello please tell me how I will update my 3000 mikrotiks again quickly and easily is already the second time that this happens ...

The critical need is to update the ones that directly touch external gateways. Routers within your own network are much less at risk (assuming you don't serve an unusually vicious territory).

still waiting for the bugfix only update

Same here.

Mikrotik SHOULD PUBLISH a how to scrub the unit clean so it gets rid of whatever that virus planted or send you a new unit.

netinstall without previous configuration ....

This is not acceptable. Netinstall requires local travel to each individual router. Also, many routers are already installed in hard-to-access locations, such as towers and customer premises.

still waiting for the bugfix only update

Same here.

Me too

This is not acceptable. Netinstall requires local travel to each individual router. Also, many routers are already installed in hard-to-access locations, such as towers and customer premises.

Then what do you consider acceptable? A way to wipe the entire router erasing all traces of previous actions, but keeping the current configuration? Weird...

Hello please tell me how I will update my 3000 mikrotiks again quickly and easily is already the second time that this happens ...

use the dude to manage and monitor your mikrotik routers

Hello please tell me how I will update my 3000 mikrotiks again quickly and easily is already the second time that this happens ...

If you know how to manage 3000 devices you must have heard of The Dude or expect scripting.
At work we use expect scripting to automate a lot of networking related tasks.

I am too new to have discovered or researched netinstall or dude. I did buy and install an SD card which I believe is needed for dude.......
Thats fine if there is a way but I would expect MIKROTIK to publish a specific how to for this episode.

So how do you expect to secure 3000 routers without even reading MikroTik Documentation which is way smaller than the C++17 release specification??

If I understood correctly, Mikrotik keeps user passwords in a file in open form, not encrypted?!?!?!?!

If I understood correctly, Mikrotik keeps user passwords in a file in open form, not encrypted?!?!?!?!

Yes it is.
(and this bugfix doesn't solve it)

This is not acceptable. Netinstall requires local travel to each individual router. Also, many routers are already installed in hard-to-access locations, such as towers and customer premises.

Then what do you consider acceptable? A way to wipe the entire router erasing all traces of previous actions, but keeping the current configuration? Weird...

A previous exploit was closed with a release that ran a tool that sought out and destroyed files that were not supposed to be in the ROS image. That's a fair solution.

I can also envision a tool that allows a router to reboot from something you might think of as a predefined virgin netinstall image. As long as there is a way to set the default radio behavior so it would reconnect to its tower, everything else could be managed via ROMON.

But driving out to every router in a 220-square-mile territory, and making appointments to enter 400 homes to access their ethernet cables, is a non-starter.

still waiting for the bugfix only update

Same here.

Me too

still waiting ...

If I understood correctly, Mikrotik keeps user passwords in a file in open form, not encrypted?!?!?!?!

Yes it is.
(and this bugfix doesn't solve it)

Nope. Passwords do are encrypted, but using symmetric (a.k.a. reversible) encryption. And there is a pretty big reason for that - Winbox "secure mode" uses CHAP for authentication. CHAP requires the server to know the correct user input in order to derive hashes for confirmation. (TMK MT doesn't use MSCHAPv2 for some patent reasons inside the USA and PAP authentication is not secure in transit. They also can't use a proprietary protocol because of SSO login / RADIUS integration.)

Clue: attackers can compromise only the local user database, so if you make a local admin account "emergency-only" and active only to the reserved IP address (after a VPN or something like that) and every normal admin is authenticated through radius SSO, their account are 100% secure (provided they aren't using trivial passwords)

Change the service port can resolve the problem?
The problem with allow from is that not always we have static ip address
Suggestions could be that field accept dns names, or allow to read from addressing list

Sent from my XT1580 using Tapatalk

You may consider using a VPN (PPTP/OpenVPN) to be accessing your touter and set a firewall rule to allow only the IP of the VPN server.

sorry for my english. Let's say the files save.sh and dnstest hit the router. By changing the password and limiting access from outside through winbox, is there a guarantee that there will be no outgoing connection from my infected router and the new password will not be transferred to the attackers in this way?

No. Outgoing connection are not that much or even not limited by the default rules.
You have to clean or restore before hooking the router to the wild wide west (internet) and don't forget to learn from and imlement the tios given in the first posting of this thread.

No. These files were found in the RouterOS files directory. You can't run binaries or scripts from there. It seems the attacker though he will copy them inside RouterOS system to run them, but failed to do so. You can even see it inside the script, that there are actions that were supposed to be done, but obviously failed (like deleting of these files).

When a previously discovered vulnerability was fixed, we closed any options to run scripts and copy files inside other directories. This is why in this case, the attacker has uploaded something to the RouterOS Files folder (like you can also), but has failed to do anything else.

Well, this is really embarrassing, my enthusiasm with MikroTik is fading due to this few recent vulnerabilities and attacks.

Security must be top priority of vendor this size - we are not in the 90's anymore.
You could have set up at least few honey pot routers and tie them with some SIEM software so you could have deeper info when attack is happening - people have this at their homes nowadays.

Kind regards,
Robo

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

Shifting of the blame onto users... what else are we supposed to use for remote management?

why would you let everyone have possible access to your router?
EVERY router needs to be secured. You would not want anyone controlling your Cisco router, so why would you allow that on any other type of router?
If you want mgmt access, get a secure ip range or some fixed IP's which you control and deem as secure and manage from there. Like you would with any platform.
Securing your router is YOUR responsibility, not the manufacturers. Granted that they have to make sure the platform is secure, but leaving everything open because you *think* it is secure is your own fault if you're hacked then.

Just my $0,02

Well, this is really embarrassing, my enthusiasm with MikroTik is fading due to this few recent vulnerabilities and attacks.

Use Ubiquiti instead Then you will have huge security problems and vulnerabilities. In last two years they had very serious problems with attacks (with one our network was seriously affected). If you properly configure firewall on Mikrotik it is very safe.

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

Shifting of the blame onto users... what else are we supposed to use for remote management?

true indeed, but you shall not use winbox anyway. stuff that just downloads dlls from a remote devie (it used to for quite a long time) always scared the sht out of me

1. No. RouterOS user passwords are not stored in plain text, but anything can be decrypted with enough effort. We will now make this much harder to do.
2. Even if your device has other firewalls, but you have Management access open to the world, yes this still means unprotected.

true indeed, but you shall not use winbox anyway. stuff that just downloads dlls from a remote devie (it used to for quite a long time) always scared the sht out of me

Winbox should be merged with WebFig, everything in javascript and executed in a browser sandbox on the client.
But at the moment, the priorities are probably different.

There has to be privilege separation on the router. The service running on the router for winbox/webfig should not run with root permissions and it should not have access to things like user/password files, no write access to software storage locations, etc.
All accesses to those spaces should be via small and well-audited programs similar to "login", "sudo", "passwd" etc.

When can we expect the fixed BUGFIX. still waiting on that.

6.42.1 is "newer" than 6.42rcNN, right? It's an upgrade, not a downgrade?

6.42.1 is "newer" than 6.42rcNN, right? It's an upgrade, not a downgrade?

Yes, of course. We also have 6.43rc, don't mix those up.

Versions with FIX are the following:

6.42.1 (released)
6.43rc4 (released)
6.40.8 bugfix (released)

Firewall for Winbox port also protects your device, even with older versions.

6.40.8 is released, just updated!

@MT devs: I'd love to see new feature/button in Winbox (in wireless > registration table) which would mass upgrade all clients currently connected to AP to (let's say) latest version from current channel.

6.42.1 is "newer" than 6.42rcNN, right? It's an upgrade, not a downgrade?

Yes, of course. We also have 6.43rc, don't mix those up.

Versions with FIX are the following:

6.42.1 (released)
6.43rc4 (released)
6.40.8 bugfix (release coming today)

Firewall for Winbox port also protects your device, even with older versions.

Maybe someones will not agree with me, but I appreciate the speed of actions. The guide how to minimize the risks within 36 hours (over the weekend) after the first info popped up and the new release with the fix within one working day.
Thank you, normis.

Hi,
should I also upgrade firmware or just RouterOS is enough?

@MT devs: I'd love to see new feature/button in Winbox (in wireless > registration table) which would mass upgrade all clients currently connected to AP to (let's say) latest version from current channel.

Not likely to get added to Winbox, as it's already in Dude.

My Router after upgrade , Restart and Restart and Restart and ... what i must do ? i have CCR1036-12G-4S

Hi,
should I also upgrade firmware or just RouterOS is enough?

Yes, new firmware brings better performance.

Hi,
should I also upgrade firmware or just RouterOS is enough?

As you have not done that for a long time, it is a good idea to upgrade it.
However I question the need for updating firmware each and every RouterOS update (requiring an extra reboot).

@MT devs: I'd love to see new feature/button in Winbox (in wireless > registration table) which would mass upgrade all clients currently connected to AP to (let's say) latest version from current channel.

Not likely to get added to Winbox, as it's already in Dude.

But You have to add all clients on the map as devices?

Well, this is really embarrassing, my enthusiasm with MikroTik is fading due to this few recent vulnerabilities and attacks.

Disappointment, the only word i can think right now.
BruteForce Prevention rules, Port scanning rules... are useless if front door is wide open.

Warning : Don't forget IPv6 if it is enabled on your router .
You must also create rules in
/ipv6 firewall filter

Hi,

another report and still the same attack IP 103.1.221.39. Do the attacker really sends these probes from the same IP? Or it is some bug in Router OS logging improper IP source?

always blame the knife if you cut yourself ...

Just to bust some myths, i re-did the connection to a device that doesn't have no firewall input filter protection for the winbox port, but only the "allowed-address" type filterint in /ip service. some claim, that it is possible to extract information from the device this way. it seems, it isn't.

whenever a TCP SYN is sent to the device from a source address, that is not listed in the "allowed-address" field of ip service, the device responds with a TCP reset (RST, ACK). that is, no tcp connection is established. TCP RST messages do not have payload.
all in all, i suppose the address filtering is taking place "service independent" like a set of auto-generated invisible firewall rules with "reject" action or using TCP-wrappers.

capture screenshot attached.

long story short: ip services address restriction is OK.
additional message: nowadays no network segment can be treated as "secure"

Thanks for checking and reporting to us @doneware. Much appreciated.

Only difference between firewall access restriction and ip service access restriction is that last one accepts connection, if source address does not match allowed list closes it. Firewall drops starting from the first syn packet.

Just to bust some myths, i re-did the connection to a device that doesn't have no firewall input filter protection for the winbox port, but only the "allowed-address" type filterint in /ip service. some claim, that it is possible to extract information from the device this way. it seems, it isn't.

whenever a TCP SYN is sent to the device from a source address, that is not listed in the "allowed-address" field of ip service, the device responds with a TCP reset (RST, ACK). that is, no tcp connection is established. TCP RST messages do not have payload.
all in all, i suppose the address filtering is taking place "service independent" like a set of auto-generated invisible firewall rules with "reject" action or using TCP-wrappers.

capture screenshot attached.

long story short: ip services address restriction is OK.
additional message: nowadays no network segment can be treated as "secure"

But the intruder can also sit inside your network. What if the intruder connects in with the MAC address/Neighbors service? There is no filtering possible on that.

Hi, just to clearly understand, and according to the OP that said 'RouterOS user database security will be hardened, and deciphering will no longer be possible in the same manner.', does the patched release already include that feature ?
TIA

Hi, just to clearly understand, and according to the OP that said 'RouterOS user database security will be hardened, and deciphering will no longer be possible in the same manner.', does the patched release already include that feature ?
TIA

It is a work in progress, it will take a while (weeks, possibly). Many programs need to be changed.

Ok! thanks for your quick answer!

Anyone had problems with his SXT2lite after upgrade to RouterOS/Firmware to 6.42.1?

I'm using a SXT2lite as client for HAM RADIO usage (HAMNET). Firmware/RouterOS before upgrade was 6.41.3.
AccessPoint is a Ubiquity Nanostation M2 with 5 MHz bandwith.
I can see the AP pretty well (in SCAN or SNOOPER mode) and it has a big signal with about -55 dBm.
But the SXT2lite can't connect to it anymore after the upgrade (it was connected before upgrade!).
Connecting a standard 20 MHz AP locally works fine (Signal about -70 dBm).
But the 5 MHz AP can not be connected anymore.

I tried to downgrade RouterOS to 6.41.4, but 5 MHz connection wont work.
Well, the Firmware was still 6.42.1 ... this is not changed by RouterOS Downgrade.
Is there a way to downgrade also Firmware for testing?

Thanks in advance

I'm glad to see this got fixed so soon!
Many thanks to the team who works on this (and lost a lot of sleep probably)!

Attacks seem to be rather specific though, haven't seen the mentioned log entries on my dutch and czech routers.

I'm glad to see this got fixed so soon!
Many thanks to the team who works on this (and lost a lot of sleep probably)!

Attacks seem to be rather specific though, haven't seen the mentioned log entries on my dutch and czech routers.

Do not forget the users that brought this to the attention of Mikrotik. Those users certainty lost sleep and looks probally still a bit pale around the nose.

Other see a daunting task in upgrading farms of routers and I wish them all the strength and luck with this challenge.

But the intruder can also sit inside your network. What if the intruder connects in with the MAC address/Neighbors service? There is no filtering possible on that.

yes. one can disable the mac-winbox functionality. but the attack surface is a lot broader on the internet. i just pointed out that remote exploits can be mitigated using ip service filters

But the intruder can also sit inside your network. What if the intruder connects in with the MAC address/Neighbors service? There is no filtering possible on that.

Nope. If in-port is a part of a bridge - You can filter MAC-Winbox and MAC-Telnet pakets using bridge filter chain input.
Example drop all MAC-Winbox: "/interface bridge filter add action=drop chain=input disabled=yes dst-port=20561 ip-protocol=udp mac-protocol=ip"
Make Your own rule to describe trusted hosts by any criterya e.x. src-ip, src-mac, etc.

I have a home-based installation with my small business running behind. I do have another firewall from another vendor between my wan and my lan. I wasn't hit by this bug despite the fact that winbox port was open. This might be just lucky as I blacklist any IP trying famous "attack ports" and the current attack tried telnet first before running the attack on 8291.

What I can say is:
* This was a serious mistake leading to a serious bug! Shame on you! (Sry to say that)
* MT's reaction is fast and advisory is clear (if you read carefully)

What I would expect now in terms of security feature requests could be amoung of these things:
* including Port-Knocking functionality in Winbox: I do use port knocking, but I think it would be a good idea to include this to winbox to encourage ppl to use port knocking.
* Geo-IP-Functionality included in Winbox: As the attacks came from asia and I would have restricted access to the countries I a usually travel. This would help a lot of people to minimize attacks.

* Communication: As soon as a good percentage of ppl have hardenend their routers we need more information on what was going on and why this hasn't been detected by Mikrotik.
* A monitoring for specific MTik attacks (by using honeypots or by any other means) should be established.

with hundreds of routers that do not enable connection-tracking whats the best RAW firewall rules to protect a router. Has anyone got a template they can share? We cannot enable any rules in the services / ip firewall filter otherwise packet fragments are not passed.

The best INPUT firewall rule is always: allow what you require, drop everything else. Vary for your requirements.
But be careful not to lock yourself out and not block replies to outgoing traffic, especially without connection tracking.

there is no input firewall on RAW. only prerouting and output.

My 2ct on the best way:

Drop all input/output traffic on public interfaces (not only internet, treat your customers network as public too!)
Connect all routers to a management network (physical or VPN)
Use L2TP/IPSEC VPN to connect to the management network
On the VPN router, drop all input/output on the public interface except L2TP/IPSEC
Monitor the log of the VPN router.
On every router, put all IP that try to connect to port 21, 22, 23, 80, 443, 8291 on a blacklist and share the blacklist between routers.

If you're blacklisting based on connection attempts to certain ports, I would advise against it. Doing this opens up a new attack vector where an attacker with IP spoofing capabilities (eg many cheap VPS providers) can spoof popular IPs and cause your network to block legitimate services. Taking any action on unauthenticated packets other than dropping is not a good idea.

Why blocking access to router is bad idea? Should "popular" addresses try to access our router?

When a mikrotik network could be compromised, you need to do some basics steps for EACH router in the network (i.e. all cpe):
- disabile scripts and schedule (could be injected malicious code)
- remove dns static entry (could be poisoned)
- remove odd nat rules (could be used as reflector to internet or to other routers in the network)
- add a new administrator with new password
- remove ALL other users
- secure ip ports allowing only connections from management source address (securing these router first)
Without any other firewall filter rule, this router is now secure and could be upgraded
HIH

Why blocking access to router is bad idea? Should "popular" addresses try to access our router?

You should be dropping such packets anyway. If you add them to a blacklist which blocks all communications from that IP, then you block legitimate services if someone spoofs them.

I know ... but it input chain is not the same as forward one. You can block access to router but not traffic forwarded to/from users.

Port knocking is really poor security IMO. It is basically an additionnal static password .. made only of numbers => very quick to brute force. A proper VPN is superior in every aspect.

another interesting stuff i found while dumping traffic on a router with winbox disabled in ip services but mac-winbox enabled under /tools mac-server mac-winbox on internal interfaces. As it was told, this stuff runs between unicast MAC addresses, but using 0.0.0.0 and 255.255.255.255 IP addresses respectively. so, at the end of the day, this is indeed sort of IP traffic.

just installed a first rule in ip firewall, to see whether it could be jacked there: did not had high hopes, so i fired up winbox, and connected to the router via MAC address. It just succeeded w/o any hesitation. the captured traffic on the host showed the usual pattern (my.ip.add.ress->255.255.255.255 on port 20651 and response as 0.0.0.0 port 20651 -> 255.255.255.255). now i was checking out the firewall rules, and behold:
so the IP firewall "sees" the traffic, the rule is actually evaluated _and_ it matches, but no action is taken. the capture shows no special options, the packet's TTL is set to 64.
now - unless RouterOS manages to validate whether the TTL was decreased in any way - the mechanism can be fooled. i'd strongly recommend Mikrotik to use TTL=1 responses and accept only requests with TTL=1, so packet forging can be eliminated. Luckily the responses are sent to 255.255.255.255, so they would be dropped by any intermediate router.
kind of curious whether i could trick it to accept the packet with the same dst port but with an unicast IP as destination.

I know ... but it input chain is not the same as forward one. You can block access to router but not traffic forwarded to/from users.

Dropping in input is fine, but I've seen several blacklists use raw table which would obviously affect forwarded traffic too.

so the IP firewall "sees" the traffic, the rule is actually evaluated _and_ it matches, but no action is taken.

This is an application that listens on a raw socket. It sees the traffic before the firewall. It does not matter what you do in the firewall (block or allow).
It is similar to the DHCP server. You do not need an allow rule for DHCP packets, you can even have a drop rule, the DHCP server will work anyway.

Also true for the packet sniffer. You probably know that when you run wireshark on a Linux machine you see all traffic on the ethernet interface, also
traffic that is blocked by the firewall. In fact, it is quite difficult to do a trace of "only the traffic passed by the firewall", even when that is sometimes desired.

Of course it is very important that such applications are secure.

i just put a log rules and catchup already a rogue ip...
19:17:16 firewall,info winboxtest input: in:ether1-BGP out:(unknown 0), src-mac de:ad:b3:3f:ba:ad:f0:0d, proto TCP (SYN), 181.214.87.34:41028->xxx.xxx.xxx.xxx:8291, len 40

This is the second advisory for this same port in as many weeks. Whilst we block it to the world we still feel compelled to update all our customers' routers. I hope this is not a sign of things to come.

While I'm on my soapbox I'd like to suggest that graphs are moved off the web management port. They are very different in the scope of their intended audiences, yet the functions are bound together.

Colourful language aside, hashed passwords are the way to go.

Things would be mush simpler to set if we have option to bind services to specific interfaces. That would help to simply narrow access to services by network interfaces without messy IP filtering rules.

It can be done with one simple firewall rule.
Create interface list and add
/ip firewall filter add in-interface-list=xx ...

This is the second advisory for this same port in as many weeks. Whilst we block it to the world we still feel compelled to update all our customers' routers. I hope this is not a sign of things to come.

While I'm on my soapbox I'd like to suggest that graphs are moved off the web management port. They are very different in the scope of their intended audiences, yet the functions are bound together.

You can access graphs within winbox - no need to use web access to them.

How about this for an idea... If the firewall was sound... this would make Winbox accessible to specific IP addresses.

Not at either of those allowed addresses, you have to VPN to one of those allowed IP Addresses. Then you could access the OTHER router's winbox.

Too simple? Or right track?

use layer7-protocol can solve this?
if can,how?

use layer7-protocol can solve this?
if can,how?

why? more simple and quick firewall solves this (see above examples).

use layer7-protocol can solve this?
if can,how?

why? more simple and quick firewall solves this (see above examples).

becouse i am Maintain 500+ mikrotik node,i have not static ip,i need to remote to connect.i can't reboot the mikrotik nodes,i need keep network normal first.and later to update.

Things would be mush simpler to set if we have option to bind services to specific interfaces. That would help to simply narrow access to services by network interfaces without messy IP filtering rules.

That is basically what you have when you set the "allowed from" in the service. At least when you can confine your internal networks using IP subnet declarations.
Also, you can match on in-interface in firewall filters. So you don't need to match on source IP when you don't like to.

becouse i am Maintain 500+ mikrotik node,i have not static ip,i need to remote to connect.i can't reboot the mikrotik nodes,i need keep network normal first.and later to update.

Either configure VPN on the routers so you can connect from anywhere and have more security, or get some VPS at a couple of $/month where you have a static IP, configure VPN to there, and set the fixed IP address of that VPS as your trusted external IP.

becouse i am Maintain 500+ mikrotik node,i have not static ip,i need to remote to connect.i can't reboot the mikrotik nodes,i need keep network normal first.and later to update.

Either configure VPN on the routers so you can connect from anywhere and have more security, or get some VPS at a couple of $/month where you have a static IP, configure VPN to there, and set the fixed IP address of that VPS as your trusted external IP.

i will update all nodes,but need a few days.before update need a temp plan.i want to use layer7-protocol to control.

You can't. This is a legitimate winbox connection. You can only block winbox itself this way. You must block unknown IP addresses, change the port, so that the "attacker" can't easily find your devices, implement other security measures (port knocking would be one, if you can't set up VPN yet)

Very nice tutorial on port knocking: http://blog.cactiusers.org/2009/04/17/m ... -knocking/
to: 9939781 - it is with Layer 7 packet sniffing if you insist on it

i will update all nodes,but need a few days.before update need a temp plan.i want to use layer7-protocol to control.

To implement any change, you will have to go along all the nodes. So better use a permanent solution instead of wasting time now and having to re-do it later.
A VPS is like $4/month install CHR on it or some other OS that can do VPN and you have your own private jumphost that you can allow as allowed from address in the services.
You can use it to run Dude as well so you can monitor your network!

You can access graphs within winbox - no need to use web access to them.

Yes but the graphs in Winbox are rubbish compared to the web ones with their time and throughput scales.

From our network each and every router/switch has a unique randomly generated password. Each router/switch connects via an openvpn tunnel to our radius server for login details, i.e each engineer gets their own user/password to login for accountability.

Also on our edge we block port 8291, 22, 23 etc from outside our ASN, if you are outside our network you need to connect via a VPN.

Every network should have as much and as practical security/firewall procedures in place. No matter who the vendor is, there will always be future exploits.

There has to be a trade-off between a secure access and the risk of unreachable devices when something breaks.
With such config the device will be inaccessible when the connection to radius cannot be set up.
We use radius for customers, but to use it for management of the device would be too much of a risk for me.
Similar for using address lists. We have address lists with allowed management address (source) but they are static and a drag to maintain.
I would use DNS based address list, if they would not be flushed on reboot. Now, when a device is rebooted and is without DNS, it would be unable to load its address list from DNS and management would not be possible. A bit too risky.

my take on remote accessible device management - and some may be behind a "one-way" access medium, like NAT or 3G/4G, where you can't just connect to the device from the outside - is to have a VPS running routeros. and there's no ports exposed there, but only IPSec.
so the managed devices shall connect to it via IPSec. no need for pushed down routes, what so ever.
then the manager user shall do the same.

and they can rendezvous in "cloud #9".
this way you don't have to expose no mgmt interfaces to anywhere.
you don't even need static IP for this, as tunnels can be initiated to FQDNs.

you can drop any management traffic on all routers on their exposed interfaces. yes, that would include also the subscriber/customer side as well.
whenever you access supports it, you can also use IPv6 as the transport of the tunnels to pull this off on some places.

There has to be a trade-off between a secure access and the risk of unreachable devices when something breaks.
With such config the device will be inaccessible when the connection to radius cannot be set up.
We use radius for customers, but to use it for management of the device would be too much of a risk for me.
Similar for using address lists. We have address lists with allowed management address (source) but they are static and a drag to maintain.
I would use DNS based address list, if they would not be flushed on reboot. Now, when a device is rebooted and is without DNS, it would be unable to load its address list from DNS and management would not be possible. A bit too risky.

Hence why each router also has a unique admin password, so if the tunnel/radius had to break we can still get into the router/switch. All passwords are stored on a cloud service.

my take on remote accessible device management - and some may be behind a "one-way" access medium, like NAT or 3G/4G, where you can't just connect to the device from the outside - is to have a VPS running routeros. and there's no ports exposed there, but only IPSec.
so the managed devices shall connect to it via IPSec. no need for pushed down routes, what so ever.
then the manager user shall do the same.

and they can rendezvous in "cloud #9".
this way you don't have to expose no mgmt interfaces to anywhere.
you don't even need static IP for this, as tunnels can be initiated to FQDNs.

you can drop any management traffic on all routers on their exposed interfaces. yes, that would include also the subscriber/customer side as well.
whenever you access supports it, you can also use IPv6 as the transport of the tunnels to pull this off on some places.

indeed. I do the same with OpenVPN as most of my client routers are either behind NAT or have dynamic IP's.
I give each router a loopback (bridge) interface with a /32 IP and either use OSPF or BGP and redistribute the loopback IP's for management.
My management workstation connects to the same VPN and from there I can access all my managed routers.
In case the VPN fails for static IP customers or devices that can be directly reached from the internet (not behind NAT), I use an address-list with my management IP's and only allow access in the INPUT table of the tik from that management address-list.
by default my INPUT table is just DROP (except from my management address-list) and LOG (logging to a central syslog server which is then fed into Graylog2)