wip: new(rules): introduce rule to detect drop and execute pattern in containers

[loresuso]

Signed-off-by: Lorenzo Susini [email protected]

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind release

If contributing rules or changes to rules, please make sure to also uncomment one of the following line:

/kind rule-update

/kind rule-create

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area engine

/area rules

/area tests

/area proposals

/area CI

What this PR does / why we need it:
This PR introduces detection for the drop and execute pattern in containers. It uses the new field proc.is_exe_upper_layer.
Currently on wip to wait for libs version bumping.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

[poiana]

@loresuso: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: loresuso
Once this PR has been reviewed and has the lgtm label, please assign mstemm for approval by writing /assign @mstemm in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[loresuso]

cc @incertum

[incertum]

Yay the rule is up ❤️ ! Thanks for opening this @loresuso ! This is a very impactful, much needed more generic / behavioral detection to cover a variety of file based RCE kind of threats. In addition, this rule is not easily circumvented as strict fileless / memory based attacks are more difficult to pull off.

Highly recommend:

• end users may appreciate more information in desc, e.g. "is_exe_upper_layer filter field only applies for container runtimes with overlayfs configured" or similar (btw the existing description is nicely written and concise)
• consider adding %evt.arg.flags to output fields, so all execve flags including EXE_WRITABLE (cc @LucaGuerra) are available
• consider adding %proc.name %proc.sname %proc.pname %proc.aname[2] to output fields
• tags: would see mitre_execution more fitting, but obviously a random new implant that is being executed can accomplish anything ...
• shorten rule name "Drop and execute of a binary within a container" -> "Drop and execute new binary in container"?

Question:

Sometimes rules of the same evt.type can overshadow each other (first match wins). Is placing this rule at the end desired? Could other rules match before this one, causing possible inconsistencies?

Considerations for later:

Only deployed a rule to prod containing proc.is_exe_upper_layer=true that also included filtering with respect to the time axis (fields introduced here falcosecurity/libs#595, see also our discussion HackMD, falcosecurity/libs#615), so can't tell how noisy the rule as is can become over time.

At the same time it would be challenging to suggest such filters, therefore one option could be to simply add a longer comment section above the rule that outlines some additional tuning options and once those exe ino time related fields are available additional output fields (useful for incident response) could be added to this rule, such as %proc.exe_ino %proc.exe_ino.ctime %proc.exe_ino.mtime %proc.exe_ino.ctime_duration_proc_start %container.start_ts ...

[jasondellaluce]

/milestone 0.34.0

[leogr]

/milestone 0.35.0

[loresuso]

Closing this to reopen it in the brand new falcosecurity/rules! Moving the discussion there soon