[#8982] - Potentially vulnerable to attack
- Closed
- 26 Jan 2016
- Critical
- Build: master
- # 8982
Steps to reproduce the issue
Using the CMS on a customer's server
Expected result
safe use of the system
System information (as much as possible)
PHP Version 5.4.16
APC 3.1.15-dev
Joomla 3.4.8
Additional comments
Hello
We need for our clients in different instances the latest version of Joomla. I have to several critical comments.
1.) logfiles
Please tell me again why a log file must be a PHP file? This is a highly ritisches construct because this file write permissions must have for the web user. This can be any code you eingeschläußt. An almost random revision of that file showed exactly that. In about 5000 character spacing has been inserted into this file further encrypted PHP code. Since this is so kindly is a PHP script, any attack floodgates open.
2.) Plugins
Currently I find nowhere an explanation of how I can install / update plugins manually. Only via the web frontend this is at all possible. But again, all files have write permission, which pulls a gigantic hole in any form of security.
Currently, there is the fact as follows:
A fresh Joomla instance with all the latest updates is compromised irreversibly after about 2 hours. Various files available for editing and are also entirely new constructs are introduced into the instance. I miss all kinds of security fully conscious in this Framwork.
If I may proceed according to the viewpoint of safety, Joomla would never any where used. Unfortunately, customers want repeatedly exact Framwork. By that I am faced with the problem that I can not protect it.
My suggestions:
1) any login exclusively via HTTPS (with inspection certificate)
2.) log files must also log files and no PHP scripts
3.) plugins must be manually installed
4. for most directories to access block) .htaccess Files
These are just the most critical "vulnerabilities" in the system.
I hope innständig, which is read and understood this ticket under precisely this point of view.
Hello
Exactly such an answer I suspected. But I have been hoping that does not happen there.
Why is an architectural problem pushed to the user?
Why do not you go to a point 1 of my question?
The server is clean. The Joomla was downloaded as a package at joomla.org.
Your first answers are therefore not advisable.
Let's see to the fact:
administrator / components / com_extplorer includes Java scripts. These were (from whatever reason) simply transformed into PHP. This is just another example ...
Where can I find a guide as to which part of an extension must be copied in all places. Joomla has the most complex by far plugin system which I am aware. A plugin consists of different parts, which must be copied to different locations. Obviously governs an XML file. Sure, I'm here but not.
Nevertheless, it remains highly critical system architecture.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8982.
com_extplorer for example is not part of joomla core code
It will be delivered in the basic package with!
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8982.
what basic package ? from where or who ?
I'm sure that com_extplorer is a 3dp extension not part of Joomla core code
Sounds like you are installing a customised version of joomla and NOT the
official one from joomla.org
Where are you getting it from.
On 26 Jan 2016 7:27 am, "Nicola Galgano" notifications@github.com wrote:
what basic package ? from where or who ?
I'm sure that com_extplorer is a 3dp extension not part of Joomla core code—
Reply to this email directly or view it on GitHub
#8982 (comment).
Some stupid providers include com_extplorer in their software installer packages.
@ReneMuetti As a first step to more seurity you shoukdn't use software installers with manipulated packages and never ever com'_extplorer... and a provider that provides a secure server architecture.
As this is not related to the core of joomla or the official distribution I am closing this here.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-01-26 08:11:56 |
| Closed_By | ⇒ | brianteeman |
We have this kind of plug-ins installed.
I have looked through the compromised files and the installation for Cade and found 3 more plugins in the logs / error.php.
This file serves as a primary gateway.
I have the relevant parts removed and deleted the files.
long as it will not hold :(
This is indeed a critical bug in the Joomla core architecture!
I can not understand this approach.
If you were correct don't you think there would be millions of hacked
sites. And if every site would be hacked within just a few hours of it
going live no one could ever build an website with joomla.
Please think a little before posting.
On 26 Jan 2016 8:14 am, "ReneMuetti" notifications@github.com wrote:
This is indeed a critical bug in the Joomla core architecture!
I can not understand this approach.—
Reply to this email directly or view it on GitHub
#8982 (comment).
Well - hushing is also a possibility ...
It was an attempt - not with success ...
You might find it easier to explain yourself and find out what is going wrong on the german language forum http://forum.joomla.de
Please tell me again why a log file must be a PHP file?
If you look at log files generated through Joomla's logging API (specifically the formatted text format which is the one used by default and writing to the filesystem), the first few lines should resemble this:
#
#<?php die('Forbidden.'); ?>
#Date: <date when created>This effectively blocks the log files from being triggered as PHP scripts, unless someone manually edits the file and removes that line the log files cannot be used in any malicious way (and if someone does edit that line, your site is already compromised). Using another plain text file format (.txt, .log, etc.) potentially exposes the log files to being viewed by web requests without additional protection (i.e. .htaccess rules).
I would suggest you do a scan of your system. There is almost certainly a backdoor somewhere prior to you installing Joomla. This is the root of your issue, not Joomla itself, assuming you took the latest version from www.joomla.org and not an already hacked version
Make also sure you don't install any vulnerable extensions. You can check https://vel.joomla.org/ for that.
To install an extension manually, you can copy the files using FTP to the proper places (which depends on the extension) and then use the discovery feature in the extension manager to install it.
If you find a real security issue in the code, please use security@joomla.org to notify us about the problem. Don't use a public readable place to share that information.