Sunday, December 16, 2012

OS Commanding

OS commanding (a.k.a. OS command execution, shell injection) is a vulnerability in websites that lets attackers execute operating system commands through the manipulation of application input. It occurs when scripts execute external commands that are constructed using unsanitised input data. Such commands will run with the privileges of the component (database server, Web application server, Web server, wrapper or application) that executed the command. This lets the attacker gain access to otherwise unreachable areas (e.g., operating system directories and files), inject unexpected and dangerous commands, upload malicious programs or even obtain passwords directly from the operating system. The diagram below illustrates this. An OS commanding attack An OS commanding attack OS commanding vulnerabilities are frequently found in Perl and PHP scripts, because these programming environments encourage programmers to reuse operating system binaries. However, there are also chances of such vulnerabilities in Java and ASP. Let’s take a look at a few Perl and PHP examples. The following Perl CGI code is part of a Web application for server administration. This function allows administrators to specify a directory on the server, and view a summary of its disk usage: #!/usr/bin/perl use strict; use CGI qw(:standard escapeHTML); print header, start_html(""); print "
";
my $command = "du -h --exclude php* /var/www/html";
$command= $command.param("dir");
$command=`$command`;
print "$commandn";
print end_html;

When used as intended, this script simply appends the value of the 
user-supplied dir parameter to the end of a specific command, which 
it executes, and displays the results. A normal usage URL might be 
something like http://www.example.com/cgi-bin/showinfo.pl?dir=/public.

This functionality can be exploited in various ways, by supplying 
crafted input containing shell characters that have a special meaning
 to the command interpreter. For example, the pipe character (|) is
 used to redirect output from one process to the input of another, 
enabling the chaining of multiple commands. An attacker can leverage
 this to inject a second command (and retrieve its output) with a 
malicious URL such as 
http://www.example.com/cgi-bin/showinfo.pl?dir=/public|%20cat&20/etc/passwd. 

Here, the original du command’s output is redirected as input to the
 cat /etc/passwd command, which simply ignores it, and just outputs 
the contents of the passwd file.
Note: Most operating systems restrict access to system files. Also, 
the advent of shadow passwords has rendered this specific attack less
 useful than it previously was. Still, damaging attacks can be made 
by obtaining .php files which may contain database hostnames, 
usernames and passwords, or other configuration data, or by obtaining
 the database files themselves.

PHP also provides functions, such as passthru() and exec(), and the 
back-tick operator, to execute external programs. Consider the 
following PHP code, which displays a list of files in a particular 
user’s home folder:
$output = `ls -al /home/$username`;
echo $output;

A valid URL for this might be 
http://www.example.com/viewfiles.php?username=arpit. 
If a semicolon is used in the input, it will mark the end of the 
first command, and the beginning of a second. An example of a 
malicious URL would be 
http://www.example.com/viewfiles.php?username=arpit;cat%20/etc/passwd,
 which again displays the contents of the passwd file.

With such a vulnerability, attackers can execute any binary on the
 server like starting a telnet server, logging in to it with the 
privileges of a Web server user, performing exploits to gain root 
access, and perhaps attacking other hosts that are reachable from 
the compromised server.

The time for security

OS commanding is on the list of least-addressed vulnerabilities, but
 the following security measures can help curb it considerably:

    Remove the execution bit from the everyone group (-rwxrwxrw-) 
for OS commands. The Web server user account will not be able to 
execute the targeted command even if an attacker is able to trick 
the Web application into attempting to execute it.
    Validate all input fields for characters like ;, |, / or %00. 
Now, since the list of such characters can be endless, the best thing
 would be to only allow the expected input, and filter out everything 
else — create a whitelist of acceptable inputs that strictly conform
 to specifications, and reject any other input, or transform it into
 acceptable input. For example, to neutralise the ampersand character
 (&) that appears in user data, and which needs to be a part of an 
HTML page, it must be converted to &.
    As additional security, you can also try filtering out command 
directory names such as bin, sbin, opt.

Source: http://www.linuxforu.com

No comments:

Post a Comment