Denial of service attack in winbox service cause winbox service to totaly fail to respond and also various results in the whole router.. 100% cpu always and sometimes BGP and interfaces failures after long time attack..
Details, script code and video example here.. : http://www.133tsec.com/2012/04/30/0day-ddos-mikrotik-server-side-ddos-attack/
Isn’t this pretty much the same topic?
they are 2 seperate vulnerabilities..
One for winbox (client side) and one for winbox service on server side..
I went looking to see about the DOS attacks, and all the threads I can find, have been deleted.
I find this quite troubling.
Is MikroTik simply going to address security vulnerabilities by quashing any discussion of them?!?!
I’m not aware of any security list, or the like so one can know about such issues and how to address them.
So, I’d like an answer MK …
- Is discussion of a security vulnerability and the steps to mitigate it off limits?
- If so, how do you propose to allow these kind of issues to be discussed?
- Finally, shouldn’t there be a security channel where such problems are announced and the issues raised addressed?
-Greg
Winbox from my perspective is for management and should not be available to ANY ip source addresses.
Do this to any management protocol at your own risk.
We configure all our routers to have a ‘safe’ list and a ‘hacker’ list, any management ips are added to safe list statically and added to source allow at top of firewall rules, then anyone connecting to 8291 port is added to ‘hacker’ list which is blocked
First line : allow safe list
Second line : block source hacker list
Third line : If tcp 8291 dst add source address to list ‘hacker’
These are all nice replies, but mostly meaningless unless we know more about the problem and a full discussion of the issues from MT. Since this hasn’t happened, these mitigation may well not “mitigate” anything.
Further, while mitigating a problem is nice - there are some cases where allowing WinBox management from the WAN side in an unrestricted manner is the only real option.
Again, banning or deleting discussion of the problem and avoiding full disclosure is simply stupidity, IMO.
The “bad guys” will all have the ability to attack your systems, and you’ll be without any real knowledge about the issue and how to best protect yourself.
This kind of response makes me question the choice to use MT. It’s misguided and the only people it hurts is the user base.
It may appear to help MT in the short-term, but companies that stomp all over discussion of vulnerabilities, especially in the security world, should die quick deaths.
Witness RSA and the secure ID fob token train-wreck. No disclosure, until months later, and then only when cornered. “Ah, yeah, everyone who used our product was totally vulnerable to a horrible attack. But trust us, we have your interests in mind!”
I don’t trust anyone, and especially not anyone who has a financial interest in misleading me. Give me details and let me evaluate the issue.
-Greg
RouterOS with a firewall is not vulnerable. Affected is only device with no protection. We are working on a fix for those unprotected machines.
by quashing any discussion of them?!?!
we are not quashing discussions, we are simply not blowing the problem out of proportion, to reduce peoples want to exploit this
Hello MikroTik support team,
was both DDoS issues solved in released 5.16 version, please? I can’t see information related to this topic in changelog.
Thank you
Also curious if 5.16 addresses any of this?
No. The problem is actually only one (DOS, not DDOS, because it’s not distributed). You can solve it, by configuring a firewall rule on the router, to stop unknown connections to the router. Normally you should have such rules in place already, as most RouterBOARDs have such configuration by default.
We will solve the issue in the next version. The other “problem” works like this - somebody could create a program that looks like a router to the Winbox Loader. When the Winbox user is tricked into connecting to this fake “router”, the windows user could be attacked. In near future, Winbox loader will be eliminated (Winbox will be one program), and this problem will be solved by itself.
None of these issues are new. They have been there since Winbox was first released.
Normis…
I’m not sure why you all feel so strongly about this. [Quite clear, since you deleted my last post…]
I’m really not trying to be a PITA, but I haven’t heard any real answers.
So, I’d like an answer MK …
- Is discussion of a security vulnerability and the steps to mitigate it off limits?
- If so, how do you propose to allow these kind of issues to be discussed?
- Finally, shouldn’t there be a security channel where such problems are announced and the issues raised addressed?
What I know about the issues is REALLY thin.
…And apparently I’m not allowed to pose further questions here, or to prod you/MikroTik to provide more answers etc.
So lets try, for the sake of furthering the discussion, to talk about disclosure, a security notification process etc.
Is there a security channel, or list-serv? [If not, which I assume is the case, is there a plan to create one?]
If you’re not going to have one, should people just submit known vulnerabilities to CERT and let them handle the disclosure?
I’d assume you’ve seen these, but this is what I’d expect in a security channel:
http://www.us-cert.gov/cas/bulletins/SB12-135.html
and
http://www.us-cert.gov/cas/techalerts/TA12-101B.html
It has the date it was published.
It has a clear synopsis of the problem.
It has a score and category of severity.
It has a link to a fuller discussion of the issue (e.g. http://www.adobe.com/support/security/bulletins/apsb12-08.html) where you learn:
Which versions are affected.
What the potentials are. (e.g. A DOS with potential for remote privileged access.)
…and lots more.
[That’s a whole different world than we’ve seen around this issue.]
I think a similar approach is a very good thing for MikroTik, and for those of us supporting the product.
And one specific question about the current issues:
Do you have a time-frame for a fix?
[I really need WinBox access from the world, as I suspect most others do too. Simply firewalling off the WinBox port, or disabling WinBox support completely really isn’t a workable solution for me. …and yes, I could turn it off, login with SSH, turn it on for a single host, do my work, and then turn it back off - or some other work-around, but these are practically unworkable. The result is that it’s such a PITA to manage the box, you just either turn it on and live with the risk, or turn it off and never turn it on except in the most dire of emergencies. And I think it’s pretty clear that either of those two extremes are less than ideal.]
-Greg
This is one of the things that has hurt Mikrotik’s reputation the most. This is the internet, and nothing attracts attention more than a company deleting posts about security issues or bugs. If they can’t discuss it on your official forums they’re going to go discuss it on your competitor and 3rd party forums. There’s numerous examples of this.
The correct way to handle such issues it to acknowledge it and post a notice about the vulnerability, versions affected, and mitigation steps to take until a patch is issued.
well as a RouterOS and RouterBOARD user myself all i can suggest is - create decent firewall that will allow you everything you like and still keep the router safe.
There have been endless discussions about what is and what is not safe. Now - suggested configuration have proposed WAN interface completely cut off, hence all the attacks can come only from within your network where you can deal with them swiftly and easily.
And once again - having proper configuration in place resolves the issues like this. When i configure the router usually i have port-knocking in place and allow encrypted tunnel to the router. In user list - connection to the router is allowed only from management IP addresses. That was so in 2.9.x era and so it is now.
Anyway described problems are worked on. And this topic looks more like scaremongering than anything else.
Some nice suggestions here: http://gregsowell.com/?p=3773
Something that many have missed: RouterBOARDs have this firewall rule by default
It doesn’t have to be that way, but it will end up that way if posts like this get deleted. The way to handle it is to make a sticky notice about the vulnerability, what versions are affected, how to mitigate it, and that Mikrotik is aware of the problem and working on a patch.
I guarantee you that people that will actually use the vulnerability already know about it. The professional thing to do is notify your users about the issue in an official channel. That way you appear in control of the situation instead of trying to cover it up, and if the internet has taught the world anything it’s that trying to cover anything up only makes it spread faster.
So, Normis and Janisk both post elaborate defenses, and simply ignore all the queries about a security list-serv or equivalent?
Seriously?! [With all due respect, can I have what you’re smoking? It’s got to be good stuff!]
– First: I can show you scare mongering, and this isn’t it. [The first post or two, who knows. I’m not going to get into analyzing the mindset of another poster. Perhaps they are people with ill will toward RB/MikroTik, perhaps not. But my posts, and my queries, they’ve been respectful and simply asking for more data. The other posts also have been asking for more data.]
– Second: Scaremongering only works if you refuse to get out in front of the problem and actually address the issues in non-bunker mentality. Be open about the issue, it’s cause and ramifications, remediation steps and time for a fix.
You’ve had to be led, screaming and kicking the whole way, to get the most minimal disclosures so far. So, in that environment, you are being your own worst enemy in allowing MikroTik to be a “victim” of scare-mongering, IMO.
When people think you’re being evasive, not fully honest, hiding things - that’s when fear-mongering works.
[And that’s how it looks to me - and really, I’m no hostile audience. I really WANT MikroTik to succeed. I’ve just spent a very significant amount of time moving my clients to RB and writing scripts and doing a lot of bench-testing etc. I don’t have lots of great alternatives. So, believe me when I say, I really want RB to succeed. At it’s core, it looks like a really great product. If I didn’t want your success, I wouldn’t have spent the time, money and resources here.]
So, if you want to immunize yourself against fear-mongering, just be fully open and very up-front about the problems. If you don’t, someone will fill up the vacuum with mis-information - intentional or not.
– Third: Please stop with all the “firewall blocks on the WAN interface fix the problem.” You act as though this isn’t a problem because you shouldn’t use WinBox on the WAN interface. You act as though this is just “normal” and any non-retarded non-moron wouldn’t be complaining at all, that this is all a total freak-out over absolutely nothing.
Lets just, for the sake of argument, assume this is a reasonable/plausible suggestion. [That it’s all a “freak-out” over nothing.]
If that is really so, and freaking-out over nothing, and there’s really nothing there, there…then why bother fixing the problem at all?
Oh, that’s right, because it really is a problem.
Any station that can communicate with WinBox can exploit this and DOS the Routerboard, including internal stations - or something infected with a virus etc. [And yes, it would have to be specially tailored etc - I fully understand this.]
And the attacks from a “fake” RB server are, from the minimal data I have, very serious.
So, it IS a real problem. You’re admitting that by fixing it. But you can’t have it both ways. Either it’s not a problem and we’re not going to bother fixing it, or it IS a real problem and that is WHY we’re spending the resources to fix it.
The mitigation steps help for people who can practically implement them. However, some won’t be able to implement them, and the thing is still vulnerable unless you disable all management except through the serial interface. Do you think Cisco would get away with claiming that “only people on the LAN could DOS Cisco routers” and thus it was all no real problem? [Answer: ABSOLUTELY NO!]
However, there are, essentially, NO mitigation steps for the fake RB server problem however. [Again, going from the extremely limited data that MikroTik has divulged so far.]
– Fourth. You continue to avoid any time-frame of a fix. “We’re working on it,” doesn’t mean a lot to me. Did you ever hear about Duke NukEm Forever? They’re working on it. [Just to save you time, it was a FPS game that went through a 15 year development cycle, and still generally sucked when it finally rolled over the finish line. It received a “Lifetime achievement award” for being vaporware.]
So, “working on it” is nice, but not enough.
When, generally, do you expect to have resolution in place. I understand that dev cycles aren’t solid guarantees, but rough estimates are good. Should we expect six days, six weeks, six months, six years, six decades or six millenia?
Lastly:
And again. Is there some plan to put in place a security announcement list-serv? I shouldn’t need to check the forum. Every other Linux product: Postfix, sendmail, dovecot, apache etc all have security-announce lists.
If I subscribe to the announce list, I get notifications of security problems and links to fuller discussion and remediation steps. MikroTik REALLY, REALLY, needs to do the same. Don’t expect people to check in here every day/month/year to see if there was a security vulnerability that was addressed and fixed. You need to proactively contact anyone who wishes for notification of a problem. A moderated list-serv is usually the time-honored way to handle this.
I’ll leave it there - but really MikroTik, you can get in front of this and actually lead the way. If you refuse, there are those of us who will “help” you. You probably won’t like it, and as the above shows, it sure seems you don’t. But as the saying goes: “You can either lead or follow, but get the *** out of the way.”
To Recap, here’s what I and others are asking!:
-Answers about the problem and it’s scope. [Would be nice, but I’m not holding my breath.]
-Time-frame on a working fix for this undefined set of security vulnerabilities/DOS attacks. [Must have!]
-Position on a security list-serv and when and how you plan to implement. [Must have!]
-Greg
I already said that the problem is not serious, and that we will fix it.
And I can repeat again - by default, with no user interaction, a firewall rule exists to prevent this.
if we thought what you claim us to think - this would not exist:
http://wiki.mikrotik.com/wiki/Securing_New_RouterOs_Router
http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter#Router_protection
so if you have that in place, how serious is the vulnerability?
IMHO we are pretty open that you have to protect your router and configuration should be very strict what should and what should not be allowed.
And of course we are grateful that such a flaw was discovered and we can resolve the issue.
So, the hyper-defense continues unabated. Whatever. I guess you’ll believe what you want and we/I will believe what I believe.
I just can’t figure out
- why you refuse to go the full-disclosure route,
- why you won’t give an estimated time for release
- why you won’t commit to a list-serv or equivalent security notice mechanism.
[You know, the 1990’s called and they want their security notification model back!]
If you change your mind, and decide to actually handle security-release notices like the rest of the civilized world, give me a shout. I’ll certainly be glad to welcome you to the modern age.
-Greg