Or maybe everyone noticed it afterwards, because they hadn't noticed before...
Do people really make the web interface public?
I'd imagine the number is larger than most of us would think.
- Many devices do not come with a default firewall, and some users may assume it has one and never check explicitly... that set is >0% I'm sure.
- SSTP is enabled by Quickset's VPN checkmark, so that be one way to TLS connection open.
- And In theory, there actually should not be a problem with HTTPS open. Now whether advisable in practice is a different question.
To be honest I hadn't used it in ages, but hadn't disabled it either.
No. Do this whether you upgrade or not. Does anyone NOT do this by default? I manage edge routers for many clients, and not a single one is vulnerable, because we KNOW that these things may be there. There is no excuse for anyone to be vulnerable to this and they should be embarrassed if they are any level of IT professional and are vulnerable.
A little bit concerned about this.
access your device with a strong VPN like Wireguard.
How about the other VPN options, such as OVPN, IPsec, SSTP, and ZeroTier? Are they less secure?
Seems like about the only takeaway I see for Wireguard is simple setup, followed by decent speed. (Neither of which does it have a complete lock on.)
Myself, I have zero interest and use ipsec and OpenVPN. Ipsec is good in the enterprise space, so it's good enough for me.
In my case, I do use OVPN with the port 443, as some ISPs have port restrictions. So yes, what you’re saying makes sense. I just wanted to hear @normis’ thoughts on that.
The full list of VPN tech in RouterOS is much broader than that. If @normis had simply said "use a VPN" some twit would've taken that as an implicit endorsement of PPTP despite it being known-broken for a quarter century, for no better reason than because it's on that list.
There are also items on that list that explicitly lack their own encryption, like EoIP, because "VPN" is a very broad topic that covers more than encrypted remote access.
One of the biggest advantages of WireGuard is that it's completely silent to port scanning. If the attacker doesn't have the correct keys, they won't see any trace of response at all. This is normally not true for the TCP based VPNs or IKE/IKEv2.
lucky me ...
partition backups are intact
since my backup script run on sunday ... i could restore all important device this time
Dropbear is not mentioned here: https://mikrotik.com/software/legal
I had a clanker take a look at bndl/security/nova/bin/sshd found in routeros-7.24.2-arm64.npk and it claims there are too many differences to support the hypothesis that it's just a copy of Dropbear. If it ever did start that way, it's diverged significantly.
That then leads us back on-topic: if this is indeed an in-house development, it means they won't be subject to all the same problems, but they also aren't getting the benefit of the "many eyes" on the FOSS alternatives.
One additional big advantage in case of MikroTik: they (afaik) use the upstream WireGuard kernel implementation, whereas many of the other VPN options are either wholly or in part (re)implemented themselves.
Which means it's the only remote access option that's reasonably safe to expose to WAN, all others have seen remotely exploitable bugs which have compromised thousands of devices: Winbox, Webfig and now (MikroTik) sshd.
I wouldn't trust MikroTik SSTP/OpenVPN to be safe, it's just that finding bugs in sshd/webfig is a lot more rewarding if you're out to pwn the internet.
The SSH implementation is largely custom but it's not an implementation that is at fault but how it interacts with rest of RouterOS internals. The vulnerability is authentication bypass due to argument injection and IPC confusion. The direct cause is lack of sanitization of usernames being passed directly as arguments to another process.
Presence of ops user is indication of specific campaign but not necessity for exploit to function - any changes to configuration can be made, it's just that in this case attacker left themselves an easier backdoor for post-exploitation work.
Focus being on SSH is mostly due to it being most popular service being exposed, the actual vulnerability exists beyond that scope and affects every management service, though whether it can be exploited in same way is another question that needs investigation. You should however assume that they are all vulnerable.
For regular home device users and default configurations, the issue does not pose an immediate risk, but we still suggest all users to upgrade.
I do not agree with this statement. While "default configuration" part is true, the "regular home user" is a bit of a stretch here because it implicitly assumes that user did not go beyond QuickSet or the mentioned default configuration. Who's to say that "regular home user" did not expose WinBox port? It's really unnecessary to put it there and makes vulnerability seem less critical than it is.
Also I take big issue with the fact that MikroTik did not disclose that the vulnerability is being actively exploited. Note that patched versions explicitly check for existence of ops user with specific policies set, which confirms that MikroTik knew about this being exploited in the wild and tailored flagged checks for it specifically.
There are two most important questions you need to answer when publishing security bulletin - is it being actively exploited? What are immediate steps to take to remediate and what configuration is affected (or all)? In this case, the answers should've been clearly laid out:
- Yes, this is under active exploitation
- Any device with management port exposed to untrusted network is at risk
These two answers do not make it any easier for attacker to find a flaw (they can just diff .npk file and see that all management processes were updated) yet provide clear guidance and call for immediate action or remediation for your users. All this drama could've been easily avoided if you've just explained it clearly. Ironically, you did provide these answers, in unrelated replies on forums, but not in email, security bulletin or new version announcements.
This. When reading a security bulletin or examining the changelog my first question would be: Am I at risk? And having the answer already at hand would clearly take away my next question: Which devices I need to update with highest priority first?
Yes and no 
Do not want the devil's advocate but
It's hard to sum up whole situation in a short sentence. We, including you, are part of the forum where you can find mostly quite involved and skilled MT's nerds (sorry if anyone felt offended) but also total no more than Quickset step beginers.
Most topics on forum need some knowledge that is beyond needs of home users that are not MT's "home users" in a strict sense but users that got preconfigured by ISP devices for home usage but not for advanced networking ISP style center.
Yes, I know that it means that they are not configured at "default" that means "home user" level style but they are not usually exposed to the wild.
We could discuss that situation again and again but at least we were informed & warned & instructed what to do openly, not smuggled behind the courtin of "improved system stability"
"Also I take big issue with the fact that MikroTik did not disclose that the vulnerability is being actively exploited"
I don't know, but the wording of the announcement hardly could be interpreted in different way than "update now, we are serious", which could mean only one thing - it is or it could soon be exploited so don't waste time...
But that is just my oppinion
I'm still fairly new to Mikrotik/RouterOS, so this is probably a beginners question.
I already upgraded my router, but is there any information available for newer users in the Mikrotik world on what to check exactly to protect my router the best way possible from this (and future issues), and where exactly to configure this using Winbox?
I did go beyond QuickSet, but my router config is basically Firewall rules and VLANs, and during setup I tried to harden the router to the best of my knowledge and using some guides. But this incident makes me wonder if this is sufficient.
Questions I have for example:
I checked Log as suggested in the OP. I din't find any way to filter for 'Critical' entries of the Flagged status. I did use the Find field and found no reference to Critical or Flagged. Is this the correct way to check and sufficient?
(I also checked/system/device-mode/printwhich shows Flagged = No)
In/IP/servicesfollowing services are disabled: api, api-ssl, ftp, ssh, telnet, www, www-ssl
WInbox is configured to be only 'Available From' LAN IP ranges. Is this sufficient? Or are there any other places in RouterOS where I should disable or actively block certain services, ports, protocols, ...
I haven't setup any VPN (Wireguard, IPSec) but I also don't know if any services are active by default which I should disable?
So while I understand the decision of Mikrotik to not fully disclose all information ATM, I would be helpful to provide some more guidelines for all different types of users (beginners vs experts).
Default configuration is a really good one. The problem is that some services were vulnerable, so till the next "hole" would be find we should believe that everything is all right.
I disagree with this view. A vendor shouldn’t tailor their security related statements based on one less knowledgeable audience, they should accommodate all of their customers, especially those who can and will try to assess it beyond what normal users would.
What mikrotik should have done was to put a disclaimer - saying it is a critical security update and it patches actively exploited vulnerabilities, this lays out the facts and applies to everyone, those who dig dipper as well as those who don’t. And than provide additional information about what is being affected and the implications, for the more advanced users who are able to asses the situation themselves.
What they did instead was to put a vague statement, being pressed to answer questions from users trying to assess the situation, all while creating unnecessary chaos due to these uncertainties and the obvious attempt to conceal what’s really going on.
And most importantly - stop painting security patches as “improvements” or “stability”. Leaving out information about the patches themselves does not withhold it from being exposed within hours, regardless of their complexity.