When a file is executed in a Unix / Linux system, execution is done using the privileges of the user who started execution. This usual behavior could be altered using setuid and setgid flags. Setuid and setgid flags provide elevated access rights while executing a file. When setuid flag is set, execution is done using the privileges of the owner of the file. Similarly, when setgid flag is set, privileges of the group owner of the file are used for executing the file. This facility of executing files with elevated privileges is necessary for certain tasks of the operating system. However, this facility poses risk when exploited by an attacker.
To mitigate the risk posed by presence of files having suid and sgid files set, careful examination should be done to identify whether the setuid and setgid flags are actually necessary for the functionality of the system. All those that are not necessary should be removed.
Here is a command to list files that have suid flag set.
$ find / -perm -4000 -exec ls -l {} \; 2>/dev/null
Here is a command to list files that have sgid flag set.
$ find / -perm -2000 -exec ls -l {} \; 2>/dev/null
Here is a command to list files that have both suid and sgid flag set.
$ find / -perm -6000 -exec ls -l {} \; 2>/dev/null
Are you wondering how is this facility is used by the Unix / Linux operating system. Well, check the lists obtained from commands listed above. You will see passwd which is used to update passwords of system users. You will see sudo that is useful for executing a command as superuser or another user. You will see ping, the useful networking command. And many others. So, before taking action on files that have suid or sgid flag set, careful examination should be done to ensure that we're doing what is right. In an attempt of hardening the system, we don't want to halt some legitimate functionality of the system.
And how could an attacker exploit this facility. Well, if an attacker gains access to the system, they could write a program to make a copy of /etc/shadow file. Then set suid flag on that file. Then change ownership of that file to superuser, who has access to /etc/shadow file. Thus, /etc/shadow file is obtained. Then remove the program that helped in this endeavor. Now passwords could be obtained using John the Ripper. Of course, these actions would be logged, and could be traced. But why let the damage take place, when you could avoid it.
To mitigate the risk posed by presence of files having suid and sgid files set, careful examination should be done to identify whether the setuid and setgid flags are actually necessary for the functionality of the system. All those that are not necessary should be removed.
Here is a command to list files that have suid flag set.
$ find / -perm -4000 -exec ls -l {} \; 2>/dev/null
Here is a command to list files that have sgid flag set.
$ find / -perm -2000 -exec ls -l {} \; 2>/dev/null
Here is a command to list files that have both suid and sgid flag set.
$ find / -perm -6000 -exec ls -l {} \; 2>/dev/null
Are you wondering how is this facility is used by the Unix / Linux operating system. Well, check the lists obtained from commands listed above. You will see passwd which is used to update passwords of system users. You will see sudo that is useful for executing a command as superuser or another user. You will see ping, the useful networking command. And many others. So, before taking action on files that have suid or sgid flag set, careful examination should be done to ensure that we're doing what is right. In an attempt of hardening the system, we don't want to halt some legitimate functionality of the system.
And how could an attacker exploit this facility. Well, if an attacker gains access to the system, they could write a program to make a copy of /etc/shadow file. Then set suid flag on that file. Then change ownership of that file to superuser, who has access to /etc/shadow file. Thus, /etc/shadow file is obtained. Then remove the program that helped in this endeavor. Now passwords could be obtained using John the Ripper. Of course, these actions would be logged, and could be traced. But why let the damage take place, when you could avoid it.
No comments:
Post a Comment