CVE-2024-54772 Information About

Hello,

https://www.cve.org/CVERecord?id=CVE-2024-54772

Do you have any information about CVE-2024-54772? Which versions are valid?

Is this vulnerability present in versions 7.17.2 and 6.49.18?

Thanks,

According to the repository, it’s still exploitable in 7.17.2 https://github.com/deauther890/CVE-2024-54772.

It is worth mention that this is related only to info enumeration, when assigned, this CVE will have a low risk score

Maybe I am a bit tough :open_mouth: , but I fail to perceive the severity of the vulnerability in practice.

IF you have Winbox access, then:
If you try to log in with a wrong username, you get a reply 35 bytes long.
If you try to log in with a right username, you get a 51 bytes long one.

So this allows to brute-force the user name(s), given enough time and number of attempts.
It is (in my perverted mind) VERY different from what is reported on main page on github;

This repo contains the exploit for CVE-2024-54772 which > can enumerate > valid usernames in Mikrotik routers running RouterOS v6.43 through v7.17.2.

From that it seemed to me like an attacker could download the list of users with a single, swift command.

This doesn’t mean that it is to be ignored, but I think we can sleep without worries tonight.

Yeah, brute force dictionary attack is the correct term here. ‘Username Enume’ is totally off in this context—probably named that way just to create some hype.

Issue Summary:
A vulnerability has been identified in the WinBox service, where a discrepancy in response size between connection attempts with valid and invalid usernames allows attackers to confirm if user accounts exists via brute forcing the login process. In other words, when attacker tries to log into the device, by examining the response, the attacker can deduce if such a user exists on the device.
Even if username is found, password still needs to be guessed as well.

Affected Versions:
RouterOS versions prior to 6.49.18 and 7.18.

Recommended Actions:
Update RouterOS – Upgrade to 6.49.18, 7.18beta2, or a newer version to patch the vulnerability, 7.18 will be released soon.
Monitor for unusual login attempts – Review router logs for suspicious authentication activity and take action accordingly.

Mitigation strategies for devices that cannot be updated immediately:
Restrict WinBox Access. Firewall the WinBox port on public interfaces and untrusted networks.
Limit connections to trusted IP addresses using the “IP → Services” menu to specify allowed sources (e.g., your LAN and trusted public IPs).

Use additional protection methods if access from untrusted networks is necessary:
Port Knocking: https://help.mikrotik.com/docs/spaces/ROS/pages/154042369/Port+knocking
Brute-Force Prevention: https://help.mikrotik.com/docs/spaces/ROS/pages/268337176/Bruteforce+prevention
Secure MAC-WinBox Connections:
Restrict MAC-WinBox connections to trusted interfaces using:
“/tool mac-server mac-winbox set allowed-interface-list=”

If your device is running the default configuration with firewall enabled, WinBox service is already limited to LAN access. In this case, the only potential attack vector would be internal network threats.
For more details, please see:
https://help.mikrotik.com/docs/spaces/ROS/pages/167706788/Default+configurations

https://mikrotik.com/supportsec/cve-2024-54772
Can be a way to trick brute force attack to leave admin user without rights. If is cleverly crafted attack it may not be enough, when admin user is compromised, after performing API request with its credentials which only admin user can perform and API fails, it mark admin user as invalid and can continue with brute force users detection.

How many years can brute force continue undetected with a random 254 characters password???

Very devious! and even if they did, as you stated no rights associated with admin username LOL

As for passwords, most nefarious regimes are storing tons of encrypted data whilst awaiting for quantum computing and AI to mature to the point where all past information is easily accessed.
Hence, keep your crypto on your own stick !! 13th RULE :wink:

… but when that will happen, around year 2047, the unit will probably have been replaced, by a new one running RoS 42.2 that will use telepathy instead of user/password credentials …

Strangely enough, brute-forcing times depend on the rate on which you can try a value (and wait for the response of the device), so, even if you expose access to the router from WAN :open_mouth: , and the rate to which the attacker can probe (without choking the connection or the device itself) is very limited, in the order of magnitude of tens per second, possibly hundreds per second. I have seen logs with 8 attemps per second, example: http://forum.mikrotik.com/t/many-attempt-to-log-in-from-winbox/139277/1

But let’s exaggerate and assume 100,000 per second.

The super secret admin name I use on all my devices “pippopippo” [1], probed at 100,000 attempts per second takes max 44 years time, on average 22 according to this calculator:
https://www.proxynova.com/tools/brute-force-calculator
(“pippopippo2” will take 1163 years)



[1] no, wait, … :blush:

I managed to in one try. :slight_smile:
Its changed to pippil0ngst0cking

Depends how lucky attacker is, just mentioned as possible edge case, from 7.18 without possibility of user enumeration it is even lesser probability for brute force.

A lucky attacker should play the lottery, much more to gain in case of success…

Surely 1/(∞-1) is bigger than 1/∞, but not much, and here we are more around the probability of two to the power of 276,709 to one against.

I haven’t tested it for a long time (maybe it has changed recently), but I’ve seen one fairly serious design bug with safe mode - previous config was not restored on power failure.

There is an extremely simple and easy-to-implement solution to mitigating brute-force attacks: just gradually increasing the response delay after each failed login attempt, up to a set limit, to prevent account lockout.

@optio
Maybe we didn't understand each other.

Intentionally leaving the admin account and letting someone brute force a 100-character random full ascii-7bit (from space to ~) characters password.
How many resources does an attacker need before giving up?
How can something that takes a billion years to test go unnoticed?
Even if in the future the speed went from a billion years to 100 years, it would still be much longer than the life of the product.

And then what do you do after find that admin is useless? Try root? And what if that is also a fake account?...

But with this analogy what is difference to brute force fake admin user or changed admin user with strong password which takes “a billion years to 100 years”? After billion years or 100 years when changed user is compromised you will realize that it was better to have fake admin user? :slight_smile:

two topics related to the same CVE were merged

Ok, to follow up my post, @rextended was probably thinking in direction for having fake admin user with very strong password and other user with less strong password, but still, brute force attack can be performed in parallel tasks which one task tries to brute force admin user and other which tries to brute force usernames to find other user and perform brute force password attack on it when found which can be less secure if other user has less stronger password.

If you could try more users in parallel and increase the speed of the brute force it would be absurd, so the more users you try, the longer it takes.

Finding a non-stupid user like admin, root, superuser, etc. with a dictionary attack is “easy”.
Finding a user like @Rex#Tended23 takes 640 years… Or let’s say it’s just two years…

But the question is always the same: How many years must pass before someone notices the brute force?