OWASP - User contributions [en]

Logging issues

2007-02-19T16:45:56Z

Amwestgate: bullet points added. the formatting in this article can be improved.

[[OWASP Code Review Guide Table of Contents]]__TOC__
=== In Brief===
Logging is the recording of information into storage that details who performed what and when they did it (like an audit trail) This can also cover debug messages implemented during development as well as any messages reflecting problems or states within the application. It should be an audit of everything that the business deems important to track about the applications use. Logging provides a detective method to ensure that the other security mechanisms being used are performing correctly. 

Logging should be at least done at the following events: 

* Authentication: Successful & unsuccessful attempts.
* Authorization requests.
* Data manipulation: Any (CUD) Create, Update, Delete actions performed on the application.
* Session activity: Termination/Logout events.

A good logging strategy should include the recording of any errors that occur in the application. 
The application should have the ability to detect and record possible malicious use such as events that cause unexpected errors or defy the state model of the application. Users who attempt to get access to data that they shouldn’t (authorization), and incoming data that does not meet validation rules or has been tampered with. In general any error condition which could not occur without an attempt by the user to circumvent the application logic. 

Logging should give us the information required to form a proper audit trail of a users actions. 
Leading from this the date/time the actions were performed would be useful.
Logging functionality should not log a any personal or sensitive data pertaining to the user of function at hand that is being recorded; An example of this if your application is accepting HTTP GET the payload is in the URL and the GET shall be loged. This may result in logging sensitive data. 

Logging should follow best practice regarding data validation; maximum length of information, malicious characters…. 
We should ensure that logging functionality only log’s messages of a reasonable length and that this length is enforced. 

Common open source logging solutions: 

Log4J: http://logging.apache.org/log4j/docs/index.html

Log4net: http://logging.apache.org/log4net/

Commons Logging: http://jakarta.apache.org/commons/logging/index.html
 

In Tomcat(5.5), if no custom logger is defined (log4J) then everything is logged via Commons Logging and ultimately ends up in catalina.out. 
catalina.out grows endlessly and does not recycle/rollover. Log4J provides “Rollover” functionality, which limits the size of the log. Log4J also gives the option to specify “appenders” which can redirect the log data to other destinations such as a port, syslog or even a database or JMS.

The parts of log4J which should be considered apart from the actual data being logged by the application are contained in the log4j.properties file:

#
# Configures Log4j as the Tomcat system logger
#

#
# Configure the logger to output info level messages into a rolling log file.
#
log4j.rootLogger=INFO, R

#
# To continue using the "catalina.out" file (which grows forever),
# comment out the above line and uncomment the next.
#
#log4j.rootLogger=ERROR, A1

#
# Configuration for standard output ("catalina.out").
#
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
#
# Print the date in ISO 8601 format
#
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

#
# Configuration for a rolling log file ("tomcat.log").
#
log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
log4j.appender.R.DatePattern='.'yyyy-MM-dd
#
# Edit the next line to point to your logs directory.
# The last part of the name is the log file name.
#
log4j.appender.R.File=/usr/local/tomcat/logs/tomcat.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
#
# Print the date in ISO 8601 format
#
log4j.appender.R.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

#
# Application logging options
#
#log4j.logger.org.apache=DEBUG
#log4j.logger.org.apache=INFO
#log4j.logger.org.apache.struts=DEBUG
#log4j.logger.org.apache.struts=INFO

=== Vulnerable patterns examples for Logging===

====.NET====
The following are issues one may look out for or question the development team /deployment team.
Logging and auditing are detective methods of fraud prevention. Much overlooked in the industry, which enables attackers to continue to attack/commit fraud without being detected.

They cover Windows and .NET issues:
'''Check that:'''
#Windows native log puts a timestamp on all log entries.
#GMT is set as the default time.
#The Windows operating system can be configured to use network timeservers.
#By default the event log will show: Name of the computer that generated the event; The application in the source field of the viewer. Additional information such as request identifier,username,and destination should be included in the body of the error event.
#No sensitive or business critical information is sent to the application logs.
#Application logs are not located in the web root directory.
#Log policy allows different levels of log severity.

===== Writing to the Event Log=====
In the course of reviewing .NET code ensure that calls the EventLog object do not provide any confidential information.

EventLog.WriteEntry( "<password>",EventLogEntryType.Information);

====JAVA====

[[Category:OWASP Code Review Project]]

Command Injection

2007-02-12T16:00:40Z

Amwestgate: Without the quotes, the shell command line interpretter handles the second command.

{{Template:Attack}}

==Abstract==

Executing commands that include unvalidated user input can cause an application to act on behalf of an attacker.

==Overview==

Command injection problems are a subset of injection problem, in which the process is tricked into calling external processes of the attackers choice through the injection of control-plane data into the data plane.

Command injection attacks take two forms:

* An attacker can change the command that the program executes: the attacker explicitly controls what the command is.
* An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case we are primarily concerned with the first scenario, in which an attacker explicitly controls the command that is executed. Command injection vulnerabilities of this type occur when:

# Data enters the application from an untrusted source.
# The data is part of a string that is executed as a command by the application.
# By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

==Consequences ==

* Access control: Command injection allows for the execution of arbitrary commands and code by the attacker.

==Exposure period ==

* Design: It may be possible to find alternate methods for satisfying functional requirements than calling external processes. This is minimal.

* Implementation: Exposure for this issue is limited almost exclusively to implementation time. Any language or platform is subject to this flaw.

==Platform ==

* Language: Any

* Platform: Any

==Required resources ==

Any

==Severity ==

High

==Likelihood of exploit ==

Very High

==Avoidance and mitigation ==

* Design: If at all possible, use library calls rather than external processes to recreate the desired functionality

* Implementation: Ensure that all external commands called from the program are statically created, or - if they must take input from a user - that the input and final line generated are vigorously white-list checked.

* Run time: Run time policy enforcement may be used in a white-list fashion to prevent use of any non-sanctioned commands.

==Discussion ==

Command injection is a common problem with wrapper programs. Often, parts of the command to be run are controllable by the end user. If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, he may then be able to insert an entirely new and unrelated command to do whatever he pleases.

The most effective way to deter such an attack is to ensure that the input provided by the user adheres to strict rules as to what characters are acceptable. As always, white-list style checking is far preferable to black-list style checking.

==Examples ==

===Example 1===

The following code is wrapper around the UNIX command ''cat'' which prints the contents of a file to standard out. It is also injectable:

<pre>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {
char cat[] = "cat ";
char *command;
size_t commandLength;

commandLength = strlen(cat) + strlen(argv[1]) + 1;
command = (char *) malloc(commandLength);
strncpy(command, cat, commandLength);
strncat(command, argv[1], (commandLength - strlen(cat)) );

system(command);
return (0);
}
</pre>

Used normally, the output is simply the contents of the file requested:

<pre>
$ ./catWrapper Story.txt
When last we left our heroes...
</pre>

However, if we add a semicolon and another command to the end of this line, the command is executed by catWrapper with no complaint:

<pre>
$ ./catWrapper "Story.txt; ls"
When last we left our heroes...
Story.txt doubFree.c nullpointer.c
unstosig.c www* a.out*
format.c strlen.c useFree*
catWrapper* misnull.c strlength.c useFree.c commandinjection.c nodefault.c trunc.c writeWhatWhere.c
</pre>

If catWrapper had been set to have a higher privilege level than the standard user, arbitrary commands could be executed with that higher privilege.

===Example 2===

The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

<pre>
int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}
</pre>

Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

===Example 3===

The following code from a privileged program uses the environment variable $APPHOME to determine the application's installation directory and then executes an initialization script in that directory.

<pre>
...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...
</pre>

As in Example 2, the code in this example allows an attacker to execute arbitrary commands with the elevated privilege of the application. In this example, the attacker can modify the environment variable $APPHOME to specify a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, by controlling the environment variable the attacker can fool the application into running malicious code.

The attacker is using the environment variable to control the command that the program invokes, so the effect of the environment is explicit in this example. We will now turn our attention to what can happen when the attacker can change the way the command is interpreted.

===Example 4===

The code below is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make in the /var/yp directory. Note that since the program updates password records, it has been installed setuid root.

The program invokes make as follows:

<pre>
system("cd /var/yp && make &> /dev/null");
</pre>

Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to system(). However, since the program does not specify an absolute path for make and does not scrub any environment variables prior to invoking the command, the attacker can modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. And since the program has been installed setuid root, the attacker's version of make now runs with root privileges.

The environment plays a powerful role in the execution of system commands within programs. Functions like system() and exec() use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.

==Related problems ==

* [[Injection problem]]

==Related Threats==

==Related Attacks==

[[OS Command Injection]]

==Related Vulnerabilities==

==Related Countermeasures==

* [[:Category:Input Validation]]

==Categories==

[[Category:Attack]]

[[Category:Injection Attack]]

[[Category:OWASP_CLASP_Project]]

[[Category:Design]]

[[Category:Implementation]]

[[Category:Input Validation]]

[[Category:Code Snippet]]

[[Category:C]]

{{Template:SecureSoftware}}
{{Template:Fortify}}