Today’s post is a collaboration sent by the team of CSIRT-CV, the ICT Security Center of the Valencian Community, in relation to the detection of a vulnerability in the CMS Tiki-Wiki during last December.
A few months ago, in December 2019, the CSIRT-CV team discovered a vulnerability in the CMS Tiki-Wiki, a WordPress, Joomla or Drupal style content management system.
This vulnerability was published months later, in April 2020, with the code CVE-2020-8966, as can be seen on our alerts page, giving developers enough time to correct the problem detected in the application. All of this was channeled through INCIBE-CERT, which mediated with the developer company. Once corrected and published, and after the problems derived from the Covid-19, we have taken some time to go through its details.
During an penetration test carried out on an internal website using this CMS, several Reflected Cross-Site Scripting (XSS) vulnerabilities were detected on version 18.3, even though its exploitation was still effective on the last available version, v.20.0 at that time.
The XSS vulnerability allows code to be injected into a data entry field on a website: a search engine, a forum discussion field or a data collection form. The intention is to execute the injected code in the victim’s browser after they access the resource. This vulnerability can be persistent, when the injected code is stored on the site and executed in the browser of each user accessing the page, or reflected, when it is not stored but is embedded within the URL, and is sent to the victim to click on, such as an email, a social network link, etc.
In this case, several resources were identified as being vulnerable to reflected XSS, which could (and can, on vulnerable systems) be exploited by any malicious user to carry out different types of attack: session theft, browser attacks, downloading of malware, keyloggers or other client-side attacks.
Resource tiki-index.php
After this brief introduction, we go to the first security problem, detected in the msg parameter of the tiki-index.php resource (URL: http://server/resource/tiki-index.php).
As can be seen in the proof of concept (PoC), the parameter msg does not prevent the use of special characters and therefore allows the execution of the alert function. The following JavaScript code was injected into the request, displaying the XSS text and confirming that it was vulnerable.
Resource tiki-contact.php
Another parameter vulnerable to XSS was subject of the resource tiki-contact.php (URL: http://server/resource/tiki-contact.php), a form used to send an email to the CMS administrator. As in the previous case, it also did not correctly filter the text input allowing the injection of the code, as shown in the image:
This time the following code was used with the alert function, to be executed when passing the mouse over the subject field (“Tema”) of the contact form:
Resource tiki-pagehistory.php
The following three vulnerable parameters were detected on the CMS history resource tiki-pagehistory.php (URL: http://server/resource/tiki-pagehistory.php).
The first vulnerable parameter was detected when observing that it was possible to enable paging and set a maximum number of results per page.
The history_pagesize parameter, as in the previous cases, did not filter the input data and allowed to execute JavaScript code again. For this PoC, the request made by the resource on the client side against the server was modified to enable and select the maximum pagination value, which, since it was not correctly sanitized, allowed the following code to be injected:
With the second vulnerable parameter we find a similar situation to the previous one when changing pages in the history.
To do this, the parameter history_offset was established with the value previously indicated as the maximum value of results per page and on the same URL (http://server/resource/tiki-pagehistory.php?page=Inici&history_offset=25), and it was found that the following code could be executed:
The third vulnerable parameter on the tiki-pagehistory.php resource was identified by pressing the “Collapse Into Edit Sessions” button.
It made a GET request (http://server/resource/tiki-pagehistory.php?page=Inici&clear_versions=1&show_all_versions=n) containing the show_all_versions parameter, which was also not validated correctly, allowing the injection of the following code on the URL itself:
Resource tiki-browse_freetags.php
Finally, another security flaw was detected in tiki-browse_freetags.php (URL:http://server/resource/tiki-browse_freetags.php). This case is special because the code to be injected goes right after the file name, before the definition of the parameters with which the resource is called, so there is no parameter involved.
When this resource is accessed, one of the links generated by the website itself, responsible for displaying more content, takes part of the current URL as the destination URL. Since it is not filtered properly, by inserting the character “/” it was possible to inject JavaScript code, as can be seen in the following images:
With this we conclude this entry about the XSS security flaws discovered by CSIRT-CV in the CMS Tiki-Wiki, emphasizing the importance of developing applications following the existing guides of secure development, thus improving the security of our users.
