CVE-2016-7919 - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Severity

50%

Complexity

99%

Confidentiality

48%

** DISPUTED ** Moodle 3.1.2 allows remote attackers to obtain sensitive information via unspecified vectors, related to a "SQL Injection" issue affecting the Administration panel function in the installation process component. NOTE: the vendor disputes the relevance of this report, noting that "the person who is installing Moodle must know database access credentials and they can access the database directly; there is no need for them to create a SQL injection in one of the installation dialogue fields."

** DISPUTED ** Moodle 3.1.2 allows remote attackers to obtain sensitive information via unspecified vectors, related to a "SQL Injection" issue affecting the Administration panel function in the installation process component. NOTE: the vendor disputes the relevance of this report, noting that "the person who is installing Moodle must know database access credentials and they can access the database directly; there is no need for them to create a SQL injection in one of the installation dialogue fields."

CVSS 3.0 Base Score 7.5. CVSS Attack Vector: network. CVSS Attack Complexity: low. CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).

CVSS 2.0 Base Score 5. CVSS Attack Vector: network. CVSS Attack Complexity: low. CVSS Vector: (AV:N/AC:L/Au:N/C:P/I:N/A:N).

Demo Examples

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89

In 2008, a large number of web servers were compromised using the same SQL injection attack string. This single string worked against many different programs. The SQL injection was then used to modify the web sites to serve malicious code.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89

The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.


               
...

The query that this code intends to execute follows:


               
SELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>;

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string:


               
name' OR 'a'='a

for itemName, then the query becomes the following:


               
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';

The addition of the:


               
OR 'a'='a

condition causes the WHERE clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:


               
SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89

This code intends to print a message summary given the message ID.


               
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");

The programmer may have skipped any input validation on $id under the assumption that attackers cannot modify the cookie. However, this is easy to do with custom client code or even in the web browser.

While $id is wrapped in single quotes in the call to mysql_query(), an attacker could simply change the incoming mid cookie to:


               
1432' or '1' = '1

This would produce the resulting query:


               
SELECT MessageID, Subject FROM messages WHERE MessageID = '1432' or '1' = '1'

Not only will this retrieve message number 1432, it will retrieve all other messages.

In this case, the programmer could apply a simple modification to the code to eliminate the SQL injection:


               
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");

However, if this code is intended to support multiple users with different message boxes, the code might also need an access control check (CWE-285) to ensure that the application user has the permission to see that message.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89

This example attempts to take a last name provided by a user and enter it into a database.


               
$query = "INSERT INTO last_names VALUES('$userKey', '$name')";# ensure only letters, hyphens and apostrophe are allowed

While the programmer applies a whitelist to the user input, it has shortcomings. First of all, the user is still allowed to provide hyphens which are used as comment structures in SQL. If a user specifies -- then the remainder of the statement will be treated as a comment, which may bypass security logic. Furthermore, the whitelist permits the apostrophe which is also a data / command separator in SQL. If a user supplies a name with an apostrophe, they may be able to alter the structure of the whole statement and even change control flow of the program, possibly accessing or modifying confidential information. In this situation, both the hyphen and apostrophe are legitimate characters for a last name and permitting them is required. Instead, a programmer may want to use a prepared statement or apply an encoding routine to the input to prevent any data / directive misinterpretations.

Demo Examples

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.


               
}
}
print "Login Successful";
print "Login Failed - incorrect password";
print "Login Failed - unknown username";

In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.

While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:


               
"Login Failed - incorrect username or password"

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

This code tries to open a database connection, and prints any exceptions that occur.


               
}
openDbConnection();
//print exception message that includes exception message and configuration file location
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';

If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database.

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file.


               
}
return userAccount;
}
userAccount = (BankAccount)queryResult.getObject(accountNumber);
Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex);

The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database.

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

This code stores location information about the current user:


               
}...
Log.e("ExampleActivity", "Caught exception: " + e + " While on User:" + User.toString());

When the application encounters an exception it will write the user object to the log. Because the user object contains location information, the user's location is also written to the log.

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

The following is an actual MySQL error statement:


               
Warning: mysql_pconnect(): Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/wi-data/includes/database.inc on line 4

The error clearly exposes the database credentials.

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

This code displays some information on a web page.


               
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>

The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary.

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

The following program changes its behavior based on a debug flag.


               
} %>

The code writes sensitive debug information to the client browser if the "debugEnabled" flag is set to true .

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:


               
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:


               
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.

Overview

First reported 8 years ago

2016-10-28 15:59:00

Last updated 8 years ago

2016-12-02 23:13:00

Affected Software

Moodle 3.1.2

3.1.2

Stay updated

ExploitPedia is constantly evolving. Sign up to receive a notification when we release additional functionality.

Get in touch

If you'd like to report a bug or have any suggestions for improvements then please do get in touch with us using this form. We will get back to you as soon as we can.