Security issue when Winbox exposed

There seems to be an issue that allows bypass firewall and nat if winbox is exposed.
Please read this carefully

https://medium.com/tenable-techblog/mikrotik-firewall-nat-bypass-b8d46398bf24

Enviado desde mi Redmi 3 mediante Tapatalk

I think you missed the red herring and flaw in the whole article…
“One important thing about this setup is that I opened port 8291 in the router’s firewall to allow Winbox access from the WAN. By default, Winbox is only available on the MikroTik hAP via the LAN. Don’t worry, I’m just simulating real world configurations.

a. who keeps 8291 as the winbox port
b. who allows winbox open to the internet

No, I haven’t missed it: look at the title I have choosen.

This, from surface reading the article, seems very serious. There should be full support and expected behavior for allowing Winbox to the world if it is password protected. I think a look from someone at MikroTik is appropriate.

Fixed in 6.42.12, 6.43.12 and 6.44

Thank you, I was about to ask because I saw 6.42.1 used in the video. So, fixed 9 days ago. I see the line item: *) winbox - improvements in connection handling to router with open winbox service; I would not have caught that as being this serious.

This shows that current winbox authentication code is flawed. Winbox server should not accept any commands until you log in with valid user and password.
Checking if user is logged in for every function call is not a good practice, it needs to be fixed globally. User must authenticate itself before any other code is even accessible.
Also this is some dude extension that’s not even used in normal winbox. One might wonder how many similar “gems” are still hidden in the code…

Why is this not mentioned as high severity security bug in changelog? Why no mention on security blog? Come on Mikrotik…

Geez, I didn’t know this forum was a nursery, I have never heard such whining.
If you proper follow security protocols these are not issues that a serious IT admin is going to lose his bowels over.
I do agree that its best to be transparent and I will await response and some facts from MT before passing any judgement on that front.
Until then, all this rhetoric does is feed trolls — don’t become one …

If it’s fixed in .12 means you (@Mikrotik) knew about it for a while now. And you didn’t warn your customers? What’s the point of security blog if you don’t use it (last update: 9th Oct, 2018)?

REALLY disappointed

Wow Sebastia, are you going to lose sleep over it. Has it changed your life drastically, need some depression medication…
All kidding aside, as I said, there is no security issue per se, but the transparency and communication piece have yet to be explored and explained by MT.
I will wait for their feedback before passing judgement.

I can send you nekkid pictures of myself running in the snow if it will cheer you up! :wink:
(oops not quite, I will be wearing socks)

@anav

There is no troll feeding. @mrz admitted it was fixed so it is confirmed issue. (if there is not and issue, there wouldn’t need to be a fix, right?)
Page with CVE contains timeline which shows how fast it was handled.
Please, do not take this situation lightly anav. You can do better. :frowning:

Ps: it’s 5am here.. Your pic won’t make my day, no matter how much clothing you have. Good coffee and brekky will… Send those instead.

Regarding disclosure of full details: I don’t think that’s necessary nor wise. Or at least not immediately after fix is published. It takes some time for people to install new version and if exploit is not running wild it might be better to stay low profile not to attract attention of some hackers not knowing the vulnerability yet.

MKX, damn that sounds plausible!
Since all the other security issues have been on the street for months some years and the corrective actions such as closing down crappy configs, using netinstall to upload the latest firmware should be in the forefront of any reader… The issue should be covered and issuing another warning to do the same thing (upgrade firmware config properly etc) would not change an iota for people who have not paid attention but would alert badguys to another available tool??? Not bad tactical thinking. In any case … speculation.

Would I see the day that Mikrotik just states current, minimal RouterOS version is x.xx in plain sight for us!?!?

We have now a security blog which not telling anything about this even not the current minimal version.

Excellent that it was fixed that fast however we are left in the dark.

@mkx: I don’t think full detail disclosure is necessary. I even agree that it is not wise. (however that is what actually happened) All I ask, is having correct info in changelog which will at least give me info that it might be good to upgrade the router for security reasons. Given current situation with “stable” being sometime pretty unstable, I can’t really update every time there is an “improvement in connection handling”. (I hate to admit it, but I actually love this play with words.. “improvement” yeaaaah :laughing: )

Current misleading changelog:

What’s new in 6.43.12 (2019-Feb-08 11:46):

*) winbox - improvements in connection handling to router with open winbox service;

Appropriate changelog (partially inspired by 6.42.1 and 6.42.7 which both fixed similar vulnerabilities):

MAJOR CHANGES IN v6.43.12:

!) winbox - fixed vulnerability that allowed to gain limited access to an unsecured router; (Details will be published in 90 days)

I see where you are coming from, so I fixed it for ya…

Software with fixed bug is better than software without fixed bug, you can’t say that it’s not an improvement, that description is 100% true. And MikroTik’s approach to releasing details is well-thought strategy, carefully crafted to avoid both spreading unnecessary panic among users and tipping off the bad guys at the same time. It’s all nice and smooth, “improvement” sounds interesting to users, but not too interesting to bad guys. If they’d use “vulnerability”, it scares users and attracts bad guys. Although it’s not yet clear how it will work in long term, it’s possible that RouterOS users could eventually become terrified by word “improvement”. :slight_smile:

Please try to keep in mind some of us run networks where we can’t just take down the router for every RouterOS release. This was clearly not labelled as a security fix, so I personally did not consider it a priority to deploy during a maintenance window. And this vulnerability applies equally to LAN or WAN - users inside the network can proxy through winbox to different network segments, potentially accessing management LANs and devices that should be totally restricted.

Now I had to interrupt the network outside of maintenance hours to get this fix applied.

State minimal safe RouterOS and let the bad boys guess what vulnerability is. Agree with the ones bringing the ‘problem’ under attention of Mikrotik to have a delay of 30 days after patching, before going public so that users can upgrade in that time. To me Tenable went public to soon.

If Mikrotik takes more than 60 days to patch then the 90 days is still a hard limit.

It is not important how Mikrotik looks in public but that the buyers/users of their devices, can trust in Mikrotik that they are kept up-to-date despite being kept in the dark about what exactly is the vulnerability.