Home > CAPEC List > CAPEC-108: Command Line Execution through SQL Injection (Version 2.6)  

CAPEC-108: Command Line Execution through SQL Injection

 
Command Line Execution through SQL Injection
Definition in a New Window Definition in a New Window
Attack Pattern ID: 108
Abstraction: Detailed
Status: Draft
Completeness: Complete
+ Description

Summary

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
  1. Probe for SQL Injection vulnerability:

    The attacker injects SQL syntax into user-controllable data inputs to search unfiltered execution of the SQL syntax in a query.

    Indicators

    IDTypeIndicator DescriptionEnvironments
    1Negative

    Attacker receives normal response from server.

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    2Positive

    Attacker receives an error message from server indicating that there was a problem with the SQL query.

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    3Negative

    Server sends a specific error message that indicates programmatic parsing of the input data (e.g. NumberFormatException)

    env-Web env-ClientServer env-Peer2Peer env-CommProtocol

    Outcomes

    IDTypeOutcome Description
    1Success
    At least one user-controllable input susceptible to injection found.
    2Failure
    No user-controllable input susceptible to injection found.

    Security Controls

    IDTypeSecurity Control Description
    1Detective
    Search for and alert on unexpected SQL keywords in application logs (e.g. SELECT, DROP, etc.).
    2Preventative
    Input validation of user-controlled data before including it in a SQL query
    3Preventative
    Use parameterized queries (e.g. PreparedStatement in Java, and Command.Parameters.Add() to set query parameters in .NET)
Exploit
  1. 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

    IDTypeOutcome Description
    1Success
    Attacker's injected code is executed.

    Security Controls

    IDTypeSecurity Control Description
    1Preventative
    Disable xp_cmdshell stored procedure on the database.
    2Detective
    Search for and alert on unexpected SQL keywords in application logs (e.g. SELECT, DROP, etc.).
    3Preventative
    Input validation of user-controlled data before including it in a SQL query
    4Preventative
    Use parameterized queries (e.g. PreparedStatement in Java, and Command.Parameters.Add() to set query parameters in .NET)
  2. 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

    IDTypeSecurity Control Description
    1Detective
    Search for and alert on unexpected SQL keywords in application logs (e.g. SELECT, DROP, etc.).
    2Preventative
    Input validation of user-controlled data before including it in a SQL query
    3Preventative
    Use parameterized queries (e.g. PreparedStatement in Java, and Command.Parameters.Add() to set query parameters in .NET)
  3. Trigger command line execution with injected arguments:

    The attacker causes execution of command line functionality which leverages previously injected database content as arguments.

    Outcomes

    IDTypeOutcome Description
    1Success
    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 Severity

Very High

+ 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).

Reference: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6799

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: High

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).

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Integrity
Modify application data
Confidentiality
Read memory
Read application data
Availability
DoS: crash / exit / restart
DoS: instability
Confidentiality
Access_Control
Authorization
Gain privileges / assume identity
Confidentiality
Integrity
Availability
Execute unauthorized code or commands
Run Arbitrary Code
+ Relevant Security Requirements

Validate all data syntactically and semantically before writing it to the database

Do not implicitly trust database data and validate it to ensure that it is safe in the context in which it is being used

+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: High
+ Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
+ Content History
Submissions
SubmitterOrganizationDateSource
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team

Page Last Updated: July 23, 2014