Allow scanning of IoC inside events.

• IoC configuration file (not to depend of any IoC provider)

Evaluate if replacing FdMap (heavy solution) could be replaced by task_struct's fd lookup.

Mount event stopped working on 6.6 and needs to be done from scratch to track fsmount syscall.
Initially mount event was introduced, because implementation was already made, so it was zero cost.
The benefit of this event is very limited, as I don't see what real value it brings in terms of security/threat monitoring.
On the other hand it seems this event would need several probes and maybe events to handle all the possible cases and being cross-kernel compatible.
Making the cost/benefit ratio of keeping supporting this event (in a cross-kernel fashion) seems pretty high, so it has been decided to remove it completely from next release (i.e. v0.2.0)

Hello,

While building a docker container I get the following errors:

[2023-12-06T12:59:30Z ERROR kunai] failed to retrieve bpf_prog instructions: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })
[2023-12-06T12:59:30Z ERROR kunai] failed to retrieve bpf_prog instructions: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })
[2023-12-06T12:59:46Z ERROR kunai] failed to retrieve bpf_prog instructions: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })
[2023-12-06T12:59:46Z ERROR kunai] failed to retrieve bpf_prog instructions: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })

Using the latest binary (v0.1.0).

What might be the reason?

clone/fork events might be useful for some scenario

example: bpfdoor is forking and terminates the main thread.

Without generating fork event we might think the process is terminated while it is not

Hook points:

• kernels [5.4; 5.9] : https://elixir.bootlin.com/linux/v5.4/source/kernel/fork.c#L2339
• kernels ]5.9; latest] : https://elixir.bootlin.com/linux/v6.5/C/ident/kernel_clone

uname: 5.4.0-170-generic #188-Ubuntu SMP Wed Jan 10 09:51:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

probes::send_data line=19 tgid=659 comm=snapd BufferError: unimplemented iter

Some features aren't working on aarch64

Linux version
Linux debian 6.1.0-22-arm64 #1 SMP Debian 6.1.94-1 (2024-06-21) aarch64 GNU/Linux

Some stats on the error log file (running for a few hours)
cat error.log | cut -d " " -f 4 | sort | uniq -c

    280 probes::clone
    159 probes::connect
    192 probes::execve
16407863 probes::fs
   3613 probes::send_data
... [other errors]

Generate an event when kunai get stopped

current clone probe can be simplified by hooking https://elixir.bootlin.com/linux/v6.6.14/C/ident/security_task_alloc

Hello,

Getting the following errors:

[2023-12-05T19:36:26Z ERROR kunai_ebpf::probes::schedule] failed to read argv
[2023-12-05T19:36:26Z ERROR kunai_ebpf::probes::schedule] failed to read argv
[2023-12-05T19:36:26Z ERROR kunai_ebpf::probes::schedule] failed to read argv

Using the latest binary (v0.1.0).

What might be the reason?

Lots of changes happened in Aya and kunai need to be updated accordingly:

• fix for bpf_probe_read_user_str_bytes helper of empty strings
• fix to be compatible with rust nightly

An upgrade attempt has been made but an issue was encountered: aya-rs/aya#808

• Kernel Version
• Interfaces
• Ip Addresses
• Modules

In .info.host section, put a machine UUID in case the hostname changes.

• use a derive of /etc/machine-id
• make it configurable in config file

The following happens because the file executed got deleted before the userland program could retrieve its hash.
Currently an error message is reported. Either make the error message more explicit or generate an event when such a case happens.

Example:

  "data": {
    "ancestors": "/usr/lib/systemd/systemd|/usr/sbin/sshd|/usr/sbin/sshd|/usr/sbin/sshd|/usr/bin/bash|/usr/bin/sudo|/usr/bin/su|/usr/bin/bash|/tmp/bpfdoor.mwr|/usr/bin/dash",
    "parent_exe": "/usr/bin/dash",
    "command_line": "/dev/shm/kdmtmpflush --init",
    "exe": {
      "file": "/dev/shm/kdmtmpflush",
      "md5": "",
      "sha1": "",
      "sha256": "",
      "sha512": "",
      "size": 0,
      "error": "hash not found"
    },
    "interpreter": {
      "file": "/dev/shm/kdmtmpflush",
      "md5": "",
      "sha1": "",
      "sha256": "",
      "sha512": "",
      "size": 0,
      "error": "hash not found"
    }
  }

Form #PTS2024:

• Make ICO severity configurable.
• Default to the feed's severity?
• Don't default to 10? :D

When parent_exe is the kernel, the field value is currently ?, this must be changed to another value.
One can identify whether parent task is KTHREAD

{
  "data": {
    "ancestors": "?|?|?",
    "parent_exe": "?",
    "command_line": "/sbin/modprobe -q -- net-pf-10",
    "exe": {
      "file": "/usr/bin/kmod",
      "md5": "b14b91a0bb23dc63c89adb1e0da886b4",
      "sha1": "3482856787ce9b659039092bdfb06fa65775e8a6",
      "sha256": "4c756856466594ba8be8af34ad827e546a966e9392404be89e11ad5efa525afe",
      "sha512": "01bfc892c6f863523385f9edd10aac2de59bd918d0c9cefdc364052b57dcc8f40018172a18ea4ff0614fc3aab378f750bd090d46f4c2efbd2a37c9405050f8af",
      "size": 166008
    }
  },
  "info": {
    "host": {
      "hostname": "whiterose",
      "container": null
    },
    "event": {
      "source": "kunai",
      "id": 1,
      "name": "execve",
      "uuid": "6b19e669-ecc2-4aab-fba4-b57d73a82ec9",
      "batch": 14
    },
    "task": {
      "name": "modprobe",
      "pid": 72088,
      "tgid": 72088,
      "guuid": "6de76f27-4312-0000-0d52-d89898190100",
      "uid": 0,
      "gid": 0,
      "namespaces": {
        "mnt": 4026531841
      },
      "flags": "0x400000"
    },
    "parent_task": {
      "name": "kworker/u16:1",
      "pid": 55275,
      "tgid": 55275,
      "guuid": "0606a127-630e-0000-0d52-d898ebd70000",
      "uid": 0,
      "gid": 0,
      "namespaces": {
        "mnt": 4026531841
      },
      "flags": "0x4208060"
    },
    "utc_time": "2024-01-03T15:24:24.250472947Z"
  }
}

Hooking connect syscall misses call to socketcall syscall
For a more robust approach _sys_connect must be hooked

cc: @blightzero

In latest LTS a bug shown up and raised the following error: failed to resolve exe: failed to read dentry ctime

Root cause: between kernel 6.5 and 6.6 struct inode changed. More specifically, the ctime field got renamed to __ctime which brakes the shim currently in place. This needs to be fixed at shim level.

Ancestors is a way to bring context to every event, as it allows to track where the event comes from. It is sometimes the only way to identify whether a specific event is suspicious or not.
So it would be really nice to have this field in every event.

Hello,

For execve events, the data.exe field is an object. For events like read_config and file_unlink, the data.exe field is a string.

To ease data ingestion it could make sense to use the same data type for a specific field name.

So far hostname correlation works only a per process basis.
That means that if process A resolves test.com only IPs matching this hostname in this process will be correlated back.
We could extend the resolution table to also work on a system basis, while keeping the per process resolution table.
The system resolution table would be used only as a fallback.

When using kunai to monitor Kubernetes containers @blightzero reported that lots of error messages regarding cgroups gets generated.
This is very likely a bug !

ERROR kunai_ebpf::probes::clone] failed to resolve cgroup: failed appending to path
ERROR kunai_ebpf::probes::execve] failed to resolve cgroup: failed appending to path
ERROR kunai_ebpf::probes::schedule] CgroupError

Setup: Kernel 6.1.0 from Debian backports

send_data probe seems not to work on debian 12 (bookworm)

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm

Kernel: 6.1.0-21-amd64

bpfdoor malware uses setsockopt to load BPF packet filters

Kernel functions:

• https://elixir.bootlin.com/linux/latest/C/ident/sk_attach_filter
• https://elixir.bootlin.com/linux/latest/C/ident/reuseport_attach_prog

Socket filter attached has been addressed in #3, however there are other ways to attach BPFs program to socket.

• https://elixir.bootlin.com/linux/v5.4/C/ident/sk_attach_bpf
• https://elixir.bootlin.com/linux/v5.4/C/ident/sk_reuseport_attach_bpf

Both the API use the already hooked functions __sk_attach_prog and reusedport_attach_prog so it should be a special case to handle in handle_socket_attach_prog function.

For the moment a warning is displayed when a BPF program gets attached to a socket !

NB: as I understand the kernel code, the BPF program first needs to be loaded before being attached. So it is likely we would see a bpf_prog_load event prior to attach event.

cc: @davidszili @xme

Kunai suffers from an issue with kretprobes not working after a cycle of suspend/resume.
After investigation, this bug is not related to Kunai itself nor Aya. After some discussion with Aya folks we concluded that it is very likely a Linux kernel bug. A issue has been created to track down this bug: https://bugzilla.kernel.org/show_bug.cgi?id=218775
Even though the bug, very likely happen in the kernel, we can find a way to fix it in Kunai by reloading programs when system resumes.
This can be achieved by attaching a kprobe to syscore_resume function.

Everything is ready so that it works.

Rarely an error appears in prctl probe, mostly when spinning a new docker container.

2024-01-29T15:06:55Z ERROR kunai_ebpf::probes::prctl] line:44 BpfMapError

Guessed root cause: the LruHashmap was not explicitely cleaned up and I think this may be an issue when entries arrive too quickly (i.e. some relevant entries are overwritten because the LruHashmap cannot know which one to remove better than us). After testing with explicit map cleanup, the error does not show up anymore.

It is not obvious to detect zombie processes for the time being, find a smart way to do this.

Sometimes when docker containers get started this error pops up

[2024-01-29T11:10:26Z ERROR kunai_ebpf::probes::clone] line:11 EventError

after a successful build, I can't find the executable

root@deb12:/kunai# pwd
/root/kunai
root@deb12:/kunai# find . -iname "kunai*" -type f
root@deb12:~/kunai#

send_data probe returns ERROR kunai_ebpf::probes::send_data] BufferError

This is caused because iov member of struct iov_iter got renamed to __iov.
Shim needs to be fixed accordingly

• switch the display of some errors to warnings
• define own way to transmit errors to userland (do not rely on aya log anymore)

After fixing #25, we realize that entropy value is always 0.
It seems there is an issue while reading the iovec structure.

https://github.com/corelight/community-id-spec

Some members of inode structure (atime and mtime) used by Kunai changed names and causes error on kernels >= 6.7

• i_atime -> __i_atime
• i_mtime -> __i_mtime

https://elixir.bootlin.com/linux/v6.7/source/include/linux/fs.h#L639

Hello,

Getting the following errors:

[2023-12-05T18:49:47Z ERROR kunai_ebpf::probes::dns] KProbeCtxRestoreFailure
[2023-12-05T19:01:47Z ERROR kunai_ebpf::probes::dns] KProbeCtxRestoreFailure
[2023-12-05T19:13:47Z ERROR kunai_ebpf::probes::dns] KProbeCtxRestoreFailure

Using the latest binary (v0.1.0).

What might be the reason?

There is a bug in schedule probe when arg_end is 0

[2024-01-29T12:57:04Z ERROR kunai_ebpf::probes::schedule] failed to read argv: arg_start=7fffe6a38f95 arg_end=0 arg_len=18446603336646684779

Root cause: mm_struct.arg_len() does not handle the case where arg_end == 0
Similar implementation: https://elixir.bootlin.com/linux/v6.6.13/source/fs/proc/base.c#L256

It is currently possible to monitor Write events, however such events may be too many for some systems (servers for instance).
In order to reduce the amount of Write events, one idea would be to catch only writes at a given position (within 1024 first bytes for instance).

1. try to find if it is really making sense ?
2. if it can be implement in Write events or if it needs a new event being created ?

some malware (such as bpfdoor) are modifying their task name to hide.
An event could be generated whenever this happens.

So far it is not very clear when an event comes from a container or not.
As the notion of container is a completely abstract notion built around Linux namespaces, we could consider (in kunai) a container is a process having a different mount namespace from the kunai process.

Generate event when a file gets deleted

Hook do_unlinkat [5.4; latest] : https://elixir.bootlin.com/linux/v5.4/source/fs/namei.c#L4018

Following fix #38 clone event present wrong data in .info.task, it presents information about the thread before being completely forked/cloned. As a result, we lose information some information about new threads.

Such a rule generates errors when trying to match

name: docker
params:
    filter: true
match-on:
    events:
        # match any event
        kunai: []
matches:
    $docker: .info.host.container.type == 'docker'
condition: $docker

Issue: .info.host.container may be null and the event matching engine consider it as an error as it cannot find the field type within container object. This is a wanted behavior to show people when they do mistake in their rules.

Hooking on sock_sendmsg seems not working anymore (at least on my Kernel)
A working alternative is to hook on security_socket_sendmsg available since 5.4