17 October 2011

Timestamps falsification

I recently had to do forensic analysis of a server in my organization who had suffered an intrusion.

The input vector was evident as soon as I crossed a few words with the administrator of the machine ... again, a huge investment in security infrastructure had been wasted by an administrator who had gone from our recommendations and had used a dictionary word as his password. The attack had been classic. The logs registered a brute force attack, followed finally by "logins" from other countries' IP addresses. Soon I located in a hidden directory a package of tools for network scanning and brute force attacks. As far as we know, it did not seem attackers had time to use the compromised server as a bridge to our network.

At that point, we decided to format server, reinstall, patch, limiting the maximum services running and make sure we put a trustfull password manager ... and we set our IDS/IPS thresholds starker.

Nothing out of the routine ... and that was what made me think on the possibility that all that might not have been more than a decoy. Everything was so clear since the administrator told his too-easy password that when I found the hidden folder and did a search of timestamps "too actual" in the system (unsuccessfully) I made no further investigation (other things urged). The problem is that the "timestamps" or modification timestamps of the files are not unreliable. Despite this, many programs such as forensics Autopsy / SleuthKitor Forensics Toolkit uses the timestamps of files to develop timelines that allow calls to trace changes made ​​will the intruder. In the case of attack that I had to investigate, timestamp trail was clear. However, as I think about that coldly, that clear trail denoted whether that the attacker was very careless or very cunning because he left a false trail to let my follow it. As we could not be sure so be decided to format server.

Forging the time stamp of a file is not difficult. For example, if you create a file, it will time stamp the date and time of our server at that time. Each time you modify the file timestamp is updated to the date and time the modification is made. Given that many of the files on a server remain unchanged for long periods of time their time stamps are usually very old, so a recent modification by an intruder often calls our attention. However, if the attacker is careful to use the command touch to get your old time stamp to all files that you modified. Here is an example, suppose you create a test file:



@ dante dante-desktop: ~ / test $ echo test> test.txt
@ dante dante-desktop: ~ / test $ ls-l test.txt
-Rw-r - r - 1 7 01/03/2008 6:18 dante dante test.txt

After a few minutes we modify the file you just created:

@ dante dante-desktop: ~ / test $ echo test2>> test.txt
@ dante dante-desktop: ~ / test $ ls -l test.txt
-Rw-r - r - 1 dante dante test.txt 15 01/03/2008 6:22 

As you can see, the time stamp has been updated. An easy way to hide this update wold be using touch command:

@ dante dante-desktop: ~ / test $ touch -t 03010618 test.txt
@ dante dante-desktop: ~ / test $ ls -l test.txt
-Rw-r - r - 1 dante dante test.txt 15 01/03/2008 6:18

This functionality is easily integrated into scripts that allow restoring directory timestamps integers. As a demonstration of it I developed  TSpoofer , a tool made ​​in python that allows you to collect timestamps of files and directories which  hang from a specified directory. This tool can be used afterwards to restore the marks of time previous to modifications making harder to forensics to create their timelines.

As you can see, it is very easy to falsify the time stamps of files thus negating the usefulness of the timelines of forensic tools. You will need to bear this in mind when doing forensics: timelines help but only with careless attackers.



Update of March 19, 2008 -> Something great of computer security is that you are always learning new things. In that sense I have found that using a "ls-l" is only a very superficial way to check the modification timestamp of a file, since it only shows the mtime of the inode. I mean, the timestamps consist of 3 components: mtime, atime and ctime. The mtime check the date and time of the last write to the file, atime last reading of the file and ctime last change of the file. We must take into account a very common confusion, in which I include myself until today, which many believe ctime corresponds to creation-time when it actually refers, at least in linux, to change-time. What is the difference between mtime and ctime? that ctime is a superset of mtime, I mean when mtime is updated so it happens with ctime, but there are times when ctime is updated but mtime not. This occurs in cases where the file is updated but not their contents, for example by changing the permissions associated with the file.
As a demonstration we will perform the same tests as before but this time using the find command to display the timestamps.


@ dante dante-desktop: ~ / test $ date
Wed Mar 19 13:53:23 CET 2008
@ dante dante-desktop: ~ / test $ echo test> test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
644, 19/03/08, 13:53:27, 19/03/08, 13:53:27, 19/03/08, 13:53:27, 1000, 1000, 1000, 7,. / Test. txt
Because we can see the timestamp find complete, the first triple (date, time) correspond to the atime, mtime and the second to the third to ctime.

@ dante dante-desktop: ~ / test $ echo test2>> test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
644, 19/03/08, 13:53:27, 19/03/08, 14:00:14, 19/03/08, 14:00:14, 1000, 1000, 1000, 15,. / Test. txt 

You can view the atime remains the same as I have not read the file but entered data in it, but both the mtime and the atime has been updated after file writing.

@ dante dante-desktop: ~ / test $ chmod 666. / test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 19/03/08, 13:53:27, 19/03/08, 14:00:14, 19/03/08, 14:08:05, 1000, 1000, 1000, 15,. / Test. txt

This test demonstrates the difference between mtime and ctime. We have changed the file to alter its permissions, which is recorded in the ctime, but as this change is not supposed to write data to file the mtime remains unchanged. Hence the difference of 8 seconds that appears between the mtime and ctime.

Remains to be seen what will happen when using the touch command.

@ dante dante-desktop: ~ / test $ echo test3>> test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 19/03/08, 13:53:27, 19/03/08, 14:14:56, 19/03/08, 14:14:56, 1000, 1000, 1000, 23,. / Test. txt
@ dante dante-desktop: ~ / test $ touch -t 03081400.14. / test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 08/03/08, 14:00:14, 08/03/08, 14:00:14, 19/03/08, 14:18:43, 1000, 1000, 1000, 23,. / Test. txt 

It seems that "touch -t" modifies both the atime and mtime. To correct the atime we used "touch -a -t".

@ dante dante-desktop: ~ / test $ touch -a -t 03081353.27. / test.txt
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 08/03/08, 13:53:27, 08/03/08, 14:00:14, 19/03/08, 14:21:00, 1000, 1000, 1000, 23,. / Test. txt
@ dante dante-desktop: ~ / test $ ls-l. / test.txt
-Rw-rw-rw-1 dante dante 23 08/03/2008 14:00. / Test.txt 

The problem is that touch does not have any possibility to change the ctime.Using this tool, an attacker can trick an administrator who is limited to reviewing your file system with a "ls-l" but not a more conscientious to use findor "ls -l - time = ctime".

Should we declare victory? ... not yet. While an attacker would not be having to cover their tracks touch itself could use a low-level tool called debugfs (for ext2/ext3 systems, but for reiserfs systems we have debugfs.reiser4) to modify the ctime of the file. This tool requires root privileges, and it is very delicate since a failure can corrupt the entire file table. Besides, this tool is more difficult to integrate into a script and, as far as I know, you need to restart the system to apply the changes if these are done on a live filesystem. Its use is as follows:

@ dante dante-desktop: ~ / test $ ls-li
total 28
96 984-rw-rw-rw-1 dante dante 23 08/03/2008 14:00 test.txt
@ dante dante-desktop: ~ / test $ sudo debugfs-w / dev/sda1
debugfs 1.40.2 (12-Jul-2007)
debugfs: mi <96984>
Mode [0100666]
User ID [1000]
Group ID [1000]
Size [23]
Creation time [1205932874] 1204981214
Modification time [1204981214]
Access time [1204980807]
Deletion time [0]
Link count [1]
Block count high [0]
Block count [8]
File flags [0x0]
Generation [0x4091865b]
File acl [0]
High 32bits of size [0]
Fragment address [0]
Direct Block # 0 [204803]
Direct Block # 1 [0]
Direct Block # 2 [0]
Direct Block # 3 [0]
Direct Block # 4 [0]
Direct Block # 5 [0]
Direct Block # 6 [0]
Direct Block # 7 [0]
Direct Block # 8 [0]
Direct Block # 9 [0]
Direct Block # 10 [0]
Direct Block # 11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
debugfs:
debugfs: close
debugfs: quit
@ dante dante-desktop: ~ / test $ f ind. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s; % p \ n "| grep test.txt
666, 08/03/08, 13:53:27, 08/03/08, 14:00:14, 19/03/08, 14:21:00, 1000, 1000, 1000, 23,. / Test. txt
@ dante dante-desktop: ~ / test $ sudo shutdown-r now
Broadcast of messages from @ dante dante-desktop
(/ Dev/pts/0) at 17:10 ...

The system will shut down for reboot NOW!
(...)
@ dante dante-desktop: ~ / test $ find. /-printf "% m,% Ax,% AT;% Tx,% TT,% Cx,% CT,% U,% U,% G,% s,% p \ n "| grep test.txt
666, 08/03/08, 13:53:27, 08/03/08, 14:00:14, 08/03/08, 14:00:14, 1000, 1000, 1000, 23,. / Test. txt
It is notable that a tool like debugfs also confuses the meaning of ctime and ask for the "Creation Time", but as mentioned it is a common mistake (think what sense would be having a creation time mark that changes with each modification the file). Anyway, as you can see, now that has changed the value of ctime completely, erasing tracks left in the timestamps ... 

No comments:

Post a Comment