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:
- Santander: La entidad afectada, el Banco.
- TAISA Chile: Una de las empresas involucrada en el desarrollo del sistema.
- 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.
Etiquetas: Hacking · Interes general · Seguridad · Sitios Vulnerables
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 →]
Etiquetas: Hacking · Interes general · Seguridad · Sitios Vulnerables
Hace un tiempo escribí sobre las vulnerabilidades AXFR, tambien publiqué un script que nos ayuda a buscar dns que tengan esta configuración.
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.
Etiquetas: Hacking · Seguridad
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.
[Leer Más →]
Etiquetas: Hacking · Interes general · Privacidad · Seguridad · Sitios Vulnerables
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.
[Leer Más →]
Etiquetas: Hacking · Interes general · Privacidad · Seguridad · Sitios 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.
[Leer Más →]
Etiquetas: Interes general · Mis cosas · Proyectos · Seguridad · Sitios Vulnerables
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
[Leer Más →]
Etiquetas: Hacking · Seguridad
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!
Etiquetas: Anecdotas · Interes general · Mis cosas · Seguridad
MyStore es una plataforma de comercio electrónico (eCommerce) escrita en PHP y utilizada por miles de sitios web. La plataforma tiene una vulnerabilidad Cross-Site Scripting en el archivo usado para desplegar errores al usuario, en el módulo de administración y es accesible por cualquier usuario sin previa autentificación, por lo que es posible explotar la vulnerabilidad y preparar un ataque hacia los clientes de los sitios web que implementan el sistema.
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.
[Leer Más →]
Etiquetas: Hacking · Seguridad · Sitios Vulnerables
