[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What is the best free HIDS for Debian




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







Reply to: