lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 7 Dec 2011 13:31:28 -0800
From: Gage Bystrom <themadichib0d@...il.com>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: one of my servers has been compromized

You use everything but the compromised box, right. And that's because of
the proliferation of kernel rootkits in the first place. Userland rootkits
can be defeated quickly, easily, and sometimes by accident. A kernel
rootkit can only realistically be beaten by other machines monitoring the
network, imaging the hard drive, etc. As an attacker you increase the
chances of losing by not using a kernel rootkit. Which is why if you're
going for a rootkit, there's no reason to use a userland over kernel. Not
to mention a kernel rootkit is in a better position to delay or prevent
discovery in the first place barring good mitigations.

Which is where my statement 'if you are worried about a userland kit, you
must worry about a kernel rootkit.
On Dec 7, 2011 1:18 PM, "Paul Schmehl" <pschmehl_lists@...rr.com> wrote:

> From a computer science standpoint there's a difference, of course, but
>> not
>>
> from an investigation standpoint.  Say the kernel has a rootkit and is
> creating files.  How do you find those files?  If it's opening network
> connections, how do you find out what those connections are and what
> process is tied to them?
>
> --On December 7, 2011 10:13:42 AM -0800 Gage Bystrom <
> themadichib0d@...il.com> wrote:
>
>
>> Oh it certainly is a distinction, and that very distinction is important
>> enough to have caused the creation of kernel rootkits in the first place:
>> the kernel is absolute. There is nothing any software can do without the
>> kernel.
>>
>> For instance say you got a guy with a userland rootkit. He wants to hide
>> a file so ls, and several other binaries were modified. You load up
>> python, whip up a quick script and boom you can see all the previously
>> hidden files. Kernel kit and you have to hook a few system calls and
>> monitor the incoming values. If it would return your file and the
>> 'password' wasn't given, you can return bogus information and EVERY tool
>> will fall for it.
>>
>> Also not everything has to be done in userland to get done. The kernel is
>> fully capable of sending out packets, creating files, etc. Userland in
>> fact relies on the kernel for all of these. If you get to the kernel you
>> control all of both worlds. You get the userland and in truth you only
>> control a portion of the userland.
>>
>> Mighty difference indeed.
>> On Dec 7, 2011 7:20 AM, "Paul Schmehl" <pschmehl_lists@...rr.com> wrote:
>>
>> But whether you have a kernel rootkit or not isn't all that important.
>>  In either case the system is going to be doing unwanted things, and you
>> detect those unwanted things with the usual system utilities.  If a
>> kernel rootkit didn't affect userland, what would be its purpose?  Even
>> to transmit data offsite you have to invoke network capabilities, file
>> system capabilities, etc.
>>
>> IOW, it's a distinction without difference.
>>
>> --On December 6, 2011 11:48:02 AM -0800 Gage Bystrom
>> <themadichib0d@...il.com> wrote:
>>
>>
>>
>>
>> My bad, should have said that you can't trust the md5sum tampering(since
>> you stated to have a static copy on the flash drive) but you couldn't
>> trust it since you couldn't trust the system calls.
>>
>> The immediate moment you have to worry about a legit userland rootkit you
>> have to worry about a kernel rootkit. After all you have to consider the
>> psychology of the attacker. If you were to compromise a box, and cared
>> enough to hide a backdoor they cannot detect without static, write proof
>> media, then you care enough to go the extra step for a kernel rootkit.
>> Otherwise you would be spending even more time and effort to make your
>> userland kit work to satisfaction for a far weaker hold on the box. It
>> would simply be idiotic. And I think we can all agree that an attacker
>> able to do either of the above is not an idiot.
>>
>> On Dec 6, 2011 10:19 AM, "Paul Schmehl" <pschmehl_lists@...rr.com> wrote:
>>
>>
>> A "poor man's" root kit detector is to take md5sums of critical system
>> binaries (you'd have to redo these after patching), and keep the list on
>> an inaccessible media (such as a thumb drive).  If you think the system
>> is compromised, run md5sum against those files, and you will quickly
>> know. You could even keep statically compiled copies on the thumb drive
>> to use in an investigation.
>>
>
>
>
> --
> Paul Schmehl, Senior Infosec Analyst
> As if it wasn't already obvious, my opinions
> are my own and not those of my employer.
> *********************************************
> "It is as useless to argue with those who have
> renounced the use of reason as to administer
> medication to the dead." Thomas Jefferson
> "There are some ideas so wrong that only a very
> intelligent person could believe in them." George Orwell
>
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ