What is the best free HIDS for Debian

[Sylvain]

Hello everyone !

I unsuccessfully tried Tripwire, Aide, Integrit and now OSSEC and OSSEC+.

All these softs throw errors while running or compiling on my Debian 11.3...

So can you tell me if there is another free HostBase Intrusion Detection
System.

Sylvain

[Hannes von Haugwitz]

Hi Sylvain,

On Mon, May 02, 2022 at 08:11:18PM +0200, Sylvain wrote:
> I unsuccessfully tried Tripwire, Aide, Integrit and now OSSEC and OSSEC+.
>
> All these softs throw errors while running or compiling on my Debian 11.3...

Can you please be more specific? What are the errors you get from AIDE
on Debian 11.3?

Best regards

Hannes

[Dave P.]

Did you try Suricata?

https://suricata.io/download/

D Pro

[Gianluca Gabrielli]

Have you checked Wazuh [0] out?


[0] https://wazuh.com/

--
. o . Gianluca Gabrielli gianlu.ca
. . o Software security engineer suse.com
o o o D78D 3FDC 2591 7EBA B52F 2362 6E17 38B8 2B60 B31D
-Dance like no one's watching, encrypt like everyone is-

[Darren S.]

Would definitely be good to know more detail on the issues you're
encountering with a pretty broad spectrum of tooling here.

I also recommend you take a look at osquery: https://osquery.io/

I'd also recommend a look at Wazuh as others have mentioned.

Another suggestion in the thread:

> Did you try Suricata?

This isn't HIDS, it's NIDS (network), but it's valuable nonetheless.
It's best deployed on a network perimeter or similar segment level to
protect multiple hosts. Particularly when running larger size
rulesets, memory consumption can be significant, so it may not be
suited for protecting each individual host in a fleet.

--
Darren Spruell
phatb...@gmail.com

[mlnl]

Hi Sylvain,

Sylvain <ssec...@free.fr> wrote:

>So can you tell me if there is another free HostBase Intrusion
>Detection System.

I have used Tripwire and Aide in the past and now, since a few years,
Samhain from source <https://la-samhna.de/samhain/> together with
signify instead of gnupg for the signature database but without
Beltane management. Btw. i don't think, the "best" HIDS exist.

--
mlnl

GPG:1FC05426F87FA623

[Sylvain]

Thank you for your responses!


Tripwire:
---------
- It throws a segfault error while scaning on one PC. No errors
mentioned in log files.
- on another machine tripwire worked fine for a long time but now I have
this error while scaning:
*** Fatal exception: basic_string::_M_create
*** Exiting...
run-parts: /etc/cron.daily/tripwire exited with return code 8


Aide:
-----
I have a segfault and this line in syslog: kernel: [ 1771.894150]
aide[7032]: segfault at 1c ip 00007f7472672050 sp
00007fffc95d5bf0 error 4 in libnss_systemd.so.2[7f7472671000+33000]. The
system is up to date from backports. The segfault is solved if I use the
aid-dynamic package, but the scan is too much long...


Integrit:
---------
I have this error while initializing the DB: integrit (main): Error:
walk_file_tree: Permission denied
The support is simply a mailing list and I still don't have an answer
about this problem.


OSSEC:
------
There is no .deb for this soft. The compilation ends with an error. I've
just contact the support.


OSSEC+:
-------
There's a problem during installation. I've just contact the support.



I'll test Wazuh.

[Jonathan Hutchins]

With that many errors from that many different programs it strongly
suggests that there is a problem with your filesystem, possibly an
existing infection.

When testing for intrusion on a system that has been running with a live
connection, it's necessary to test from an inviolate source, an ISO
image that is known to be un-infected. Obviously, this should not be
created on an infected machine, which is a problem if you have limited
resources.

Nevertheless, you can try building a live image and testing from that.

--
Jonathan

[Elmar Stellnberger]

On 03.05.22 15:03, Jonathan Hutchins wrote:
> When testing for intrusion on a system that has been running with a live
> connection, it's necessary to test from an inviolate source, an ISO
> image that is known to be un-infected.  Obviously, this should not be
> created on an infected machine, which is a problem if you have limited
> resources.
>

Yes, exactly. If you are running Debian I would personally recommend
debcheckroot (https:/www.elstel.org/debcheckroot/). It can test against
fresh, untampered binary packages from any bootable Linux media. Debian
is not required, use the next Linux magazine dvd. A system like Tripwire
that monitors against file changes can itself be attacked, manipulating
the checksums being stored by it in a way that you won´t detect these
changes. You would need a backup of the sha256sums from a time of before
the intrusion which is however not too old either. Using a package based
checksum verifier like debcheckroot you do not have these problems!
Note also that the date and time of the *first* intrusion may be
before of what you think they are from the timeline if you have a tricky
attacker. Timeline (file access, modification, creation times) is good
for reconstructing on what has happened but you don´t need any with
debcheckroot.

[Marc Haber]

On Tue, May 03, 2022 at 02:18:51PM +0200, Sylvain wrote:
> I have a segfault and this line in syslog: kernel: [ 1771.894150]
> aide[7032]: segfault at 1c ip 00007f7472672050 sp
> 00007fffc95d5bf0 error 4 in libnss_systemd.so.2[7f7472671000+33000]. The
> system is up to date from backports. The segfault is solved if I use the
> aid-dynamic package, but the scan is too much long...

What did you exclude from the default configuration? aide is in default
configured to check all home directores, which is probably not a good
idea if they contain millions of movies and pictues.

Did you read the fine README.Debian that comes with the aide package?

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

[Sylvain]

Thank you very much for your answers.

I've tried to install Wazuh. It works fine but I can't install the agent
and the manager on the same PC. Is it normal? However this soft seems to
be very complex for my domestic needs...

I've just tried debcheckroot too. It throws error. I'll try to fix them.

Best regards,
Sylvain

[Elmar Stellnberger]

Dear Sylvain

Am 04.05.22 um 13:17 schrieb Sylvain:

> I've just tried debcheckroot too. It throws error. I'll try to fix them.

Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
> Here's the fileserror.lis:
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
> ...

I hope you won´t mind that I am citing the output of debcheckroot you
have given me.
These three files point to an infection with a rootkit. Don´t care
about modified configuration files like in /etc too much (but you may
still have a look at them). Executable files on the other hand must
never be modified. If these three files are different it means that
someone has altered your system. If you look at the man pages of these
executables then you also know that a maker of a rootkit would have
interest to modify exactly these files.

> The file filesunverified.lis is very long, while pkgcorrupt.lis is empty.

If you have updated your system some time ago and there are newer
versions on the update server now then debcheckroot can certainly not
find these packages any more. You could try to update your system and
then verify again. Normally the rootkit will persist. However connecting
your computer to a network may be detrimental since the rootkit owner
may simply uninstall his rootkit once he knows that his malware has been
discovered.
I would at least save suspicious executables first and additionally
the packages with known good of the same version.

Regards,
Elmar

[Elmar Stellnberger]

Dear Sylvain

The next thing I would do is create a timeline. Mount the partition with
noatime so that access times are preserved as they are on new file
operations and then let find output access, modification and creation
time of all files. Look on when these three executables have been
modified/created and then search back on what has happened at the
earliest time right before the rootkit has been installed. Once I
analysed a system of mine like this and found out that some suspicious
files had been uploaded in the ~/.skype directory. If I remember back I
think I had used vim for it but it should also be possible to use sth.
like sort.

Regards
E.

Am 06.05.22 um 15:52 schrieb Elmar Stellnberger:

[Sylvain]

Dear Elmar,

Thank you for your help. I really appreciate very much.

I thought a lot about your answer and I feel a bit tricky... I
understand what you're writing but I don't know how to do this.

Do you think I can simply get rid of these rootkit? I've tried to move
the file "crontab" in a safe place and then reinstall the package cron.
The new "crontab" file seems to be the same as the previous since the
md5 are equal, but debcheckroot still throws an error for it...

Regards

Sylvain

[Elmar Stellnberger]

On 08.05.22 16:51, Sylvain Sécherre wrote:
> I thought a lot about your answer and I feel a bit tricky... I
> understand what you're writing but I don't know how to do this.
>
> Do you think I can simply get rid of these rootkit? I've tried to move
> the file "crontab" in a safe place and then reinstall the package cron.
> The new "crontab" file seems to be the same as the previous since the
> md5 are equal, but debcheckroot still throws an error for it...
>

Dear Sylvain

No, I don´t think you can get rid of the rootkit by reinstalling a
package. Usually rootkits are designed in a way that updating or
reinstalling packages doesn´t damage the rootkit. The best thing to do
is to reinstall new from scratch. In order to do this without
complications I have an own home partition that I can register and reuse
with /etc/fstab. If you don´t have that make a

> cp -a /home /mnt/usbhdd/home

However that is not all you need to respect. Basically any infected
file can cause the rootkit to get reinstalled on your computer. That can
also be the case for hidden files in your home directory like
/home/sylvain/.*
I always do it like this:

> cd /home/sylvain
> ls -lad .[^.]*
> mkdir /mnt/usbhdd/hidden-quarantine
> mv .[^.]* /mnt/usbhdd/hidden-quarantine

the .[^.]* - expression works like this:
* first match anything that starts with a dot (under Linux hidden files
start with dots)
* second match a character that is not a dot [^.]: This excludes ..
which denotes the parent directory. This one should of course not be copied
* third match any from zero up to more characters: *

Make sure that you move away the hidden files before you copy your
home directory back.
Moving away hidden home directory files will also reset your Firefox
bookmarks and saved passwords. If you have progressed this far I can
tell you how to reinstall them - and under normal circumstances reusing
a database file should not cause a rootkit to reinstall. If you are very
thorough you can export the bookmarks as html and write down all saved
passwords on a sheet of paper. You need to know however that getting rid
of a rootkit with 100% certainty is hard since basically any binary file
can result in an attack vector.
If you have progressed this far, sure I am going to continue to help
you with setting up a new installation and rescuing bookmarks (at least
for FF).

Kind Regards,
Elmar

[Elmar Stellnberger]

[Michael Lazin]

I think if you have a root kit it is very unlikely to get rid of it without backing up and reimaging but you may be able to achieve it if you try first rkhunter and second apparmor which is similar to selinux which was developed by the nsa and made accessible as a Red Hat package.  Both solutions have the ability to limit what root can do and is your only real option for saving a rooted system.  It is important that if you try this that you dump your memory rkunter picks up a memory anomaly.  Fileless malware is popular among sophisticated threat actors and rkhunter is equipped to find malware that resides in memory.  Apparmor is included in Debian.

Thanks,

Michael Lazin

--

Michael Lazin

.. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.

[Elmar Stellnberger]

Hi Sylvain

If you also care about the package selection you have installed you
may do a 'dpkg -l' or copy /var/lib/dpkg/status. Possibly I will write
something to clean the status file from packages that will be installed
implicitly as dependency. Under Mageia you can use urpmi_rpm-find-leaves
for that. Possibly also ask at a Debian mailing list (and tell me about it).
I also forgot that you should possibly
> cp -a /etc /media/usbdisk
to save configuration files for later lookup. The /etc directory is
not that big and you can copy it.

Elmar

On 08.05.22 17:15, Elmar Stellnberger wrote:
> On 08.05.22 16:51, Sylvain Sécherre wrote:

>> I thought a lot about your answer and I feel a bit tricky... I
>> understand what you're writing but I don't know how to do this.
>>
>> Do you think I can simply get rid of these rootkit? I've tried to move
>> the file "crontab" in a safe place and then reinstall the package
>> cron. The new "crontab" file seems to be the same as the previous
>> since the md5 are equal, but debcheckroot still throws an error for it...
>>

[este...@elstel.org]

Am 08.05.22 um 20:21 schrieb Michael Lazin:> I think if you have a root

kit it is very unlikely to get rid of it
> without backing up and reimaging but you may be able to achieve it if
> you try first rkhunter and second apparmor which is similar to selinux
> which was developed by the nsa and made accessible as a Red Hat
> package. Both solutions have the ability to limit what root can do and
> is your only real option for saving a rooted system. It is important
> that if you try this that you dump your memory rkunter picks up a
> memory
> anomaly. Fileless malware is popular among sophisticated threat actors
> and rkhunter is equipped to find malware that resides in memory.
> Apparmor is included in Debian.
>
> Thanks,
> Michael Lazin

Yes, it would be really interesting if rkhunter has also found the
rootkit. If it was developed by the NSA, I am sure it would not find a
rootkit used by the NSA. To my knowledge Apparmor was first developed as
part of openSUSE. I can remember having filed them a report with the
quest to keep Apparmor as it is more easy to use than SELinux.

Elmar

P.S.: A memory only rootkit would still need a hook to reinstall on a
fresh boot.

[Michael Lazin]

SELinux was made by the NSA but it open source, anyone can review the source code, this is part of what makes open source software reliable, it gets seen by many eyes, and even if you don’t review every line of code yourself you have a web of trust that someone has reviewed it, and it is strengthened by key signing which is more common in the Debian community.  Thank you.  

Michael Lazin

[este...@elstel.org]

Am 08.05.2022 20:48, schrieb Michael Lazin:
> SELinux was made by the NSA but it open source, anyone can review the
> source code, this is part of what makes open source software reliable,
> it gets seen by many eyes, and even if you don’t review every line
> of code yourself you have a web of trust that someone has reviewed it,
> and it is strengthened by key signing which is more common in the
> Debian community. Thank you.
>
> Michael Lazin
>

If you talk about SELinux then let me talk about the times when
Apparmor was not a default component to be installed, when I was
creating and sharing Apparmor profiles to keep this technology
supported. Sure, I have also read into SELinux. It can offer a better
level of security, but it is more difficult to create profiles for it.
The thing about rkhunter as I learned to know it was that it can only
detect known rootkits. So who is adding NSA rootkits then? I am sure the
NSA knows to prevent this. It would be nice to know about the circle of
people who add rootkit descriptions/ detection code. Any way, if they
have written the software, they will always know about the quirks and
intricacies to avoid detection when it comes for them to deploy their
own rootkits.

[este...@elstel.org]

Am 08.05.2022 20:43, schrieb este...@elstel.org:
> P.S.: A memory only rootkit would still need a hook to reinstall on a
> fresh boot.

Yes I know it is an issue. Debcheckroot does f.i. not check you
initrd. To fix this issue I would need to program an own piece of
software like debcheckinitrd. Anyone who wants to support me can do
this: https://www.elstel.org/Contact.html. I am a free developer and I
do not get paid for my open source related work.

[Michael Lazin]

Rkhunter does find patterns of known rootkits but it also finds indicators like memory anomalies like I mentioned and it logs each file change from the install, this is why ideally you should install it in a fresh system.  Thanks.

Michael Lazin

[Tomasz Ciolek]

Hi All

I have been following this discussion with some interest.

I have few questions, which all go to

1. what behaviour leads the syetem owner/manager to believe that there is a security issue at play here?
2. how old is the syusytem in question?
3. have there been manual tools installs done on the system?
4. Has the system been fully updated/upgraded?
5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?
6. finally - does the debcheckroot tool look at the security distribution archive as well as the
main debian archive? There are times where packages are updated in the
security archive, but not reflected in mailine

Cheers
Tomasz

--
Tomasz M. Ciolek
*******************************************************************************
tmc at vandradlabs dot com dot au
*******************************************************************************
GPG Key ID: 0x830AD092288EF017
GPG Key Fingerprint: 07DF B95B DB58 57B6 9656 682E 830A D092 288E F017
Key available on good key-servers
*******************************************************************************

[Elmar Stellnberger]

Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:

> 5. have we eliminated other causes of file mismatch - bad/incomplete
> updates, corrupted HDD, bad RAM, user error ?

If exactly such files have been changed where there is reason to
manipulate them for a rootkit then one shall assume unequivocally that
there is a rootkit installed. With bad RAM you get a system crash and
with a physically bad hard disk you get filesystem errors on fsck, none
of which you get with a rootkit where only certain files have been
manipulated intentionally. A broken update could theoretically result in
a singleton file of half the size. Usually running programs keep to use
the old version of the file under Linux while newly issued open
operations on the same file name will use the file as replaced by an
update. A file of half the size would however result in an unusable
program, none of which you would usually observe with a rootkit.

Elmar

[Michael Lazin]

This supports the use of rkhunter and running it once on first install but you can manually find file changes systematically by becoming root and going to the top level directory and running “find -ctime 1”, “find -ctime -2” etc ad infinitum until you find all files that may have been compromised.  This method will not find deleted files so some expertise in the Linux file system is necessary when not using rkhunter.  

Thanks,

Michael Lazin

[t...@vandradlabs.com.au]

On 2022-05-09 18:04, Elmar Stellnberger wrote:
> Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:
>> 5. have we eliminated other causes of file mismatch - bad/incomplete
>> updates, corrupted HDD, bad RAM, user error ?
>
> If exactly such files have been changed where there is reason to
> manipulate them for a rootkit then one shall assume unequivocally that
> there is a rootkit installed. With bad RAM you get a system crash and
> with a physically bad hard disk you get filesystem errors on fsck,

Not always true. I have experienced what looked like creeping file
system corruption that was
in the end tracked down to bad RAM. it only occred under heavy load when
RAM was over-utilised
and then swapped out.

> none of which you get with a rootkit where only certain files have
> been manipulated intentionally. A broken update could theoretically
> result in a singleton file of half the size. Usually running programs

again I have seen bad/partial

> keep to use the old version of the file under Linux while newly issued
> open operations on the same file name will use the file as replaced by
> an update. A file of half the size would however result in an unusable
> program, none of which you would usually observe with a rootkit.

I would want to see more info9rmationa botu what diagnostics were
done before I cry rootkit.

But if you wish to err on side of caution, backup your data and rebuild
the box.
Then restore the data bit by bit avoiding executables.

Cheers
Tomasz

[Elmar Stellnberger]

Am 09.05.22 um 13:34 schrieb t...@vandradlabs.com.au:

>
>
> On 2022-05-09 18:04, Elmar Stellnberger wrote:
>> Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:
>>> 5. have we eliminated other causes of file mismatch - bad/incomplete
>>> updates, corrupted HDD, bad RAM, user error ?
>>
>>   If exactly such files have been changed where there is reason to
>> manipulate them for a rootkit then one shall assume unequivocally that
>> there is a rootkit installed. With bad RAM you get a system crash and
>> with a physically bad hard disk you get filesystem errors on fsck,

Yes, bad cache ram written on a hard disk can at least by theory
result in corrupted files on disk. If you read what I have written then
you see my argument that then the whole program would have become
unusable which is not the case for our example. Also I want to add that
bad ram just causing file corruptions but no crash is somewhat very
unlikely.

>
> Not always true. I have experienced what looked like creeping file
> system corruption that was
> in the end tracked down to bad RAM. it only occred under heavy load when
> RAM was over-utilised
> and then swapped out.

As said, I don´t really believe on what you tell here. By theory
non-ECC ram can have errors, but these are very rare. Damaged ram on the
other hand is damaged independent of the system load and it usually
causes more severe/obvious effects. The probability that a corrupt ram
block affects only block data but no kernel data structures is not that
high as these tend to be interleaved.

>
>> none of which you get with a rootkit where only certain files have
>> been manipulated intentionally. A broken update could theoretically
>> result in a singleton file of half the size. Usually running programs
>
> again I have seen bad/partial

An update can only leave a partial file that is a prefix of an
original file, never a corrupted one. That is, if you read, what I have
told. All modern Linux filesystems use journalling and there will be no
corruption like eventually on old Windows machines.

> I would want to see more info9rmationa botu what diagnostics were
> done before I cry rootkit.
>

You are one of the people who want to tell people that they are not
infected by a rootkit, when they obviously are. My recommendation for
everyone is, care not to trust such people!
Besides this I have requested Sylvain to collect more information, as
this can still be interesting.

[Tomasz Ciolek]

On Mon, May 09, 2022 at 01:55:20PM +0200, Elmar Stellnberger wrote:
> You are one of the people who want to tell people that they are not
> infected by a rootkit, when they obviously are. My recommendation for
> everyone is, care not to trust such people!

One: Show me that due dilidgebnce was done, and I will agree with your
rootkit theorem. As you stated, data collection is ongoing, but it
seems you have already made up your mind. That is not intellecutally
honest. that is looking for confirmation bias.

Two: Do you feel personally offended, somehow, that I ask questions,
to start being personally accustative and agressive? I am simpoly
suggesting there are other, sometimes simpler explanations. Disocount
them all before you say "rootkit".

kind regards
Tomasz

[Vitaly Krasheninnikov]

Hi Elmar,
Thank you for debcheckroot. I think it is a great project, which makes us one step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed us: "..._.GM" and "..._..M".
According to the description on your website, it means the modification of the file permissions, not the actual content.

Since I was curious, I tried debcheckroot on my system, and found the same binaries at fileserror.lis (amongst a few others):

..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755

Here is the actual u/g and permissions:
-rwxr-sr-x 1 root crontab Feb 23 2021 /usr/bin/crontab
-rwsr-xr-x 1 root root Jan 13 22:32 /usr/bin/pkexec
-rwxr-sr-x 1 root ssh Mar 13 2021 /usr/bin/ssh-agent

It is indeed different from the original deb-package permissions but I found the reason for that:
# egrep -e dpkg-statoverride /var/lib/dpkg/info/cron.postinst
dpkg-statoverride --update --add root crontab 2755 /usr/bin/crontab
# egrep -e chmod -e chgrp /var/lib/dpkg/info/openssh-client.postinst
chgrp ssh /usr/bin/ssh-agent
chmod 2755 /usr/bin/ssh-agent
# egrep -e set_perms /var/lib/dpkg/info/policykit-1.postinst
set_perms() {
set_perms root root 4755 /usr/bin/pkexec

So while I truly consider the debcheckroot very useful, I think in this case it was a false positive due to the side effects of the postinst scripts of the relevant packages.

Thank you,
Vitaly

[Richard van den Berg]

On 10/05/2022 05:37, Vitaly Krasheninnikov wrote:

> Thank you for debcheckroot. I think it is a great project, which makes us one step closer to a verifiable Debian system.
> In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed us: "..._.GM" and "..._..M".
> According to the description on your website, it means the modification of the file permissions, not the actual content.

Thanks a lot for clarifying this. I found the interpretation of the
results of debcheckroot at https://www.elstel.org/debcheckroot/

On 06/05/2022 15:52, Elmar Stellnberger wrote:
> Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
> > Here's the fileserror.lis:
> > ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> > ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root
> 755
> > ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
> > ...
>
>   I hope you won´t mind that I am citing the output of debcheckroot
> you have given me.
>   These three files point to an infection with a rootkit. Don´t care
> about modified configuration files like in /etc too much (but you may
> still have a look at them). Executable files on the other hand must
> never be modified. If these three files are different it means that
> someone has altered your system. If you look at the man pages of these
> executables then you also know that a maker of a rootkit would have
> interest to modify exactly these files.

Since you are the author of the debcheckroot tool, why do you think that
the G (group) and M (mode) flags indicate the content of the files were
altered? Or did you make a mistake and forgot what the output of
debcheckroot actually means? If so, does this change your opinion that a
rootkit is installed on this system?

Kind regards,

Richard

[Elmar Stellnberger]

Dear Vitaly

On 5/10/22 05:24, Vitaly Krasheninnikov wrote:
> Hi Elmar,

> Thank you for debcheckroot. I think it is a great project, which makes us one step closer to a verifiable Debian system.
> In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed us: "..._.GM" and "..._..M".
> According to the description on your website, it means the modification of the file permissions, not the actual content.

> ...

> So while I truly consider the debcheckroot very useful, I think in this case it was a false positive due to the side effects of the postinst scripts of the relevant packages.
>
> Thank you,
> Vitaly
>

Thanks for pointing that out! I have not used the tool for long on my
own, so that I forgot about the change indication marker letters. Of
course there isn´t much you can say about the modified group and file
permission of a file. See here what Sylvain Sécherre had written me in
her original email:

On 5/6/22 15:05, Sylvain Sécherre wrote to este...@elstel.org,
(BCC possible):
> Hello Elmar,
> ...

> Here's the fileserror.lis:
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755

> ..._..M /usr/libexec/polkit-agent-helper-1
> ...

> The file filesunverified.lis is very long, while pkgcorrupt.lis is empty.
>

> I ran debcheckroot on a possibly infected machine.
>
> Thank you for your help!
>
> Best regards,
>
> Sylvain

If debcheckroot was executed inside the infected root file system,
then no wonder it can´t find anything. The rootkits I know, and I have
discovered and burned several root kits on blue ray, have behaved like
this: Inside the root infected executables compare ok against the
pristine version, but not so outside the rootkit root when you have a
fresh boot. The fact that group and file permissions of these
executables have changed could at least be interpreted as suspicious
though, since normally I´d truly believe there will be nobody who
modifies that.

Regards,
Elmar

[Sylvain]

Dear Elmar,

Thank you for your tips. But before reinstalling from scratch on my
desktop, that is a lot of work, I will reinstall Debian on an old
netbook which is on a desk and I don't use anymore. I'll run debchekroot
on it and we will see...

I must apology if my English is not very good. I'm french and I do
really have problems learning over languages. So sorry if I'm not very
clear and if I use words in an unusual way...

Best regards,
Sylvain

[este...@elstel.org]

Michael Lazin had published a private email between me an Sylvain
Sécherre. It means he is an NSA guy, since he had access to a wiretapped
conversation.

https://lists.debian.org/debian-security/2022/05/msg00018.html

-------- Originalnachricht --------
Betreff: Re: Fwd: What is the best free HIDS for Debian
Datum: 12.05.2022 12:53
Von: Sylvain Sécherre <ssec...@free.fr>
An: Elmar Stellnberger <este...@elstel.org>



Dear Elmar,

Don't worry about this, feel free to cite me if you want, even if it was
a private mail.

However, I'd prefer posting on usenet because it's a sharing attitude!
So, if you don't mind, let's continue this topic on
linux.debian.security.

Best regards,

Sylvain
-------------------------

Le 11/05/2022 à 18:45, Elmar Stellnberger a écrit :

> Dear Sylvain
>

> When you first wrote to me asking for help I saw that the email was
> only addressed to me and I wanted to keep our conversation
> confidential. However then I got the email I am forwarding you now
> from below cited by Miachel Lazin (read here:
> https://lists.debian.org/debian-security/2022/05/msg00018.html)
> publicly on the list so that I got to believe that you had
> intentionally made the conversation public. Now I have checked the
> email in my Inbox again and the headers say that I am the only
> addresse, if there was no BCC by you. If your writings were public, so
> why did I keep my own ones confidential then? When I noticed I re-sent
> my emails with the same sending date of before but now also to
> debian-...@lists.debian.org.
> The more I think about it, the more I am prone to believe that
> Michael Lazin could be an NSA guy who has published a mail, which both
> of us wanted to keep confidential. If this has happened, please excuse
> my re-sending of our private emails publicly to the debian-security
> list! If I err in what I have started to believe now, please do also
> clarify that for me.
>
> to put it in short: An email adressed privately to me has appeared on
> the debian-security list, and if you haven´t used BCC to yield this,
> then it means that M.L. was the one who has wiretapped and published
> an email meant to be confidential. If he did and I have made emails
> public because of this which you didn´t want to have public, then my
> sincere excuse for what has happened here!
>
> Best Regards,
> Elmar

>
> -------- Forwarded Message --------
> Subject: Re: What is the best free HIDS for Debian
> Date: Sun, 8 May 2022 16:51:46 +0200
> From: Sylvain Sécherre <ssec...@free.fr>
> To: Elmar Stellnberger <este...@elstel.org>
>
> Dear Elmar,
>

> Thank you for your help. I really appreciate very much.
>

> I thought a lot about your answer and I feel a bit tricky... I
> understand what you're writing but I don't know how to do this.
>
> Do you think I can simply get rid of these rootkit? I've tried to move
> the file "crontab" in a safe place and then reinstall the package
> cron. The new "crontab" file seems to be the same as the previous
> since the md5 are equal, but debcheckroot still throws an error for
> it...
>

> Regards
>
> Sylvain
>
>
------------------------------------------------------------------------

>
>
> Le 06/05/2022 à 16:13, Elmar Stellnberger a écrit :
> Dear Sylvain
>
> The next thing I would do is create a timeline. Mount the partition
> with noatime so that access times are preserved as they are on new
> file operations and then let find output access, modification and
> creation time of all files. Look on when these three executables have
> been modified/created and then search back on what has happened at the
> earliest time right before the rootkit has been installed. Once I
> analysed a system of mine like this and found out that some suspicious
> files had been uploaded in the ~/.skype directory. If I remember back
> I think I had used vim for it but it should also be possible to use
> sth. like sort.
>
> Regards
> E.
>

> Am 06.05.22 um 15:52 schrieb Elmar Stellnberger:

> Dear Sylvain
>
> Am 04.05.22 um 13:17 schrieb Sylvain:
> I've just tried debcheckroot too. It throws error. I'll try to fix
> them.
>

> Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:

>> Here's the fileserror.lis:
>> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
>> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root
> root 755
>> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root
> 755

>> ...
>
> I hope you won´t mind that I am citing the output of debcheckroot
> you have given me.
> These three files point to an infection with a rootkit. Don´t care
> about modified configuration files like in /etc too much (but you may
> still have a look at them). Executable files on the other hand must
> never be modified. If these three files are different it means that
> someone has altered your system. If you look at the man pages of these
> executables then you also know that a maker of a rootkit would have
> interest to modify exactly these files.
>

>> The file filesunverified.lis is very long, while pkgcorrupt.lis is
> empty.
>

[Elmar Stellnberger]

I mean Michael Lazin didn´t say anything bad, on the contrary he has
given us some valuable information. I just wanted people to know here
that secret services apparently have their people posting on this list,
likely not always disinterestedly. I have double checked with Sylvain -
her mail had in deed been written to be between her and me only although
it had been cited by this person.

Elmar

Am 13.05.22 um 20:01 schrieb este...@elstel.org:

> Michael Lazin had published a private email between me an Sylvain
> Sécherre. It means he is an NSA guy, since he had access to a wiretapped
> conversation.
>
> https://lists.debian.org/debian-security/2022/05/msg00018.html
>
> -------- Originalnachricht --------
> Betreff: Re: Fwd: What is the best free HIDS for Debian
> Datum: 12.05.2022 12:53
> Von: Sylvain Sécherre <ssec...@free.fr>
> An: Elmar Stellnberger <este...@elstel.org>
>
>
>
> Dear Elmar,
>
> Don't worry about this, feel free to cite me if you want, even if it was
> a private mail.
>
> However, I'd prefer posting on usenet because it's a sharing attitude!
> So, if you don't mind, let's continue this topic on
> linux.debian.security.
>
> Best regards,
>
> Sylvain
>

> ...

[Noah Meyerhans]

Can we please take this tinfoil hat lunacy somewhere else? There are
plenty of conspiracy theory forums out there. I'm sure you've got your
favorite, but this isn't one.

[Elmar Stellnberger]

From what Sylvain has answered me, she didn´t do that. As said the mail
header I got also did not show anything like that.

Am 13.05.22 um 20:25 schrieb Adam D. Barratt:

> On Fri, 2022-05-13 at 20:01 +0200, este...@elstel.org wrote:
>> Michael Lazin had published a private email between me an Sylvain
>> Sécherre. It means he is an NSA guy, since he had access to a
>> wiretapped
>> conversation.
>>
>> https://lists.debian.org/debian-security/2022/05/msg00018.html
>>
>

> So far as I can see, the mail in question made it to debian-security
> because it was posted to linux.debian.security and was then
> automatically reposted via mail.
>
> The headers of
> https://lists.debian.org/debian-security/2022/05/msg00017.html , which
> is the mail you claim was private, include:
>
> Message-Id: <6277d936$0$22287$426a...@news.free.fr>
> X-Trace: 1652021558 news-2.free.fr 22287 86.254.12.140:18486
> X-Complaints-To: ab...@proxad.net
> Sender: rob...@news.nic.it
> X-Original-Newsgroups: linux.debian.security
>
> which look remarkably similar to those from one of Sylvain's mails
> earlier in the thread.
>
> Regards,
>
> Adam
>

[Adam D. Barratt]

On Fri, 2022-05-13 at 20:01 +0200, este...@elstel.org wrote:

> Michael Lazin had published a private email between me an Sylvain
> Sécherre. It means he is an NSA guy, since he had access to a
> wiretapped
> conversation.
>
> https://lists.debian.org/debian-security/2022/05/msg00018.html
>

[Sylvain]

Hello,

Le 13/05/2022 à 20:30, Elmar Stellnberger a écrit :
> From what Sylvain has answered me, she didn´t do that. As said the mail
> header I got also did not show anything like that.

I must precise that I'm a man. "Sylvain" is for boys and "Sylvie" for
girls. :)

[Sylvain]

Hello,

Here's the result of debcheckroot on an entirely fresh install of
debian, without any access to the internet from a browser or a mail
client. I only:
- ran "apt update" to test my internet connection
- copied files on a USB stick

Here's the fileserror.lis:

..._..M /usr/libexec/polkit-agent-helper-1
policykit-1_0.105-31+deb11u1_amd64 root root 755

..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755

.._L... /usr/share/dict/words american-english
wamerican_2019.10.06-1_all root root 777
..._.GM /usr/lib/dbus-1.0/dbus-daemon-launch-helper dbus_1.12.20-2_amd64
root root 755
_.C_... /var/lib/aspell/en-common.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-variant_2.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-w_accents-only.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en-wo_accents-only.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en.compat aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-w_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_AU-wo_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-w_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_CA-wo_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ise-w_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ise-wo_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ize-w_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-ize-wo_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-variant_0.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_GB-variant_1.rws aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_US-w_accents-only.rws
aspell-en_2018.04.16-0-1_all
_.C_... /var/lib/aspell/en_US-wo_accents-only.rws
aspell-en_2018.04.16-0-1_all
..._..M /bin/fusermount fuse_2.9.9-5_amd64 root root 755
..._..M /bin/ntfs-3g ntfs-3g_1:2017.3.23AR.3-4+deb11u1_amd64 root root 755
_.._..M /etc/sudoers sudo_1.9.5p2-3_amd64 root root 644

Greetings,
Sylvain

[Elmar Stellnberger]

Sylvain,

I just wanna warn you that there is a hardware backdoor in x86
computers. Using that you won´t see any manipulation; like from a fresh
install. See: https://www.elstel.org/uni/ DualSat master thesis,
Epilogue, point 6 (as far as I remember, or last point).

Also please don´t re-send private emails like this one as new to
debian-security. People will misinterpret your emails if they do not
know the whole conversation.

Elmar

P.S.: If emailing does not work for you, you can call me via phone,
usually on Tuesday, Wednesday and Thursday, but not this/next week; see
elstel.org/Contact.html. FAX is also a possibility.


Am 16.05.22 um 12:34 schrieb Elmar Stellnberger:
> Dear Sylvain
>
>   That does not expose any rootkit. It is of course possible that the
> rootkit had already been deinstalled when you ran the test. Basically if
> you have suspicion you would need to unplug any physical connection. You
> could run an update before if you think the rootkiter has no reason to
> suspect what you will do next.
>   I have discovered my first rootkit by installing offline merely from
> DVD, without updates. Then I installed again on a plain media and
> compared file for file (with a program called dircmp that I have not
> published yet). Afterwards I decided to write debcheckroot and that time
> it made me discover some more rootkits which I had burnt on blue ray
> along with the good files/packages to save evidence.
>
> Yours,
> Elmar
>
>
> Am 16.05.22 um 11:38 schrieb Sylvain:

[Elmar Stellnberger]

Am 16.05.22 um 11:38 schrieb Sylvain:

> Hello,
>
> Here's the result of debcheckroot on an entirely fresh install of
> debian, without any access to the internet from a browser or a mail
> client. I only:
> - ran "apt update" to test my internet connection
> - copied files on a USB stick
>
> Here's the fileserror.lis:
>
> ..._..M /usr/libexec/polkit-agent-helper-1
> policykit-1_0.105-31+deb11u1_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
> .._L... /usr/share/dict/words american-english
> wamerican_2019.10.06-1_all root root 777
> ..._.GM /usr/lib/dbus-1.0/dbus-daemon-launch-helper dbus_1.12.20-2_amd64
> root root 755

Dear Sylvain
Dear readers of debian-security

I have now analyzed these packages and in deed policykit sets setuid
permissions in the postinst script manually instead of having these
files unpacked with setuid bit set. This in order to honor
dpkg-statoverride --list. However the problem for debcheckroot is that
it can hardly analyze the postinst scripts; analyzing program logic
would be turing complete and every postinst script is different.

policykit: calls set_perms if no statoverride present
cron: package configures dpkg-statoverride on its own
openssh-client: direct chmod, chgrp if no statoverride present
dbus: invokes dpkg-statoverride if not yet present

Almost each of these packages would need its own logic for scanning
the postinst script for setuid/chown/chgrp changes. Since there are only
a limited number of such setuid programs it would be doable but probably
not worth doing since as it turned out you can never truly rely merely
on file modes any way.
Debcheckroot was designed to detect file content alterations and it
has several ways to do so. If this feature is not used you don´t get
meaningful output information.

So this time it was a false alarm. Debcheckroot did not detect
anything, but in order for debcheckroot to be able to detect something
you need to follow the recommendations at
https://www.elstel.org/debcheckroot/. Most important is - do not scan
from inside of the infected system. This does almost never give usable
information.
Please also excuse that I did not remember the docs correctly. I have
not used the program on my own for quite a long time now. My main
productive system has been running on Mageia and so applying
debcheckroot was no more option for me.

Finally I wanna conclude that this does certainly not mean Sylvain´s
system was/is clean. Normally if you have a suspicion like him you don´t
have that without reason. Also I have seen many rootkits not detected by
rkhunter and chkrootkit, but yes by debcheckroot (I still have blue ray
images of these incidents). If debcheckroot is not applied correctly it
won´t yield any good result however. Besides this it is already quite a
long time ago since I had developed that script and perhaps today´s
rootkits are more prudent like the suggested memory only rootkits. To
scan for this I would need to develop something like debcheckinitrd.
Doable, but if there is little true known interest I won´t do that
without any reward since my own interest is different. I just know from
the weblogs that a South American university is using it besides some
private people.

The only thing that speaks for Sylvain´s initial allegation is that
here appear to be posting people on this list who wiretap our private
communication. He said "Feel free to cite me even if it WAS A PRIVATE
EMAIL". - and that private email got cited by Michael Lazin posting on
this list. Sylvain would have told me if the email was not private
because this was my question. It is the only thing provable for me now.
Also I have noted that several emails addressed only to me got posted to
the whole list. I simply don´t believe that Sylvain would do that
intentionally for several times. At least I have not heard any
explanation for it by him. I´d also believe there is no reason to
interfere with me helping Sylvain if none of us were targeted in some
way. I have asked Sylvain multiple times to repeat the scan fromout of a
clean boot CD, because that could have been interesting. As far as what
has reached me, he did not do that yet.

Regards,
Elmar Stellnberger