All RouterOS versions are secure against the Heartbleed issue.
All versions prior to v6.13 used an unaffected, older version of OpenSSL, and since v6.13 the latest OpenSSL version will be used, where the heartbleed issue is fixed.
We didn’t use any of the affected OpenSSL versions in any of our products, so no specific action is required on your side.
v2 until v6.12 (included) = secure because use an older OpenSSL version
v6.13 (and above) = secure because use a newer OpenSSL version
MikroTik vs. Cisco
MikroTik Wins 8-2
As mentioned Mikrotik is not effected by Heartbleed, so I don’t understand comment Mikrotik - Cisco or Mikrotik Win8-2???
Cisco is affected to Heartbleed.
Excellent …
Can you write which version use? Number of OpenSSL version?
Not sure how you are claiming that Mikrotik wins over Cisco with regards to heartbleed - yes, Cisco has affected products - just about everyone does, but if you want to compare apples to apples (or firewall or firewall to firewall), then it’s a tie - the Cisco ASAs are unaffected. Switches are unaffected. Routers are unaffected. IPS is unaffected. The only thing listed as confirmed affected related to the ASAs is the AnyConnect Secure Mobility Client for iOS - yay apple. The list of unaffected products is longer than the list of affected products. Source
But have SOME affected products, MikroTik NONE.
And MikroTik not win 1-0 for that, but 8-2.
I do not want reveal why 8-2.
I’m guessing you’re counting the total security issues, and whether the vendor was affected by them at all.
In the case of MikroTik’s 2 points, I’m sure one of them is the SSH DoS bug. I’m not entirely sure about the other one.
You have revealed one, the other are rights excalation by API (obvious if are enabled).
But I not want write only single detail, for not make public this discovery.
I think I know what you’re talking about… I’ll verify my suspicions, and if true, I shall report it to support.
(I won’t say more before that… no need for a false flag panic.)
OK, I did found just one thing… but since it requires a lot of situational variables to line up (and is therefore unlikely to happen in practice), I think I can share it publically.
If you run a script with a user that has high permissions (e.g. “admin”), and within that script you write a file that you then import from that same script (e.g. a file that you’ve fetched via “/tool fetch”)… Even in normal circumstances, you need to do a “:delay” of at least two seconds for the file to be written on disk before importing it.
Within that delay, an API user that only has “write,api,ftp” policy can modify the file to anything it wants, including, for example “/export file=FileWithPasswordsAndAll.txt” or “/user set limitedApiUser group=full”, and the script would execute just that, allowing the user to access previously restricted data and functionality.
This does not work if the user does not have “ftp” permissions, since even the API needs these to read/write files from the “/file” menu. Also, the writing needs to happen EXACTLY during the delay. If it’s too early, the script will override the malicious content with its own, and if it’s too late, the script would already be executing the actual script, rather than the malicious one.
Also, who gives anyone write access to their router via the API protocol without trusting them? Therefore, even if there’s a breach via this method, it will need to happen by an insider - someone with a RouterOS user account with sufficient permissions.
The above is in v6.12. I tried a lot of other things, but failed to escalate my permissions. I don’t know if earlier versions are vulnerable to the other things I’ve tried, including:
@rextended I’m guessing that’s not the one you have in mind… Have you tried duplicating your issue with 6.12 yet?
I not want to start a quiz, mystery, flame, post chain, etc. (and I hope I have written this well on English)
But for each hint about the problem I have found subsequently come out more post, question, etc.
I only “say” well done, you center the problem!
I am sorry, but here are some points:
you knowingly allow this to happen, where it the problem?
if you are not fetching through secured channel, you are vulnerable to the man-in-the-middle attack, that will just inject required code to create new user/remove configuration whatever.
If you want security you should move from “pull-updates” to “push-updates” scenario that you can do over API-SSL.
With “write,api,ftp”, you’re not allowing the API user to read files, reboot the system, change passwords, read other sensitive information, do pings, etc. and you may not want that to happen… and yet it does, even though you never intended for it to happen.
However, you have a point. As I said both at the start, and towards the end, few admins would give even just write access to an untrusted party, which combined with the limited window, makes this an unlikely attack to happen in practice.
I guess the only remotely realistic scenario where this MAY cause a problem IF you ALSO somehow manage to intervene in the middle of the delay, would be an API application that for whatever reason (say, convenience) is used for both management by end users and by admins for FTP purposes (say, to allow quick hotspot page updates). As an attacker, you’d need to rely on the management (API) part to do the work of writing a file, escalate the API user’s permissions that way, and then read sensitive information or do similarly dangerous things.
But even that scenario requires an API application that has been compromised enough to, at the very least, allow arbitrary file writes by end users. In practice, an API application that writes files should check the name of the file to make sure it’s not the name of a known to-be-executed script OR forbid the overwriting of files AND allow only the removal of files that it itself knows are owned by that user by other means (e.g. a database or an artificial prefix to the file name to “namespace” the uploaded files from fetched scripts and the like). So the onus is more on the API application, rather than RouterOS.
The only thing RouterOS could possibly do to prevent this (again, extremely unlikely) attack would be to not release any file write locks obtained during the script, until that script is over, and thus block other scripts and protocols (including the API) if they try to write to the same file before the script is over. This approach however risks a badly written script hanging, and thus making touched files be completely unavailable until a system reboot.
then again, user with ill intent that has write access can change your configuration enough to get ALL your traffic and simply filter through unencrypted data to get information.
I do not see a point to call this a flaw in RouterOS. It is a flaw in user configuration.
Yes exactly, but is still better MikroTik, versus Cisco…
How about http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0224 ? As far as I can see, this allows man in the middle attacks and allows to steal the session, when you use the RouterOS WebConfig, maybe also a SSH connection, but not sure about that.