Anyone had problems with his SXT2lite after upgrade to RouterOS/Firmware to 6.42.1?

I'm using a SXT2lite as client for HAM RADIO usage (HAMNET). Firmware/RouterOS before upgrade was 6.41.3.
AccessPoint is a Ubiquity Nanostation M2 with 5 MHz bandwith.
I can see the AP pretty well (in SCAN or SNOOPER mode) and it has a big signal with about -55 dBm.
But the SXT2lite can't connect to it anymore after the upgrade (it was connected before upgrade!).
Connecting a standard 20 MHz AP locally works fine (Signal about -70 dBm).
But the 5 MHz AP can not be connected anymore.

I tried to downgrade RouterOS to 6.41.4, but 5 MHz connection wont work.
Well, the Firmware was still 6.42.1 ... this is not changed by RouterOS Downgrade.
Is there a way to downgrade also Firmware for testing?

Thanks in advance

I'm glad to see this got fixed so soon!
Many thanks to the team who works on this (and lost a lot of sleep probably)!

Attacks seem to be rather specific though, haven't seen the mentioned log entries on my dutch and czech routers.

I'm glad to see this got fixed so soon!
Many thanks to the team who works on this (and lost a lot of sleep probably)!

Attacks seem to be rather specific though, haven't seen the mentioned log entries on my dutch and czech routers.

Do not forget the users that brought this to the attention of Mikrotik. Those users certainty lost sleep and looks probally still a bit pale around the nose.

Other see a daunting task in upgrading farms of routers and I wish them all the strength and luck with this challenge.

But the intruder can also sit inside your network. What if the intruder connects in with the MAC address/Neighbors service? There is no filtering possible on that.

yes. one can disable the mac-winbox functionality. but the attack surface is a lot broader on the internet. i just pointed out that remote exploits can be mitigated using ip service filters

But the intruder can also sit inside your network. What if the intruder connects in with the MAC address/Neighbors service? There is no filtering possible on that.

Nope. If in-port is a part of a bridge - You can filter MAC-Winbox and MAC-Telnet pakets using bridge filter chain input.
Example drop all MAC-Winbox: "/interface bridge filter add action=drop chain=input disabled=yes dst-port=20561 ip-protocol=udp mac-protocol=ip"
Make Your own rule to describe trusted hosts by any criterya e.x. src-ip, src-mac, etc.

I have a home-based installation with my small business running behind. I do have another firewall from another vendor between my wan and my lan. I wasn't hit by this bug despite the fact that winbox port was open. This might be just lucky as I blacklist any IP trying famous "attack ports" and the current attack tried telnet first before running the attack on 8291.

What I can say is:
* This was a serious mistake leading to a serious bug! Shame on you! (Sry to say that)
* MT's reaction is fast and advisory is clear (if you read carefully)

What I would expect now in terms of security feature requests could be amoung of these things:
* including Port-Knocking functionality in Winbox: I do use port knocking, but I think it would be a good idea to include this to winbox to encourage ppl to use port knocking.
* Geo-IP-Functionality included in Winbox: As the attacks came from asia and I would have restricted access to the countries I a usually travel. This would help a lot of people to minimize attacks.

* Communication: As soon as a good percentage of ppl have hardenend their routers we need more information on what was going on and why this hasn't been detected by Mikrotik.
* A monitoring for specific MTik attacks (by using honeypots or by any other means) should be established.

with hundreds of routers that do not enable connection-tracking whats the best RAW firewall rules to protect a router. Has anyone got a template they can share? We cannot enable any rules in the services / ip firewall filter otherwise packet fragments are not passed.

The best INPUT firewall rule is always: allow what you require, drop everything else. Vary for your requirements.
But be careful not to lock yourself out and not block replies to outgoing traffic, especially without connection tracking.

there is no input firewall on RAW. only prerouting and output.

My 2ct on the best way:

Drop all input/output traffic on public interfaces (not only internet, treat your customers network as public too!)
Connect all routers to a management network (physical or VPN)
Use L2TP/IPSEC VPN to connect to the management network
On the VPN router, drop all input/output on the public interface except L2TP/IPSEC
Monitor the log of the VPN router.
On every router, put all IP that try to connect to port 21, 22, 23, 80, 443, 8291 on a blacklist and share the blacklist between routers.

If you're blacklisting based on connection attempts to certain ports, I would advise against it. Doing this opens up a new attack vector where an attacker with IP spoofing capabilities (eg many cheap VPS providers) can spoof popular IPs and cause your network to block legitimate services. Taking any action on unauthenticated packets other than dropping is not a good idea.

Why blocking access to router is bad idea? Should "popular" addresses try to access our router?

When a mikrotik network could be compromised, you need to do some basics steps for EACH router in the network (i.e. all cpe):
- disabile scripts and schedule (could be injected malicious code)
- remove dns static entry (could be poisoned)
- remove odd nat rules (could be used as reflector to internet or to other routers in the network)
- add a new administrator with new password
- remove ALL other users
- secure ip ports allowing only connections from management source address (securing these router first)
Without any other firewall filter rule, this router is now secure and could be upgraded
HIH

Why blocking access to router is bad idea? Should "popular" addresses try to access our router?

You should be dropping such packets anyway. If you add them to a blacklist which blocks all communications from that IP, then you block legitimate services if someone spoofs them.

I know ... but it input chain is not the same as forward one. You can block access to router but not traffic forwarded to/from users.

Port knocking is really poor security IMO. It is basically an additionnal static password .. made only of numbers => very quick to brute force. A proper VPN is superior in every aspect.

another interesting stuff i found while dumping traffic on a router with winbox disabled in ip services but mac-winbox enabled under /tools mac-server mac-winbox on internal interfaces. As it was told, this stuff runs between unicast MAC addresses, but using 0.0.0.0 and 255.255.255.255 IP addresses respectively. so, at the end of the day, this is indeed sort of IP traffic.

just installed a first rule in ip firewall, to see whether it could be jacked there: did not had high hopes, so i fired up winbox, and connected to the router via MAC address. It just succeeded w/o any hesitation. the captured traffic on the host showed the usual pattern (my.ip.add.ress->255.255.255.255 on port 20651 and response as 0.0.0.0 port 20651 -> 255.255.255.255). now i was checking out the firewall rules, and behold:
so the IP firewall "sees" the traffic, the rule is actually evaluated _and_ it matches, but no action is taken. the capture shows no special options, the packet's TTL is set to 64.
now - unless RouterOS manages to validate whether the TTL was decreased in any way - the mechanism can be fooled. i'd strongly recommend Mikrotik to use TTL=1 responses and accept only requests with TTL=1, so packet forging can be eliminated. Luckily the responses are sent to 255.255.255.255, so they would be dropped by any intermediate router.
kind of curious whether i could trick it to accept the packet with the same dst port but with an unicast IP as destination.

I know ... but it input chain is not the same as forward one. You can block access to router but not traffic forwarded to/from users.

Dropping in input is fine, but I've seen several blacklists use raw table which would obviously affect forwarded traffic too.

so the IP firewall "sees" the traffic, the rule is actually evaluated _and_ it matches, but no action is taken.

This is an application that listens on a raw socket. It sees the traffic before the firewall. It does not matter what you do in the firewall (block or allow).
It is similar to the DHCP server. You do not need an allow rule for DHCP packets, you can even have a drop rule, the DHCP server will work anyway.

Also true for the packet sniffer. You probably know that when you run wireshark on a Linux machine you see all traffic on the ethernet interface, also
traffic that is blocked by the firewall. In fact, it is quite difficult to do a trace of "only the traffic passed by the firewall", even when that is sometimes desired.

Of course it is very important that such applications are secure.

i just put a log rules and catchup already a rogue ip...
19:17:16 firewall,info winboxtest input: in:ether1-BGP out:(unknown 0), src-mac de:ad:b3:3f:ba:ad:f0:0d, proto TCP (SYN), 181.214.87.34:41028->xxx.xxx.xxx.xxx:8291, len 40

This is the second advisory for this same port in as many weeks. Whilst we block it to the world we still feel compelled to update all our customers' routers. I hope this is not a sign of things to come.

While I'm on my soapbox I'd like to suggest that graphs are moved off the web management port. They are very different in the scope of their intended audiences, yet the functions are bound together.

Colourful language aside, hashed passwords are the way to go.

Things would be mush simpler to set if we have option to bind services to specific interfaces. That would help to simply narrow access to services by network interfaces without messy IP filtering rules.

It can be done with one simple firewall rule.
Create interface list and add
/ip firewall filter add in-interface-list=xx ...

This is the second advisory for this same port in as many weeks. Whilst we block it to the world we still feel compelled to update all our customers' routers. I hope this is not a sign of things to come.

While I'm on my soapbox I'd like to suggest that graphs are moved off the web management port. They are very different in the scope of their intended audiences, yet the functions are bound together.

You can access graphs within winbox - no need to use web access to them.

How about this for an idea... If the firewall was sound... this would make Winbox accessible to specific IP addresses.

Not at either of those allowed addresses, you have to VPN to one of those allowed IP Addresses. Then you could access the OTHER router's winbox.

Too simple? Or right track?

use layer7-protocol can solve this?
if can,how?

use layer7-protocol can solve this?
if can,how?

why? more simple and quick firewall solves this (see above examples).

use layer7-protocol can solve this?
if can,how?

why? more simple and quick firewall solves this (see above examples).

becouse i am Maintain 500+ mikrotik node,i have not static ip,i need to remote to connect.i can't reboot the mikrotik nodes,i need keep network normal first.and later to update.

Things would be mush simpler to set if we have option to bind services to specific interfaces. That would help to simply narrow access to services by network interfaces without messy IP filtering rules.

That is basically what you have when you set the "allowed from" in the service. At least when you can confine your internal networks using IP subnet declarations.
Also, you can match on in-interface in firewall filters. So you don't need to match on source IP when you don't like to.

becouse i am Maintain 500+ mikrotik node,i have not static ip,i need to remote to connect.i can't reboot the mikrotik nodes,i need keep network normal first.and later to update.

Either configure VPN on the routers so you can connect from anywhere and have more security, or get some VPS at a couple of $/month where you have a static IP, configure VPN to there, and set the fixed IP address of that VPS as your trusted external IP.

becouse i am Maintain 500+ mikrotik node,i have not static ip,i need to remote to connect.i can't reboot the mikrotik nodes,i need keep network normal first.and later to update.

Either configure VPN on the routers so you can connect from anywhere and have more security, or get some VPS at a couple of $/month where you have a static IP, configure VPN to there, and set the fixed IP address of that VPS as your trusted external IP.

i will update all nodes,but need a few days.before update need a temp plan.i want to use layer7-protocol to control.

You can't. This is a legitimate winbox connection. You can only block winbox itself this way. You must block unknown IP addresses, change the port, so that the "attacker" can't easily find your devices, implement other security measures (port knocking would be one, if you can't set up VPN yet)

Very nice tutorial on port knocking: http://blog.cactiusers.org/2009/04/17/m ... -knocking/
to: 9939781 - it is with Layer 7 packet sniffing if you insist on it

i will update all nodes,but need a few days.before update need a temp plan.i want to use layer7-protocol to control.

To implement any change, you will have to go along all the nodes. So better use a permanent solution instead of wasting time now and having to re-do it later.
A VPS is like $4/month install CHR on it or some other OS that can do VPN and you have your own private jumphost that you can allow as allowed from address in the services.
You can use it to run Dude as well so you can monitor your network!

You can access graphs within winbox - no need to use web access to them.

Yes but the graphs in Winbox are rubbish compared to the web ones with their time and throughput scales.

From our network each and every router/switch has a unique randomly generated password. Each router/switch connects via an openvpn tunnel to our radius server for login details, i.e each engineer gets their own user/password to login for accountability.

Also on our edge we block port 8291, 22, 23 etc from outside our ASN, if you are outside our network you need to connect via a VPN.

Every network should have as much and as practical security/firewall procedures in place. No matter who the vendor is, there will always be future exploits.

There has to be a trade-off between a secure access and the risk of unreachable devices when something breaks.
With such config the device will be inaccessible when the connection to radius cannot be set up.
We use radius for customers, but to use it for management of the device would be too much of a risk for me.
Similar for using address lists. We have address lists with allowed management address (source) but they are static and a drag to maintain.
I would use DNS based address list, if they would not be flushed on reboot. Now, when a device is rebooted and is without DNS, it would be unable to load its address list from DNS and management would not be possible. A bit too risky.

my take on remote accessible device management - and some may be behind a "one-way" access medium, like NAT or 3G/4G, where you can't just connect to the device from the outside - is to have a VPS running routeros. and there's no ports exposed there, but only IPSec.
so the managed devices shall connect to it via IPSec. no need for pushed down routes, what so ever.
then the manager user shall do the same.

and they can rendezvous in "cloud #9".
this way you don't have to expose no mgmt interfaces to anywhere.
you don't even need static IP for this, as tunnels can be initiated to FQDNs.

you can drop any management traffic on all routers on their exposed interfaces. yes, that would include also the subscriber/customer side as well.
whenever you access supports it, you can also use IPv6 as the transport of the tunnels to pull this off on some places.

There has to be a trade-off between a secure access and the risk of unreachable devices when something breaks.
With such config the device will be inaccessible when the connection to radius cannot be set up.
We use radius for customers, but to use it for management of the device would be too much of a risk for me.
Similar for using address lists. We have address lists with allowed management address (source) but they are static and a drag to maintain.
I would use DNS based address list, if they would not be flushed on reboot. Now, when a device is rebooted and is without DNS, it would be unable to load its address list from DNS and management would not be possible. A bit too risky.

Hence why each router also has a unique admin password, so if the tunnel/radius had to break we can still get into the router/switch. All passwords are stored on a cloud service.

my take on remote accessible device management - and some may be behind a "one-way" access medium, like NAT or 3G/4G, where you can't just connect to the device from the outside - is to have a VPS running routeros. and there's no ports exposed there, but only IPSec.
so the managed devices shall connect to it via IPSec. no need for pushed down routes, what so ever.
then the manager user shall do the same.

and they can rendezvous in "cloud #9".
this way you don't have to expose no mgmt interfaces to anywhere.
you don't even need static IP for this, as tunnels can be initiated to FQDNs.

you can drop any management traffic on all routers on their exposed interfaces. yes, that would include also the subscriber/customer side as well.
whenever you access supports it, you can also use IPv6 as the transport of the tunnels to pull this off on some places.

indeed. I do the same with OpenVPN as most of my client routers are either behind NAT or have dynamic IP's.
I give each router a loopback (bridge) interface with a /32 IP and either use OSPF or BGP and redistribute the loopback IP's for management.
My management workstation connects to the same VPN and from there I can access all my managed routers.
In case the VPN fails for static IP customers or devices that can be directly reached from the internet (not behind NAT), I use an address-list with my management IP's and only allow access in the INPUT table of the tik from that management address-list.
by default my INPUT table is just DROP (except from my management address-list) and LOG (logging to a central syslog server which is then fed into Graylog2)

Hence why each router also has a unique admin password, so if the tunnel/radius had to break we can still get into the router/switch.

... but that still leaves you vulnerable to the current problem. only your port filtering saved you, not your advanced password management!

I'm glad to see this got fixed so soon!
Many thanks to the team who works on this (and lost a lot of sleep probably)!

I reacted earlier to your post to include also the users of Mikrotik devices.

I agree that Mikrotik worked fast and were communicative about the vulnerability. The final solution for this will take a bit longer to arrive so we are not out of the woods yet.

Thanks also from my side.

Hence why each router also has a unique admin password, so if the tunnel/radius had to break we can still get into the router/switch.

... but that still leaves you vulnerable to the current problem. only your port filtering saved you, not your advanced password management!

Yes and no, having a unique admin password at least lets you limit the risk. i.e not one standard password across all devices.

It can be done with one simple firewall rule.
Create interface list and add
/ip firewall filter add in-interface-list=xx ...

And what if you have disabled conntrack? In a powerful router, we need all power for routing purposes, and firewall is downstream it. Any linux service can be bound to a specific address / firewall...

By now, the only way I've found is disabled winbox and use RS232 IP gateway...

Things would be mush simpler to set if we have option to bind services to specific interfaces. That would help to simply narrow access to services by network interfaces without messy IP filtering rules.

That is basically what you have when you set the "allowed from" in the service. At least when you can confine your internal networks using IP subnet declarations.
Also, you can match on in-interface in firewall filters. So you don't need to match on source IP when you don't like to.

No, it isn't the same. "allowed from" allow you to open a socket to that service, and if it your src ip address isn't listed, it will close the connection. If service daemon is vulnerable...
If you bind a service to a specific address / interface, it will be close to other networks

Can we get a straight answer for...
THIS ROUTER OS UPDATE PREVENTS THIS EXPLOIT.

AKA... one CAN NOT download the user file from router OS 6.42.1, using port 8291, without authenticating to the router first.

Can we get a straight answer for...
THIS ROUTER OS UPDATE PREVENTS THIS EXPLOIT.

AKA... one CAN NOT download the user file from router OS 6.42.1, using port 8291, without authenticating to the router first.

Excuse me, but the whole point of releasing RouterOS in all channels yesterday was to completely close the vulnerability. It is right there in the changelog. Why are you even asking? Was this not made clear ?

Can we get a straight answer for...
THIS ROUTER OS UPDATE PREVENTS THIS EXPLOIT.

AKA... one CAN NOT download the user file from router OS 6.42.1, using port 8291, without authenticating to the router first.

If you cannot be bothered to read the manufacturer's changelog for code that you download and manage, why are you here?

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;

unless your question is a very bad attempt at asking for more details of the exploit, now that the fix is out, and how a customer can test that it has been actually fixed...

That is basically what you have when you set the "allowed from" in the service. At least when you can confine your internal networks using IP subnet declarations.
Also, you can match on in-interface in firewall filters. So you don't need to match on source IP when you don't like to.

No, it isn't the same. "allowed from" allow you to open a socket to that service, and if it your src ip address isn't listed, it will close the connection. If service daemon is vulnerable...

Vulnerable to what? This close of the connection occurs before any data exchange. It is not an RST reply to the SYN as was suggested by someone else, that would be even better, but it is SYN/SYN ACK/ACK/FIN ACK/FIN ACK/ACK, all without any data being exchanged. There does not appear to be much room for vulnerability exploits.

That is basically what you have when you set the "allowed from" in the service. At least when you can confine your internal networks using IP subnet declarations.
Also, you can match on in-interface in firewall filters. So you don't need to match on source IP when you don't like to.

No, it isn't the same. "allowed from" allow you to open a socket to that service, and if it your src ip address isn't listed, it will close the connection. If service daemon is vulnerable...

Vulnerable to what? This close of the connection occurs before any data exchange. It is not an RST reply to the SYN as was suggested by someone else, that would be even better, but it is SYN/SYN ACK/ACK/FIN ACK/FIN ACK/ACK, all without any data being exchanged. There does not appear to be much room for vulnerability exploits.

And what if you send a specially formed packet, and the router answers with the whole user database content? I prefer a brick wall instead of a door with 20 locks

And what if you send a specially formed packet, and the router answers with the whole user database content? I prefer a brick wall instead of a door with 20 locks

I advise you to stop using software and go out of the IT business. Really.

It can be done with one simple firewall rule.
Create interface list and add
/ip firewall filter add in-interface-list=xx ...

And what if you have disabled conntrack? In a powerful router, we need all power for routing purposes, and firewall is downstream it. Any linux service can be bound to a specific address / firewall...

You don't need connection tracking for this.
Read the manual for which features connection tracking is necessary
https://wiki.mikrotik.com/wiki/Manual:I ... n_tracking

That is basically what you have when you set the "allowed from" in the service. At least when you can confine your internal networks using IP subnet declarations.
Also, you can match on in-interface in firewall filters. So you don't need to match on source IP when you don't like to.

No, it isn't the same. "allowed from" allow you to open a socket to that service, and if it your src ip address isn't listed, it will close the connection. If service daemon is vulnerable...

Vulnerable to what? This close of the connection occurs before any data exchange. It is not an RST reply to the SYN as was suggested by someone else, that would be even better, but it is SYN/SYN ACK/ACK/FIN ACK/FIN ACK/ACK, all without any data being exchanged. There does not appear to be much room for vulnerability exploits.

And what if you send a specially formed packet, and the router answers with the whole user database content? I prefer a brick wall instead of a door with 20 locks

Somethng about TCP connection usage in applications. There are basically these steps which occurs in TCP conenction life:
1) LISTEN phase = application/daemon indicates that it is waiting for a connection
2) ACCEPT phase = a connection is established by a remote and application is informed that there is a connection in queue ready to be served. The application calls 'accept' function on the connection and receives basic information about the remote side (IP address, port). And this is the time when allow-from is checked. If all is OK the step 3) occurs, if not the connection is closed. It means the application reads no data from remote but just informs the kernel to close the connection.
3) reading/sending data
4) connection close/teminate

Yes, there is a possibility that some packet type/content can cause the kernel (TCP/IP stack) will go nuts (there were ping of death packets etc) but the chance that it will allow to read /etc/passwd file very low IMHO (I wouldn't like to be wrong). Since there are tons of lines of software which handles the packet delivery (network drivers, TCP/IP stack) before it reaches firewalling rules, there still is a chance that something wrong can happen.
There is a possibility to upload filtering rules directly to network card (not supported by ROS) but the card is full of potentially badly written software too

Please upgrade to 6.40.8 or 6.42.1,
https://mikrotik.com/download
The issue was addressed in both versions,
!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;