Making Free Software Safer: Bugs and Fixes InstantCMS

    With this article, we begin a series of materials devoted to the search for vulnerabilities in popular open source systems. Errors in OpenSSL and glibc showed that thousands of eyes accessing the code are not a guarantee of open source security. Of course, even closed code does not become safer from the fact of being closed. Simply, with the right tools, the availability of the source code allows you to identify much more vulnerabilities than when testing with the "black box" method. The only question is who will take advantage of this before - developers or attackers.

    image

    Over the past two years, during the development of the source code analysis system PT Application Inspector, we have tested hundreds of free and commercial, open and proprietary applications at 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 , some are expected to die in a responsible disclosure.

    We take advantage of the open source openness and show how vulnerabilities in the source code are identified and analyzed. The first test subject is the free InstantCMS community management system, which runs on PHP and MySQL. Based on this constructor, a lot has been created.social networks, dating sites, online clubs, city portals and government resources.

    Currently, the InstantCMS developer has fixed all the vulnerabilities that we discovered. In this article, we will consider errors of the version that was relevant at the time of testing - several dozen bugs of varying degrees of risk were found in it. The most interesting are described below.

    Brief FAQ about the project:
    Q: How are systems selected for verification?
    A: Meet experts in the course of consulting work on penetration testing and security analysis.

    Q: What is PT Application Inspector?
    A: Source code analysis system: ptsecurity.ru/appsecurity/application-inspector

    Q: Why do not you write about the XXX system?
    A: It has either not yet been tested, or its vulnerabilities are still fixed by the developers. Write to us in the comments or by mail, put in the queue.

    Q: What do you do with vulnerabilities?
    A: We send information to software manufacturers and help eliminate errors. Full list of detected vulnerabilities: ptsecurity.ru/lab/advisory

    Any CMS has at least one XSS


    Examining the InstantCMS code, our analyzer reported the possibility of carrying out an XSS attack (cross-site scripting) in this format: Fig. 1.1. Reporting an XSS Vulnerability The message contains the full name of the script, line number, and the code itself containing the vulnerability. This information is important for the developer: now he can find the error that caused this vulnerability. Now, to check for vulnerabilities, we will look at the automatically generated exploit, as well as the conditions under which the operation of the error will be successful. Fig 1.2. Details of the XSS Found Obviously, the condition is true only when a specific parameter is passed in the request: '

    image







    image





    textinputs[]='

    Let's check how it works in practice. We send the 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 delve into the code and find a programmer's error. We will use the information from the Application Inspector, namely the full name of the script, the line number and the code itself containing the vulnerability (see Fig. 1.2). After analyzing the source code, we get the following picture: File spellchecker.php:

    image










    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 known line number 27, in which the dangerous function “echo” is called: The

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

    What can be achieved with XSS? At least an invite on the Habré :) And if the stars converge - get at your disposal the cookies of the site administrator, and therefore access to the admin panel.

    HTTP Response Splitting Vulnerability


    In the course of further scanning, it was found out that it was possible to carry out an attack based on splitting the HTTP response of the server (HTTP Response Splitting): Figure 2.1. Application Inspector report (on the right - vulnerability in detail) A classic test exploit was generated that adds an additional header by introducing the characters "line feed" and "carriage return". Operation is possible if the application runs on PHP version lower than 5.1.2 (in later versions, the interpreter has built-in protection against such attacks). Fig. 2.2. Vulnerability Flow Graph Shows Vulnerability

    image





    image



    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 dangerous function was called on line 32 of the set.php file. Having opened the source code, we really see that the parameter received without any filtering from the POST request in the 15th line of the same file falls into the indicated line.

    image

    Fig 2.3. Program code containing the vulnerability

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

    Open Redirect Vulnerability


    As a result of the scan, it was possible to carry out an attack classified as Open Redirect - an open redirect: Figure 3.1. Report on the availability of Open Redirect, with detailed information. We will use an automatically generated exploit request: we will send it to the stand server and analyze the response. Fig 3.2. Request-exploit for checking the vulnerability of Open Redirect and the answer to it As we can see, in the CMS under study there really is an open redirection: the response to the request was a page of a third-party resource transmitted in the attack vector. Let's try to figure out the reasons. The report says that the attack exit point is line 32 of the set.php file. Let's open the program code: Figure 3.3. Vulnerable Code

    image





    image





    image



    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 reason for the vulnerability becomes clear - passing the unfiltered parameter in the 15th line of the set.php file. To fix the error, additional checks are needed for the $ back variable.

    Why is this vulnerability dangerous? First of all, by the ability to almost invisibly redirect the user to the infected page, and then, just as quietly, return it.

    Splitting and redirecting in fresh PHP and Internet Explorer


    Splitting using the character sequence% 0D% 0A works on PHP versions lower than 5.1.2, but in some situations it is possible even if the server uses a modern version of PHP.
    Suitable conditions arise if the client is Internet Explorer: it understands the sequences% 0A% 20 or% 0D% 0A% 20 as a delimiter, while other browsers consider the new line starting with a space to be the continuation of the previous header. This IE behavior and insufficient filtering in the header () function in PHP make 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 introduction of the header and content in IE are below, the address for verification is: molnar.es/php-header/test.php. Fig. 4.1 Fig. 4.2

    image



    image



    It is possible to check the introduction of headers and open redirection to a vulnerable script (InstantCMS set.php in IE) using AI. Let's take information from two exploits obtained by AI (address, method, unfiltered parameter) to demonstrate such an attack vector using ptsecurity.com as an example. Let's create a form that sends the desired vector to the desired address, and see if the attack works. As you can see, yes: in fig. Figure 4.4 shows both the address of the script (set.php), and the redirect (status 302 and then loading ptsecurity.com) and splitting (custom header).

    Now the steps:

    1. Create a page with the form:



    2. We go to the page in IE and send a request.

    The result of the query: Fig. 4.3 Fig. 4.4 In fig. Figure 4.4 shows that in addition to the redirection, the Custom-Header header was set with the value Test.

    image



    image





    SQL injection


    Consider another example of a vulnerability discovered using AI. According to the results of the scan, the implementation of SQL-code (SQL Injection) is possible in InstantCMS, and even in various versions. Fig. 5.1. Snippet report PT AI. The same type of SQL injection - and detailed information about one of them In addition to identifying the vulnerable code fragment and parental vulnerability in the application, PT AI provides the necessary conditions for an attack.

    image





    In fig. Figure 5.1 shows that the operation of SQL Injection requires several conditions, one of which is the presence of an attack vector in the session. This is a sign of inter-module vulnerabilities (Second Order SQL Injection stored by XSS). For such bugs, data does not fall into a vulnerable function immediately from variables from entry points, but from some intermediate repositories - databases, sessions, etc., where they somehow ended up before.

    Exploitation of intermodular vulnerabilities occurs in several stages. For example, for stored XSS, data is entered into the DBMS with one request, and is extracted from there with the second request and displayed on the page with something.

    image

    Fig. 5.2. Stored XSS Maintenance Scheme

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

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

    To do this:

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

    2. Make a request with a cookie corresponding to the session file from p. 1, to the InstantCMS page, upon generation of which the vector from the session will fall into the SQL query.

    An example of a PHP script generating a file:

    ' . $output . '
    '; ?>
    The attack takes place in two stages:

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

    image

    Fig. 5.3. Example 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 after about 5 seconds for the vector with sleep (5), which confirms the presence of SQL Injection.

    It is worth emphasizing a couple more points:

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


    The SQL Injection vulnerability allows you to crank up 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 among those considered in this article. Session management errors can be found in the presentation on ZeroNights, which showed a similar case of session management errors in relation to CMS.

    That's all with InstantCMS. We will continue to investigate vulnerabilities in other open source systems in the following materials.

    Also popular now: