vBulletin is one of the most popular proprietary forum solutions over the Internet. It is used by some major websites, and according to the BuildWith website, vBulletin currently ranks at the second place on the Forum Software Usage Distribution in the Top 1 Million Sites, with over 2.000 websites using it among the “top 1 million”. vBulletin is also known for some famous 0-day Remote Code Execution (RCE) vulnerabilities that led to significant data breaches in 2019 and 2020.
According to the official website ImpressCMS is an open source Content Management System (CMS) designed to easily and securely manage multilingual web sites. With this tool maintaining the content of a website becomes as easy as writing a word document. ImpressCMS is the ideal tool for a wide range of users: from business to community users, from large enterprises to people who want a simple, easy to use blogging tool. ImpressCMS is a powerful system that gets outstanding results and it’s free!
SugarCRM is a pretty popular Customer Relationship Management (CRM) application written in PHP code. It was born in 2004 as an open source project hosted on SourceForge, a development repository for free software. By June of the same year, the rapid success of the project allowed the original developers to found SugarCRM Inc. and raise $2 million in venture capital. A month later, on July 3, Sugar Open Source version 1.
Magento, which was acquired by Ebay Inc back in 2011, is one of the most popular e-commerce platforms written in PHP. There is an interesting bug bounty program in place that offers bounties of up to 10,000$ for Information Disclosure and Remote Code Execution vulnerabilities. In November 2014, I decided to give it a try, so I started looking for security bugs in Magento CE, and almost immediately I discovered a PHP Object Injection vulnerability which (un)fortunately requires administrator privileges in order to be exploited.
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.
Welcome to my third blog post ever, the first in this new year, but still talking about an old friend of mine. Yes, 2014 is here, however the topic is always the same: PHP Object Injection! Perhaps those few people who read my blog are wondering if I will ever write about something else, or whether this is going to be a monothematic blog… Well, who knows?! It could be, or maybe not, but the point is that right now I’m really in love with this kind of vulnerabilities, and today I would like to share with you what in my view is an interesting story about a PHP Object Injection vulnerability which affected the Horde Framework.
Last week I have disclosed KIS-2013-04, another PHP Object Injection vulnerability which affects the Joomla CMS. I had initially reported this vulnerability to the Joomla Security Strike Team in December last year, within an e-mail reply about the KIS-2013-03 vulnerability: “Furthermore, I would suggest you to investigate other potentially vulnerable unserialize() calls, for example the plgSystemRemember::onAfterInitialise() method uses the unserialize() function with user input passed through cookies, but I’m not sure it may be exploitable, due to the encryption system”.
Today I have disclosed KIS-2013-03, a PHP Object Injection vulnerability which affects the Joomla CMS. I have reported this vulnerability to the Joomla Security Strike Team only some months ago, but to be honest I have noticed that vulnerable unserialize() call a long time before. The only one reason why I have not notified them before is because I thought that it wasn’t exploitable: I had not noticed any useful magic method which could be abused to conduct malicious attacks, so I have come to the conclusion that it wasn’t an actual security vulnerability.