Re: Britney and Kevin are Chaotic

[joanna <joanna () invisiblethings org>]

El Nahual wrote:
> As soon as attacker tries to execute the BDs problem arises, se46 is right
> on kernel, pull it down kernel goes with it, so no binaries can actually run
> at all without the signature (a sha-1 signature with revocation on line)
>
> I know that if you probably get stuck with lets say syscall proxy, hey it
> doesn't touch the HD CIS cant stop it, as soon as you DL shit you have a
> problem since you have to exec(), no exec for unsigned binaries you would
> have to patch a memory segment and have it run by a jmp (we check threads
> too)
ok, let me clarify then:
1) attacker exploits a bug in a legitimate process
2) shellcode "downloads" the rootkit, which means:
 a) it allocates some memory in the space of exploited process
 b) it "downloads" (for e.g. via the same socket the exploit was sent)
special position independent code, which happens to be "rootkit installer"
 c) jmp's to this rootkit installer code
3) now the rootkit installer does one of two things
 a) subverts kernel via \Device\PhysicalMemory. the only interesting
part here is physical 2 linear address translation.
 b) exploits some kernel BOv; kernel subverting is done by shellcode
used in exploiting the kernel bug.

Now the kernel was subverted! :o

having our own code in the kernel means that we can also have a special
kernel level backdoor too (or some covert channel) - no need to exec()
BDs. and if we really would like to exec() something (good old cmd.exe
for e.g.) there are few ways for doing this from within kernel mode,
without the need of ZwCreateProcess()...

My question is how can you stop/detect this kind of scenario?

> Windows policies restriccions do it by binary and path, we do it by changes

what do you mean by "do it by changes"?

joanna.
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave