Can someone confirm if MikroTik devices are vulnerable to the current SSH backdoor?
See here https://openssf.org/blog/2024/03/30/xz-backdoor-cve-2024-3094/.
Althought the malware scans for .rpm or .deb packages in general it would be a good to know if MikroTiks SSH server relys on liblzma or not.
No, Mikrotik is not affected by this vulnerability.
MikroTik software does not contain any of the vulnerable versions, but we are still doing a full audit and if anything changes, we will let everyone know.
Edit: this vulnerability has several other dependencies that would make it impossible to affect RouterOS, even if RouterOS did include the vulnerable xz version. So 100% not affected.
Great to hear.
Maybe this topic can be pinned somewhere for the next couple of days/weeks if someone else is raising this question?
Done
It beggars belief that this exploit could even in principle affect RouterOS. It’s a an attack on the liblzma2 underlying the xz utility, and it only affects the patched version of sshd on systemd-based OSes like Debian, where they integrate with its notification system.
If any of that exists in RouterOS, any single other missing piece is enough to break the exploit. No xz, no systemd, no OpenSSH, no exploit.
That last is in significant doubt, if nothing else. RouterOS’s SSH daemon identifies itself as “ROSSH”, with unknown provenance, but if it were based on OpenSSH, then why did it take them so darn long to get Ed25519 support?
I also thought that RouterOS is not affected by this version but it makes sense if any CISO or other IT-related staff got the order to query if any product of MikroTik is vulnerable or not.
That’s why it make sense from my point of view to highlight “we are not vulernable”.
I’m guessing ROSSH it’s based on Dropbear
While RouterOS may not be affected by this specific vulnerability, everyone should remember it’s a dangerous supply chain attack - very well prepared over 2 years (by skilled and well funded professionals, probably secret services of some country, not just some random script kiddies) and only discovered because we were lucky this time and someone paid attention to little details (performance issues which most people might not even notice), the story (still being investigated and more things discovered) looks very interesting. There may be other vulnerabilities of similar kind as yet undiscovered, RouterOS too (just like a lot of other software we came to depend on) includes many software components, some of which could be maintained by overworked people who could fall victim to similar social engineering (accepting help from a rogue co-maintainer) as the original XZ maintainer. Good security practices are more important than ever, it’s a never ending arms race.
Well I hope everyone was inspired and did a double check on all Firewall rules, to make sure nothing can access the router from any untrusted network. If no packet can reach the router, even yet undiscovered vulnerabilities won’t bother you.
One more common observation on that - if your device acts as VPN gateway then it is accessible from outside and that can pose its’ own risks - recent sslvpn vulnerability in Fortigate devices can be a good example on that…
Unless malware connects to CC server which then takes control over the infected hosts in which case firewall is useless since connection is initiated from the LAN which is trusted…
Strictly speaking the attack is against systemd which is dependent on liblzma, regular upstream openssh (unpatched for systemd notify functionality) is not affected…
Our SSH is not based on 3rd party implementation.
This is freaking ! Does that mean SSH server implementation is closed source developped in house ?
That’s scary. Doing security and crypto stuff from scratch is high risk, low reward.
RouterOS is made since 1995, it’s not like we started yesterday. A lot of RouterOS is made in-house.
The copyright notice says 1999 I think… 
RouterOS 2.0 was released then
And more importantly in this particular case RouterOS doesn’t use systemd as far I can tell, but does use xz (where malware is actually distributed) for npk archives so maybe you should check if what you are using is affected version…