El rincón de Zerial

El proceso para iniciar sesión de LinkedIn es vulnerable a ataques de fuerza bruta y es posible, mediante un diccionario, descubrir la password de usuarios. Este ataque es factible debido a un error en la validación del token de seguridad (Csrf token) que permite enviar tantos request remotos como queramos, probando distintos usuarios y usando el mismo token.
La única protección que existe, es que luego de decenas de intentos, nos muestra un Captcha, sin embargo, luego de esperar un tiempo y con un nuevo Token, es posible continuar con el ataque.

Para obtener un Token y poder probar el ataque, debemos atrapar el POST que se hace en el formulario de login y obtener el “sourceAlias” y “csrfToken”.

Cuando realizamos el ataque, no es necesario enviarle estos valores metiante POST, ya que no discrimina el métido por el cual se le entregan los valores, pudiendo generar un simple script que haga consultas mediante GET pasandole las variables por URL.

[Leer Más →]

Luego de que se propusieran la idea de inscribir automaticamente a todos los chilenos, el SERVEL tuvo la brillante idea de poner la base de datos de todos los inscritos disponible para cualquier persona en su sitio web.

Con solo ingresar el RUT o el nombre de una persona, es posible obtener su domicilio, por ejemplo:

El formulario no cuenta con un captcha para validar que sea una persona quien consulta los datos y tampoco tiene las validaciones necesarias para proteger request desde sitios remotos y asi poder evitar que un “bot” se dedique a hacer un dump de la base de datos.

Como el sistema de consultas es vulnerable a CSRF, con un pequeño script podemos obtener información de personas, por ejemplo:

15000XXX-7
LECAROS XXXXX ELENA XXXX
PILCO XX XXXXXX DPTO 106
————
15000002-5
XXXXXX NIETO XXXXXXXX ANDRES
SITIO XXXXXX EL SAUCE XXXXXXX
————
15000XXX-3
ROJAS XXXXXX PAMELA XXXXXXX
PJ LOS XXXXX XX
————
15000XXX-1
BELLO XXXXX SUSANA XXXXXX
DIEGO XXXXX XXXXX POBL. SAN JOSE
————
15000XXX-K
GONZALEZ XXX PATRICIA XXXX
ANIBAL PINTO XXXX PBL.M.ORIENTE
————

En esta prueba de concepto lo unico que hice fue un script que cuente de 15.000.000 a 15.000.010, obtenga el digito verificador de cada RUT y consulte con cURL o wget al sitio del SERVEL. Un bot podria ser programado para que recorra todos los rut y obtenga información sobre las personas.

[Leer Más →]

El dispositivo de la imagen corresponde a un control de acceso con tarjetas de proximidad y biometrico ZEM560, aunque no lo crean, en muchos lugares se usa para restringir el acceso a ciertos sectores donde solo personal autorizado puede ingresar, por ejemplo a un Data Center.

Estos dispositivos no son más que un sistema Linux 2.6.24 corriendo sobre MIPS, el cual basicamente tiene una interfáz ethernet con la cual se puede acceder vía telnet al sistma o bien vía web para la administración de usuarios, reportes, mantención del equipo, etc.
El panel de administración es así

En el menú de la izquierda se pueden ver distintas opciones como administrar usuarios, acceder a reportes, configurar las tarjetas de red y lo más interesante la opción Open Door.

[Leer Más →]

En Chile, nuevamente el Gobierno cambió la configuración de la zona horaria, aplazando el cambio de hora que debería haberse hecho hoy, para el 28 de Abril.

La medida, que replica el esquema adoptado el año pasado, establece que el horario de invierno entrará en vigencia la medianoche del Sábado 28 de Abril y posteriormente, se retornará al horario de verano, la medianoche del Sábado 1 de Septiembre.

Para UNIX existe una solución que es modificar el archivo que define el TimeZone de Chile/Continental. Esta solución es mucho más limpia que cambiar la hora a mano o que usar la zona horaria de otro país, ya que continuamos usando la zona horaria de Chile pero con las modificaciones que el gobierno impuso.

La solución rápida es descargar este archivo “timezone” que modifiqué con las nuevas fechas, descomprimirlo y pisar el archivo /etc/localtime y en el directorio donde tengas los archivos de zona que generalmente se encuentran en /usr/share/zoneinfo/Chile/Continental.

[Leer Más →]

Esta vez la vulnerabilidad afecta al sitio de Servipag Empresas, permitiendo realizar ataques del tipo CSRF+XSS, es decir, incrustar código html/javascript y realizar peticiones desde sitios remotos. La vulnerabilidad se encuentra en el formulario para iniciar sesión que al momento de realizar la validación, si el usuario o clave no existen o están incorrectos, muestra una alerta al usuario

El formulario de login envia un POST a servipagempresas.cl/Servipag/SES_ControlAcceso.asp pasando las variables ACC=ND&IdColumna=&IdComunidad=2&IdNoticia=&LoginEmpresa=empresa_prueba&login=empresa_prueba&password=1, cuando se envian datos incorrectos, SES_ControlAcceso.asp nos devuelve a la URL servipagempresas.cl/Servipag/acceso.asp pasando por GET el mensaje de error, el cual podemos manipular.

[Leer Más →]

Ya han sido varias las vulnerabilidades que han afectado a este sistema, como pueden ver en Secureless, se han reportado vulnerabilidades correspondientes a redirección de URL abierta, es decir, el usuario podía ser redireccionado a cualquier URL externa sin su autorización y otras del tipo Cross-Site Scripting, que permite al atacante incrustar código html/javascript arbitrariamente y aprovecharse de la confianza que el usuario tiene sobre el sitio para robar información, suplantar su identidad mediante el robo de cookies o bien incrustando un formulario falso para que el usuario entregue sus datos de autentificación (rut, password) al atacante.

Esta es una demostración de que tener un sitio con SSL o HTTPS no significa que sea “seguro”.

DISCLAIMER: Antes que todo, me gustaría aclarar los motivos de hacer pública esta demostración. Hace varios meses intenté reportar la vulnerabilidad de Redirección de URL que afectaba al momento de iniciar sesión pero no obtuve respuesta y luego de haberla hecho publica, apareció solucionada. La última vulnerabilidad XSS que encontré logré reportarla al encargado de seguridad de la institución (gracias a un contacto que no tenía antes), la respuesta que obtuve fue:

Escalé al Area de Mantención , para que mitigue la vulnerabilidad, te enviaré e-mail cuando esté mitigada.

Muchas gracias por la información

1 mes despues de este correo, no he recibido ninguna notificación. Luego de haber dicho lo siguiente, hace 3 dias:

La vulnerabilidad apareció corregida.

Esta vez avisaré a los responsables pero no esperaré a que lo solucionen para hacer público este artículo. Creo que los usuarios del Servicio de Impuestos Internos debe conocer los riesgos de realizar trámites online con una plataforma que no brinda la suficiente seguridad.

[Leer Más →]

Hace un par de días estaba en uno de esos Transfer que te llevan desde el aeropuerto hasta tu casa, de la empresa Transvip. El movil tenia un dispositivo en el lado del chofer con el cual me imagino que lo usan para ver las reservas y rutas a seguir.

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:

ACTUALIZADO (10 de Febrero):

La empresa Transvip tiene un sistema de gestión de liquidaciones alojado en liquidacionestransvip.cl (al parecer no conocen los subdominios), en la cual aparece un login para iniciar sesión

Pero si ingresamos directamente al directorio “/pdfs” podemos ver el listado de todos los archivos PDF correspondientes a liquidaciones, donde podemos acceder a información sensible de la empresa y sus clientes

Gracias a aermann por la colaboración!

Despues del ultimo post relacionado con la vulnerabilidad que permitia acceder al código fuente del sistema, hubo distintos tipos de reacciones por parte de los usuarios y de las empresas involucradas.

Otras vulnerabilidades comenzaron a ver la luz, como por ejemplo la que afecta al sistema de asignación/modificación de los pagos automaticos de cuentas (pat/pac), que permite asignar pagos automaticos a terceras personas, sin previa confirmación. De esta forma, Juanito Perez, puede asignar el pago automatico de la cuenta de luz, agua, movil u otro a Pedrito, sin su autorización.

Varias personas se contactaron conmigo y me comentaban que habian enviado un reclamo a su ejecutivo de cuentas, para tener una respuesta formal y seria respecto a estas vulnerabilidades reportadas. Una de ella me llamo la atención, corresponde a @Van_ultraviolet, que le respondieron:

• Es una persona que necesita mucha atención, por eso hace esto.
• Cualquier persona puede acceder al código fuente.
• Revisamos las alertas del pseudo-hacker y no son reales.

Pueden ver a respuesta completa aca: http://twitter.theinfo.org/152376559511142400

Considero que esto es impresentable y que la persona que entregó esa respuesta debería pensar seriamente en dejar de ejercer su profesión.

Por otro lado, una de las empresas responsables se contactó conmigo y hemos creado un canal de comunicación para el reporte de vulnerabilidades. Ellos admitieron el fallo del Source Code Disclosure y tambien la vulnerabilidad PAT/PAC, indicando que ya está corregida en su entorno de desarrollo, sólo falta ponerla en producción.

El banco no ha respondido publicamente sobre el asunto, el “canal web” y el llamado “Community Manager” que maneja la cuenta de Twitter (@SantanderChile), tampoco se pronuncia al respecto, apesar de las insistentes quejas y reclamos de sus clientes.

Como conclusión, hay 3 empresas involucradas:

1. Santander: La entidad afectada, el Banco.
2. TAISA Chile: Una de las empresas involucrada en el desarrollo del sistema.
3. NEOSECURE: Segun los comentarios del post anterior y segun la información que me llegaba por correo, twitter, etc, es la empresa que ve la “seguridad” del Banco, es decir, es la “empresa lider en seguridad informatica” que audita periodicamente los sistemas del santander, según ellos; Aviso de seguridad Santander.

De estas tres empresas involucradas, la uinca que se ha hecho responsable y ha dado la cara, es TAISA, quien ha reaccionado bastante bien, agradecida y con ganas de crear un canal de comunicación para este tipo de incidentes. Ademas, han reaccionado bastante rapido despues de que se hizo la publicación.

Ustedes juzguen.

Ya he publicado algunas vulnerabilidad que afectan a los clientes del Santander, esta vez escribiré sobre una vulnerabilidad que afecta directamente al Banco y que permite al atacante obtener el codigo fuente de la banca. El atacante puede navegar por los directorios en busca de los archivos “asp” y descargar el archivo, teniendo acceso al codigo fuente del sistema.

Se trata de una vulnerabilidad Local File Include + Directory Traversal = Source Code Disclosure, solo debemos modificar el valor de una variable de la URL para obtener el archivo que necesitemos. Se trata de un fallo basico e irresponsable que ningun alto estandar de seguridad permite.

Lo curioso es que segun el aviso de seguridad oficial del banco santander, hay una empresa “lider” en seguridad informática que les hace auditoría periodica:

Cierto, parece un chiste.
[Leer Más →]