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. I thought this reason was good enough to choose not to report my finding under their bug bounty program, since Magento administrators should already be able to upload and execute arbitrary code through the administration panel. However, after a couple of weeks a friend of mine encouraged me to submit the finding, because you never know. So I did it, and when I finished writing my report including a PoC, and I was about to send it, I noticed that the bug had already been (silently!) patched only a few days earlier! The researcher who reported the vulnerability has been awarded with 2,500$ for the very same finding… Continue reading
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. Continue reading
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.
I’ve noticed this vulnerability in late May 2013, during my free time, while testing the Horde Framework version 5.1.0. During a first stage I have spotted only a couple of useful magic methods which could be leveraged to carry out some kind of attack. The first interesting thing I noticed was in the Horde_Auth_Passwd::__destruct method, which allows to rename arbitrary files through some of its properties. I thought that this could be exploited somehow even to achieve arbitrary code execution (e.g. renaming a log file into something.php) or to cause a Denial of Service condition by renaming an essential file like /config/conf.php, however the point is that the full path of the file to be renamed should be known, and this requirement increases the attack’s complexity, making the issue quite weak. Continue reading
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”.
In early February have been released new Joomla updates, which included corrections for three security issues, among which the “highlighter” PHP Object Injection vulnerability. However, this updates have not solved the “remember me” vulnerability, for this reason, on February 12, I sent another e-mail to the Joomla Security Strike Team: “I noticed that the unserialize call is still present within the plgSystemRemember::onAfterInitialise method in versions 3.0.3 and 2.5.9, so I was looking a bit deeper, in order to understand if I was wrong when I said «I’m not sure it may be exploitable, due to the encryption system», and sadly I was wrong!”. Continue reading
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() 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.
Some time later, after the release of Joomla 3.0, I thought to look again at the Joomla source code in order to see if some useful magic method was added. I didn’t find so much new PHP classes or magic methods compared to those present in Joomla 2.5, but I have noticed a little change inside a destructor method which was the key for me to understand that the vulnerability actually exists and it can be exploited through (but not only) this magic method. Continue reading