Seems to be some weeks old, but haven’t found a topic about this CVE number.
Description:
MikroTik RouterOS through version 7.14.2 and SwOS through version 2.18 initialize the WebFig management interface with HTTP enabled by default and without automatic redirection to HTTPS. After a factory reset, the management UI including the login page and associated JavaScript loads entirely over cleartext HTTP. During authentication, the client-side script stores the username and password in window.sessionStorage and transmits credentials over port 80, allowing interception by any on-path attacker. Packet capture confirms that management traffic and credentials are fully visible and modifiable in transit.
This insecure default configuration exposes administrators to credential theft and session tampering via simple man-in-the-middle attacks on the local network. The issue affects devices such as CRS326-24G-2S+ and likely other models using the same WebFig component in RouterOS and SwOS.
Attack prerequisites:
An attacker must have network-level access capable of intercepting or modifying HTTP traffic between the administrator’s browser and the device.
Mitigation:
Place management interfaces on isolated, trusted networks. Enable HTTPS for WebFig where possible, or use encrypted management channels such as SSH or VPN tunnels. Administrators should treat all HTTP-only management interfaces as unencrypted and sensitive until HTTPS is enforced by default.
=> So as a quick fix, just add a FW rule dropping the Webfig traffic and switch to SSH until further notice as maybe more version are affected as well.
What’s with the publishing one CVE for effectively two separate device operating systems? They are both separate considerations.
SwOS is most straightforward. It doesn’t do HTTPS and ideally needs to be able to otherwise it’s susceptible to an internal intercept. Whether that’s possible given the small footprint of SwOS I don’t know.
RouterOS is a different matter. A device arrives with a default config and from that perspective it could be argued that HTTPS should be enabled with a default certificate with port 80 to 443 redirect enabled. Given it’s not your average consumer device though this should be taken care of by a consultant before commissioning. So effectively it’s a box checking exercise and probably not going to change the world for the better.
Not defending MikroTik but feels like a spurious claim to a CVE to me. Will gladly stand corrected if there’s a good counter point though
Edit: missed the point where the password was captured in plain-text. So the other thing here is that the password need sending securely as well.
Description:
Any device in the World that use HTTP can be victim of man-in-the-middle attack
Attack prerequisites:
An attacker must have network-level access capable of intercepting or modifying HTTP traffic between the administrator’s browser and the device.
Truly silly and ridiculous.
Even stones know that HTTP is insecure... Or rather, they should know...
Another one that default firewall and default settings avoid from WAN.
Credits:
Discovered by Oliver Bölin.
A true genius...
I'll try it too, with all the <CENSORED>, <CENSORED>, <CENSORED>, and <CENSORED> peripherals, and others.
I can "discover" the same bug everywhere and claim credit for it...
During authentication, the client-side script stores the username and password in window.sessionStorage and transmits credentials over port 80, allowing interception by any on-path attacker.
That’s of course the classic cleartext and man-in-the-middle issue with HTTP. There’s no need to panic — client-side “encryption” approaches have been around for a long time, and none of them turned out to be secure in the end. Anyone serious would simply use HTTPS, and that’s perfectly fine.
I no longer have a 7.14.x setup to verify this, but if the password was indeed stored in sessionStorage in cleartext, that would be a serious lapse in judgment on the developer’s part.
Indeed, the default no-password admin issue could reasonably qualify for a CVE, in my opinion.
I’ve never installed a CHR myself, but I’d assume that every virtualization environment provides a console. RouterOS could easily generate a secure random password on each boot and print it to the VM console (until you set one) — that alone would completely prevent these avoidable compromises of freshly deployed CHRs.
Alternatively, RouterOS could simply allow setting an environment variable for the admin password during initialization.
What I find most concerning is that MikroTik must be aware of these cases but has chosen not to take any effective action so far.
I understand... But 99.9% of the time I use NetInstall, it's always direct, never done remotely...
So what's in between? If it's a virus on your computer, it doesn't matter how NetInstall works...
This right here is why many (including me) believe that the CVE system is fundamentally broken. (1)
A freshly installed/reset router has no way of obtaining proper credentials that are needed to use https normally. Alternatives would be:
Disable the http interface entirely, as according to the interpretation of the references given in the CVE, it should only ever be used to redirect to https in these scenarios. Okay, but users expect to be able to set up their routers over a a web browser. Disabling this is not very welcoming for new users.
Supply a self-signed certificate. In this case the certificate would have to be somehow securely delivered to the user, but more importantly: the user would have to configure their system to trust it. Not very welcoming to new users.
Some other, more secure means of initial configuration should be provided, such as a mobile app… but hey, wait a minute, there is a more secure mobile app (actually two) both for Androids and iPhones, and wait… there’s a tool called winbox for PCs, but wait… Mikrotik actually supports the industry standard SSH protocol fresh out of the box.
(1) By broken, I mean blindly using it to assess the security of a product as used in any given scenario blindly, as it is (sadly) used by many compliance teams. Many people use the CVE system to pad their resumes or otherwise elevate their importance. Much more concerning is that I’ve seen instances where competitors use it to smear one another through paid intermediaries. Of course, it’s not broken in the sense that it’s an infinitely good idea to have an easily referenced database of possible problems.
The problem Is that somehowsomeone should examine the proposed vulnerability under the light of common sense [1] (besides verifying that It is actually doable) and assign three different severity grades:
stupidity or incompetence of the programmer of the vulnerabile code
dangerousness in theory
dangerousness in practice
And - when applicable - should inscribe the researcher as contestant in either "Captain Obvious Award" or the "@sshole of the year" contests.
This specific hypothetical CVE seems like:
99%
10%
0.01%
to re-cap, essentially a nothingburger when It comes to dangerousness in the real world, while a disaster for the reputation of the (unknown) programmer of netinstall.[2]
The researcher would be well postioned in the final for the 2025 Captain Obvious Award.
[1] not so common, unfortunately
[2] I guess even a kid in secondary school knows that you don't send plain text over unencrypted connection, no exceptions.
P.S. I wrote hypothetical and netinstall but you can replace them with actual and webfig, the substance won't change much.
Well,
you made me think of something trivial, but obvious if you think about it.
Until there's a surefire way to install an https certificate, the man-in-the-middle attack remains even in https
because it's not clear whether the self-signed certificate belongs to the man-in-the-middle or the end device...
