Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Honeypots: Re: sebek as a patch?

Re: sebek as a patch?

From: Edward Balas <ebalas_at_iu.edu>
Date: Wed, 05 Oct 2005 08:13:00 -0500

Thorsten Holz wrote:

>Edward Balas wrote:
>
>>Could you elaborate on what you mean by rather hard to hide the
>>kernel module? I presume you mean beyond simply modifying the kernel
>>data structure to remove the module from the linked list of modules
>>which is done currently?
>
>
>I think he means that it is hard to hide a module on a host if the
>attacker has uid 0. After all, he can then start to dig around, search
>through kernel memory for patterns (e.g. module structure, modifications
>in the network code, ...), insert his own modules, and basically
>arbitrary things. So shouldn't it be easy to detect the presence of
>Sebek by searching through the memory for the constant strings? Or
>triggering a little fork bomb and see whether the system behaves unusual
>compared to normal behavior?

Heh, yeah that was the point I was leading up to, which is to say if
you have root you can then do pattern matching on kernel memory
to identify interesting things. This is true regardless of kernel patch
or module.

>>As for a patch, it does offer some advantages, however I am skeptical
>> that it will be the magic fix. First most of the detection stuff we
>>have seen is pattern match based. Going to kernel patch, just changes
>>the patterns that one needs to looks for. Second, once you have
>>patched the kernel, detection can happen on there kernel image in the
>>fs itself.
>
>
>I agree that it will not be the magic fix, but it can help the more
>paranoid people. After all, Sebek is then part of the kernel and
>removing it becomes much harder.

Yes but you trade detectablity for a vague sense of security that you
will be able to not disable a kernel patch. For example if I know where
in memory the destination IP information or other parts of the config
are stored, can't I manipulate them to send the data to the incorrect
remote
host making the collector blind?

>
>And if we observer the kind of detection techniques you mention, we can
>start to add polymorphism ;-)
>
>>The one thing that is pretty sweet about a patch is that you dont
>>need to worry about how to reinstall the kernel module after reboot.
>
>
>Another option is detailed in "Infecting loadable kernel modules",
>Phrack Volume 0x0b, Issue 0x3d, Phile #0x0a
>(http://www.phrack.org/phrack/61/p61-0x0a_Infecting_Loadable_Kernel_Modules.txt)
>
>I hope that there will be soon a diploma thesis about improving the Data
>Capture mechanism at my Lab. I keep you up-to-date on this topic.
>
It would be really sweet if someone could crank out a port of linux sebek
which operated as a kernel patch and then did a comparision of the two
regarding the situations to which each was best suited. There are a
lot of assumptions about what a kernel patch can do for us, sounds
like a perfect opportunity to test them ;-)

Edward
Received on Oct 05 2005

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos