fbpx

Vulnerable Joomla! Installation under active attack

A Core Remote Code Execution Vulnerability (CVE-2015-8562) in the popular content management system (CMS) Joomla! was recently discovered. The vulnerability affects all versions of Joomla! prior to 3.4.6, and while updating the CMS to the latest version will patch the bug, there are still plenty of unpatched targets out there and Symantec has observed attackers actively scanning for and attacking vulnerable servers.

With over 50 million downloads Joomla! is one of the most widely used content management platforms and is used by some very popular websites, meaning the vulnerability potentially puts millions of users at risk. In an attack scenario, an attacker can use this vulnerability to execute commands on the server, tamper with the website or database contents, host malware on the server, or even redirect visitors to  other malicious websites.

How attackers find and exploit vulnerable servers
The exploit code is relatively easy to deploy and doesn’t require much skill, all that is needed is a single HTTP request. According to our telemetry, the methods attackers are using to scan for vulnerable versions of Joomla! is similar to methods we covered in a recent blog on an RCE vulnerability in the vBulletin platform. Attackers are scanning for servers running vulnerable versions of Joomla! by attempting to call a phpinfo() function or printing out an MD5 of a predetermined value. As with the vBulletin RCE exploit attacks, it is likely attackers are scanning and documenting vulnerable web servers for exploitation at a later time.

Let’s take a look at how attackers are doing this.

In one method used by attackers, if the targeted server is vulnerable, the MD5 hash for the value 233333 is printed in the response sent by the server.

Figure1_17.png
Figure 1. MD5 hash printed in the server response

Another method involves the attacker attempting to execute the eval(char()) function and waiting for any output from the die(pi()); function in the response. If this response is received it tells the attacker that the server is vulnerable.

Figure2_10.png
Figure 2. Server response from eval(char()) function

System administrators can look for the methods described previously as possible indicators of attack (IoA) or indicators of compromise (IoC). By examining web access logs, administrators can look for the requests and, if found, compare the time they were made to the time the server was patched to determine if the system was likely to have been breached.

Malicious script injection
Once a system is found to be vulnerable, the attackers can then proceed to the main attack. This usually involves the installation of a back door to enable the attackers to gain full access to the compromised computer.

The section of code shown in Figure 3 is part of an encoded PHP back door which is used against vulnerable Joomla! servers. Once the back door is established on the server, the attacker can execute commands, tamper with websites hosted on the server, or upload and download files at will.

Figure3_7.png

Read the full article at Symantec

How To Protect Your Server From The GHOST Vulnerability

ghost-vulnerability-1
Want to know more about GHOST Vulnerability? It is listed as a Critical issue and is officially known as CVE-2015-0235. It is a vulnerability located in the glibc library of most Linux systems and takes advantage of a condition called a “buffer overflow” and can allow a remote attacker to gain complete control of a system. Any system running a version of glibc older than 2.18 is likely to be susceptible to an attack in this manner.

How to Check Your Server

Red Hat Enterprise Linux & CentOS
You can use rpm (the Red Hat Package Manager) to check the glibc version:
[root@box ~]# rpm -q glibc
The command will give an output similar to this:
glibc-2.5-123.el5_11.1
Note the version information, highlighted in red in the above example. If this version matches, or is more recent than the versions listed below, you are safe from the GHOST vulnerability:
- CentOS 6: glibc-2.12-1.149.el6_6.5
- CentOS 7: glibc-2.17-55.el7_0.5
- RHEL 5: glibc-2.5-123.el5_11.1
- RHEL 6: glibc-2.12-1.149.el6_6.5
- RHEL 7: glibc-2.17-55.el7_0.5

Any version older than these is vulnerable to GHOST and should be patched as soon as possible.

Debian & Ubuntu

The ldd command, used to check for dynamic dependencies, can be used to see the version of glibc on Debian-based systems, including Ubuntu:
debianbox:~# ldd -version
The output will look similar to this:
ldd (Debian EGLIBC 2.11.3-4) 2.11.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Note the version information, highlighted in red in the example. If this version matches, or is more recent than the versions listed below, the system is not vulnerable to GHOST:

– Ubuntu 12.04 LTS: 2.15-0ubuntu10.10
– Ubuntu 10.04 LTS: 2.11.1-0ubuntu7.20
– Debian 7 LTS: 2.13-38+deb7u7

Any versions older than these are vulnerable and should be patched as soon as possible.

How to Fix the Vulnerability

The simple way to fix the GHOST vulnerability, is to use the default package manager for your distribution to update the glibc version. Below, we will offer sample processes for a Red Hat/CentOS based environment, and for a Debian/Ubuntu based environment.

RHEL & CentOS
The default package manager for Red Hat Enterprise Linux, CentOS, and related distributions is yum:
[root@box ~]# sudo yum update glibc
When the system prompts you for confirmation, respond with ‘y’.

Once the system is done updating, you will need to reboot it. This is necessary because glibc is used by many applications, and those applications must be restarted to use the new library version. Theoretically, you could manually restart each application, but if you miss one, you will leave your system vulnerable to attack. You can reboot your system with either of the following commands:
[root@box ~]#sudo reboot
or
[root@box ~]#sudo shutdown -r now
Once your system has restarted, make sure the vulnerability has been patched by using the instructions from the earlier section.

Debian & Ubuntu

The default package manager for Debian, Ubuntu, and related distributions is apt. For currently supported versions of Debian and Ubuntu, update all of your packages to the latest version available. In most situations, we recommend doing a ‘dist-upgrade’, however, in some cases this may cause issues with certain packages, as the dist-upgrade command can add and remove packages in addition to upgrading them. If you are concerned that this is the case on your system, you can use ‘upgrade’ as an alternative, though make extra sure to check your system for the vulnerability afterwards if you do this.
debianbox:~# sudo apt-get update && sudo apt-get dist-upgrade
or
debianbox:~# sudo apt-get update && sudo apt-get upgrade
In either case, then respond to the confirmation prompt with ‘y’.

Once the system is done updating, you will need to reboot it. This is necessary because glibc is used by many applications, and those applications must be restarted to use the new library version. Theoretically, you could manually restart each application, but if you miss one, you will leave your system vulnerable to attack. You can reboot your system with either of the following commands:
debianbox:~# sudo reboot
or
debianbox:~# sudo shutdown -r now
Once your system has restarted, make sure the vulnerability has been patched by using the instructions from the earlier section.

For more information about the GHOST vulnerability, please see this link from the United States Computer Emergency Readiness Team (US-CERT):
https://www.us-cert.gov/ncas/current-activity/2015/01/27/Linux-Ghost-Remote-Code-Execution-Vulnerability

WordPress Under Attack, 100,000+ WP Websites Compromised By SoakSoak Malware

SoakSoak Malware Compromises 100,000+ WordPress Websites

News of a malware campaign against WordPress has been doing the rounds since owners and webmaster of wordpress blogs found out about websites getting blacklisted by Google. Around 11,000 domains had been blocked due to the latest malware campaign which has now swelled to 100,000. This campaign has been brought by SoakSoak.ru, thus being dubbed the ‘SoakSoak Malware’ epidemic.

SoakSoak malware modifies the file located at wp-includes/template-loader.php which causes wp-includes/js/swobject.js to be loaded on every page view on the website and this “swobject.js” file includes a malicious java encoded script malware.

Read full article from TechWorm.net