2

I don't want anybody to create a file then change the creation date to backward date(For example using touch or system call).

In my Ubuntu hosting account I'm getting many hacked php code getting uploaded.

Disallowing them to change the time of file when it landed will help me locate new files easily.

What is the way to achieve it? I could not find answer anywhere!

  • 4
    Um, maybe identifying the breach(es) and preventing further intrusions would be a more profitable approach? – jasonwryan Oct 28 '14 at 5:49
  • 1
    As long as the user is the owner of the file you cannot prevent modifications of the inode information. – mdpc Oct 28 '14 at 6:28
  • Why not just disallow PHP? Seems like a positive idea. – HalosGhost Oct 28 '14 at 13:17
  • I also think that tampering with such low level feature is not the right approach. If I were you I'd research the topic audit. Auditing is targeted to address problems like yours and it does so by collecting information about system changes in a reliable way. – Luis Antolín Cano Nov 14 '14 at 11:20
2
+50

You can prevent hackers from using PHP code to change modification time (mtime) of files that are writeable by your web server by disabling those PHP functions (such as touch) using [disable_functions][1] option in php.ini configuration file.

However, tracking modification time is not the right approach because the modification time of files do not change when they are uploaded to your server (i.e. this time could be much earlier than the time when your system is breached). A better approach is to track status changed time (ctime) of the inode file. To demonstrate what I mean:

$ touch test.txt
$ stat test.txt
  File: ‘test.txt’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
...
Access: 2014-10-28 05:51:10.329081380 +0000
Modify: 2014-10-28 05:51:10.329081380 +0000
Change: 2014-10-28 05:51:10.329081380 +0000

$ touch -t 10011234 test.txt 
$ stat test.txt
  File: ‘test.txt’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
...
Access: 2014-10-01 12:34:00.000000000 +0000
Modify: 2014-10-01 12:34:00.000000000 +0000
Change: 2014-10-28 05:52:57.669657564 +0000 <= unadulterated by touch

Without root access, I think it is quite impossible to modify ctime.

  • Yes you're right link – user5858 Oct 28 '14 at 9:19
  • Are you sure ctime can't be rolled back to earlier time by non-privileged user? – user5858 Nov 10 '14 at 2:59
  • @user5858, this is by design of the OS. Unless there is a bug, ctime should be reliable. – Question Overflow Nov 16 '14 at 2:56
3

As far as I know, there is no way to restrict a user from changing the modification time of a file. Changing the modification time is a normal feature, use for example when extracting files from an archive or copying them from another machine.

Instead of looking at the modification time, look at the inode change time (ctime). Pass the option -c to ls to list the ctime instead of the mtime.

Listing the ctime lets you detect which files have been modified or moved recently. It may turn up false positives, of course. If the attacker has root access, all bets are lost.

This is more useful for forensics than for repair. Only the most basic attacks can be countered by a simple repair like removing the obviously-infected file: usually there's more stuff than what you can find. If you detect an attack:

  1. Take the system offline. Make a copy of it.
  2. Reinstall the whole system from known good sources. Don't reuse anything from the infected system: you can't trust it. Be sure to install the latest versions of all software, with no known security holes.
  3. Restore your data from a known good backup. Again, you can't trust data produced by the infected system.
  4. Study the copy of the infected system to figure out how the attackers got in. Note that how the attackers got in (the vulnerability) is very different from what the attackers later did (the payload). You need to track down the root cause, not the symptom. This part may require a professional.
  5. Once you've established that the root cause is no longer present (the misconfiguration or security bug has been fixed), take the new system online.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.