MikroTik RouterOS contains a weakness in its API authentication handling that lacks effective safeguards against excessive login attempts. The system does not enforce meaningful rate-limiting, account lockout, or source-based restrictions, allowing repeated authentication failures to proceed without defensive response. In some versions, a fixed per-connection delay is present, but it can be bypassed through concurrent sessions, resulting in continued high-volume attempts. This deficiency increases the risk that an attacker could eventually obtain valid credentials and gain unauthorized access to administrative services.
lol, this is known like for centuries. Nobody cared, noone from Mikrotik took measures. And now someone filed a CVE for this grandpa issue? Good job....
You can implement connection rate limiting in the firewall.
The problem with "researchers" is: you can always think up another "vulnerability" and publish a CVE. Then some people panic and the developers have to start coding again.
And worse: after implementing some measures, the normal every-day use of the device, even in setups where a problem isn't important at all, is impacted.
And all that only for those "researchers" (often at some university) to get research budget...
If you don't use easily guessable passwords (dictionary attack) then with only 8 alpha-num character long passwords, on average 100 trillion attempts are needed. If MikroTik adds only a 10ms delay, and force serialization of the authentication attempts, then no more than 100 attempts can be made per second. That means the brute-forcing would need 35000 years on average . That should be enough.
The real problem is:
How did anyone manage to log in via API or whatever?
It's like asking door manufacturers to make like an unbreakable lock,
and then the door is on a public road, without even a guard.
Your team is ridiculous.
First of all, we need to prevent anyone from even trying, and then we can talk about the rest...
The first defense against any (alleged) bug is always the firewall.
If something is written in the CVE that's false, everything else is automatically false.
Since it's more than obvious that it's possible to determine with absolute precision the IP(s) who accesses the API and everything else,
the entire CVE is a load of bullshit.
Like all things, if it is configured incorrectly, it is not the manufacturer's problem, but the user's.
As powerful as a RouterBOARD is in terms of speed,
it is not its strong point to do parallel or internal calculations,
a high volume of attempts saturates the CPU very easily...
More than a certain number at a time cannot be handled...
The calculation is "wrong"...
Presented this way, it's enough to say "I use multiple machines" or "multiple sessions in parallel"...
But just say "change password every 28 days" and... all change...
You'll never be sure that you haven't already tried the new password,
or that it'll be a password you'll try in the future...
And if you steal a device, even if you find the password sooner or later,
you'll never know the password for the other devices,
even if it was the same at the time of the theft,
because it changes over time...
In fact, passwords should usually change instantly in the event of a theft or a dismissal...
If Mikrotik applies a delay that is shared between sessions, I'll submit a CVE for a DoS vulnerability, where a malicious actor can prevent authorized access and effective use of the API interface by simply performing a sufficint number of incorrect authentication attempts against the endpoint.
An API session‑management flaw in products with the MikroTik RouterOS API enabled are vulnerable to a Insufficient Session Expiration vulnerability. This could allow active sessions to retain their previous permission set after inactivity timeouts or user‑group changes. As a result, an authenticated user whose permissions have been reduced may continue accessing information.
. That should be enough.
