I would also tend to agree. If you firewall all services on your WAN unless it comes from trusted IP’s/ranges, then it would be very difficult to hack the tik from the WAN
I always firewall everything incoming to the tik and only allow access from specific ranges/ip’s
In addition to what was written :
set first in firewall filter “Drop port scanners rules” like this https://wiki.mikrotik.com/wiki/Drop_port_scanners but drop the scanners with RAW and finaly change the number of service port too !
the Czech case contained the same IP in the log like the others I have seen yet. The IP is 103.1.221.39 (some network from Taiwan). Either someone tries to test some proof of concept (and runs the attack from only one station) or the IP in the log is faked one and the attack source was different IP. Maybe the attack vector causes the IP source is logged improperly? I have analysed data for last days and I can say that there was no communication with the IP 103.1.221.0/24 and our network (big amount of public IPs so I would expect a scan should hit us)…
Normis, could you explain if it is possible that the logged IP is not the real one? Or confirm that it really is the source of the attack?
If the Winbox server is the one doing the IP filtering, then an IP Services “Available From” restriction may not prevent the attacker from using the exploit against the Winbox server because the vulnerability is in the Winbox server …
To be safe for now, only put IP restrictions on the IP Firewall itself.
Currently there is no sure way to see if you were affected. If your Winbox port is open to untrusted networks, assume that you are affected and upgrade + change password + add firewall. The log may show unsuccessful login attempt, followed by a succefful login attempt from unknown IP addresses.
This doesnt seam to work for me very good, i set the rules on top of my firewall list, also blocked via RAW but for example if i run port scanner from http://en.dnstools.ch/port-scan.html, it works and blocks access to it immediately as it runs.
It has loooooong been known that ROS stores passwords using reversible encryption instead of hashes, and I’m surprised it has taken this long for this to get changed: http://manio.skyboo.net/mikrotik/
On the other hand, when you are the one that set the password and you can’t log in to your own router, even though you could just reset to defaults or Netinstall to fix it, it’s sometimes nice to be able to recover it so that the question of “what on EARTH could I have possibly set the password to?” doesn’t constantly nag you.
We can only imagine what problems there will be when a vulnerability in the firewall is found…
And at the rate that they are found lately, how long will that take?
Remember that normis has told us time after time that it is not possible to recover a password from a MikroTik device, you would have to reset and netinstall it.
Was that really true? Or is what is now called a “vulnerability” in fact really a backdoor to retrieve the passwords from a seized device?
It is a bit too obvious that you can download the user database, something you normally cannot even do from winbox as an authenticated user, over the winbox port, without being authenticated.
RouterOS doesn’t have backdoors. This is a bug that was introduced in 6.29.
The fact that password encryption was considered “weak” is not news. The file was previously hard to get. We are also improving the encryption of the user password file now.
Then paste the following - make sure to update the port knocking rules to something random that you can remember.. the easiest way is to hit these sequentially using a web-browser if you’re coming from a new IP address and need access.
OK, try this :
ip fi fi add action=add-src-to-address-list address-list=Port_Scanner address-list-timeout=1w chain=input comment=“Port Scanner Detect” protocol=tcp psd=21,3s,3,1
Change:
We have discovered a new RouterOS vulnerability affecting all RouterOS versions since v6.29. By:
We have discovered, thanks to our customers, a new RouterOS vulnerability that affects all versions of RouterOS since v6.29.
Do you have a problem with the ssh daemon? import to store: 1
STORE /nova/store/ssh-forwarding: openIdx failed: 2 No such file or directory
password:
Even with the later versions or ROS, you can download a backup, restore it on a virtual machine running same software version, downgrade to an earlier software version, take a new backup and feed that to the reverse engineer tool which will spew out the passwords for every user in the database.
This has been known for quite a few years. In part it is why they implemented the restore password, but if you downgrade to a version which does not require a password for the backup you’re all set for recovery.
It would mean that you need to have access to the device, but with bugs like this one, that could become very trivial in the near future
Actualy i just realized i does work good in theory, but this site alternates ip address, so it took me 3-4 runs to block all 3 IPs and now it returns zero ports and blocks it properly.
But that whats the point of this, i ran it 3 times and got all my ports listed 3 times before mikrotik blocked it, “attacker” already have all it needs.