republican-creole
Search:  

 
 
   All ForumsHot TopicsGallery






how-to block ads


 
Forums » Tech and Talk » OS and Software » All Things Unix » Open source release takes Linux rootkits mainstream
Search Topic:
Uniqs:
724
Share Topic:
RSS topic:
toggle:
flat / full
normal / watch
Posting:
Post a:
Post a:
A big slow down »
« Mint help: Speakers gone after update!!  
page: 1 · 2
AuthorAll Replies

SUMware
Premium
join:2002-05-21

Open source release takes Linux rootkits mainstream

From The Register
4th September 2008 -
quote:
The art of burying invisible malware deep inside a Linux machine is about to go mainstream, thanks to a new open-source rootkit released Thursday by Immunity Inc., a firm that supplies tools for penetration testers.

When implemented, Immunity's DR, or Debug Register, makes backdoors and other types of malware extremely difficult to detect or eradicate. It's notable because it cloaks itself by burrowing deep inside a server's processor and availing itself of debugging mechanisms available in Intel's chip architecture. The rootkit, in other words, mimics a kernel debugger.

By exploiting a CPU's native ability to generate interrupts, DR escapes some of the pitfalls that have visited more traditional types of rootkits, which modify an operating system's system call table. That's of increasing importance as more and more Linux distributions make it harder to make changes to the syscall table and rootkit detection programs such as chkrootkit and rkhunter actively check for such modifications.

Over the past few years, a growing body of malware has incorporated rootkits, making detection much harder. Until now, the benefit of using a rootkit was counterbalanced by the difficulty of building one. DR, which is available here under version 2 of the general public license, will make it profoundly easier.

"In the old days, to attack a computer, you needed to 1) find a bug, 2) write an exploit, 3) run the exploit 4) hide yourself," Charlie Miller, principal security analyst for Independent Security Evaluators, said in an email. "The gap between a script kiddie and a hacker just got a little smaller."

While DR simplifies the task of cloaking nasty malware on Linux boxes, it doesn't support symmetric multiprocessing or actively hide itself at the kernel level. The good news is that those are shortcomings that limit the rootkit's functionality and make it easier to detect.

The bad news: these features could be added with about a week's worth of development time. Indeed, Immunity is offering commercial support for DR as part of its Canvas toolkit


happylurk

@look.ca
Why did I just feel my sphincter clench up when I read that?


drjim
Premium,MVM
join:2000-06-13
Torrance, CA
clubs:
You're not the only one.....


happylurk

@look.ca
Ten again on rereading I noted that it seems to be specific to Intel architecture. Does that mean I've bought myself some extra time by running an All-AMD shop?

SUMware
Premium
join:2002-05-21


edit:
September 5th, @03:29PM

reply to SUMware
Yep, not a "feel-good"...
More info: »seclists.org/dailydave/2008/q3/0215.html

Edit: At this time I could find no information that this would affect any other product except Intel. It would also somehow need to be installed by root.

SUMware
Premium
join:2002-05-21

reply to SUMware
An open source rootkit kit September 5th, 2008
said by Dana Blankenhorn :
The Register is convinced that former NSA programmer Dave Aitel has gone over to the dark side by making his DR Rootkit open source under GPL 2.

While it’s true that the program can make rootkits, I don’t see it as a net loss for Linux security.

I think it may be more of a honeypot.


TSI Gabe
Network Kung Fu
Premium,VIP
join:2007-01-03
Chatham, ON

This just shows that tools like chkrootkit can be useless if you know what you are doing. While it is a good thing that they released this under GPL and that I'm sure that they will add some sort of detection in the tool for this technique.

Something tells me that a lot of Rootkits will derive from this one and probably very soon...
--
TSI Gabe - TekSavvy Solutions Inc.


BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000

said by TSI Gabe See Profile :

Something tells me that a lot of Rootkits will derive from this one and probably very soon...
I believe there's a few in the wild behaving this way today. This just happens to be a company releasing it rather than a miscreant. Unless I'm missing something, the part that's new is the license. There's even been "commercially supported" rootkits in the past.

Ugly, but not worse than where we were I suspect.
--
Overpower, overcome.

dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL

reply to SUMware
It's notable because it cloaks itself by burrowing deep inside a server's processor
Wow! Burrowing deep inside a server's processor! Sounds really hardcore. I wonder what they mean?

and availing itself of debugging mechanisms available in Intel's chip architecture.
Oh, you mean it 'executes instructions' and 'writes to registers'. Wow indeed!

dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL

reply to happylurk
said by happylurk :

Ten again on rereading I noted that it seems to be specific to Intel architecture. Does that mean I've bought myself some extra time by running an All-AMD shop?
If the AMD doesn't have equivalent debug registers, it's useless for OS development. Therefore we can conclude AMD has debug registers.

I think they've been in the architecture since the 386, so AMD has had plenty of time to copy them!


JohnInSJ
Premium
join:2003-09-22
San Jose, CA
·SONIC.NET

reply to dave
said by dave See Profile :

It's notable because it cloaks itself by burrowing deep inside a server's processor
Wow! Burrowing deep inside a server's processor! Sounds really hardcore. I wonder what they mean?

and availing itself of debugging mechanisms available in Intel's chip architecture.
Oh, you mean it 'executes instructions' and 'writes to registers'. Wow indeed!
LOL... Yeah. It uses machine code and everything. Be afraid.

KodiacZiller

join:2008-09-04
73368

There's nothing to be afraid of as an average desktop user. As I'm sure you all know, all rootkits do, by definition, is allow someone to cover their tracks once the machine is ALREADY cracked. It isn't like you can accidentally download one (a la trojans on Windows). And even if you did, it wouldn't execute unless you explicitly give it permission.

Turn off unneeded services, update often, and run a firewall, and the chances of a desktop user being cracked are next to nil. Security 101 is all you need.

Now "high value" servers on the other hand... They might have a problem with this, but I doubt it will be epidemic.


Brano
Premium,MVM
join:2002-06-25
Burlington, ON
·TekSavvy Solutions..
·ELECTRONICBOX

reply to SUMware
Not to undermine the seriousness of this, but since it's open source one can be sure that kernel developers and other security experts will analyze the code and will try to make future kernel more resistant against such rootkits.
Open source works both ways

SUMware
Premium
join:2002-05-21


edit:
September 6th, @10:04AM

reply to dave
said by dave See Profile :

It's notable because it cloaks itself by burrowing deep inside a server's processor
Wow! Burrowing deep inside a server's processor! Sounds really hardcore. I wonder what they mean?

and availing itself of debugging mechanisms available in Intel's chip architecture.
Oh, you mean it 'executes instructions' and 'writes to registers'. Wow indeed!
Excerpted from: »seclists.org/dailydave/2008/q3/0215.html

From: Bas Alberts
Date: Wed, 03 Sep 2008 16:32:54 -0400

Currently the rootkit can:

o Hide processes
o Hide network sockets
o Hide files
o Get a remote MOSDEF Node (via hidden userland-backdoor)

The major benefit of the DR rootkit is that all this happens transparently to the end user. The children of a hidden process are also automatically hidden. The sockets a hidden process creates are also hidden. But if you are a hidden process, you can see hidden resources. This makes the DR rootkit nicely manageable.

DR loads via insmod - we've tested the rootkit on a number of Linux distributions including CentOS and Ubuntu.

About
=====

DR features a reference implementation of a IA32 debug register based rootkit hooking engine. It does not modify IDT or syscall_table at all but still provides transparent syscall hooking on IA32 Linux 2.6.

Features
========

SystemCall hooking without modifying IDT, or syscall_table, at all. Not even for a milisecond(tm). Using hardware execute and read breakpoints.

Details
=======

DR places a hardware breakpoint on the syscall handler, and the resulting trap places a memory watch on the syscall_table entry for the __NR_syscall of the intercepted syscall. It does this for both INT 0x80 and sysenter based system calls.

When the memory watch for the syscall_table entry kicks in, the trap handler then redirects execution for that syscall to a syscall hook.

Example Flow
============

Execute global breakpoint on syscall handler in dr0, syscall is called, breakpoint kicks in. Modified do_debug handler places global read watch on syscall_table[__NR_syscall]. When syscall is called, memory access breakpoint kicks in. Modified do_debug handler places function pointer to hooked syscall in task regs eip. Execution is redirected to hooked syscall. Repeat.

[ 864.447800] ******* LOADING IA32 DR HOOKING ENGINE *******
[ 864.447868] *** loader: handler for INT 128: C0104210
[ 864.447923] *** loader: syscall_table: C02FC540
[ 864.447934] *** loader: syscall_call call *table(,eax,4): C010424B
[ 864.447952] *** loader: handler for INT 1: C02F4360
[ 864.448085] *** loader: INT 1 handler patched to use __my_do_debug
[ 864.448165] *** loader: initialized hook_table
[ 864.448199] *** loader: systenter_entry call *table(,eax,4): C01041CB
[ 871.592214] *** dr0/dr1 trap: setting read watch on syscall_NR of 220 at C02FC8B0
[ 871.598191] *** got dr2 trap (syscall_table watch)
[ 871.598723] *** hooked __NR_220 to E0AC7350

Using the memory watch approach, one does not have to modify IDT or syscall_table ever. This is an original approach, but considering we _are_ the debugger .. one could dream up a million other viable and fruitful solutions to non-memory modifying DR rootkits.

Limitations
===========

This is a reference implementation. A lot more can be done to actually be hidden. Production code will include kmalloc based non-LKM code handling. Full Global Detect debug register access detection support, and additional memory watching for the debug ENTRY call offset patch.

Additional testing is required to check for scheduler issues and other racy problems. This reference implementation is intended as a case study into the general rootkit approach now that the cat is out of the bag.

The provided example hooks serve as a basic example rootkit known to suffer the following limitations:

Detection
=========

In it's current form there is no prevention of someone else accessing the debug registers. This could be easily added with GD access flag control, however this is left as an exercise to the reader.

Furthermore this module behaves like a normal LKM in that is has symbols and is resident in memory like a normal LKM. This can be bypassed by porting the module init to a kmalloc based loading logic. To be added in v0.2.

- - Detection via module based symbols
- - Detection via granted access to hardware debug registers
- - Detection via timing logic
- - Detection via open("/proc/hiddenpid/stat"); success

Adding/Changing hooks
=====================

All hooks are defined in hooktable.h. A good example template is the hook_example_exit function. Once a hook is added to the global hook table, it will be automagically used by the hooking engine.

10 asmlinkage static void hook_example_exit(int status);

...

149 asmlinkage /* required: args passed on stack to syscall */
150 static void hook_example_exit(int status)
151 {
152 /* standard hook prologue */
153 asmlinkage int (*orig_exit)(int status);
154 void **sys_p = (void **)sys_table_global;
155 orig_exit = (int (*)())sys_p[__NR_exit];

...

167 else
168 return orig_exit(status);
169 }

You then initialize this function in the global hook_table as such:
121 hook_table[__NR_exit] = (void *)hook_example_exit;

The hooking engine was designed to be very friendly and open to modification/extension. It was designed to provide a more current hooking engine for existing sycall_table based rootkit logic. All rootkit specific logic lives in hooktable.h.

Todo
====

- - move to kmalloc based init loader, -EINVAL return
- - improve hooks to do proper '/proc' and getdents handling
- - move /proc handling to inode based checks
- - instruction emulation for outside debug register access GD stylee

Credits
=======

The debug register based hooking engine was written by Bas Alberts, all additional hooks contained in hooktable.h, besides the example hook_exit were written by Daniel Palacio.
**************
Edit:
Pierre Falda posted additional comments here.
Joanna Rutkowska posted additional comments here.

dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL


edit:
September 6th, @12:38PM

The 'new thing' in this kit is used of the hardware debug registers.

You're familiar with attacks such as hooking the system call table? This has heretofore been done by planting instructions in said table, to revector control to where we want it to go.

That's how we used to do software debugging.

However, a better approach (less fussing around rewriting pieces of the code under test) relies on hardware support. Instead of modifying the instruction at address N, for example, you set up debug registers to say 'issue a trap when you are about to execute the instruction at address N'.

You can also do things like 'trap when any instruction tries to read or write address N', which is a lot more convenient than doing the same thing by software manipulation of page tables.

OK, so here's some guesswork on my part about what this new approach does:

It substitutes 'patching dispatch tables' with 'setting up debug registers to achieve the same thing'. This is a good idea, since it's less invasive, and presumably therefore less easy to detect.

I imagine that the rest of it, while fearsome, is 'standard rootkit stuff'. You could do that with any method that allows you to grab control at suitably-chosen points in execution.

One can infer all this from, basically, this single paragraph:

quote:
DR features a reference implementation of a IA32 debug register based rootkit hooking engine. It does not modify IDT or syscall_table at all but still provides transparent syscall hooking on IA32 Linux 2.6.
Lest you misunderstand my first post, I was criticizing the reporter's use of garbage phrases like 'burrowing deep inside the processor'. This is not rocket science. It is (AFAIK) using documented processor facilities in the manner in which they were intended to be used. The new insight is that debugging and call-trapping for rootkits are the same thing.

dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL

reply to Brano
said by Brano See Profile :

Not to undermine the seriousness of this, but since it's open source one can be sure that kernel developers and other security experts will analyze the code and will try to make future kernel more resistant against such rootkits.
Open source works both ways
I'm pretty sure that when Windows gets attacked, kernel developers and other security experts will analyze the code and will try to make future kernel more resistant against such rootkits.


a333
A hot cup of integrals please

join:2007-06-12
Corona, NY
I'm quite sure that's why Windows has helped created a billion-dollar antivirus software market, and a wide array of exploits that grow by the 100's as we speak...

dave
Premium,MVM
join:2000-05-04
not in ohio
What has that got to do with anything? The subject was whether kernel programmers and security experts look at the affected kernel software after rootkits are published.

Feral Kid

join:2006-12-27
UK

edit:
September 7th, @04:25AM

reply to SUMware
It sounds all scary and everything but how would I actually get this thing to infect me?

p.s. it's just a general reply, not specifically to SUMware (sorry first post)


a333
A hot cup of integrals please

join:2007-06-12
Corona, NY
·Verizon Online DSL

reply to dave
If what you said actually played out in the real world, Windows wouldn't have created a multibillion-dollar antivirus software industry. By your logic, each release of Windows would be significantly safer, and by now, the need for AV S/W would be close to nil. Also, malware devs/ script kiddies would give up writing viruses for Windows, and move on to an easier platform...
-
Forums » Tech and Talk » OS and Software » All Things UnixA big slow down »
« Mint help: Speakers gone after update!!  
page: 1 · 2


Tuesday, 02-Dec 09:19:29 Terms of Use | Privacy Policy | Hosting by www.nac.net - DSL,Hosting & Co-lo | feedback | contact
over 9 years online! © 1999-2008 dslreports.com.
page compression OFF
Most commented news this week
· [100] AT&T Metered Billing Trial Hits Second Market
· [74] UDP BitTorrent Will Destroy The Interwebs!
· [57] Comcast Tries To Slow Verizon's Philly Entry
· [17] FCC To Vote On Free National Wireless Broadband
· [14] Clearwire May Slow WiMax Build
· [9] Hawaii Telecom Files For Bankruptcy
· [8] Embarq Rejected Higher Offer
· [6] Monday Evening Links
· [2] EFF Challenges Telecom Immunity
· [1] Tuesday Morning Links
Most people now reading
· Is this a good thing for the net? [news,99366]
· [Rant] Bestbuy receipt checker [Rants, Raves, & Praise]
· Upverting DVD players vs Blue ray DVD players. [General Questions]
· Coalition Government Possible? [TekSavvy]
· Level 80 PVP gear info? [World of Warcraft]
· Best way to clean your screen [LCD] [General Questions]
· Ted Rogers passed away [Rogers]
· 80 done, Naxx cleared.....can you say WOW...GG? [World of Warcraft]