Woop!

Información y solución al exploit remoto de ProFTPD (CVE 2010-3867)


IMPORTANTE: Este documento pretende ir recogiendo información sobre el exploit remoto de ProFTPD publicado hace apenas unas horas, se actualizará constantemente con nuevas novedades, puedes ponerte en contacto conmigo en santi-AT-woop.es o vía Twitter.




Informacion sobre el exploit remoto de ProFTPD (CVE 2010-3867)


Todas las versiones comprendidas entre 1.3.2rc3 y 1.3.3b (ambas incluidas) de ProFTPD son vulnerables al exploit remoto "TELNET_IAC Remote Code Execution Vulnerability", que permite a un atacante remoto ejecutar código arbitrario.

La vulnerabilidad ha recibido los IDs: CVE 2010-3867 (todavía en revisión), OSVDB 68985 y Bugtraq 44562.

El alcance de la vulnerabilidad es grave, ya que a partir de la versión 9.5 del panel de control Plesk (muy utilizado por empresas de alojamiento web), se distribuye la versión 1.3.2e de ProFTPD que es vulnerable.

Una vez explotada la vulnerabilidad en el servidor se quedará un proceso in.proftpd consumiendo el 100% de CPU, sintoma directo de que la máquina ha sido comprometida.



Versiones de ProFTPD vulnerables



Todas las versiones de ProFTPD comprendidas entre 1.3.2rc3 y 1.3.3b son vulnerables, el listado completo es:


A partir de la versión 9.5.0 del panel de control Plesk (independientemente del sistema operativo donde se ejecuten: CentOS, Debian, OpenSuSE, etc.) se instala la versión 1.3.2e de ProFTPd que es vulnerable al exploit remoto. Las versiones anteriores (7.x, 8.6, 9.3, etc.) instalan la versión 1.3.1 que no es vulnerable, a modo de resumen:

Plesk 8.6.0  => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.0.0  => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.0.1  => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.2.1  => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.2.2  => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.2.3  => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.3.0  => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.5.0  => ProFTPD v1.3.2e => Vulnerable = SI
Plesk 9.5.1  => ProFTPD v1.3.2e => Vulnerable = SI
Plesk 9.5.2  => ProFTPD v1.3.2e => Vulnerable = SI
Plesk 9.5.3  => ProFTPD v1.3.2e => Vulnerable = SI
Plesk 10.0.0 => ProFTPD v1.3.3  => Vulnerable = ? (Si, pero no existe exploit)
Plesk 10.0.1 => ProFTPD v1.3.3  => Vulnerable = ? (Si, pero no existe exploit)


NOTA: Josué González, me informa via Twitter, de que el exploit utiliza el método pop-pop-ret y que posiblemente no funcionará sobre x86_64, ya que los argumentos de las call's van en los registros y no en la pila, mas dificil de explotar, lectura recomendada: Introducción a los overflows en Linux x86_64. En las pruebas realizadas sobre una CentOS-5 + ProFTPD v1.3.2e el exploit no ha funcionado.



Solución al exploit remoto de ProFTPD


Actualizar Plesk

Parallels ha sacado una actualización (Micro-Update, hotfix) para el paquete psa-proftpd con una versión parcheada de ProFTPD v1.3.2e, podemos aplicarla con el Autoinstaller de Plesk:

# autoinstaller --select-release-current --upgrade-installed-components


NOTA: Parallels ha parcheado la vulnerabilidad en la misma versión, no ha actualizado a ProFTPD v1.3.3c, por lo que el banner al conectarnos por FTP seguirá siendo el mismo: "220 ProFTPD 1.3.2e Server (ProFTPD)..".



Actualización a ProFTPD v1.3.3c

La mayoría de distribuciones ya han liberado nuevas versiones de ProFTPD con parches que solucionan el problema, en caso de no ser así tendremos que actualizar manualmente a la versión 1.3.3c, para ello:

# wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.3c.tar.gz
# tar xfvz proftpd-1.3.3c.tar.gz
# yum install pam-devel
# ./configure
# make


NOTA: Es importante instalar el paquete pam-devel para que el binario tenga soporte PAM, necesario en Plesk.

Tendremos que copiar el fichero "proftpd" a la ruta correcta, en el caso de distribuciones basadas en Red Hat será /usr/sbin/proftpd, este método ha funcionado correctamente en servidores con CentOS-5 y Plesk 9.5.



Deshabilitar el servicio ProFTPD

En caso de que no exista parche y/o no podamos actualizar, en la medida de lo posible y dada la gravedad, se recomienda deshabilitar el servicio FTP. En la mayoría de los casos este servicio estará controlado por xinetd, por lo que tendremos que editar su fichero de configuración y cambiar la directiva "disable = yes":

# cat /etc/xinetd.d/ftp_psa
service ftp
{
		disable         = yes
		socket_type     = stream
		protocol        = tcp
		wait            = no
		user            = root
		instances       = UNLIMITED
		server          = /usr/sbin/in.proftpd
		server_args     = -c /etc/proftpd.conf
}




Filtrar con Netfilter

El exploit de "Kingcope" utiliza una reverse shell que realiza una conexión saliente al puerto 45295/tcp, podemos denegar este tipo de conexiones con:

# iptables –A OUTPUT –p tcp --dport 45295 –j DROP


Ademas, podemos utilizar el modulo "strings" de iptables para filtrar por una cadena característica del exploit de "Kingcope" (gracias a Luis Miguel Ugalde por el "tip"!):

# iptables -t filter -A INPUT -p tcp --dport 21 -m string --algo bm --hex-string "|000000000000000000000000|" -j DROP


IMPORTANTE!! Este "hack" se debería utilizar como solución temporal, ya que si editamos el exploit para modificar el puerto y/o el string los bloqueos por iptables dejarán de ser efectivos, lo ideal es actualizar a una versión de ProFTPD que solucione el problema.



Timeline













Referencias



Powered by Woop!