Our SAST tool RIPS analyzed the whole application in only 1m 32s and uncovered many severe security issues. Most of them are straight-forward SQL Injections that can be used to extract confidential user data, such as passwords, private messages, course results, and personal information. Also, a code evaluation vulnerability was detected but luckily for the users, the affected user-defined function is not in use. Still, we added it to our demo report.
Example 1: SQL Injection and Context Tab
The first example is a SQL Injection vulnerability that can be exploited by any registered student. A student account is easily attainable due to the nature of the platform and no other obstacles have to be bypassed. The following code lines trigger the vulnerability.
Here, the GET parameter
id is concatenated directly into the third parameter
$where of the
eF_getTableData() function without any input sanitization or validation. Then, this parameter is passed to the
prepareGetTableData() function in order to built a SQL query.
$where variable is appended to the SQL query in line 401, as shown in the code summary above. As a result, the susceptible SQL query is executed within the
GetAll() method. An attacker can inject arbitrary SQL commands into the where clause and alter the SQL query result, such that sensitive information are retrieved from the database instead of the intended topics data. For example, the attacker is able to retrieve the professors’ passwords or to read all private messages. The vulnerability can be patched by casting the GET parameter
id to integer:
$id = (int)$_GET['id']. This way, only numeric values can be used as
id in the WHERE clause and no SQL commands can be injected.
RIPS is able to follow the data flow throughout the function and method calls and detects the tainted data in the SQL query that is finally executed. The cool thing is that RIPS is also able to reconstruct the full SQL query that is built. This eases the verification of a vulnerability drastically, specifically for large data flow traces. In the context tab of RIPS, the fully reconstructed SQL query and the injection point of tainted user input is presented:
Example 2: SQL Injection and Array Analysis
Our second example shows a SQL injection that is very similar to the first one, which is the case for almost all SQL injections within the application.
Here, all data within the superglobal
$_POST variable is propagated to the
$fields array (lines 10-12). Then, the keys
users_LOGIN are concatenated unsanitized to the SQL query via the
$where parameter of the
From the static code analysis point of view, this example is interesting because it requires a highly precise analysis of data flow through arrays and its keys. First, the propagation of arbitrary tainted data to arbitrary array keys in the
foreach loop has to be detected. Then again, the tainted data in specific array keys are overwritten (
users_LOGIN) or unset (
objectives), effectively eliminating the possibility for exploitation for these specific keys. In the end, the analysis must decide which array keys can be tainted by a malicious user, and which array keys cannot and would lead to false positive reports.
|2016/09/28||First contact with vendor|
|2016/09/28||Vendor publicly declares EOL for open-source edition|
In this post, we covered two SQL injection vulnerabilities. While the issues seem easy to spot from our code summaries, they were hidden in 700,000 lines of code. With the help of our code analysis solution RIPS the issues were automatically and precisely detected.
The vendor reacted quickly to our submission and, surprisingly, declared the end-of-life for the open-source edition. For the plenty of users of this version there are currently no patches available. Hopefully, the community will be able to address some of these problems, for example by introducing prepared statements to the code base. We did not perform an analysis of the professional edition.
Follow us on Twitter to be notified when the next gift of our advent calendar is opened!
APAV Time Table
Disclaimer: The information provided here is for educational purposes only. It is your responsibility to obey all applicable local, state and federal laws. RIPS Technologies GmbH assumes no liability and is not responsible for any misuse or damages caused by direct or indirect use of the information provided.