51–58 of 58 posts
Earlier quoted context omitted.
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.
I'm quite surprised to learn that Android allows this
Earlier quoted context omitted.
If Kernel Lockdown is enabled, a zero-day exploit is required to bypass module restrictions without a reboot. Unfortunately, threat actors tend to have a stash of them and the initial entry vector often involves one (container or browser sandbox escape), and once you have that, you are in ring 0 already and one flipped bit away from loading the module. The Linux kernel is not really an effective privilege boundary.
So what would you recommend instead? To run workflows in VMs?
Only the old Sun systems with hardware encrypted mmu pages could actually enforce context isolation.
If performance is not important, and people are dealing with something particularly nasty... than running an emulator on another architecture is a better solution. For example, MacOS M4 with a read-only windows amd64 backing-image guest OS is a common configuration.
https://github.com/86Box/86Box/releases
https://github.com/Moonif/MacBox/releases
Best of luck =3
Earlier quoted context omitted.
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.
Naive question: does Linux check checksum of loaded modules? If not I could just replace them and voila?
The kernel provides the option to embed a signing key for kernel modules at compile time. But (AFAIK) you'll need to compile your own kernel to go that route.
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.
Earlier quoted context omitted.
So what would you recommend instead? To run workflows in VMs?
A kvm hypervisor is not perfect, as sandbox escape was demonstrated even with https://qubes-os.org/ . On modern AMD/Intel/ARM64 consumer processors it is not possible to completely prevent bleeding keys across regions. Only the old Sun systems with hardware encrypted mmu pages could actually enforce context isolation. If performance is not important, and people are dealing with something particularly nasty... than ru…
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.
The most obvious reason would be the fear of patching a vulnerability which the attacker used to gain initial access. Persistence is required.
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.
Earlier quoted context omitted.
A kvm hypervisor is not perfect, as sandbox escape was demonstrated even with https://qubes-os.org/ . On modern AMD/Intel/ARM64 consumer processors it is not possible to completely prevent bleeding keys across regions. Only the old Sun systems with hardware encrypted mmu pages could actually enforce context isolation. If performance is not important, and people are dealing with something particularly nasty... than ru…
I am hearing first time of a sandbox escape in QubesOS. Can you link the source?
The modern slop-web is harder to find things now, and I can't recall specifically if it was something more than just common hypervisor guest escape. =3