Cognitive and Scientific Brainology

Security - consulting,assessment,research,solutions,penetration tests.
Face - detect,track,recognize,extract features,learn emotions,character animation.

AthCon3 2012 Day2, Track1, 14:00-14:50 "Why rootkits suck"

06/11/12 | by zveriu | Categories: Conference, AthCon, Write-up

Download here.

Code:

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

Comments, Pingbacks:

No Comments/Pingbacks for this post yet...

This post has 1 feedback awaiting moderation...

HIRE! - My Resume

Contact

Upcoming talks

PHDays
Hack In Paris
BlackHat USA

Cognitive and Scientific Brainology

A deep dive into brain's curiosities

June 2013
Sun	Mon	Tue	Wed	Thu	Fri	Sat
<< <		> >>
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

Friends

Misc

XML Feeds

RSS 0.92: Posts, Comments
RSS 1.0: Posts, Comments
RSS 2.0: Posts, Comments
Atom: Posts, Comments

What is RSS?

Contact the admin • Miami blue skin by Miami condo real estate • Credits: open source blog | SSH hosting | team

	`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`

Cognitive and Scientific Brainology

AthCon3 2012 Day2, Track1, 14:00-14:50 "Why rootkits suck"

AthCon3 2012 Day2, Track1, 14:00-14:50 "Why rootkits suck"

Comments, Pingbacks:

Leave a comment:

HIRE! - My Resume

Contact

Upcoming talks

Ads

Cognitive and Scientific Brainology

Friends

Categories

Archives

Misc

XML Feeds