https://blog.mikrotik.com/security/cve-2023-30799.html
In short - very low risk issue.
Very informative. Thanks 
Thanks.
Interesting, but pretty much a non-issue since it requires the actor to be logged in with full admin privilege anyway…
Example: I hire a expert to setup my router. That person needs access on admin level and that person could gain “super-admin” level and makes changes that are not logged and normally not allowed.
When the temp. account is deleted the changes stay in place.
My impression from what I read here: https://vulncheck.com/blog/mikrotik-foisted-revisited
I would soooooo love to take a peek under the hood
Might even try to break into my own 750G…
Been there done that.
By the if only most users remember that you can get an email sent to you when the router is accessed with admin credentials.
Though I agree that the way they built the Kernel now the router is more secure
In short, a RouterOS admin with full rights can already do anything in RouterOS and has full control over all configuration, but should not be able to run other code or inject other files in the subsystem of RouterOS.
A trivializing sentence at the end.
Someone may gain access to the device by admin user and could change any of the configuration. Most of the time these intruders would not hit “/system/reset-configuration”. They rather would open some ports or enable some services, so they can enter the network further. But I would still be able to review or observe changes with “/export” or “/export verbose”. Make a diff and see immediately what changed. Could be automated.
But when someone gains access to a real root shell and uploads any possible binary one can think of. Adds the binary to a init-script so it starts on boot. Or manipulate configuration on the underlying OS - these are not in any kind visible in the “/export verbose” output.
None of this would be noticed. Nor could it be noticed. You could just simply netinstall the device, if you see e.g. signs of unusual logins from unusual source/ip or time of day.
In short - very low risk issue.
As someone working for Mikrotik, you should not play this down.
You don’t need any CVE for that. Please re-read the original post.
In theory you could even take the router apart and re-solder some chips on it. What is the point calling such situations “vulnerabilities”? If your device has full admin access to malicious parties, ALL IS LOST already
You could also just give in and grant users the capability to get a Linux shell, of course protected by a flag in device-mode and a warning that routers with this enabled cannot be supported via the usual channels.
That would likely end the constant search of “vulnerabilities” to get that access. And having it visible (in export and device-mode) also increases awareness.
I’m not sure about that. I’ve been following curl maintainer’s sage with MITRE — conclusion was “panic by default”: https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/
One can also enable RADIUS logins with 2FA, if worried about vulnerabilities that start with “admin with valid credentials” cases.
Could you not integrate a feature into RouterOS, to check that the subsystem has not been manipulated?
In the case scenario that a breach has been made but I still have remote access and I change credentials and upgrade. I would have the ability to avoid sending out technicians to replace or netinstall equipment
There is System->Packages->Check installation but it is completely unclear what it does and what it doesn’t do.
We have already done that, it’s called “device mode” https://help.mikrotik.com/docs/display/ROS/Device-mode
It will lock down your device if any suspicious activity is detected