6 ms·

MikroTik authentication revealed

180 points by aaronsdevera 5y ago

graton 5y ago
I'm confused on why this is needed. I have a couple MikroTik devices and I just use SSH to login to them. I also have automation that runs via SSH to update things on the devices.
- mongol 5y ago
  Someone else in this thread mentioned it was used to login with Level 2 access. I.e with Ethernet MAC address?
- dboreham 5y ago
  When you screw up and delete the ip address from a remote router it will come in handy.
  - dicknuckle 5y ago
    When that device is hundreds of miles away, it's double handy.
PragmaticPulp 5y ago
> The single best resource we used in reverse engineering was an unfinished IEEE submission draft courtesy of the WayBack Machine. In fact, MikroTik's implementation is nearly identical to the draft's proposed protocol. See if you can spot the minor nuances and marvel (as we did) that the shared secret remains the same. That's a surprising twist. They duplicated the protocol from this unfinished draft almost exactly, but the draft doesn't appear to have gone anywhere (hence the archive link) I wonder if the same person who wrote the paper consulted on this implementation, or if the MikroTik team just saw the paper at some point and decided to use it.
- wiml 5y ago
  There are a surprising number of internet-drafts that died before reaching RFC status but nevertheless were implemented, even became widely implemented standards. The sftp protocol ("filexfer" over ssh) is one example. Does anyone know why this is? I've never been closely involved in the RFC process; is there some hard-to-clear hurdle at the end of it?
  - Kadin 5y ago
    The draft standard was an IEEE proposal, not an IETF one (RFCs are specific to the IETF standardization process), but it seems like the author was pretty familiar with the IEEE process and is involved with that organization. Maybe it was just a solution looking for a problem at the time of its proposal? Honestly, I'm not sure exactly whether the exotic encryption choices (strange, little-used elliptic curves, etc.) actually add much security, or if they're window dressing.
r1ch 5y ago
Well this is downright scary. Homebrew crypto implementations, what could go wrong... I expect we'll see an exploit to log in with any password soon enough :).
- cyounkins 5y ago
  It's "nearly identical" to an IEEE submission draft by a world renown cryptographer. While there could still be implementation issues, this isn't homebrew crypto.
pabs3 5y ago
Anyone know what software/OS Mikrotik devices run?
- smcleod 5y ago
  RouterOS - https://mikrotik.com/software https://mikrotik.com/software
  - nbernard 5y ago
    Which is Linux based, yet Mikrotik seems somewhat reluctant to honor the spirit of the GPL... https://forum.mikrotik.com/viewtopic.php?t=100803 https://forum.mikrotik.com/viewtopic.php?t=100803 https://github.com/robimarko/routeros-GPL https://github.com/robimarko/routeros-GPL
    - usr1106 5y ago
      Can you explain "somewhat" reluctant? The forum seems to suggest you write an email to support. If that works (I haven't tried) it's not too bad. You have to register at many vendor sites to download something. You also give a github link, but that's shared probably just same random github user, not by Microtik so there is even less evidence that it's complete.and correct.
    - pabs3 5y ago
      That post was a long time ago, have they improved on that front?
radicaldreamer 5y ago
Amazing work and another warning that Microtik remains subpar when it comes to security and doubly worrying because their strategy seems obfuscation rather than engaging the community. It’s a shame because their hardware seems great for the price point (especially their point to point mmWave gear)
- cyounkins 5y ago
  There doesn't seem to be any security issue here, other than an undocumented protocol.
  - yardstick 5y ago
    MAC-then-Encrypt is used, should be Encrypt-then-MAC.
- yabones 5y ago
  That's been my experience as well. Fantastic hardware value, but not great software. And not just "insecure" libraries etc, just... strange design decisions. For example, SwitchOS doesn't allow configuration of a default gateway on the management interface, instead it just returns the request on whatever interface/vlan it gets it from. It leads to some very very strange behaviour when setting up firewall rules... It's a shame, because the hardware is absolutely brilliant. I just wish they would open enough of their bootloader/hardware platform to allow 3rd party firmware to run easily.
  - jareds 5y ago
    What would a basic home Wi-Fi network with two access points, a router, and a switch look like? I attempted to figure this out since I wanted to set up a network with multiple VLANs to separate work machines, IOT devices, and trusted devices once I started working remote. I couldn't figure it out so just bought Ubiquity gear. They were the sweet spot for configurability with out spending weeks learning how to configure network equipment as far as I could tell.
    - 5y ago
mdb31 5y ago
Oh, this is long-awaited, if it works. For context: Mikrotik uses some (semi-)proprietary, but pretty nifty protocols to manage their gear. One of these protocols, MAC-telnet, has been reverse-engineered pretty extensively previously. But, due to a (not unreasonable) security-related upgrade, the login phase was changed, and 3rd-party implementations stopped working. Mikrotik has refused repeated requests to document this protocol. The linked repository looks like it may re-enable MAC-telnet logins, which would be great for 3rd-party scripts and management solutions. (Why? Because it allows you to connect to, and properly provision, any Mikrotik gear using your own scripts, just based on Layer-2 presence. This is very cool for many use cases...)
- stingraycharles 5y ago
  So you can still connect to a device if it doesn’t have an IP? That’s pretty cool. Then out of curiosity, do I understand correctly that these types of packets are bridged, not routed, and as such doesn’t work if you’re not in the same subnet?
  - w7 5y ago
    Correct. You can't use these protocols outside of the same broadcast segment[0]. That segment can be stretched though with some frame encapsulation protocol like VXLAN or VPNs with bridged TAP devices. [0] Broadcast segment would be the more accurate term here, given that subnet generally refers to layer 3 addressing mechanics. Technically a broadcast segment can contain more than one operational IP subnet, but this is uncommon on most user networks.
    - swinglock 5y ago
      The accurate term is "broadcast domain" or "Ethernet segment".
      - w7 5y ago
        Haha, whoops I mashed the two together. Similar to one of those moments when one speaks and swaps the first letters of two words.
cryptojournal 5y ago
Amazing one!
squarefoot 5y ago
The article does not explain enough the implications for us mere mortals without high math/security knowledge. I think many people owning a Mikrotik device would want to know if: 1 - To what extent this makes Mikrotik hardware less secure? -> solutions? 2 - Does this make easier to flash open 3rd party Linux/BSD/whatever based firmware on said devices? -> suggestions?
- withzombies 5y ago
  It re-enables third-party scripts that were disabled when mikrotik updated the authentication algorithm with routerOS 6.45.1 (August 2019). A1. From a cryptography perspective it's a little bonkers but nothing is glaringly wrong. A2. This doesn't relate to any secure boot chains (if they exist -- i don't think they do)

180 points by aaronsdevera 5y ago

I'm confused on why this is needed. I have a couple MikroTik devices and I just use SSH to login to them. I also have automation that runs via SSH to update things on the devices.

mongol 5y ago
Someone else in this thread mentioned it was used to login with Level 2 access. I.e with Ethernet MAC address?
dboreham 5y ago
When you screw up and delete the ip address from a remote router it will come in handy.
- dicknuckle 5y ago
  When that device is hundreds of miles away, it's double handy.

PragmaticPulp 5y ago

> The single best resource we used in reverse engineering was an unfinished IEEE submission draft courtesy of the WayBack Machine. In fact, MikroTik's implementation is nearly identical to the draft's proposed protocol. See if you can spot the minor nuances and marvel (as we did) that the shared secret remains the same. That's a surprising twist. They duplicated the protocol from this unfinished draft almost exactly, but the draft doesn't appear to have gone anywhere (hence the archive link) I wonder if the same person who wrote the paper consulted on this implementation, or if the MikroTik team just saw the paper at some point and decided to use it.

wiml 5y ago
There are a surprising number of internet-drafts that died before reaching RFC status but nevertheless were implemented, even became widely implemented standards. The sftp protocol ("filexfer" over ssh) is one example. Does anyone know why this is? I've never been closely involved in the RFC process; is there some hard-to-clear hurdle at the end of it?
- Kadin 5y ago
  The draft standard was an IEEE proposal, not an IETF one (RFCs are specific to the IETF standardization process), but it seems like the author was pretty familiar with the IEEE process and is involved with that organization. Maybe it was just a solution looking for a problem at the time of its proposal? Honestly, I'm not sure exactly whether the exotic encryption choices (strange, little-used elliptic curves, etc.) actually add much security, or if they're window dressing.

r1ch 5y ago

Well this is downright scary. Homebrew crypto implementations, what could go wrong... I expect we'll see an exploit to log in with any password soon enough :).

cyounkins 5y ago
It's "nearly identical" to an IEEE submission draft by a world renown cryptographer. While there could still be implementation issues, this isn't homebrew crypto.

pabs3 5y ago

Anyone know what software/OS Mikrotik devices run?

smcleod 5y ago
RouterOS - https://mikrotik.com/software https://mikrotik.com/software
- nbernard 5y ago
  Which is Linux based, yet Mikrotik seems somewhat reluctant to honor the spirit of the GPL... https://forum.mikrotik.com/viewtopic.php?t=100803 https://forum.mikrotik.com/viewtopic.php?t=100803 https://github.com/robimarko/routeros-GPL https://github.com/robimarko/routeros-GPL
  - usr1106 5y ago
    Can you explain "somewhat" reluctant? The forum seems to suggest you write an email to support. If that works (I haven't tried) it's not too bad. You have to register at many vendor sites to download something. You also give a github link, but that's shared probably just same random github user, not by Microtik so there is even less evidence that it's complete.and correct.
  - pabs3 5y ago
    That post was a long time ago, have they improved on that front?

radicaldreamer 5y ago

Amazing work and another warning that Microtik remains subpar when it comes to security and doubly worrying because their strategy seems obfuscation rather than engaging the community. It’s a shame because their hardware seems great for the price point (especially their point to point mmWave gear)

cyounkins 5y ago
There doesn't seem to be any security issue here, other than an undocumented protocol.
- yardstick 5y ago
  MAC-then-Encrypt is used, should be Encrypt-then-MAC.
yabones 5y ago
That's been my experience as well. Fantastic hardware value, but not great software. And not just "insecure" libraries etc, just... strange design decisions. For example, SwitchOS doesn't allow configuration of a default gateway on the management interface, instead it just returns the request on whatever interface/vlan it gets it from. It leads to some very very strange behaviour when setting up firewall rules... It's a shame, because the hardware is absolutely brilliant. I just wish they would open enough of their bootloader/hardware platform to allow 3rd party firmware to run easily.
- jareds 5y ago
  What would a basic home Wi-Fi network with two access points, a router, and a switch look like? I attempted to figure this out since I wanted to set up a network with multiple VLANs to separate work machines, IOT devices, and trusted devices once I started working remote. I couldn't figure it out so just bought Ubiquity gear. They were the sweet spot for configurability with out spending weeks learning how to configure network equipment as far as I could tell.
  - 5y ago

mdb31 5y ago

Oh, this is long-awaited, if it works. For context: Mikrotik uses some (semi-)proprietary, but pretty nifty protocols to manage their gear. One of these protocols, MAC-telnet, has been reverse-engineered pretty extensively previously. But, due to a (not unreasonable) security-related upgrade, the login phase was changed, and 3rd-party implementations stopped working. Mikrotik has refused repeated requests to document this protocol. The linked repository looks like it may re-enable MAC-telnet logins, which would be great for 3rd-party scripts and management solutions. (Why? Because it allows you to connect to, and properly provision, any Mikrotik gear using your own scripts, just based on Layer-2 presence. This is very cool for many use cases...)

stingraycharles 5y ago
So you can still connect to a device if it doesn’t have an IP? That’s pretty cool. Then out of curiosity, do I understand correctly that these types of packets are bridged, not routed, and as such doesn’t work if you’re not in the same subnet?
- w7 5y ago
  Correct. You can't use these protocols outside of the same broadcast segment[0]. That segment can be stretched though with some frame encapsulation protocol like VXLAN or VPNs with bridged TAP devices. [0] Broadcast segment would be the more accurate term here, given that subnet generally refers to layer 3 addressing mechanics. Technically a broadcast segment can contain more than one operational IP subnet, but this is uncommon on most user networks.
  - swinglock 5y ago
    The accurate term is "broadcast domain" or "Ethernet segment".
    - w7 5y ago
      Haha, whoops I mashed the two together. Similar to one of those moments when one speaks and swaps the first letters of two words.

cryptojournal 5y ago

Amazing one!

squarefoot 5y ago

The article does not explain enough the implications for us mere mortals without high math/security knowledge. I think many people owning a Mikrotik device would want to know if: 1 - To what extent this makes Mikrotik hardware less secure? -> solutions? 2 - Does this make easier to flash open 3rd party Linux/BSD/whatever based firmware on said devices? -> suggestions?

withzombies 5y ago
It re-enables third-party scripts that were disabled when mikrotik updated the authentication algorithm with routerOS 6.45.1 (August 2019). A1. From a cryptography perspective it's a little bonkers but nothing is glaringly wrong. A2. This doesn't relate to any secure boot chains (if they exist -- i don't think they do)