Fwd: Re: Fwd: What is the best free HIDS for Debian
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 An: Elmar Stellnberger 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-security@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 To: Elmar Stellnberger 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. 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
Re: What is the best free HIDS for Debian
Am 08.05.2022 20:43, schrieb estel...@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.
Re: What is the best free HIDS for Debian
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.
Re: What is the best free HIDS for Debian
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.
Fwd: Re: arbitrary code execution on unformatted usb stick
I am forwarding you this email in the hope that it will be useful: (They simply could not have known what reason I was installing mininet for and that I would try to install it at all if they would not have observed what I was doing even if they would have supposed that I wanna continue on a̅tea. Besides this kind of live-blocking every step that would be useful to achieve my goal is noteable on a computer that I believed to be totally clean in the time before. That was how things started to uncover.) Originalnachricht Betreff: Re: arbitrary code execution on unformatted usb stick Datum: 02.05.2020 18:22 Von: estel...@elstel.org An: vi...@vheuser.com Dear Vince I in deed mean that they have an internet connection channel for this offline computer. The computer does not have Wifi nor a LAN cable. What they were doing can not be explained by other means. I wonder how they transfer the data between the internet and that computer that should be separated physically from the internet. What I have observed can not be explained by malware unleashed at the time I have last plugged an USB stick. Elmar Am 02.05.2020 18:16, schrieb vi...@vheuser.com: Yes, I know the article and the long history building up that capacity. You may recall I backed you up on the DANE support discussion. What you are developing is a reliable secure software system. The problem of compromised hardware is a different problem. Intel builds back door circuits for NSA into their chips So I don't think you'll build a laptop from them that NSA can't compromise. Unless you are engaging in international espionage or blowing the whistle on them like Eric Snowden, I don't think they will compromise their systems on low value targets. In that case, it doesn't make much difference that they can get in, does it? On the other hand, a working DANE system can be used to keep our conversation between us against most others except NSA and that alone is worth something. Isn't it? Debian Security list members can't do must about compromised hardware except be aware of it
Re: Scripts that run insecurely-downloaded code
I've seen this before with Firefox. Basically Firefox has disabled weaker certificates from working, where Chrome and IE still accept ones with 128bit encryption, they do show an error (at least in Chrome) if you dig into the SSL debug screen. Firefox just refuses to view it. Ah, I have read somewhere on the internet that AES-256 would be less secure than AES-128 because the AES algorithm has been designed for 128bit.
Fwd: Re: AW:webhosting mit DANE
I have decided to not only forward but now also translate the following email for you. A conversation with someone I know from here made me believe that you would understand things better if you knew the content of that email: Weitergeleitete Nachricht Betreff: Re: AW:webhosting mit DANE Datum: Thu, 16 Apr 2020 21:22:20 +0200 Von: estel...@elstel.org An: Lars-Helge Wilbrandt Am 14.04.2020 22:26, schrieb Lars-Helge Wilbrandt: What I would be interested in is if that only concerns you or if other people are simply too stupid to notice that? Best Regards Lars-Helge Wilbrandt Dear Mr. Lars-Helge Wilbrandt Now, that is a long story. The first time they have cracked my computer was in May 2008: "Oh what do we have here? Wordbook German-Portuguese. Haha, we gonna delete it now!". Two people with very German pronunciation have been talking to me via the PC speaker. They have also controlled my mouse pointer. By now I am sure that they have cracked my computer because of my love. My homepage www.elstel.org did not exist at that time and thus also no environmental or security-technical engagement like now. That could have been a reason for cracking my computer but that time it was not. Unfortunately I did not understand everything they have told me. Something must have hindered me to understand them. I had to suffer from recurrent cracks in the years to come. I had no idea how they could crack into my computer and I kept installing my system new over and over again which has cost me a lot of time. Once I had inferenced from the installation timeline that they must have come in via Skype but not installing Skype did not improve anything. A new milestone has come with my visit to South America in 2011 (You can still find traces from then in the internet). I had a fresh installation of RedHat with SELinux on my PB mini-notebook. I have solely visited the website of my bank for a wire transfer and the notebook got thereby cracked. The first and only time I went online with that notebook. I could prove that there was a rootkit on that computer by installing the exactly same packages again from DVD and by comparing file by file. It was good luck that I had not updated the system before so that I had all packages available offline. When I had come home I developed debcheckroot v1.0. With debcheckroot I could spot another rootkit at home. However proving that there was a rootkit did not help against becoming infected with a rootkit. A few minutes after installing from scratch my system was infected again. Today/ just a few days ago I am also still terrorized: They always switch my keyboard layout from German to US, they make mouse and keyboard hang, so that I can hardly or not at all use them any more. On my notebook keyboard the always switch on NumLock so that it outputs numbers instead of letters. If you gonna ask me what has made the difference, then that there was no way for me to give up. Someone else would have stopped to program security tools or ended his environment-political engagement to be left in peace. However I could and can not give up my love. It is simply not possible. It is like a question of suriving or not surviving (Yes it is true; they have tried to kill me in South America.). As I did not have any simple possibility to give up I have gradually gained some insight by all of what has happened - to know what would need to change so that we could again gain a safer internet. I have already experienced a lot: manipulated firmware of my sdcard readers which did refuse to read a specific sdcard image which I needed to install a clean system. Some other sdcard readers of the same model, make and shipment had been locked in a box and they could read the very same sdcard well. Is it really that simple: Buy a padlock? You have to have a good mood if you meet some people who would tell you that secret services can open any lock by special applicances. However I have reason to believe that these are lies and that there has been another reason why they got into another padlock. I do not want to tell more about it since this will be important for the survival of my computing. They are coming into my room and manipulate my computers. The first time I knew it, it had happened in 2011 as I was running my PB notebook only offline any more to analyze the rootkit on there. When I came home one day I have encountered the partition table of the notebook to be deleted. On resume from s2ram they have shown me an octopus. Today they have become more violent: They are making my computers fully unusable. Some years ago I have sent blue ray images with provably cracked systems to some respective organizations so that someone independent could verify what has happened. Up to now I have received no response. I would think they have finally been shut up or why would I not be of value for a response? The only ones
Re: Scripts that run insecurely-downloaded code
Am 02.05.2020 00:51, schrieb Marcus Dean Adams: It's better than nothing. Even if somebody were using self signed certificates that aren't publicly trusted, the information would still be encrypted in transit. Whether the other end is trustworthy is another issue and up to the user and package maintainers to decide, but it would, at the very least, make it more difficult for a third party to manipulate the information between the intended endpoints. Yes, I agree. With https you can only make man-in-the-middle when the connection is established with http you can hijack the connection any time. Besides this https is for sure the way to go when you are using (a possibly unencrypted) Wifi. It prevents people around you from interfering with your internet connection. For the normal user you can not hijack a wired LAN connection unless you would hack into ISP or root servers. In a country which can wiretap its citizens connections but does not afford to bribe certification authorities the system as we have it now is also a protection. I just thought of the average use case where a build server in Europe or the US is cabled via LAN.
Re: Scripts that run insecurely-downloaded code
Am 02.05.2020 02:53, schrieb Paul Wise: On Fri, May 1, 2020 at 8:18 PM Rebecca N. Palmer wrote: This is already policy (and enforced by blocking network access) for official Debian package builds: dependencies must be installed by the package manager, not the build script. Correction: the debian.org buildds do not at this time block any network access. The main issue is that schroot does not support it and it has been orphaned and unmaintained for years. You might be thinking of pbuilder, which does do this by default. I still remember the times when xchroot was a candidate and schroot did not yet exist. I still used to maintain it with features like Xorg-chroot and chroot as user (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721447, https://www.elstel.org/xchroot/). The problem about it that time was that it was not yet GPLv3.
Re: Scripts that run insecurely-downloaded code
Am 02.05.2020 10:14, schrieb Davide Prina: On 01/05/20 22:00, Rebecca N. Palmer wrote: On 01/05/2020 20:31, Elmar Stellnberger wrote: https isn´t any more secure than http as long as you do not have a verifiably trustworthy server certificate that you can check for. As we know the certification authority system is totally broken. Imperfect yes, but still better than nothing. There is another problem: implementation. Not all the software that implement HTTPS verify the validity of the certificate and the validity of all the certification chain. For example where I work has been invalidated a certificate, but for mistake the new valid one was not loaded on a https site. What do you mean by loaded on a https site? That the web server of the site uses the certificate? Wasn´t there a CA for the new site? With Debian and Firefox I cannot access that site (I get "the certificate is not valid" or something similar), but other people, that use another OS, can access it with internet explorer and chrome, but not with Firefox. Ciao Davide
Fwd: Re: whonix.org DNSSEC/DANE
Dear readers of the debain-security mailing list I have recently described on how to set up a secure emailing terminal at https://www.elstel.org/DANE/. Since then I have got dozens of replies from people who said that they did not receive my emails before, not even in the spam folder. There are only two people whom I could still not reach. One of them is Patrick Schleizer. He normally always responds to me but I know he is reading debian-security and that is why I have decided to write you today. The email was on how easy it is to enable DANE for a custom domain: enable DNSSEC and provide a TLSA record. The other contact is Claudio Guarnieri. He also works in a security related context. He appears not to have received my emails though I sent out the same email a dozen of times. Yours Sincerely, Elmar Stellnberger Originalnachricht Betreff: Re: whonix.org DNSSEC/DANE Datum: 08.03.2020 07:55 Von: estel...@elstel.org An: Patrick Schleizer Am 29.12.2019 10:43, schrieb Elmar Stellnberger: Hallo Patrick Also wenn deine Domain DNSSEC unterstützt, dann ist DANE Support watscheneinfach zu haben: https://ssl-tools.net/tlsa-generator Ich verwende immer DANE-EE & Use full certificate. Das ist auf der Kommandozeile am einfachsten zu überprüfen. Mein TLSA Eintrag sieht dann folgendermaßen aus: $ drill m.root-servers.net +trusted-key=/usr/share/dns/root.key +topdown +sigchase TLSA _443._tcp.elstel.org | egrep -v "^$|^;" _443._tcp.elstel.org. 19819 IN TLSA3 0 1 a8edf0cacaf776acacdfe53564c51556ad325f03a369e4c8f4622b4dc5b06865 siehe auch: https://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml so geht es auch: dig @$dns +trusted-key=/usr/share/dns/root.key +topdown +sigchase TLSA _443._tcp.$1 Gutes neues Jahr und schöne verbleibende Festtage wünscht Dir Elmar Am 02.09.19 um 15:55 schrieb Patrick Schleizer: Elmar Stellnberger: P.S.: Wie sieht es mit der Unterstützung von DANE auf whonix.org aus? Ich habe gesehen, daß Domain-Provider wie inwx.de inzwischen schon DNSSEC/DANE unterstützen. DNSSEC sieht gut aus. https://dnssec-debugger.verisignlabs.com/whonix.org DANE: noch nicht Generell: https://www.whonix.org/wiki/Privacy_Policy_Technical_Details Naja, ist halt ein Hetzner Server. Nichts gegen Hetzner, aber viel Sicherheit kann man heutzutage von keinem Serveranbieter erwarten. Originalnachricht Betreff: Re: analysis of a complete rootkit Datum: 08.03.2020 07:54 Von: estel...@elstel.org An: Nex Dear Claudio Guarnieri I just wanted to ask you whether you know about the current mass surveillance plaintiff against the BND? The EFF has said it could even become a legal precedent for US law. As you care about the analysis of rootkits I thought you could be interested. Please respond shortly to my email so that I will know whether you have received it. I have sent you this email now a dozen of times without getting a reply. Please look at https://www.elstel.org/DANE/ and https://www.elstle.org/atea/ and on the message I will post on debian-security in some time on how to get a secure emailing client. You are one of two contacts who does not respond. All others (dozens) have responded me since I have secure DANE emailing. Best Regards, Elmar
