signed PEs and rootkit detection

[Joanna Rutkowska <joanna () invisiblethings org>]

PE singing is very useful not only in implementing "default deny"
mechanisms, but also in rootkit *detection* (not prevention!).

For example, recently I worked on yet another rootkit detector for
Windows, "System Virginity Verifier". SVV basically verifies all
in-memory mapped code sections (.text) of all important modules (that is
system DLLs and some kernel modules) if they match their corresponding
sections in the corresponding image files.

Many windows rootkits (too many - it's really boring) exploits inline
code hooking (aka raw code hooking) technique, which makes them very
easy to detect by a tool like SVV.

Now, everybody will say, why not to change original file (hook also code
in the file, not only in memory) or cheat about file contents on-the-fly
(for example hook IRP_MJ_READ)? And here is where PE signing (present on
all system files since Windows 2000) enters the scene. If the rootkit
cheated about the system file contents, we would find it, because file's
signature would be wrong (sigverif or sysinternals sigcheck tools comes
to mind at the moment, but it could be also built into SVV). if the
rootkit didn't try to cheat about system files contents then it would be
found by SVV :)

yes, I know, it is possible to write rootkit which do not change code
sections nor even SDT nor EAT/IAT. But, we need to start from somewhere
and code section verification seems to be important step in defining
vital OS parts, which should be verified to assure that OS is "clean".
And PE signing really helps with this IMHO (yes I know, we need to
ensure CA store integrity first).

personally, I don't really believe in prevention, but rather in
detection (http://www.isecom.org/omcd/).

my two cents to executables signing discussion :)

cheers,
joanna.