add mikrotik CVE-2026-67279 pre-auth rekey session check

[msuiche]

Summary

Adds vuln-mikrotik-preauth-rekey: a fully unauthenticated check for CVE-2026-67279 (MikroTrick rekey bug), complementing the existing CVE-2026-67276 pubkey check from #main.

RouterOS loses track of the incomplete userauth state when the client requests a key re-exchange before authenticating, and then accepts connection-protocol messages anyway. An unauthenticated client can open a session channel without any credentials. Fixed in RouterOS 7.24.2 / 7.23.4 / 6.49.21.

This closes a detection gap: the existing vuln-mikrotik-pubkey-bypass check needs the victim's authorized public key (--mikrotik-pubkey), while this check needs nothing but network access to the SSH service.

How it works

1. Complete the initial key exchange
2. Request a client-initiated rekey while still unauthenticated (new excrypto API, see dependency below)
3. Skip the userauth service entirely and open a session channel — a vulnerable RouterOS accepts it
4. Run /system resource print as a read-only proof/fingerprint

Two guards keep the report precise:

• Negative control: the same pre-auth channel open without the rekey must be refused; if it also succeeds, the server accepts pre-auth sessions generally (a different defect, e.g. vuln-exec-skip-userauth) and we do not report CVE-2026-67279
• RouterOS attribution: the server banner (SSH-2.0-ROSSSH) or the proof output must identify RouterOS before the CVE is named

Dependency

Requires (*ssh.UnauthClientConn).RequestKeyExchange() from runZeroInc/excrypto#89. go.mod temporarily replaces excrypto with the fork branch so this builds; it should be bumped to a tagged excrypto release once that PR lands.

Testing

• Positive (live): vulnerable CHR 7.24.1 VM — detected, control pass refused as expected:

  level=warning msg="127.0.0.1:2222 vuln-mikrotik-preauth-rekey opened a session WITHOUT authentication via pre-auth rekey"
  

  Proof: CVE-2026-67279: session channel opened without authentication after a client-requested pre-auth rekey (server: SSH-2.0-ROSSSH; control without rekey was refused)
• Negative (live): compliant Go sshd — rekey completes, pre-auth channel open rejected (ssh: no auth passed yet), nothing reported
• Unit tests for the RouterOS attribution/version helpers; full go test ./... passes

Refs:

• https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
• https://blog.tolmo.com/p/pre-auth-rce-on-mikrotik-exploited

[hdm]

time="2026-09-07 14:42:01" level=warning msg="192.168.0.30:22 vuln-mikrotik-preauth-rekey opened a session WITHOUT authentication via pre-auth rekey"

[msuiche]

To clarify what this check sits in front of (the two MikroTrick paths are independent):

Path A (this check's CVE + the privesc): CVE-2026-67279 alone is almost a dud — the pre-auth session channel opens, but the login helper runs with no valid identity (bare sessions get Login failed, incorrect username or policy). It becomes the in-the-wild unauthenticated RCE only when combined with CVE-2026-86060: a rejected auth attempt as username -2 leaves that username pending in server state; after the pre-auth rekey, the session's login helper runs as -2 and reads its trusted (name, policy-mask) fields from the PTY — attacker supplies policy 0x9fe6e = full admin. So yes: pre-auth session + that "LPE" ≈ the useful remote SSH exploit. One nuance on the -2 username: standalone, 86060 needs SSH to accept a literal -2 user (e.g. external AAA/RADIUS, since RouterOS refuses to create such a local user) — but the pending-username state after a rejected attempt removes that requirement entirely; no special config needed.

Path B (the RSA e=1 thing, CVE-2026-67276): a parallel, independent auth bypass — needs knowledge of a victim's authorized public key (modulus), gets you that account's privileges directly. Already covered by vuln-mikrotik-pubkey-bypass.

Why detecting 67279 alone is the right scope: both halves of Path A were fixed in the same releases (7.24.2 / 7.23.4 / 6.49.21), so "67279 present" ⟺ "full unauth chain present". This check intentionally stops at proving the pre-auth channel opens (with the no-rekey control refused) — the 86060 escalation isn't needed for detection and stays out of scanner code.