An attacker uses standard SQL injection methods to inject data into the
command line for execution. This could be done directly through misuse of
directives such as MSSQL_xp_cmdshell or indirectly through injection of data
into the database that would be interpreted as shell commands. Sometime
later, an unscrupulous backend application (or could be part of the
functionality of the same application) fetches the injected data stored in
the database and uses this data as command line arguments without performing
proper validation. The malicious data escapes that data plane by spawning
new commands to be executed on the host.
Attack Execution Flow
Explore
Probe for SQL Injection
vulernability:
The attacker injects SQL syntax into
user-controllable data inputs to search unfiltered
execution of the SQL syntax in a query.
At least one user-controllable
input susceptible to injection
found.
2
Failure
No user-controllable input
susceptible to injection
found.
Security Controls
ID
type
Security Control Description
1
Detective
Search for and alert
on unexpected SQL keywords in application logs
(e.g. SELECT, DROP,
etc.).
2
Preventative
Input validation of
user-controlled data before including it in a SQL
query
3
Preventative
Use parameterized
queries (e.g. PreparedStatement in Java, and
Command.Parameters.Add() to set query parameters
in .NET)
Exploit
Achieve arbitrary command execution
through SQL Injection with the MSSQL_xp_cmdshell
directive:
The attacker leverages a SQL Injection attack to
inject shell code to be executed by leveraging the
xp_cmdshell directive.
Outcomes
ID
type
Outcome Description
1
Success
Attacker's injected code is
executed.
Security Controls
ID
type
Security Control Description
1
Preventative
Disable xp_cmdshell
stored procedure on the
database.
2
Detective
Search for and alert
on unexpected SQL keywords in application logs
(e.g. SELECT, DROP,
etc.).
3
Preventative
Input validation of
user-controlled data before including it in a SQL
query
4
Preventative
Use parameterized
queries (e.g. PreparedStatement in Java, and
Command.Parameters.Add() to set query parameters
in .NET)
Inject malicious data in the
database:
Leverage SQL injection to inject data in the
database that could later be used to achieve command
injection if ever used as a command line
argument
Security Controls
ID
type
Security Control Description
1
Detective
Search for and alert
on unexpected SQL keywords in application logs
(e.g. SELECT, DROP,
etc.).
2
Preventative
Input validation of
user-controlled data before including it in a SQL
query
3
Preventative
Use parameterized
queries (e.g. PreparedStatement in Java, and
Command.Parameters.Add() to set query parameters
in .NET)
Trigger command line execution with
injected arguments:
The attacker causes execution of command line
functionality which leverages previously injected
database content as arguments.
Outcomes
ID
type
Outcome Description
1
Success
Attacker's injected code is
executed.
Attack Prerequisites
The application does not properly validate data before storing in the
database
Backend application implicitly trusts the data stored in the
database
Malicious data is used on the backend as a command line argument
Typical Likelihood of Exploit
Likelihood: Low
Methods of Attack
Analysis
Injection
Examples-Instances
Description
SQL injection vulnerability in Cacti 0.8.6i and earlier, when
register_argc_argv is enabled, allows remote attackers to execute
arbitrary SQL commands via the (1) second or (2) third arguments to
cmd.php. NOTE: this issue can be leveraged to execute arbitrary commands
since the SQL query results are later used in the polling_items array
and popen function (CVE-2006-6799).
The attacker most likely has to be familiar with the internal
functionality of the system to launch this attack. Without that
knowledge, there are not many feedback mechanisms to give an attacker
the indication of how to perform command injection or whether the attack
is succeeding.
Resources Required
No specialized resources are required
Solutions and Mitigations
Disable MSSQL xp_cmdshell directive on the database
Properly validate the data (syntactically and semantically) before writing
it to the database.
Do not implicitly trust the data stored in the database. Re-validate it
prior to usage to make sure that it is safe to use in a given context (e.g.
as a command line argument).
Vision and Technical Leadership provided by Cigital, Inc.
This Web site is hosted by The MITRE Corporation.
Copyright 2009, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.
Description
