Loop loading kernel module is too obvious

[iusearch]

Hi. By testing the rootkit, I found the current implementation seems to be looping loading the module when persisted using volundr. When it loads successfully it's fine. But when it fails to load, then it spams dmesg. Would it be a good idea to just try load several times and give up to give less trace?

[carloslack]

Hi @iusearch , thanks for reporting that. Would you mind to share steps how you tested and logs, if possible? ty

[carloslack]

Also, what is it when it fails to load? Can you please share the details? One test that can be done is just to not have the module and the infected binary will run insmod and it will fail. I emulated that behaviour and did not see it looping , it just fails. Notice that, depending on the binary you infect, if it is called regularly, it will always try to load the module, but if it fails it should be harmless. What binary you used?

[iusearch]

Sorry it was so busy I almost forgot about that. The issue is with the kernel version mismatch. When the kernel is updated, it will fail to load the module, and spam in dmesg about version mismatch so it's super obvious.

[carloslack]

Hi @iusearch thanks for thefeedback. Unfortunately this is very difficult to avoid. As you may know KoviD, as a kernel module, is highly dependent on the kernel version it is running. If it is installed in a system, and the system is updated to a newer/different kernel, things could go wrong, and it is going wrong as per your feedback. What is the kernel version you installed first and when it was updated, to which version it was? are both kernels included in the supported versions described in KoviD's README ? ty

[iusearch]

The kernel was upgraded from 5.15.0-41 to 5.15.0-65 on a ubuntu22.04 OS. I know it's not possible to avoid the loading issue without recompiling the module with updated kernel source, though I think the loading should not be kept in a loop and always try to load it. It should stop after a few attempts. That's just my opinion.

[carloslack]

I think I understand. Possibly because that is the way I persist.S is written. It could have a check for that, but at the time I wrote I did not think about that. If you fancy you could go there and modify it, however the infection mechanism was provided as an example only, not intended to be the only way of doing that. The problem you see is not in KoviD , it is a combination of the infection and the binary that is infected. From that point on, KoviD has no control.

In my example, persistence happens in the following way:

Volundr infects a binary of your choice using Kovid's persist.S, which, when executed will run a simple script that will insmod KoviD. What is looping is not KoviD, as it has no control, what is probably looping is the binary that was infected.

Everytime the infected binary is called, it will try to load the rk, if you infect sshd, for example, everytime one connects via ssh, it will run the script, but that should be OK, if module is lodaded it should just fail but not affect anything else, if module is not loaded it will try to load it, perhaps when it tries, because the change of the kernel and because you have not recompiled KoviD, it will fail and other weird things could happen.

Sorry if I am mistaken, please tell me if I am, but the way I see it, it is not an issue because it is not a valid test or environment, because when the kernel is updated and KoviD is not, all is basically lost. what do you think? ty

[iusearch]

Yup, that's my point. I did not think about every call to the binary will cause a loading of the module. I thought it was looped. If that's the case, then either a persistence file or shared mem mechanism is needed for that. I think for now the best approach is to infect some other binary that is not call intensively.

[iusearch]

Also thank you very much for your response and explanation on the issue. It helps a lot.

[carloslack]

No worries, I appreciate you reaching. If if you find anything else please let me know :) ty