athcon.org
Athens, 3-4 May, 2012
Day2, Track1, 14:00-14:50
"Why rootkits suck",
twogunz

"Why rootkits suck"

Rootkit malfunctions usually reveal that the rootkit is present on the system

Rootkit overview
    remote access
    intercept data
    etc
    transforms the computer in a zombie

Rootkits vs Botnets
    share some common characteristics
    but are not the same

userland vs kernel-land rootkits
    userland
        binary replacing
        binary injecting (detectable by tripwire)
        process injecting
        poor means to disguise the presence of the attacker
        poor means to survive reboot
        poor means to hide remote connections
    kernel-land
        need to interfere with binaries only during the booting phase
        can provide extensive means for hiding and remote access
        hard to detect
        comple (compile? complete?)

How do rootkits work
    replace files on the system with backdoored versions
    ring zero rootkits hijack function handler pointer in mem to alter normal behaviour

Anti rootkits
    rootkits make visible changes to the system
    userland rootkits will alter timestamps, dir struct file size
    kernel land rootkits alter system functions
    most kernel rootkits focus on the  syscall table
    rootkits need to add files to the filessystem, need to add processes, open ports, etc.
    anti rootkit tools, rkhunter, chkrootkit, etc.
    signature scanning does not detect newer versions of rootkits unless they are updated
    heuristics (didn't get the presenter point)

Traditional rootkit detection
    signature scanning vs integrity checks
    signature scanning fails for the slightest change in the file structure of the rootkit
    major fallback of integrity check anti-rootkits is that is relies on know to be sane system state - which makes sense

Examples - traditional rootkit detection
    Shown example: rkhunter - Adore rootkit
    Shown example: rkhunter - suckit rootkit
    Shown: Phalanax
    It is clearly seen that it is easy to go undetected if a filename or directory structure changes
    
    chkrootkit uses grep-approach

Traditional vs Heuristic Detection
Heuristic
    detects signs of rootkit activity, not the rootkit files themselves
    Soon available as online service

So how are rootkits found
    They hijack the predictable places

Remote access
    Suspicious signs of crypto inside the network (if there is encrypted traffic over a plain-text protocol)

Surviving the reboot
    need to insert persistent triggers in system files
    the triggers can be found by analyzing these files (eg.: /etc/rc/init.d)

The problem of complex code in Linux Kernel
    Many changes in 2.6 branch

Code quality in rootkit
    same code does not work on different kernel subversions
    insufficient testing of code
    coded in a hurry
    throwing together many functionalities without a plan
    portable code vs stable code, but portable code is not necessary stable

Rootkit exploits
    They come with vulnerable code because of hurry development, insufficient testing
    from buffer overflows to pure logic flaws
    taking over rootkits in memory using exploits in rootkit itself (phalanx case)
    magic user ID approach
    rootkit writers consider that only remote access to shell of rootkit requires authentication, thus local connect to backdoor authentication is either poorly implemented or inexistent
    a good method is to start PID_MAX - PID_PROCESS_NUMVER and if something fails, something is suspicious there

Phalanx exploit - MAGIC_UID flaw
    haxorgid variable of type gid_t
    limits GID space 64k
    bruteforce of GID is easy and see which one drops us to hacker shell
    after a few little hacks we are in
    example Phal-hack

Compromising the rootkit
    Full access to rootkit files
    Recovering hackers password
    Learn what hackers know about you
    Learn hacking techniques
    Important: possibly get a brand new 0day unknown to public

Model of a winning rootkit
    Describes how a perfect rootkit would look like
    Kernel code is used as a framework to launch and manage userland code
    good code testing
    several different hooking techniques to make sure there is always a fallback scenario
    Ideally, subliminal channel tcp/ip backdoor
    Timed backdoor programmed to start at certain hours
    Have several "survive the reboot" techniques
    Nothing really has to be written to the disk