🚨🚨🚨 Severe Security Issue: DHCP server scripts and PPP profile scripts, rights escalation.

DHCP server scripts and PPP profile scripts, rights escalation (not tested other points):

One user that have at least the write right,
can add or modify the script inside the DHCP Server or PPP profile for execute any RouterOS command for rights escalation.

/user group
add name=test policy=read,write,winbox
/user
add group=test name=test

Simply /user set test group=full on any script space suffice…

You lost the admin password? (cannot be recovered anyway, you can only change the password)
Your ISP lock your rights?
No problem, on this way you can do all you want, without leave any trace.


Why all that?
Because events use *sys user that is unlimited, have all possible rights
[RexTended@MATRIX] /system script job> pri detail
0 owner=“*sys” policy=*0,local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,tikapp,
*13,*14,*15,*16,*17,*18,*19,*1A,*1B,*1C,*1D,*1E,*1F
started=sep/07/2023 13:26:07 type=command
This is not happen on netwatch because the *sys user used have limited rights:
[RexTended@MATRIX] /system script job> pri detail
0 owner=“*sys” policy=reboot,read,write,test started=sep/07/2023 13:34:29 type=command

Solution:
Remove any access from external users.
MikroTik must add the field for specify what user must be used for launch scripts, on any point is possible add one script.



Probable further vulnerability:
If the user *sys has winbox authorization, someone if they find winbox open (which is wrong) could use the user *sys to access the system…

Tested: The same also on DHCP Client, both IPv4 and IPv6 versions

Do not happen on System Script or Scheduler section (unless the script or scheduler already has those permissions on its own)

Tested: do not happen via ftp upload of filename.auto.rsc

The solution: never ever allow a Muggle touch your network gear. And that includes the patch cord up and including the far end of it.

Indeed.
I’m just warning all those who think that creating an account with less privileges to let someone manage something, are actually giving them the keys to the house…

As well as: using skins thinking that if the sections are hidden they cannot be used… :wink:

Didn’t test, but would seem like act same with netwatch scripts too.

The more basic problem is the policy options are limited. It is actually following the policy (e.g. you can write config via webfig). And someone with “write” can/should already be thought of an administrative account…so “severe” may be an over exaggeration.

But seem like any of the on-script= attributes should require “sensitive” policy (in addition to write) – since often the user script need to “write” things in these various “on-this=” things (so these script likely do actually need to be system/root).

It seems like you didn’t even read what I wrote.

Did you read what I wrote? :wink:. The title indicates it’s a better problem than it is.

FWIW, I’m a believe in responsible disclosure… so reporting to Mikrotik directly and letting them respond first is better practice – but that’s just my opinion…

Too late for that, accidentally, without meaning to, it has already been published and archived by Google,
better to warn everyone (those who read the forum)…
http://forum.mikrotik.com/t/dhcp-client-script-not-working/169281/1