Live data from Hacker News

Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

github.com

11–20 of 58 posts

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#11

I understand that this is to drive research and help security researchers in this case, but I personally think Github should take a harder stance against this kind of repo, education purposes or not - saying it is for educational purposes is definitely not going to stop someone (especially people who wouldn't know how to develop this level of rootkit on their own) from going and using it. Also the specific details in…

There are many responses to this, but I'll start with:

Security through obscurity is not security [1]

When only l33t underworld h4x0rz know about software flaws, there is very little incentive or ability for regular software developers to find and fix what enables these vulnerabilities. Only through shared knowledge can the world become a better place.

[1] https://en.wikipedia.org/wiki/Security_through_obscurity

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#12
Hiding from SELinux is clever, but SELinux (for most users not running MLS) is a final level of defense. If you get to the point where SELinux is saving your butt, you've got problems higher up in the stack.

For me, the real scary part is the hiding "Audit Evasion" (for those not in the know, here's a link https://www.redhat.com/en/blog/configure-linux-auditing-audi...);

Audit is supposed to be able to track anything and everything that happens on a Linux box. Every login, application, socket, syscall, all of it. The fact that they can bypass it is HUGE. You're not supposed to be able to disable auditd without rebooting the system (when correctly configured). And rebooting the system should* trigger other alarms for the security team.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#13
post #9

first thing comes to mind is just grabbing the cr3 and finding it in physical memory for detection. also this feels a little bit too much effort for something that was never used in the real world not going to lie. ICMP reverse shell is a really cool idea, no persistence makes it rather harmless compared to what is possible.

Red teams (internal or consultants) use this sort of tooling in the real world. Their job is to emulate a real, competent threat actor. APTs routinely use high-quality rootkits for EDR evasion. Persistence is actually quite rare nowadays - since it's the most easily detected, red teams usually prefer not to and stay memory-only.

I guess it makes sense - as for persistence I guess no point in having any if you can just compromise the target again.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#14
This does not seem to work with Fedora Atomic. Because the system is read-only, the kernel module cannot be loaded. You would have to create an RPM package for the rootkit that you can then layer. In addition, due to Secure Boot, the kernel module would have to be signed with the same key as the system itself.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#15
post #10

I understand that this is to drive research and help security researchers in this case, but I personally think Github should take a harder stance against this kind of repo, education purposes or not - saying it is for educational purposes is definitely not going to stop someone (especially people who wouldn't know how to develop this level of rootkit on their own) from going and using it. Also the specific details in…

Do you think malware creators find out by reading HN or github? I don't understand the vitriol, the request "Github should take a harder stance" could have a chilling effect on security researchers, pushing high impact exploits deeper underground.

There isn't vitriol, or atleast I didn't mean it that way. The point I was trying to make is that I've seen malicious code like viruses and keyloggers and rootkits being distributed via github and they use the 'this is for education' as a cop-out when the rest of the repo makes it extremely obvious what the real intention is

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#16
post #12

Hiding from SELinux is clever, but SELinux (for most users not running MLS) is a final level of defense. If you get to the point where SELinux is saving your butt, you've got problems higher up in the stack. For me, the real scary part is the hiding "Audit Evasion" (for those not in the know, here's a link https://www.redhat.com/en/blog/configure-linux-auditing-audi... ); Audit is supposed to be able to track anythin…

The rootkit runs in ring0, at that point all kernel-enforced security controls are potentially compromised. Instead, you need to prevent the kernel module from being loaded in the first place. There are multiple ways to ensure no further kernel modules can be loaded without rebooting the computer, e.g. by having pid=1 drop CAP_SYS_MODULE out of it's bounding set before starting any child processes. After it has been loaded it's too late to do anything about the integrity of your system.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#17
post #16
post #12

Hiding from SELinux is clever, but SELinux (for most users not running MLS) is a final level of defense. If you get to the point where SELinux is saving your butt, you've got problems higher up in the stack. For me, the real scary part is the hiding "Audit Evasion" (for those not in the know, here's a link https://www.redhat.com/en/blog/configure-linux-auditing-audi... ); Audit is supposed to be able to track anythin…

The rootkit runs in ring0, at that point all kernel-enforced security controls are potentially compromised. Instead, you need to prevent the kernel module from being loaded in the first place. There are multiple ways to ensure no further kernel modules can be loaded without rebooting the computer, e.g. by having pid=1 drop CAP_SYS_MODULE out of it's bounding set before starting any child processes. After it has been…

That is a critical observation. Last time I had to root an Android device it hat pretty robust defenses like dm-verity and strict SELinux policies (correctly configured) and then everything collapsed because the system loaded a exfat kernel module from an unverified filesystem.

Permitting user-loaded kernel modules effectively invalidates all other security measures.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#18
post #4

Nice. Could it be detected by comparing output of `find /` at runtime with output of `find /` if you mount the disk on another system?

Yes. Offline is how a lot of rootkits are analyzed after the admin notices peculiar behavior. There are a lot of other tells that could be run online to find this rootkit though, most notably, its behavior with ftrace. Disabling ftrace, and then running a program that uses ftrace would tell right away that something's wrong.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#19
post #9

Earlier quoted context omitted.

Red teams (internal or consultants) use this sort of tooling in the real world. Their job is to emulate a real, competent threat actor. APTs routinely use high-quality rootkits for EDR evasion. Persistence is actually quite rare nowadays - since it's the most easily detected, red teams usually prefer not to and stay memory-only.

I guess it makes sense - as for persistence I guess no point in having any if you can just compromise the target again.

Many servers and systems are rarely rebooted, and many campaigns are not that long term. There may not be a reason to compromise the target again.

For example, a ransomware gang may compromise a company's network, steal data, deploy the cryptolocker, and then get out. There's no need to have persistent access; they got what they wanted.

Re: Singularity Rootkit: SELinux bypass and netlink filter (ss/conntrack hidden)

#20
post #11

I understand that this is to drive research and help security researchers in this case, but I personally think Github should take a harder stance against this kind of repo, education purposes or not - saying it is for educational purposes is definitely not going to stop someone (especially people who wouldn't know how to develop this level of rootkit on their own) from going and using it. Also the specific details in…

There are many responses to this, but I'll start with: Security through obscurity is not security [1] When only l33t underworld h4x0rz know about software flaws, there is very little incentive or ability for regular software developers to find and fix what enables these vulnerabilities. Only through shared knowledge can the world become a better place. [1] https://en.wikipedia.org/wiki/Security_through_obscurity

The second argument doesn't really work out in praxis. We have a quarter century knowledge about SQL injection at this point, yet it keeps happening.

Instead of trying to educate everybody about how to safely use error-prone programming abstractions, we should instead de-normalize use of them and come up with more robust ones. You don't need to have in-depth exploit development skills to write secure Rust code.

Unfortunately, there's more money to be made selling security consulting if people stick to the error-prone ones.

Post reply on HN