Re: Script to System Check Integrity against Debian Package Repository
On 09/17/2013 09:45 PM, adrelanos wrote: Situation: * You have a Debian machine, which might be compromised by a backdoor due to a targeted attack. You don't know and want to make sure it's not. For example, a server or a client internet machine. Why not just reinstall from a trusted source, then restore /etc, /home and /var from backups and audit the changes introduced by that only? In reality, it seems like many files are auto-generated and not owned by any packages. Some of them even hold binary code, which gets executed during boot. Some examples: - /boot/grub/video_fb.mod - (dpkg -S /boot/grub/video_fb.mod reports not owned by any packages) It is copied from /usr/lib/grub/i386-pc: $ dpkg -L grub-pc-bin | grep video_fb /usr/lib/grub/i386-pc/video_fb.mod - /lib/modules/3.10-2-686-pae/modules.symbols - /etc/ssl/certs/GeoTrust_Global_CA.pem - /etc/ld.so.cache - /etc/rc*.d/* - /usr/lib/python2.7/dist-packages/pygtk.pyc - and many more... It could be quite difficult to get a signed version of some of them or to deterministically freshly generate them? Aren't they generated by the package's postinst script? And I have open questions, such as: - Which package is responsible for creating device files (/dev/...)? How to check if they are legit? /dev should just be a tmpfs, so the kernel creates device files there (possibly triggered by udev). $ mount | grep '/dev ' udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1013295,mode=755) - Is there a signed dump of the grub boot sector somewhere? I think it is based on /usr/lib/grub/i386-pc/boot.img, but with some offsets adjusted. Isn't it safer to just re-install grub from your trusted system? Best regards, --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52395812.9090...@etorok.net
Re: Script to System Check Integrity against Debian Package Repository
adrelanos adrela...@riseup.net writes: * No code within the untrusted system must be required to be executed in order for the check, since no code inside the vm image is trusted while testing. How about using https://github.com/devstructure/blueprint? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84r4cme2yj@sauna.l.org
AUTO: Thomas Sinka ist außer Haus (Rückkehr am 01.10.2013)
Ich bin bis 01.10.2013 abwesend Bitte wenden Sie sich in dringenden Fällen an Frau Langenfeld: anna-meta.langenf...@it-choice.de, Tel. 0721 85 006-0 Vielen Dank! Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht [SECURITY] [DSA 2756-1] wireshark security update gesendet am 13.09.2013 19:12:56. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/off51fdb4d.a1496d83-onc1257be9.004f9694-c1257be9.004f9...@it-choice.de
Re: Script to System Check Integrity against Debian Package Repository
Paul Wise: On Wed, Sep 18, 2013 at 9:36 AM, Török Edwin wrote: Why not just reinstall from a trusted source, then restore /etc, /home and /var from backups and audit the changes introduced by that only? That is a slightly short-sighted way to do it; if you restore from scratch without doing any forensics you won't know which methods your attackers used and how you can defend yourself from them after you have restored the system from scratch. Perhaps they will attack you again soon afterwards. I didn't have that argument in mind, but I am happy to read it. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5239bd83.7050...@riseup.net
Re: Script to System Check Integrity against Debian Package Repository
Török Edwin: On 09/17/2013 09:45 PM, adrelanos wrote: Situation: * You have a Debian machine, which might be compromised by a backdoor due to a targeted attack. You don't know and want to make sure it's not. For example, a server or a client internet machine. Why not just reinstall from a trusted source, then restore /etc, /home and /var from backups and audit the changes introduced by that only? In reality, it seems like many files are auto-generated and not owned by any packages. Some of them even hold binary code, which gets executed during boot. Some examples: - /boot/grub/video_fb.mod - (dpkg -S /boot/grub/video_fb.mod reports not owned by any packages) It is copied from /usr/lib/grub/i386-pc: $ dpkg -L grub-pc-bin | grep video_fb /usr/lib/grub/i386-pc/video_fb.mod Thanks for the technical information. That will help to audit those. - /lib/modules/3.10-2-686-pae/modules.symbols - /etc/ssl/certs/GeoTrust_Global_CA.pem - /etc/ld.so.cache - /etc/rc*.d/* - /usr/lib/python2.7/dist-packages/pygtk.pyc - and many more... It could be quite difficult to get a signed version of some of them or to deterministically freshly generate them? Aren't they generated by the package's postinst script? Probably yes, but it the postinst script calls something like update-mime-database, I am not sure how to compare it's outputs. I must check first if it's outputs are deterministic (when using the same versions, of course). Maybe I have to run such commands on the trusted system to generate those files and then compare with the untrusted system. Sounds like quite some package specific work. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5239fe22.5000...@riseup.net
