Re: Script to System Check Integrity against Debian Package Repository
On Wed, 18 Sep 2013 09:47:27 +0200 Paul Wise wrote: > 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. > And say there are no traces how they did it. Then what are your options? -- Marko Ranđelović, B.Sc. Software Developer Niš, Serbia marko...@eunet.rs http://mr.flossdaily.org Note: If you see a nonsense enclosed between lines BEGIN PGP SIGNATURE END PGP SIGNATURE then this message is digitally signed using OpenPGP compliant software. You need an appropriate plugin for your email client or other OpenPGP compliant software in order to verify the signature. However, the concept of computer insecurity implies digital signature is not absolute proof of identity. -- 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/20130920110243.1d700...@eunet.rs
Re: Script to System Check Integrity against Debian Package Repository
Actually a better option might be to turn the exploited system into a honeypot to try to gain some information about the attackers, their methods and so on. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6e9mjcbafubyckn_f5jgea3qwt2pcmkuyegcdvnqwq...@mail.gmail.com
Re: Script to System Check Integrity against Debian Package Repository
On Sun, Sep 22, 2013 at 6:18 PM, Marko Randjelovic wrote: > And say there are no traces how they did it. Then what are your options? Audit possible entry points (webapps etc), general hardening, firewall things off, switch software, switch OS kernel, switch hardware, change passwords, change keys etc. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6ggkbqofm3s1-2dfva6hazusa_kv2sdc+zcjy3zfuc...@mail.gmail.com
Re: Script to System Check Integrity against Debian Package Repository
On Wed, 18 Sep 2013 09:47:27 +0200 Paul Wise wrote: > 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. > And say there are no traces how they did it. Then what are your options? -- Marko Ranđelović, B.Sc. Software Developer Niš, Serbia marko...@eunet.rs http://mr.flossdaily.org Note: If you see a nonsense enclosed between lines BEGIN PGP SIGNATURE END PGP SIGNATURE then this message is digitally signed using OpenPGP compliant software. You need an appropriate plugin for your email client or other OpenPGP compliant software in order to verify the signature. However, the concept of computer insecurity implies digital signature is not absolute proof of identity. -- 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/20130922181858.78922...@eunet.rs
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
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
adrelanos 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
Re: Script to System Check Integrity against Debian Package Repository
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. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6FMijxYs09WMH=wJe4DUQWWDvQRm9PNwwitnAr5HxR=g...@mail.gmail.com
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
Script to System Check Integrity against Debian Package Repository
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. * You have a Debian Live CD or USB install, which you believe to be clean. * You want to boot from the trusted system (CD or USB) and check the internal hdd, which might be compromised. Non-solutions: * debsums: is a fine tool, yes. But its own man page acknowledges, that it has limited use as a security tool. It also only supports checking the system in which itself it is running. There is no feature to check a Debian, which is in another folder. * I have looked into intrusion detection systems (debsums,) Afick, AIDE, FCheck, Integrit, Osiris, OSSEC, Samhain, Tripwire, but they all have in common, that they want to create a known-good database before auditing. This doesn't scale very well, because updates are pretty frequent, which render that known-good database less useful. Re-creating the known-good database after updating isn't very safe either - let's say apt-get had a bug and installed a malicious package, then the checksum of that malicious package would end up in the known-good database. Goals: * 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. Work in progress: I wrote a bash script, which uses dpkg from the trusted system, to parse the /var/lib/dpkg/status file from the untrusted system. It then uses the trusted system, to download all packages, which are claimed to be installed in /var/lib/dpkg/status and extracts them. The sha512 (could be easily replaced with sha256) checksum of all files which come with the package is created on the trusted system and checked against the files from other untrusted system. Known good files will be stored in an array, mismatches will be reported and stored in array as well. Symlinks are checked as well. At the end, the script goes through all files within the untrusted system and compares which one are already known as good or bad and reports which extra files, which have not been verified against anything, are there. Ideally, there are very few extra files. Only changed configuration files and files manually created by the user. 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) - /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? And I have open questions, such as: - Which package is responsible for creating device files (/dev/...)? How to check if they are legit? - Is there a signed dump of the grub boot sector somewhere? - What other places exist to hide rootkits? Where would be a good place to ask such questions? All in all, I am wondering, is writing such a verification script a promising or futile approach? At the moment, the script is still Whonix specific and verifies a .img image file. It wouldn't be hard to make the folder it audits configurable and to check any other hdds or root folders. If you like to have a look at the work in progress script, see: https://github.com/Whonix/Whonix/blob/master/release/verify_build Comments, criticism, enhancements, etc. welcome. It would be great if anyone is interested to co-author the script (we can pick any Free license) to make it usable for the general use-case. Cheers, adrelanos -- 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/5238a34e.6040...@riseup.net
