CategoríaInteres general

Vulnerabilidad en las cuentas PAC/PAT y reacciones del Santander

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: https://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.

Acceso al codigo fuente del Banco Santander Chile

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.
Seguir leyendo

Fallos de seguridad en Huntcha.com

Huntcha.com es un sistema hecho para “encontrar a tu amor secreto”, ingresas tus datos, registras a tu amor secreto y si tu amor secreto te agrega a ti, entonces el sistema detecta esa coincidencia y te da la alerta. Por lo tanto, ingresando a la cuanta de algun usuario es posible saber quienes son “los amores secretos” de esa persona. Si esta persona está emparejada y está casado, se podría armar un lio mas o menos.

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.

Seguir leyendo

Robo de credenciales y suplantación de identidad en sitio web del Registro Civil

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.

Seguir leyendo

Secureless: Estadisticas de sitios web vulnerables

En la conferencia de seguridad recien pasada, tuve la oportunidad de presentar el Proyecto Secureless, demostrando la realidad de las vulnerabilidades web de distintos sitios, por categoria, dominio y por tipo de organizacion.

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.

Seguir leyendo

8.8: Computer Security Conference Chile

El pasado viernes 18 de noviembre se realizó la primera versión de la 8.8, una conferencia orientada a la seguridad informática y hacking. Tuve el agrado de exponer sobre el Proyecto Secureless, que llamó la atención de varios de los asistentes y gracias a eso logré tener contacto con distintas personas encargadas de la seguridad o del area de informática de bancos, universidades, etc. Hubo charlas técnicas y otras no tanto, yo expuste, además de la presentación de Secureless, algo que ya había expuesto antes en otras conferencias, sobre Hacking Automatizado, básicamente la automatización de tareas mediante scripts en bash, php, python, etc.  De esta chalra no pude  mostrar todo por falta de conexión a internet.

De las cosas que mas me interesaron, fue “Gaining Full System Access via Virtual Memory“, que comenzó hablando sobre congelar la RAM para mantener la información  (Cryogenically frozen RAM) y que obviamente el escenario para explotar este tipo de cosas es bien complicado, ya que hay que tener acceso fisico, sin embargo, esto tambien sucede en las máquinas virtuales por ejemplo con VMWARE, que genera un archivo “.mem”, basta con hacer un dump de ese archivo y guardarlo para simular el “congelado”. Mediante este ataque, Thomas demostró que Linux es más inseguro que Windows en este sentido, por el simple hecho de que Windows es capaz de cifrar la información que está en la RAM, Linux no lo hace. Lo demostró leyendo el hash del archivo /etc/shadow desde la ram y también accediendo a la password en texto plano que se digitó para autenticarse en una shell.

Tambien me pareció interesante la charla de Marco Balduzzi quien hablaba sobre HTTP Parameter Pollution, que por el tipo de preguntas que se hicieron creo que no mucha gente entendio el sentido de HPP.

Más allá de las charlas, lo que más me gustó es que existiera la instancia de poder mirar cara a cara a los distintos responsables y tambien conocer a gente nueva que está interesada en todo este tema de la seguridad informática y hacking. Me dio mucho gusto conocer a varios de los que solo me había relacionado via email para reportar vulnerabilidades.

Nos vemos el 2012!