Darman, how do you think an update will know what socks entries are legitimate and what are not?

If CPU is at 100% for the last 5 seconds - remove all IP Socks Access entries xD

Better idea: if the router is setup incorrectly/insecurely, brick it.

But really, none of that is MikroTik's problem to solve.
It is the technician's responsibility to:

• Make sure they don't make the router insecure when they remove the default configuration.
• Make sure they can access the router remotely, and doing so doesn't make it accessible by others. For example through VPN or with an IP whitelist.
• Make sure they have a plan for how to upgrade routers remotely.

In the worst case scenario you tell the personal onsite to unplug the router until you can reach the location and fix the router directly. And then you promise your boss/customer/whatever that you fixed it and this won't happen again because you are implementing a plan on how to deal with it better from now on.

I was lucky that my predecessor had a system in place to easily roll out changes to all customer routers at once. So upgrading all customer routers was done within 24 hours of me learning about this vulnerability. We now have an IP whitelist on the winbox service to prevent anything bad in the furture.

Hi anyone had read this ?

https://medium.com/tenable-techblog/mik ... d46398bf24

https://medium.com/tenable-techblog/mak ... 0705459bc6

Hi anyone had read this ?

https://medium.com/tenable-techblog/mik ... d46398bf24

https://medium.com/tenable-techblog/mak ... 0705459bc6

You missed this: viewtopic.php?f=2&t=145600

Yes, I missed this thread - thanks for this link !

I was lucky that my predecessor had a system in place to easily roll out changes to all customer routers at once. So upgrading all customer routers was done within 24 hours of me learning about this vulnerability. We now have an IP whitelist on the winbox service to prevent anything bad in the furture.

Would you be able to share that system?

Essentially the most general most important dilemma about most commonly (well, over the ultra-modern two years or anything to that effect) vulnerabilities in ROS is that main default settings did not sincerely shut all WAN access to RB. After today pakistani talk shows which a tremendous phase of consumers (beside unobtrusive number of professionals and for no quandary all execs) do not refresh ROS on the whole. Besides, whatever the method that they do, they expect that is sufficient, yet now we have an understanding of that ancient FW units don't seem to be amazing attractive.

I was lucky that my predecessor had a system in place to easily roll out changes to all customer routers at once. So upgrading all customer routers was done within 24 hours of me learning about this vulnerability. We now have an IP whitelist on the winbox service to prevent anything bad in the furture.

Would you be able to share that system? :)

Basically my routers have a script version number, they then have a schedulered script that make them contact a web-server at regular interval to check if a file with the next script version number exist. If a file with the next script version number exist, it downloads it and executes it.

All I had to do when the crap hit the fan, was make a new script file with all the necessary changes and an added scheduler to download the newest RouterOS long-term version at midnight. I then uploaded that script file to the web-server with the next version number.

Kinda funny because this is the same system I saw the hackers were using in the few examples of their scripts I saw.

Essentially the most general most important dilemma about most commonly (well, over the ultra-modern two years or anything to that effect) vulnerabilities in ROS is that main default settings did not sincerely shut all WAN access to RB.

That is not correct! On every router except the CCR the default has been (at least for a very long time) to block all input from internet by default.
Unfortunately it was done in such a way that it stopped working when another interface, like a PPPoE client, was added for internet access.
However that has been fixed a few versions ago.

The real problem is users that follow YouTube advise instead of MikroTik documentation. On YouTube there are a couple of users who distribute videos with completely incorrect procedures.
(probably not malice but just lack of knowledge on their part)

It has come to our attention that a rogue botnet is currently using the same vulnerability in the RouterOS Winbox service, that was patched in RouterOS v6.42.1 in April 23, 2018.

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

Steps to be taken:

- Upgrade RouterOS to the latest release
- Change your password after upgrading
- Restore your configuration and inspect it for unknown settings. Delete SOCKS configurations, and any unknown scripts
- Implement a good firewall according to the article here: https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

[UPDATED with specific versions]: Full details on what to do and what is affected: https://blog.mikrotik.com/security/winb ... ility.html

Since the attacker is inserting his script into the targeted routers and changing configuration in them, we recommend to carefully inspect the configuration of your device, restore it from verified backups or export files, and follow generic advice in the above links.

Is enough only by upgrading the OS to safe version or MUST BE do netinstall?

thx

It is always safer to netinstall as it formats device.

Is enough only by upgrading the OS to safe version or MUST BE do netinstall?

As stated multiple times in this thread, and other places on the forum. If you want to be 100% sure that your router is not infested with some Lovecraftian horror, netinstall it.
If your router hasn't been attacked, probed, or accessed in anyway, you might be ok with just upgrading to latest long-term version and changing your passwords. The problem is that you'll have no idea if you were exploited, so always better to be safe than sorry.

That said, implementing a more secure firewall with VPN, IP whitelist and/or port-knocking for secure remote management access is always a good idea.

Automatic upgrade should be the default and is quickly becoming best practice.

Automatic upgrade with reboot will never become best practice in non-HA clusters.

Well, why not, as long as I can turn it off and I'm not left out with setting "active hours". But I don't think MikroTik will go for it, it's just too risky.

Well, why not, as long as I can turn it off and I'm not left out with setting "active hours".

That's not what I call "best practice"

Automatic upgrade should be the default and is quickly becoming best practice.

Automatic upgrade with reboot will never become best practice in non-HA clusters.

You are not going to tell us that those 200.000 - 400.000 compromised MikroTik routers form a HA cluster, do you?

I think the point was that unlike with HA solutions, where you can take out some part and everything else will still work, unexpected reboots of lone routers would be annoying to users. Plus MikroTik would need extremely good quality control, because small mistake could result in thousands of inoperable routers, which would not amuse users either.

Shocking, in the middle of the busy trading day, the DOW shut down unexpectedly, as the routers running the show rebooted like spontaneous combustion.
The IT admins were quite confused until they realized that automatic firmware upgrades had been applied simultaneously to both main and HA routers.
Oops.
The 4 billion dollar loss is apparently being paid by Hannah25, through a debt payment scheme that will last approx 100 generations of the family.
Just hired by the DOW to take over their IT operations is Chewbaka (phonetic spelling ;-P) who predicted the event would occur over 3 months earlier.

And Hannah25 is not even a real person, just a spam bot copying this post ( viewtopic.php?t=137572&start=200#p686945 ) and coming back later to edit in some spam links.

I think the point was that unlike with HA solutions, where you can take out some part and everything else will still work, unexpected reboots of lone routers would be annoying to users. Plus MikroTik would need extremely good quality control, because small mistake could result in thousands of inoperable routers, which would not amuse users either.

I have explained several times that they should create a separate release channel and configure by default in every shipped router that whenever a release appears on that channel that is newer than the release installed on the router, it would automatically be installed (this channel would be polled e.g. once a day or once a week, during night local time).

MikroTik should only put well tested releases on that channel and only when an issue has been found that makes it important to update.
So it should not be just another "stable" or "long-term" channel that receives updates at will. It should only be updated when security vulnerabilities have been found and fixed, and for reasons like described above it should not be released immediately but only after that same version has been out on the stable and/or long-term channel for long enough to know that there will be no such problems.

This mechanism is only there to make sure that those users (probably the majority of home users) that never check for new versions still receive those important updates.
And for those that think that they know better, the mechanism can be turned off.

Sometimes I think that this already has been silently implemented. I observe that some of my routers "regularly" connect to upgrade.mikrotik.com and retrieve the file that contains the latest version. Then they do nothing. But maybe a special message can be put in that file that instructs the router to upgrade.

It should only be updated when security vulnerabilities have been found and fixed, ...

What if they don't find any for a while? Imagine that there's no vulnerability for few years and then something happens. They would have to make an update that would apply to several RouterOS versions released over all those years. They would have to minimize the number of preinstalled versions somehow (to make testing easier), but with new hardware coming out all the time, I don't know how.

I have explained several times that they should create a separate release channel and configure by default in every shipped router that whenever a release appears on that channel that is newer than the release installed on the router, it would automatically be installed (this channel would be polled e.g. once a day or once a week, during night local time).

Better idea, prevent changing/removal of the default firewall. That is what all other "home router" brands seem to do. Simply prevent idiots from doing stupid things.

But we will still have smart idiots that will screw that up, and they will go onto making YouTube guides that are wrong, making poor unknowing people vulnerable.

There is no good solution, and even less a solution that is backward solving. There is no way to remotely fix all the routers that are already vulnerable (without breaking a few laws), so there is no point is using it as a point.

If a new release branch were to be made it would have to be totally separate from RouterOS, since I doubt they would want to release security fixes for each and every RouterOS version in existence.

And no we can't just say "use long-term branch", because even that breaks multiple features and brings bugs with every major release. Best example currently is how long-term v6.42 changes Netwatch execution permissions, but the fix for it isn't until v6.43 and still requires manual fixing.

It should only be updated when security vulnerabilities have been found and fixed, ...

What if they don't find any for a while? Imagine that there's no vulnerability for few years and then something happens. They would have to make an update that would apply to several RouterOS versions released over all those years.

I have not clearly stated (and I am not really sure) if they should make a minor release to fix security issues for every major release out in the field.
While that would reduce the risk of update problems it would increase the amount of maintenance work.
Of course when routers with very old RouterOS are now update to "stable" or even "bug-fix" versions they could encounter issues with migration of
old configuration like "switch masterport -> bridge with hardware accel" or "new IPsec configuration".
So it could be considered to have a security update version separately for versions before those major releases.

Leaving this unsolved for so long of course has contributed to the problem. Not solving it now will only make it more difficult.

Better idea, prevent changing/removal of the default firewall. That is what all other "home router" brands seem to do. Simply prevent idiots from doing stupid things.

There could be a default firewall where user can add things, and an "expert" mode where they can redesign the whole firewall when desired.

But that does not help against stupid YouTube videos that instruct beginners to to the wrong thing.

Hello, we have found that our CCR is not accessible, has been compromised, user and passw have changed V 6.38.7 (bubfix) is the version that appears from winbox, we have passed ExploitWinbox and Macserverexploit but it does not work, what else can we do? We do not have backup ..... Thanks!

Hello, we have found that our CCR is not accessible, has been compromised, user and passw have changed V 6.38.7 (bubfix) is the version that appears from winbox, we have passed ExploitWinbox and Macserverexploit but it does not work, what else can we do? We do not have backup ..... Thanks!

Bugfix version 6.38.7 should be vulnerable to the exploit, assuming firewall or service doesn't block IP access and MAC-WinBox-Server is running for MAC access.
If you can't get into it at all, you might have to cut your loses and netinstall it right away. Because you'll want to netinstall it either way, it is only a question of rather or not you can save some of your configuration.

Is there no way to extract the router configuration? or any other exploit I can try ?.
Thank you

AFAIK there is no way to extract your config wo an admin password, others (more familiar with netinstall) might chime in otherwise (netinstall has that save config button/checkbox, but i think it requires your password first). You have to consider, MT does not want to make it so that someone with even physical access to your MT can pull your config somehow (else anyone locally could grab your valuable config + vpn creds/certs or other creds, possibly wo the remote admin even knowing as they may only see the MT reboot- so this is a good thing!)

I can say that we had a customers MT that was exploited several months ago (a MT we did not control, but rather local IT did) so they physically brought the MT to us to see what was wrong with their router (lol). Out of curiosity i tried the various exploits myself, to then grab the hackers new password they had set.

to do this, We used a recent release of Kali OS and was able to pull the password via the Mac/layer2 exploit (i think it was a python script).
(you may want to try that again with KALI os, as the scripts may fail silently if they are missing some pkg or other dependency on your host os, possibly)

if it helps, here was the user/password they had used/created on this MT:

service
service42

user1
motoroll3r

fad
fad

(those worked for us to get into winbox, or maybe try those passwords above, with use admin). good luck recovering your config. even though you prob. should recreate the config from scratch anyway.

edit: also if you are trying the tcp/winbox exploit, you may want to first portscan the device, as i think in some cases they changed the winbox port (and/or restricted it to their own ip range)

Thank you very much for your explanation, I'm going to try what he says, I've tried the port with nmap and still use the original winbox.
On MAC (layer2) I have already tried the python script and it does not work either, they may have updated some package) and.Thank you

It is possible to show the column Version in the Tabsheet Managed?

It is possible to show the column Version in the Tabsheet Managed?

No, because this is just a list of bookmarked connection parameters and the winbox does not have an actual connection to these devices until you select and open it.
Depending on the topology of your network you can sometimes get such information by connecting to some central router and then select IP->Neighbors.
This shows the names and versions of all surrounding routers that have "discovery" enabled on the link. This is actual information.