CVE-2023-30799

Короче говоря, администратор RouterOS с полными правами уже может делать в RouterOS всё и полностью контролировать всю конфигурацию, но не должен иметь возможность запускать чужой код или подсовывать другие файлы в подсистему RouterOS. Немного упрощённое утверждение в конце. Кто-то может получить доступ к устройству под админом и изменить любую конфигурацию. Чаще всего такие взломщики не будут нажимать «/system/reset-configuration». Скорее, они откроют какие-то порты или включат сервисы, чтобы дальше проникнуть в сеть. Но я всё равно смогу проверить или отследить изменения с помощью «/export» или «/export verbose». Сделать diff и сразу увидеть, что изменилось. Это можно автоматизировать. Но если кто-то получит доступ к настоящему root-shell и загрузит туда любой возможный бинарник, добавит его в init-скрипт, чтобы он запускался при загрузке, или начнёт изменять конфигурацию на самом уровне ОС — этого не увидишь в выводе «/export verbose». Никто этого не заметит и заметить не сможет. В таких случаях просто можно будет сделать netinstall устройства, если, например, видишь признаки подозрительных логинов с необычных источников/IP или в необычное время. В общем, проблема с очень низким уровнем риска. Но как сотрудник Mikrotik, тебе не стоит недооценивать этот момент.

Вы также могли бы просто согласиться и предоставить пользователям возможность получить Linux-оболочку, конечно же, защищённую флагом в device-mode и предупреждением, что роутеры с этим включённым не могут поддерживаться через обычные каналы. Это, вероятно, положило бы конец постоянным поискам «уязвимостей» для получения такого доступа. А видимость этой возможности (в export и device-mode) также повысила бы осведомлённость.

Не могли бы вы добавить в RouterOS функцию, которая проверяла бы, что подсистема не была взломана? Например, если произошёл взлом, но у меня всё ещё есть удалённый доступ, и я меняю креденшелы и обновляю систему, у меня была бы возможность избежать отправки техников для замены или чистой установки оборудования.