[New Rule] PE via Container Misconfiguration

[Aegrah]

Summary

This rule monitors for the execution of processes that interact with Linux containers through an interactive shell without root permissions. Utilities such as runc and ctr are universal command-line utilities leveraged to interact with containers via root permissions. On systems where the access to these utilities are misconfigured, attackers might be able to create and run a container that mounts the root folder or spawn a privileged container vulnerable to a container escape attack, which might allow them to escalate privileges and gain further access onto the host file system.

Detection

The Docker utility leverages runc and ctr under-the-hood as well, for log writing and other administrative tasks. In order to minimize FPs of runc and ctr spawns by Docker, the and process.interactive == "true" and process.parent.interactive == "true" filter has been added. When docker spawns these processes, they will run in a non-interactive state. This query has 0 hits in RedSector over the last 365 days, while the query without this filter has 8 hits.

process where host.os.type == "linux" and event.action == "exec" and event.type == "start" and (
  (process.name == "runc" and process.args : "run") or
  (process.name == "ctr" and process.args : "run" and process.args : ("--privileged", "--mount"))
) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0" and 
process.interactive == true and process.parent.interactive == true

[brokensound77]

in this case, wouldn't we want to check that user.effective.id != "0" and user.effective.group.id != "0", otherwise sudo perms will FP?

[Aegrah]

@brokensound77 The only pitfall of using user.effective.id here, is that this field is only ingested in Linux through auditbeat, and mostly present in non-interactive process events. I just checked, and in the events from this DR this field does not exist.

This one would work with user.id, process.user.id, process.real_user.id, user.Ext.real.id, user.effective.id, as long as the field would be present. I picked user.Ext.real.id because this field always exists, and to make sure that when a normal user runs sudo, it doesn't FP, because then user.Ext.real.id will never be 0.

[brokensound77]

I guess you are right about the field availability, good call.

[brokensound77]

are these fields dependent on session data? If so, we may want to add it in setup

[Aegrah]

Good call, totally forgot about that. Added a small setup guide to the rule!

[DefSecSentinel]

LGTM