RouterOS (stable) 7.23.last admin password suddenly doesn't work

RouterOS General
1

I have an RB951Ui-2HnD, running ROS 7.23.recent (not sure if it was .3 or .4). All working fine.

I had configured and tested this device for installation at a remote site.

At a third, intermediate site, I decided to connect it and set it up on the local LAN for some further playing around. Plugged it in, connected via WinBox, no problem. Configured it for the local LAN on which I was going to mess with it for a while.

Some minutes later, suddenly the admin password - which had been working at the previous site and for a while at this interim site - is no longer accepted. "username or password wrong".

This persists no matter whether I directly connect my PC to an Ethernet port on the MikroTik, or I connect to the WiFi network that the MikroTik offers (and, that does still work).

Since I use a password manager, and WinBox has the password stored, it shouldn't be that I'm "Typing" the password wrong.

The only port open to the Internet is 80, for ACME challenge-response, and the webserver is set to only allow ACME on port 80. So unless 7.23. .3 or .4 has a hackable bug in the ACME part of the webserver, it shouldn't be that any kind of hack happened.

The upstream device (an ISP router, a FRITZ!Box) shows a live connection on the Ethernet port to which this MikroTik is plugged, and believes that the MikroTik is live.

Any idea why/how the MikroTik could suddenly decide that its password had changed, or just plain lose the admin password? (There is also a small possibility that the MikroTik automatically updated to 7.24, as I have automatic updates enabled, the MikroTik might have a path to the Internet - I'm actually not sure whether that had been configured at the point where I lost access, or whether that was the next thing that I was about to do).

Failing all, I could reset the thing and restore a backup that I had made just before shutting the device down at my main site before packing this MikroTik up for deployment; it wouldn't be a great loss. But before I do that I'd prefer to try to understand how this happened.

thank you.

2

Any chance api service was not disabled and was accessible from wan?

You can lose admin access within 15 seconds like that. I mean get hacked.

3

I don't use the API service, and I disable it on my MikroTiks.

Aside, how would the service being available make a hack so likely? My passwords are .. strong, and unique.

4

Hm, further, there's a bit more nuance about how this MikroTik is exposed to the Internet.

The ISP router does not treat this host as a DMZ host. The ISP router only forwards in two ports to this MikroTik - 80 (for ACME responses) and one other port which would be for a fallback SSTP VPN, but that service is not presently active on the MikroTik.

On the MikroTik, the firewall rule for port 80 is to automatically open port 80 briefly only when the MikroTik ACME client reaches out to an ACME server. So it's unlikely that the MikroTik was accepting input packets on port 80 at all, and, if it was, it was for 5 minutes (the mangle rule timeout).

So, I think we shouldn't be looking for hack, but rather, is there a user error that I could have unknowingly committed that caused RouterOS to be unwilling to accept WinBox connections, or that could have changed/lost/corrupted the admin password, or is there possibly a bug here?

5

OMFG. ¡¡Mikrotik!! "username or password incorrect" is NOT the correct error message to give when the reason for the failure is "Not coming from an allowed IP range for the specified user"!

Yeah, I get it, don't give more information than necessary in an error message, which would aid an attacker ... but this wasted a bunch of my time unnecessarily!

I had forgotten about the user -> allowed addresses setting, and on this temporary network (which has a different IP range than the network for which I had pre-configured the device), once I had connected via MAC telnet and given the router its local address, and then tried to connect via IP I began getting this misleading error message. (Why when I returned to trying to access via MAC telnet it seemd that that also wouldn't work, I can't be sure, because also there is no "show password" option in the password field of the WinBox connect dialog.

(Moreover, I'm sure that I had tried connecting via a WiFi connection to the router's own WiFi network, which issues IP addresses via DHCP in a network that is (was) already configured in the user's allowed addresses, and that gave the same username or password incorrect error, despite the password being correct).

? On a multi-homed host running WinBox, does WinBox do something funky in deciding from what IP address to send the WinBox connection requests to a router?

So, no hacks, unprovable but does seem like a bug somewhere (other than/ in addition to my brain!), and definitely an inappropriate error message decision in RouterOS.

6

They could replace it with a :wink::

An error has occurred

that seems like being very popular among programmers.

7

"Permission denied" would be appropriately different from the incorrect/misleading "username or password is incorrect". But even "An error has occurred", as long as it is different from "username or password is incorrect" (which is incorrect) would be better!

8

try rebooting the router. I've seen a handful of instances (out of tens of thousands of devices) where a router that's been up for a long time stops writing config changes to disk, almost like it's running in safe mode, this even includes password changes, the change appears to be made but is lost after the session ends. Only a reboot restores normal operation. Again this is a rare event I'm describing, I've seen it happen maybe 4-5 times ever, but I have seen it on multiple devices running multiple versions, and only ever when it's been up for a long time. Power fluctuations or brownouts do seem to be correlated with the issue, but that's unconfirmed. We usually only notice it after one of our automated processes changes the device password and shortly after the automation gets locked out and someone has to manually go access the equipment using the previous password (pulled from our password history)

9

Thanks, in this particular case, it was the admin user's Allowed-Addresses setting, and the misleading "username or password incorrect" error message.

10

That does seem to be hiding more infomation than necessary.

OpenVMS has three messages it will display to users, and 4 types are logged to security audit journal.

"User authorization failure" - this displayed when user has incorrect username or password, but it also displayed when too many login failures have happened in a short period of time, and breakin evasion is in effect. The security audit file has more information than is displayed to user.

"Not authorized to log in from this source" - This is more like what ROS should display when the login attempt is coming from a disallowed source, but the login prompt is allowed by the firewall.

"Not authorized to log in at this time" - when time restrictions don't allow access.

11

Well, despite being decades older, OpenVMS is far more sophisticated in policy than RouterOS.

12

Indeed, and here I'm not really asking RouterOS to become more sophisticated, only to 1. not give misleading error messages, especially 2. (if this is indeed the case) out of some misguided "security through obscurity > administrative usability" theory.