Compatibility with RouterOS 6.43

[eworm-de]

Starting with RouterOS 6.43rc17 the protocol changed. This is the relevant changelog entry:

*) mac-telnet - require at least v6.43 MAC Telnet client when connecting to v6.43 or later version server;

Please update the wire protocol to support latest RouterOS.

[MnrikSrins]

@jacob-baines did you modify your donna curve implementation for the script you posted in: #42 (comment) ? I am trying to replicate your results in C++ to validate the curve equation and I'm computing a different public key using your pasted script and curve25519-donna.cpp from your RouterOS repo. The SHA hashes are the same, so the only thing I can think of is a different implementation of the elliptic curve.

edit - for reference:

SHA(user:pass):
7b 43 17 60 ce 6a 2b 17 84 e3 14 2c 95 c8 da 2e 12 30 d4 90 42 80 6b ce 44 18 60 a5 30 95 7f f7
SHA(salt, SHA(user:pass)):
1e 9f d0 96 f3 e6 19 86 23 22 88 ac 95 c7 f1 fe 91 e4 ed fb 6f 36 1e a1 7c 4e 31 58 d2 9e da 10
user.dat public key:
4f 5e c3 c2 b1 df 38 e0 19 11 b5 82 9b e7 57 34 98 f9 30 88 a0 91 b0 1a e2 21 5f 1a 83 df 3e 72

According to my attempts, I am using 1e 9f d0 96 f3 e6 19 86 23 22 88 ac 95 c7 f1 fe 91 e4 ed fb 6f 36 1e a1 7c 4e 31 58 d2 9e da 10As a private key, the results obtained in curve25519-donna.cpp and curve25519.js are both 4f 5e c3 c2 b1 df 38 e0 19 11 b5 82 9b e7 57 34 98 f9 30 88 a0 91 b0 1a e2 21 5f 1a 83 df 3e 72 But when I was debugging libnative.so of the Mikrotik Android APP, I changed the privkey in WCurve::mul((WCurve *)bignum, (const BigNum *)&a1->privkey, (const WCurve::Point *)v8, (WCurve: :Point *)v9);When the corresponding private key memory is modified to 1e9f..., the result is 2B CC 0F 24 1C 69 D3 C3 C6 DD 85 79 38 58 EC 1B D1 13 8D C7 55 61 46 4B 1B 22 B7 DE A5 F2 EA F3 It is consistent with the result of @jacob-baines. This is the point that bothers me and I cannot explain it. Is the implementation of curve25519 in libnative.so different?

SHA(user:pass):
7b 43 17 60 ce 6a 2b 17 84 e3 14 2c 95 c8 da 2e 12 30 d4 90 42 80 6b ce 44 18 60 a5 30 95 7f f7 
SHA(salt, SHA(user:pass)):
1e 9f d0 96 f3 e6 19 86 23 22 88 ac 95 c7 f1 fe 91 e4 ed fb 6f 36 1e a1 7c 4e 31 58 d2 9e da 10 
user.dat public key:
4f 5e c3 c2 b1 df 38 e0 19 11 b5 82 9b e7 57 34 98 f9 30 88 a0 91 b0 1a e2 21 5f 1a 83 df 3e 72

function hexToBytes(hex) {
    for (var bytes = [], c = 0; c < hex.length; c += 2)
        bytes.push(parseInt(hex.substr(c, 2), 16));
    return bytes;
}

// Convert a byte array to a hex string
function bytesToHex(bytes) {
    for (var hex = [], i = 0; i < bytes.length; i++) {
        var current = bytes[i] < 0 ? bytes[i] + 256 : bytes[i];
        hex.push((current >>> 4).toString(16));
        hex.push((current & 0xF).toString(16));
    }
    return hex.join("");
}
var key = [];
key = hexToBytes("1e9fd096f3e61986232288ac95c7f1fe91e4edfb6f361ea17c4e3158d29eda10")
console.log(bytesToHex(key))

var pubKey = curve_u2a(curve25519(curve_a2u(key)));
console.log(bytesToHex(pubKey));

[comed-ian]

Hello all - excited to share an update on this effort. I just published a blog post and proof of concept programs that successfully authenticate with new MAC Telnet and Winbox versions. I wrote the POCs in Python, so apologies that it is not immediately portable to those who wrote their tooling in C, C++, etc. I'm a reverse engineer and not a developer, but happy to contribute knowledge and effort to fixing broken tools.

The protocol is EC-SRP5 (as we already knew), and is nearly identical to the link that @m0sia posted earlier. The issue is that RouterOS multiplies the private key over the Weierstrass 25519 curve and converts the resulting x coordinate to Montgomery form, returning that value as the public key. That nuanced difference is the reason that @MnrikSrins and I could not replicate the public key in user.dat. There are some other very interesting quirks about the protocol that I am happy to elaborate upon if anyone is interested.

Hope this is a big step in the direction of closing this issue and repairing our broken MikroTik tooling! Cheers!

[BrainSlayer]

Hello all - excited to share an update on this effort. I just published a blog post and proof of concept programs that successfully authenticate with new MAC Telnet and Winbox versions. I wrote the POCs in Python, so apologies that it is not immediately portable to those who wrote their tooling in C, C++, etc. I'm a reverse engineer and not a developer, but happy to contribute knowledge and effort to fixing broken tools.

The protocol is EC-SRP5 (as we already knew), and is nearly identical to the link that @m0sia posted earlier. The issue is that RouterOS multiplies the private key over the Weierstrass 25519 curve and converts the resulting x coordinate to Montgomery form, returning that value as the public key. That nuanced difference is the reason that @MnrikSrins and I could not replicate the public key in user.dat. There are some other very interesting quirks about the protocol that I am happy to elaborate upon if anyone is interested.

Hope this is a big step in the direction of closing this issue and repairing our broken MikroTik tooling! Cheers!

shit that i'm a absolute noob in python. otherwise i would be able to integrate it

[kmeaw]

Thank you, @comed-ian. I have re-implemented your PoC programs in C.

[haakonnessjoen]

Thank you, @comed-ian. I have re-implemented your PoC programs in C.

Do you have it publicly? So that we could look at implementing it in this codebase? Or do you want to fix it and do a pull request? 😅

[kmeaw]

I have fixed it in pull-request #76.

[BrainSlayer]

@kmeaw that are great news. thank you

[eworm-de]

Thanks a lot to anybody involved to solve this!

[ruheight]

@jacob-baines did you modify your donna curve implementation for the script you posted in: #42 (comment) ?

just in case somebody would look through this thread, just remove // e[0] &= 248; // e[31] &= 127; // e[31] |= 64; in curve donna, btw, it could be an security issue for mikrotik, due to small subgroup attack