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.
Permitting user-loaded kernel modules effectively invalidates all other security measures.
if so, why is it there at all?
Years back when our team was dealing with weird permission issues on multiple levels due to SELinux, I found little value in it.
Because in my experience, when people are "dealing with weird...issues" and "[finding] little value in it" they usually don't understand what it is and how to use it.
This makes any tool difficult to appreciate.
I assume you know what a network firewall is. Think of SELinux like a "System Call Firewall". SELinux will protect you from many so-called "zero-day" vulnerabilities. It watches every syscall an application makes, looks at its policy, and decides if that syscall should be allowed/denied. It is a good thing.
However, SELinux is really not user-friendly, though it is extremely well documented and learnable. (run `man -k selinux` to see all the man pages) Red Hat also has thorough documentation (https://docs.redhat.com/en/documentation/red_hat_enterprise_...)
Specifically, to your "weird permission issues". That is a "problem" with SELinux; it doesn't surface errors well. The TL;DR is: if you get a "permission denied" error, and you rule out the obvious (i.e., filesystem permissions), then you need to know to blame SELinux and look at the `/var/log/audit/audit.log` file.
That file is technically human readable, but there are tools that make it much easier, such as `ausearch` and `sealert -a`.
---
https://danwalsh.livejournal.com/71122.html
"Now this is a horrible exploit but as you can see SELinux would probably have protected a lot/most of your valuable data on your machine. It would buy you time for you to patch your system."
echo 1 > /proc/sys/kernel/modules_disabled
Which is supposed to block dynamic loading modules until a reboot.
It would be interesting if the PoC can get around that trick too. =3
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.
Persistence is actually quite rare nowadays - since it's the most easily detected, red teams usually prefer not to and stay memory-only.
Or is the only line of defense a kernel compiled without the ability to load modules?
I know all bets are off once someone already gained root, but not allowing the installation of a stealth rootkit is never bad.
Does not work if kernel Kconfig setting has:
CONFIG_MODULES=n
does this work on normal linux desktops ? My impression was that either: 1). Kernel is too big. Try making modules - link error or 2) System will not boot due to missing/misconfigured parts.
Also, kernel build will fail during 'make modules'/'make all'/'make' but will succeed for 'make bzImage'/'make install'
Desktop Linux distros' WiFi required SIGNED module support for internationalization of radio band selection.
SO, for kernel modules to be disabled on desktop and still use WiFi, one needs to rebuild WiFi without module support and specifically to comply with their country's radio authority.
Pesky little thing.
echo 1 > /proc/sys/kernel/modules_disabled
Which is supposed to block dynamic loading modules until a reboot. =3
How it works: SELinux maintains a global kernel structure called selinux_state that contains the enforcement flag. The rootkit resolves this non-exported symbol via kallsyms at module load time, then directly writes enforcing = 0 when triggered. This bypasses the normal setenforce() interface entirely.
The clever part is the dual-layer approach:
* Hooks netlink_unicast to drop audit messages for hidden PIDs
* Attempts to modify selinux_state->enforcing directly in kernel memory
On kernels built with CONFIG_SECURITY_SELINUX_DEVELOP=y, SELinux enforcement may stop at the kernel decision level, while userspace tools continue to report enforcing mode and /var/log/audit/audit.log shows nothing.
- Advanced Network Hiding
Previous versions only hide TCP connections from /proc/net/tcp* by hooking tcp_seq_show, which blocked netstat. But modern tools like ss and conntrack bypass /proc entirely - they query the kernel directly via netlink.
The new version filters at the netlink layer:
* SOCK_DIAG filtering: ss uses NETLINK_SOCK_DIAG protocol to get socket info directly from the kernel. Singularity hooks recvmsg to intercept and filter these netlink responses before userspace sees them. Commands like ss -tapen or lsof -i return empty for hidden connections.
* Conntrack filtering: Connection tracking (nf_conntrack) maintains state for all network flows. Reading /proc/net/nf_conntrack or running conntrack -L would expose hidden connections. The rootkit now filters both the proc interface and NETLINK_NETFILTER messages with conntrack types. * UDP hiding: Added hooks for udp4_seq_show and udp6_seq_show - previous versions only hide TCP.
- Other improvements:
* Optimized log filtering (switched from multiple strstr() calls to switch-case with strncmp()) * Audit statistics tracking (get_blocked_audit_count(), get_total_audit_count()) * Automated setup script
Is this independent of the Linux Security Modules policy, e.g. RHEL default policy for SE Linux?
Also the specific details in README regarding 'make sure you randomize this or you'll be detected!' makes it feel even less like it is explicitly for educational purposes since you are providing users easy instructions on how to work around countermeasures this code.
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
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.
This would really end up doing not much because buying a domain name and such hosting should be easy.
There are some service providers who will only comply in things if you provide if and only a legal complaint which is genuine and valid (like a court order) and I think no Court can order for something like this because I feel like there is / must be a legal backing for genuinely writing "this tool is for educational/research purposes" and its actually so, so I don't really understand if github's stance would even matter in the end because if you need to get court order to remove it in the end, then github will comply it with it as well (even more so than those providers even)
I don't understand what the OP wants, like should this be obscure in some tor .onion forum for hackers or should this be on github so that people can read about this and learn abotu this vector and patch up in their servers where they may have thought it was safe but they didn't know about this issue exists in the first place! (because a hacker might still use obscure persons but a sysadmin might not comparatively)