Log forging, logic bombs and Command injection ??

Developers think that log forging was not as dangerous as command injection. Often an application log name can be changed by the vary many types of parameter tampering. But these bugs are marked as medium risk. However we take the premise that the application will never execute the logs, hence it is not directly exploitable. But how many of us look at the automation associated with a production environment when we audit applications.

More often, production applications are manned by Unix admins who put cheap and dirty shell pipes and scripts to archive / search / list the log files. No one reviews those set of cheap and dirty automations. Where I am getting at? lets see..


Assume that I have a file system, where I want to find out specific types of files (Just an example), so I write a dirty automation like below:

~$> ls -falrt | grep -v "drwx" | awk {'if ($8 != NULL) {print "file " $8 $9}'} | sh | grep -i png

now, one would thing the above command, which does the following steps:
1. list files
2. greps out directories
3. awk for file names (which are not null). And creates the 'file ' command
4. shell to execute the above
5. Grep for png images.


what would happen, if I don't input validate filenames? understand that unix support the complete ascii char set for file naming, so a filename like ;netstat; is completely valid and possible (by a log tampering vulnerability).

~$> touch \;\ netstat\ \;

so what happens when i run the previous dirty script? Well I just accidentally trigger netstat command. Obviously there are other royal ways to screw people that netstat.Imagine what is possible with root binaries / cron jobs etc.

Now the question is how to check this? Just input validate everything that is created on your production server. And deploy better tested shell scripts.