A report by Check Point Research has been brought to our attention relating to a security vulnerability that was patched back in December 2015. This report has also been picked up by Threat Post.
Both reports contain a great deal of inaccuracies and intimate that the vulnerability detailed is a current one.
This statement serves to clarify the facts surrounding this issue. Furthermore we would like to assure our user base that, much as these posts attempt to state that this is a current issue, the truth of the matter is far from that.
With this in mind, we would like to clarify a few points:
- There is no current security issue with the JMail class.
- The underlying issue, used to create and store the backdoor, is a PHP issue rather than a Joomla issue.
- A successful attack is only possible with severely outdated PHP and Joomla versions that are more than 3 years out of date (PHP versions 5.4.45, 5.5.29, 5.6.13 and all higher versions are patched for this vulnerability). Please see our recent article about the importance of keeping your sites up to date here.
- A mitigation for Joomla 1.5, 2.5 and 3 was released more than 3 years ago in December 2015. Patches for EOL versions were released alongside the Joomla 3.4.7 release. Patches for the other Joomla versions are still available here. The Joomla Project also distributed WAF rules to many shared hosting providers at the time of discovery to protect against common exploits of this vulnerability.
- The file mentioned in Check Point's report is not a Joomla core file, it's a copy of the original class used by the attacker to obfuscate a backdoor.
- The file does not "override" the core JMail class.
More information on the exploit
The pattern described by Check Point is a classic one - where an attacker exploits a well-known security issue. The issue is over 3 years old and stems from a security issue found in PHP, rather than the Joomla core. More information on this issue can be found here:
By exploiting this issue an attacker can embed a backdoor in site, which can be used for malicious activity. In order to make detection as hard as possible, attackers often use copies of real application files (in this case a copy of Joomla's mailing class) to embed their exploit code. Those copies will never be used in normal application execution, so there's no "override" as claimed in the report, they simply used the file to obfuscate the actual backdoor.