6

Tripwire report shows modification dates from when I was on vacation with computer shutdown at home - how is this possible?

here is one of many examples:

Modified object name:  /lib/x86_64-linux-gnu/security/pam_systemd.so

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         14155863                    14156649                    
* Modify Time          Do 12 Mai 2016 11:39:41 CEST
                                                   Do 01 Feb 2018 15:31:23 CET 
* CRC32                B5TykA                      B/R1Fi                      
* MD5                  Ag+rN14JZRydCT88KOuyuX      BAHe4c1qm712mqcpi1k+rI    

On the first of february I wasn't near my computer which I shut down approx a month before. I came back another month later. February has nearly 3000 changes in files. January 1500 changes. I was away from 6th of january until 27th of february.

3
  • Well, either the filesystem is corrupted, or the computer was booted up between these two periods.
    – forest
    Commented Mar 20, 2018 at 4:25
  • A FS corrupted so as to give a valid set of modification times so that tripwire would log it correctly without a ton of latteral damages is an event of very low probability. Something about the probability of a library which faced an earth quake and would look clean with just a few books replaced by brand new ones 😇.
    – athena
    Commented May 13, 2018 at 14:31
  • @danielAzuelos I can think of several ways it can happen. Modification dates are stored in inodes, so corruption to data blocks (e.g. caused by a corrupt driver or fsck) would not necessarily change modification times. And the journal (on its own inode) could correct a certain amount of inode corruption.
    – forest
    Commented May 13, 2018 at 23:44

3 Answers 3

3

Are there any other traces in the system logs? It seems strange that someone could sanitize so thoroughly a system that the logs show nothing, and yet not spot Tripwire or at least reset the timestamps properly.

Try updating a package, and see whether the updated files have the timestamp of when you ran the update, or the timestamp of the original file inside the update packet (this is typical in Windows, not so in the Linux distros I'm familiar with, but on the other hand you did not say what distro you're using).

Also, you could compare the checksums with those of a known good version of your same distribution.

update

pam_systemd.so was officially updated (at least on the one system I checked, Ubuntu 14.04-LTS), and the patch was published the day you report:

-rw-r--r-- 1 root root 42864 Feb  1 16:01 /lib/x86_64-linux-gnu/security/pam_systemd.so

Notice that I am in Italy, but my system clock is in UTC; if you're in Spain, our files were updated within thirty minutes of each other.

So my guess is that someone booted up your computer at least twice (one in January, one in February), and whether he logged in or not, the system proceeded to perform automatic updates.

Depending on whether it's a laptop or a desktop etc., and whether it was plugged in, it is even possible that it might have turned on by itself (I had a desktop once that did that about once every two weeks, or in case of thunderstorms), and then turned off again by itself after some hours of inactivity.

0

I did what you suggested and upgraded a few packages and compared the dates. I came to the same conclusion like you mentioned in your update:

The mentioned date by tripwire relies on the modification date of the package and not on the date it was upgraded in my system. So is it really necessary to still consider an attack from outside? Isn't it possible that it's an upgrade from after feb 27th (the date I got back) with the package modification date from before that?

I'm pretty low profile to anybody I guess, so that anybody would manipulate my laptop to boot via internet, much less break into my apartment, seems pretty unlikely.

But to answer your other questions, my logs either are empty oder start february the 27th.

kernel log starts 27.feb
syslog starts 07.03
wtmp begins Thu Mar  1 23:31:40 2018
btmp begins Tue Mar 13 23:07:08 2018
auth.log starts 27.02
faillog is completely empty

answer to your next question is ubuntu 16.04

Here that excerpt is from before the upgrade:

Modified object name:  /usr/bin/update-notifier

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         525831                      529894                      
* Size                 57736                       57704                       
* Modify Time          Di 12 Apr 2016 12:44:15 CEST
                                                   Do 18 Jan 2018 13:42:58 CET 
* CRC32                A/JGJG                      D/hJue                      
* MD5                  A94qrwY3famFuyjNRqByy/      AIg7I1UyImK4SMXV/P3IVE  

...and that is from after the upgrade:

Modified object name:  /usr/bin/update-notifier

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         525831                      527608                      
* Size                 57736                       57704                       
* Modify Time          Di 12 Apr 2016 12:44:15 CEST
                                                   Fr 02 Mär 2018 15:40:49 CET
* CRC32                A/JGJG                      DLot5B                      
* MD5                  A94qrwY3famFuyjNRqByy/      D6A8JWReWbockgtVM8p70R

..but to support that attacker theory there is another thing: I found an alien mobile number in my ebay account with a moderate strong password.

Ah and unity was broken so I tried to fix it but failed. I created another user and then it was fine.

2
  • 2
    Is this an answer? Please do not use the Answer space for follow up comments. Post comments on LSerni's answer to answer his questions, and edit your question to provide more details.
    – schroeder
    Commented Mar 20, 2018 at 20:46
  • 1
    And please use the formatting options for copy/pastes of screen outputs
    – schroeder
    Commented Mar 20, 2018 at 20:47
0

Check the creation times of the files tripwire detected as modified. You will find they were the consequence of an installation process run by you or a cron job.

If your system would have been pirated by someone knowing tripwire you would never find such a modification log. You would rather have found tripwire uninstalled. There is no known way to corrupt the internal tripwire database to hide modifications due to an attack, unless your tripwire main key was too weak or stored in clear on the same computer (2 possibilities which would be stupid for someone security aware).

You must log in to answer this question.