Woop!

Revision [242]

This is an old revision of ProFTPD_TELNET_IAC made by SantiSaez on 2010-11-10 17:20:34.

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.




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 las 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, listado completo:


A partir de la versión 9.5 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 => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.3 => ProFTPD v1.3.1  => Vulnerable = NO
Plesk 9.5 => ProFTPD v1.3.2e => Vulnerable = SI
Plesk 10  => ProFTPD v1.3.3  => Vulnerable = ?


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, en las pruebas realizadas sobre una CentOS-5 + ProFTPD v1.3.2e el exploit no ha funcionado.



Solución al exploit remoto de ProFTPD


NOTA: Parallels no ha avisado vía email de que han planificado las siguientes Micro Updates (MU) para solucionar la vulnerabilidad de ProFTPD en las siguientes fechas:

PPP 9.5.3 MU#1, Nov 11, 2010
PPP 9.5.2 MU#6, Nov 12, 2010
PP 10.0.1 MU#1, Nov 12, 2010 




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         = no
		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!