Авторът на хранилището dinosn публикува лабораторен PoC MikroTrick за CVE-2026-67276, който показва заобикаляне на SSH удостоверяването в RouterOS.

Анализът посочва, че RouterOS съпоставя SSH ключа по тип и RSA модул, но не проверява експонентата. Затова за атаката е достатъчен известен публичен модул на жертвата и не е нужен частният ключ.

При лабораторната проверка авторът получи удостоверяване и изпълни команда в RouterOS 7.23.3. RouterOS 7.23.4 отхвърли фалшивия ключ.

Хранилището препоръчва RouterOS да се актуализира до поправената версия. До актуализацията то предлага SSH, WWW и bandwidth-test да се ограничат до доверени мрежи за управление.

Термини:

  • PoC — Proof of Concept, или демонстрация на работоспособност. В сигурността така наричат пример, който показва как може да се възпроизведе уязвимост.
  • RSA модул — Част от публичния RSA ключ. Той се използва при криптографски проверки и обикновено е достъпен заедно с публичния ключ.
  • експонентата — Параметър на RSA ключа, който участва в криптографските изчисления. Той се съхранява заедно с модула в публичния ключ.

Проверка на твърденията:

  • В контекста на инцидента MikroTrick авторът на хранилището dinosn публикува лабораторен PoC за CVE-2026-67276, който показва заобикаляне на SSH удостоверяването в RouterOS. (потвърдено от самата публикация: доказателство; «MikroTrick lab PoC — CVE-2026-67276 (RouterOS SSH public-key auth bypass)»)
  • В хранилището се твърди, че CERT PL на 5 септември 2026 година е разкрил шест активно експлоатирани уязвимости в RouterOS, обединени под името MikroTrick. (потвърдено от самата публикация: доказателство; «CERT PL (2026-09-05) disclosed six RouterOS vulnerabilities, actively exploited in the wild as the chain “MikroTrick” (unauthenticated full device takeover when SSH is internet-reachable).»)
  • Според анализа на PoC при CVE-2026-67276 RouterOS съпоставя SSH ключа по тип и RSA модул, но не проверява експонентата. (потвърдено от самата публикация: доказателство; «RouterOS matches the presented SSH public-key blob against the user’s authorized key by (key type, modulus) — the exponent is not compared.»)
  • PoC използва факта, че проверката на подписа взема ключа, изпратен от клиента: при ключ с експонента e=1 за атаката е достатъчен известен публичен модул на жертвата и не е нужен частният ключ. (потвърдено от самата публикация: доказателство; «Presenting {ssh-rsa, e=1, n=victim} makes sig^1 mod n == sig , so the valid “signature” is simply EMSA-PKCS1-v1_5(hash, authdata) — computable by anyone who knows the victim’s public modulus. No private key needed.»)
  • За възпроизвеждане авторът посочва, че е нужно устройство от засегнатия диапазон, достъпно по SSH, потребителско име и RSA модулът на неговия оторизиран ключ. (потвърдено от самата публикация: доказателство; «Preconditions (the disclosure’s own minimum): target username + that user’s authorized RSA public modulus.»)
  • В посочената лабораторна повторна проверка фалшив ключ с e=1 е дал удостоверяване и изпълнение на команда в RouterOS 7.23.3, а при поправената 7.23.4 е бил отхвърлен. (потвърдено от самата публикация: доказателство; «7.23.3 auth OK auth OK + /system resource print exec — CVE confirmed 7.23.4 (patched) auth OK rejected»)
  • Авторът отделно отбелязва, че в неговия тест RouterOS 6.49.20 е отхвърлила ключ с e=1, затова наблюдаваната уязвимост не е била потвърдена за тази версия, въпреки заявения от CERT диапазон. (потвърдено от самата публикация: доказателство; «Version nuance: on 6.49.20 the server-side match rejects the e=1 blob ( /log ssh,debug: can’t find matching key for user: admin ) — the disclosed exponent-omission was not observable in 6.x’s matcher although CERT’s blanket range lists [6.0.0, 6.49.21) .»)
  • Като незабавна мярка хранилището предлага RouterOS да се актуализира до 7.25beta3, 7.24.2, 7.23.4 или 6.49.21, а до актуализацията достъпът до SSH, WWW и bandwidth-test да се ограничи до доверени мрежи за управление. (потвърдено от самата публикация: доказателство; «Patch immediately: 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21. Interim: restrict SSH/WWW/bandwidth-test to trusted management networks; avoid RouterOS-initiated SSH/TLS from unpatched devices.»)

Първоизточници:

оценка 81.3 · тип incident · ревизия 1 · истории st-xlr7vb