Horde, eval(), Plesk, cPanel and others The last week of march to the first of April it was noted that the Horde framework was vulnerable to two nasty bugs. The first bug allowed attackers to read local system files within jurisdiction of the web servers uid/gid. One may consider that to be a relatively useless bug, but as researchers the likes of rgod have pointed out -- local file inclusions can be nasty. If you inject a bunch of arbitrary requests into an access_log, then include that log -- you can execute code. I've tried it, and was impressed.

However, the situation with the bug referenced above uses readfile(), which doesn't execute the code, just reads and spits out the specified garbage. You can still have fun though, how?

1) Read Horde's configurationm file (../config/conf.php) With luck, you can dump the database remotely. With even more luck, you may find some user hashes in the database, and they'll be valid on the system you're attacking.

2) Check out the system version, /etc/issue, etc and determine the distribution or OS involved. You can then use VMware to setup a similar configuration. With some research you can figure out which files are readable by default for that OS, and possibly use it to your advantage.

3) Read /etc/passwd, though it may be useless these days as rarely any machines leave their hashes in /etc/passwd anymore, you can still gather the systems user list, and use that in turn with THC-Hydra for some brute force action, it may yield results.

4) read the sites' php/cgi source codes, thus opening up the possibility of finding a remote execution vulnerability. If you can find a hole in the webmasters code, you can stop using the readfile() bug and elevate your attack.

NOTE: Do a full site audit on your victim, find path disclosures. This will allow you to map out the systems web server hierachy. I also suggest you scrub the victims IP for other Virtual Hosts, if you can find path disclosures on those sites you'll have a lot more success in your file read path guessing. But hopefully you can find holes in those other sites which will allow you remote execution, right? ;)

NOTE: To 'scrub' IPs for Virtual Hosts, check out a tool by the name of revhosts I've had some nice success with it.

The big advisory though, involved a tiny little line in the middle of a huge frame. An eval() with unsanitized variables right in the mix. OUCH!! The vulnerable code was something along the lines of the following:

<?php
$module = $_GET['module'];
eval('$version = "' . basename($module) . '";');
?>

NOTE: the code above was not the vulnerable code in the Horde help script, I'm just illustrating a vulnerability with similarity. So, the code above looks nasty, ugly. It is also a gaping hole. With a simply GET like the following, you would achieve remote execution (depending on the php/web server configuration that is):

http://victim/target/vulncode.php?module=;".passthru("id").";

One would assume correctly that a high number of machines with Horde 3.0.1-9 and 3.1 distributions are being actively attacked. It almost seems as if the first day I heard of the bug, there were already bots automating attacks on my servers. Geez, that was quick.

My title references Horde, eval(), and two control panels. But why? hmm. perhaps it is the fact that both Plesk and cPanel distribute vulnerable versions of Horde. Oh yes, that's it. The default template for Plesk's Horde installation ends up with the webmail.vhost.com hostname, and cPanel's Horde distribution hides the vulnerable application under an .htaccess, so you'd have to have some sort of account on cPanel in order to get down and exploit it. I'm sure there are other Control Panels which include Horde, I think I've seen an hSphere box or two with it.

I think it's time companies re-evaluate the installation, and reselling of CPs as they are yet another vector of attack.

Thanks to JRoca for the point about Control Panels.  ¶ 4/19/2006 04:34:00 AM