My adventure at JoomlaDay Italy 2013 (and my thoughts on the JSST)

Just a year ago I had the pleasure to talk about the PHP Object Injection vulnerabilities I discovered in Joomla at the JoomlaDay Italy 2013 held in Naples, one of the most beautiful cities I have ever seen. Today I would like to share with you my experience at that day and some further details about the disclosure process I had with the Joomla! Security Strike Team (JSST).Before that, I would like to take the opportunity to say thank you to Alessandro Rossi (AlexRed), one of the Italian JoomlaDay’s organizers, and most of all the guy who personally invited me on the JoomlaDay’s stage, giving me the chance to show that the vulnerabilities I discovered are actually a bit more critical compared to what the JSST has stated in its bulletins. I’m well aware about the fact that Joomla is an open source project and all developers are working in their spare time, so it’s not so fair pointing the finger at them. On the other hand, as the second most popular CMS software on the Internet, I think its security should be taken very seriously, and I guess this is the reason why in August 2008 they introduced the Joomla! Security Strike Team. As you can read in their introduction page to the JSST, one of its key responsibilities is to “release information on verified issues in the most timely and responsible way possible”. Sadly I have to disagree with this (at least based on my own experience with them), because to fix two serious PHP Object Injection vulnerabilities they took several months, while to fix what (in my humble opinion) seems to be a non-vulnerability they took just a couple of days. But let’s start from the beginning…

October 31, 2012: this is the day I tried to have the first contact with the JSST, notifying them about the PHP Object Injection vulnerability in the highlighter plugin (CVE-2013-1453). However, at the time I still hadn’t found any exploitable magic method within the Joomla core, and maybe that’s the reason why my report has been overlooked (even though I’ve stated about the possibility to exploit the vulnerability by abusing magic methods of third-party components).

November 8, 2012: seeing that after one week no response has been received, I tried to strive in finding an exploitable magic method within the core, and the result has been the arbitrary directory deletion chain I described in my first blog post. Therefore I wrote them again, describing how the vulnerability could be exploited leveraging the destructor method of the plgSystemDebug class to reach the JCacheStorageFile::_deleteFolder() method. This time they replied asking for a Proof of Concept, which I promptly sent stating that it works also in Joomla 2.x in case the “Debug System” or “Debug Language” options are enabled.

December 1, 2012: I got an email from a member of the JSST stating he is not able to reproduce the issue, so I tried to explain him how to properly use the Proof of Concept, and he replied saying that my Proof of Concept script “just gives him the source code for the index.php page, it doesn’t delete anything”. Thus, for the sake of simplicity, I just provided him a URL which triggers a __PHP_Incomplete_Class fatal error, proving that the vulnerability actually exists. The vendor replied he can see the error with that URL, and the vulnerability will be fixed in the next Joomla releases.

December 4, 2012: the vendor sent me a proposed patch for the issue, which basically replaces unserialize() with json_decode(), and asked me if the patch works fine to solve the vulnerability. I replied that the patch is ok, and at the same time I suggested to investigate other potentially vulnerable unserialize() calls, stating that e.g. the “remember me” plugin uses unserialize() on user input passed through cookies, but I wasn’t sure whether this is exploitable due to the encryption system. That day I felt that this class of vulnerabilities was still too unknown and underestimated, that’s why I decided to write an OWASP page about it.

January 11, 2013: I just asked the JSST when they was planning to release new versions to fix this vulnerability, since it had been a long time from my initial vulnerability report. The response was the following: “we don’t a firm date for version 3.0.3 but I am aiming for some time before January 31″.

February 4, 2013: new Joomla versions have been released which fix the vulnerability, and the JSST has published a security bulletin for it: the vulnerability has been classified as a trivial information disclosure, with severity “Low”. So I dropped a new email, explaining that their information was wrong, since in my view this is a more critical vulnerability, which opens the doors to further malicious attacks. They replied saying “the only vulnerability we could reproduce was the information disclosure”, basically the webroot path disclosure produced by the __PHP_Incomplete_Class fatal error. Therefore I decided to share with them a video which shows how to use my Proof of Concept code and its consequences, but nothing changed.

February 13, 2013: seeing that the potentially vulnerable unserialize() call was still present in the “remember me” plugin (and my suggestion has been ignored), I decided to dug deeper in it, realizing that its encryption system could easily be bypassed, as described in my second blog post. Therefore I wrote a new Proof of Concept code and I sent it to the JSST along with a new video to show how to reproduce the issue, and… Try to guess their response! Yes, it was “I don’t understand your video with the POC for the remember me exploit”. I started to get bored, so I used my Proof of Concept against their demo website during a chat session with one of them, proving that it works and it makes a Joomla website unavailable (Denial of Service).

February 18, 2013: while I was getting bored of being misunderstood, I continued to investigate other possible attack vectors, until I found the blind SQL injection chain described in my first blog post. So I wrote once again to the JSST, providing the description of the new attack vector along with a new Proof of Concept, stating that other attack vectors might be possible.

April 24, 2013: new Joomla versions have been released to fix the “remember me” vulnerability (CVE-2013-3242). However, once again their security bulletin about it is misleading, since it has been classified as a DoS vulnerability with severity “Moderate”. I guess they decided to publish it as a DoS vulnerability just because I showed them how it could be exploited against their demo website, not because they were able to reproduce the issue or really understand the vulnerability’s scope.

October 12, 2013: I had the opportunity to publicly show the real impact of these vulnerabilities at the JoomlaDay Italy 2013. During my talk I tried to describe what is a PHP Object Injection vulnerability generally, and how this kind of vulnerabilities has affected Joomla (here you can find the slides used in my talk). After that I performed a live demo to show how these vulnerabilities could have been exploited to carry out Session Hijacking attacks leveraging the blind SQL injection chain and cause a Denial of Service condition through the arbitrary directory deletion chain:

The video quality is not the best, but good enough to see the damage these vulnerabilities could have been done. Please note that, specially in the final part, YouTube’s automatic captions feature understands some fancy words that I swear I haven’t said, some of them should probably be prohibited to minors under 14. So please don’t watch it with your kids! 😄

Conclusion

In my view these vulnerabilities should have been classified at least as “High”, and consequently should have been fixed promptly, not waiting several months. The following is a summary of these vulnerabilities’ scope as of today:

• Joomla 1.5: this version of Joomla is affected only by CVE-2013-3242, which has not been officially fixed since it has reached EOL/EOS. As I said during the JoomlaDay I haven’t been able to exploit the vulnerability by abusing magic methods of Joomla 1.5 core. The only potentially interesting method I found is patTemplate::__toString(), however such class is not defined when unserialize() is being called, and there’s no class autoloading functions. If someone will be able to exploit this vulnerability in Joomla 1.5 (without any third-party component), then he/she will become my hero.

• Joomla 2.5: this version of Joomla is affected by both of the vulnerabilities, and when the “Debug System” or “Debug Language” options are enabled they could be exploited to cause a Denial of Service condition through the arbitrary directory deletion chain. In addition, there’s another attack vector that could be used to carry out Server-Side Request Forgery (SSRF) attacks or Distributed Denial of Service (DDoS) by abusing vulnerable Joomla websites as zombie machines.

• Joomla 3.0: this version of Joomla is affected by both of the vulnerabilities and, as demonstrated during the JoomlaDay Italy 2013, they could be exploited to carry out blind SQL injection attacks and cause a Denial of Service condition. Furthermore, a recent research shows how these vulnerabilities could have been exploited to carry out Local File Inclusion (LFI) attacks when Joomla is running on outdated PHP versions (5.1.0 – 5.3.3).

In my humble opinion, I truly believe that the JSST needs a real security expert, and it’s not just because of this long story. For instance, they classifies Cross-Site Scripting vulnerabilities with severity “Moderate”, without even making a difference between reflected and stored Cross-Site Scripting. I would agree to classify a stored XSS as “Moderate”, but not a reflected one. For example this recent XSS, classified as “Moderate”, not only is a reflected one, but the malicious payload is executed only when the victim clicks on a select box (since the JavaScript code is injected into an onchange event), so it requires more user interaction then usual, definitely qualifying it as a minor security weakness. Another example would be what in my view is an epic fail of the JSST: the non-vulnerability I was talking about at the beginning of this post (which recently got CVE-2014-7983 assigned) is supposed to be a stored XSS. However, it seems that the malicious JavaScript payload is being stored into a session variable, meaning that a potential attacker might be able to “steal” only its own session ID… What a big security threat! This is the proof that nowadays vulnerabilities like a Cross-Site Scripting are too overestimated, as opposed to more serious vulnerabilities, like a PHP Object Injection, which fortunately is going to be less underestimated, especially in recent months.