It seems the “attack” was coordinated from a single ip, 195.5.117.252. The
reverse dns for this IP points to c31.esthost.eu, and there are a lot of
services open on that system. I’ve done a short scan of the host and the
results are attached in “scan.txt”. It seems the host runs openvpn on most of
the ports, which means it is used to disguise the true identity of the
attacker (fx, if the attacker connects himself to the vpn, the external ip of
the site he will visit will be the vpn servers’ ip).

There was one question that bothered me – HOW did the remote attacker get that
shell on our server? The answer is dead simple and it’s the awful truth:
SIMPLE PASSWORDS. The “admin” user on the joomla install seems to have had the
password “adminpass”. I can’t say wether the password was set remotely, or if
the password was always adminpass, but it is now adminpass. Of course, i
disabled the account, so it can’t be used anymore.

The password wasn’t just random trial and error, it was a sure-shot. The
joomla bibtex plugin has a little problem handling some POST-vars, aka it
doesn’t mysql_real_escape_string or addslashes on the posted data. The exploit is known and you can find more info on this link:
http://www.milw0rm.com/exploits/4310

It comes with full info about how to reproduce the bug. I even tested it in
the wild and managed to list users on a couple of sites. On one of them, I
managed to login with FULL administrative access. All this, even though the
password is stored md5-hashed. A simple Google search for the hash revealed
the password (not necesarily the SAME password, but a pwd with the same hash).

So, to sum things up, this is the chain of events: script googles for sites
that expose the com_jombib extension (with, say a simple google search:
inurl:index.php?option=com_jombib), finds our site, tries the exploit,
and tricks the extension into listing all the joomla users and their md5-
hashed password. A simple google search revealed the true password
(adminpass).

At this stage, the remote user had administrative access to the site. He
now installs a plugin called “com_article” – nothing suspicious about that,
right? The plugin consists of a single php file – the php shell, that was
available at the following link:

The GET parameter is required for the shell to be rendered. Otherwise an error
is thrown. Once the user launched the shell, he edited whatever files he
wanted, and then he uploaded other files as well. And this is the end. Another
compromised box in the wild

I couldn’t have found out any of the stuff above if it weren’t for the
accesslogs. It was a good ideea to keep the last 6 months’ archives

The PHP shell can be found anywhere on the net (i think), and it had a
“clever” trick to disguise its real php code (it was base64 encoded and inline
compressed TWELVE times – hence the 12 in the shell12.php filename).

Any file could’ve been accessed by the remote attacker and a) deleted b)
searched for various info (passwords, stuff like that). I don’t know and I
can’t say what got affected by the shell, as there are no traces in the system
(it is a pseudo-shell, running simple, exec() commands).

As a general preventive measure, systems need to be updated regularly to allow
upstream security patches to be applied. This is true for every linux app,
library, distribution, and for any script (asp, php, a.s.o). There is nothing
that the user could’ve done to prevent this, except for using a stronger password
(even though this is relative – check this forum thread:

<http://forum.insidepro.com/viewtopic.php?t=1741>