Making Free Software Safer: InstantCMS Bugs And Fixes

With this article we begin a series of materials devoted to finding vulnerabilities in popular open source systems. Errors in OpenSSL and glibc have shown that the thousands of eyes that have access to the code are not a guarantee of open source security. Of course, the closed code does not become safer from the fact of closure. Just with the right tools, the availability of the source code reveals much more vulnerabilities than when testing with the black box method. The only question is who will take advantage of this earlier - the developers or the attackers.



During the last two years during the development of the PT Application Inspector source code analysis system, we tested hundreds of free and commercial, open source and proprietary applications on the stands and “in the field”. During these tests, a significant number of zero-day vulnerabilities were found. Some of these problems were closed and known from the latest SCADA security reports, and some await their death in the course of responsible disclosure.
')
Let us take advantage of open source openness and show how vulnerabilities in the source code are identified and analyzed. In the role of the first experimental is a free community management system InstantCMS, working in PHP and MySQL. On the basis of this designer, a lot of social networks, dating sites, online clubs, city portals and government resources have been created.

Currently, the developer of InstantCMS has eliminated all the vulnerabilities we detected. In this article we will look at the errors of the version that was relevant at the time of testing - several dozens of bugs of different degrees of risk were found in it. The most interesting are described below.

Every CMS has at least one XSS

Investigating the InstantCMS code, our analyzer reported the possibility of an XSS attack (cross-site scripting) in this format:



Fig. 1.1. Report XSS Vulnerability

The message contains the full name of the script, the line number and the code itself that contains the vulnerability. This information is important to the developer: he can now find the error that caused this vulnerability.

Now, to check for the presence of a vulnerability, we will look at the automatically generated exploit, as well as the conditions under which the operation of the error will be successful.



Figure 1.2. Details of the XSS found

Obviously, the condition is true only when a specific parameter is passed in the request:

textinputs[]=' '

Let's check how it works in practice. We send an exploit to the server and get the answer:



Figure 1.3. Server request and response

As you can see, the server response in the HTML page contains exactly the JavaScript code that we sent in the exploit.
So we made sure that the vulnerability exists. It's time to dig into the code and find a programmer's error. We use information from the Application Inspector, namely, the full name of the script, the line number and the code that contains the vulnerability (see Figure 1.2).

After analyzing the source code, we get the following picture:

File spellchecker.php:

 17 : $textinputs = $_POST['textinputs']; … function print_textinputs_var() { global $textinputs; foreach( $textinputs as $key=>$val ) { 27 : echo "textinputs[$key] = decodeURIComponent(\"" . $val . "\");\n"; } } … 161 : print_textinputs_var(); 

The print_textinputs_var () function is declared at the top of the same script and just contains the line number 27 known to us, in which the dangerous function “echo” is called:

The analysis showed that the code in line 17 contains a flaw - the unfiltered parameter $ _POST ['textinputs'] - which caused the vulnerability in line 27. And this, in turn, made the XSS attack possible.

What can be achieved with XSS? At a minimum, invite to Habré :) And if the stars converge, get the site administrator cookies and, consequently, access to the admin panel.

HTTP Response Splitting vulnerability

In the course of further scanning, an opportunity was discovered to conduct an attack based on splitting the HTTP response of the server (HTTP Response Splitting):



Figure 2.1. Report Application Inspector (on the right - vulnerability in details)

A classic test exploit has been generated, which adds an additional header by embedding the “line feed” and “carriage return” characters. Operation is possible if the application runs on PHP versions below 5.1.2 (in later versions, the interpreter has built-in protection against such attacks).



Fig. 2.2. The flow graph shows the presence of a vulnerability.

The result of the analysis allows you to find the cause of the vulnerability and develop recommendations for its elimination. The PT AI system indicated that the call to the dangerous function occurred on the 32nd line of the set.php file. Having opened the source code, we really see that the parameter receives a parameter that is received without any filtering from the POST request in the 15th line of the same file.



Figure 2.3. The code that contains the vulnerability

There are cases when the analysis of the causes of vulnerability is much more laborious, but in this case and the causes of vulnerability, and ways to fix it are obvious. The programmer needs to add additional checks when assigning the value of the $ back variable.

Open Redirect vulnerability

As a result of the scan, an opportunity to conduct an attack classified as Open Redirect was discovered - an open redirect:



Figure 3.1. Open Redirect availability report with detailed information

We will use the automatically generated exploit request: we will send it to the server stand and analyze the answer.



Figure 3.2. Request-exploit to check the vulnerability of Open Redirect and answer it

As we see, in the CMS under study, an open redirection actually takes place: the response to the request was a third-party resource page transmitted in the attack vector. Let's try to understand the reasons. The report says that the exit point of the attack is line 32 of the set.php file. Open the program code:



Figure 3.3. Vulnerable section of software code

In the 32nd line, the location header is formed with the value from the $ back variable. In turn, the $ back variable takes its value from the $ _POST array in the 15th line of the same file without any additional checks. Thus, the cause of the vulnerability becomes clear - passing an unfiltered parameter in the 15th line of the set.php file. To eliminate the error, additional checks are needed for the $ back variable.

What is the danger of this vulnerability? First of all - the ability to virtually redirect the user to the infected page, and then, just as quietly, return it back.

Spliting and redirecting in fresh PHP and Internet Explorer

Spliting using the% 0D% 0A character sequence works on PHP versions below 5.1.2, but in some situations it is possible even if the server is using a modern version of PHP.
Suitable conditions arise if the client is Internet Explorer: it understands the% 0A% 20 or% 0D% 0A% 20 sequences as a separator, while other browsers consider the new line, starting with a space, to be a continuation of the previous header. This behavior of IE and insufficient filtering in the PHP header () function makes splitting possible. A bug in header () has been fixed recently ( bugs.php.net/bug.php?id=68978 ) and will soon be released.

Examples of the implementation of the title and content in IE - below, the address to check: molnar.es/php-header/test.php.



Fig. 4.1



Fig. 4.2

You can check the implementation of headers and open redirection in a vulnerable scenario (InstantCMS set.php in IE) using AI. Take information from two exploits received by AI (address, method, unfiltered parameter) to demonstrate such an attack vector using the example of ptsecurity.com. Make a form that sends the desired vector to the desired address, and see if the attack works. As you can see, yes: in fig. 4.4 you can see the address of the script (set.php), and the redirect (status 302 and then download ptsecurity.com) and spliting (custom header header).

Now step by step:

1. Create a page with the form:

 <form action="http://example.com/modules/mod_template/set.php" method="POST"> <textarea cols="100" rows="10" name="back">http://www.ptsecurity.com/ Custom-Header: Test</textarea><br/> <input type="submit"> </form> 

2. Go to the page in IE and send the request.

The result of the query:



Fig. 4.3



Fig. 4.4

In fig. 4.4 you can see that in addition to the redirection, the Custom-Header header was set to Test.

SQL Injection

Consider another example of a vulnerability discovered by AI. According to the scan results, InstantCMS can inject SQL code (SQL Injection), and even in various variants.



Fig. 5.1. Fragment of the PT AI report. SQL injections of the same type - and detailed information about one of them

In addition to identifying the vulnerable code fragment and the parental vulnerability in the application, PT AI provides the necessary conditions for an attack.

In fig. 5.1 you can see that for operating SQL Injection several conditions are required, one of which is the presence of an attack vector in a session. This is a sign of intermodular vulnerabilities (Second Order SQL Injection, stored XSS). For such bugs, the data gets into the vulnerable function not immediately from the variables from the entry points, but from some intermediate repositories - bases, sessions, etc., where they somehow turned out to be.

Operation of intermodular vulnerabilities occurs in several stages. For example, for a stored XSS, data is entered into a DBMS by a single query, and the second query is retrieved from there and displayed on the page.



Fig. 5.2. Scheme of operation of stored XSS

Let us demonstrate the exploitation of the found Second Order SQL Injection vulnerability under conditions that allow an attacker to change the values ​​of variables in a session. Take the simplest example - shared hosting with shared session storage. Hosting has a configuration error - the value of the PHP directive session.save_path, which by default is equal to / tmp ( details ).

If several sites are spinning on the server, one of which is controlled by the attacker, we can attack the neighboring resource, which operates on the basis of InstantCMS, with minimal rights.

For this you need:

1. Create a session file with a vector for SQL Injection.

2. Make a request with a cookie corresponding to the session file from section 1 to the InstantCMS page, when generated, the vector from the session will be included in the SQL query.

An example of a PHP script that generates a file:

 <?php session_start(); $sessionSavePath = session_save_path(); $_SESSION['user']['id'] = "1' and sleep(5)='"; session_write_close(); $sessionFilePath = $sessionSavePath . '/sess_'. session_id(); $output = 'session id: ' . session_id() ."\n" . 'session file: '. $sessionFilePath . "\n" . 'chmod result: ' . var_export(chmod($sessionFilePath, 0755), TRUE) . "\n" . "file: \n\n" . file_get_contents($sessionFilePath) . "\n"; echo '<pre>' . $output . '</pre>'; ?> 

The attack takes place in two stages:

First, a script is launched that creates a vector file and displays the value for the session cookie.



Fig. 5.3. Sample vector file for SQL Injection in InstantCMS

Then the following request is sent to the site with InstantCMS:

 GET /admin/index.php HTTP/1.1 Host: victim Cookie: PHPSESSID=session Connection: close 

The server response will be received in about 5 seconds for the vector from sleep (5), which confirms the presence of SQL Injection.

It is worth emphasizing a couple of points:

• The described attack scenario would not work if the code in InstantCMS set the value of session.save_path, which differed from the value for the attacker's site, and did not allow the rights to the session directory to get the list of files, read them, change them and create their own.
• Sometimes there are bugs with injection in the session ( 1 , 2 ) - both in PHP itself and in the application code.

The vulnerability of SQL Injection allows you to turn a lot of bad tricks, from reading the contents of database tables to uploading to the web shell server, this is the most dangerous type of attack considered in this article. You can read about session management errors in the presentation on ZeroNights, where they showed a similar case of session management error as applied to CMS.

With InstantCMS, that's it. We will continue to explore vulnerabilities in other open source systems in the following materials.