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.

Los captchas (Completely Automated Public Turing test to tell Computers and Humans Apart) son mecanismos de detección de robots o procesos automatizados que se conectan a nuestros sistemas y nos permite diferenciar entre humanos y maquinas. Muchas veces los captchas previenen registros masivos, bots que se dedican a recolectar información o bien intentos de ataques (por ejemplo fuerza bruta).

En el caso de Facebook, el captcha está de adorno. Manualmente, un usuario puede hacer uso de google para buscar personas y llegar a su página de Facebook, por ejemplo, buscamos a “Juan Perez” y llegamos a su perfil http://www.facebook.com/juan.perez, Facebook nos mostrará un captcha para poder ver si perfil

Si ingresamos las palabras que nos aparecen (iedshm, and) podremos ver un poco más sobre el usuario como su foto

Una persona debería poder ver este tipo de información si ingresa a facebook e ingresa el captcha correspondiente, para evitar que programas automatizados o bots se dediquen a recolectar información de los usuarios, pero la verdad es otra. El captcha de Facebook está de adorno.

Hagamos el mismo ejercicio, busquemos a una persona en Google e ingresemos a su perfil en Facebook http://es-la.facebook.com/people/Paula-Rodriguez-Tortosa/1313407077 y Facebook nos muestra amablemente un captcha

¡Asombroso! Las eguridad de Facebook ha mejorado, ya que nos pide ingresar caracteres que no son alfa-numericos…. Ya, pero hablemos en serio.

Intentemos ingresar cualquier palabra a ver que pasa

Magicamente, sin ningun tipo de seguridad, nos muestra el perfil de la persona

Ahora ya sabemos que el captcha de Facebook es de juguete y que podemos saltarlo simplemente con un “enter”. Solo bastan unos minutos para programar un pequeño script que se dedique a recolectar información de los usuarios.

¿Será otra caracteristica de facebook o será otra violación a la privacidad de sus usuarios? Claramente esto se trata de un bug, ya que de lo contrario no se molestarían en pedir un captcha.

Ironicamente, cuando vemos el link “¿Que es esto?” al lado del captcha, Facebook nos muestra la siguiente información:

Otra más de facebook.

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

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

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

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

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

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

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

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

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

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/

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.

PortalInmobiliario.com es un sitio web que permite publicar, buscar y cotizar viviendas para arriendo o compra. Según ellos, son El punto de encuentro de la oferta y demanda inmobiliaria en Chile.

Como la mayoría de los sitios que tienen login y obligan a sus usuarios a registrarse para adquirir cierto tipo de información, el PortalInmobiliario tiene su propia cláusula de términos y condiciones. Ellos le llaman “Beneficios y Alcances“, y en ella podemos ver la sección donde dice “Reserva y confidencialidad de datos”:

La parte más importante es donde dice

Portalinmobiliario.com ha desarrollado tecnologías e invertido importantes recursos en mantener un alto estándar de seguridad de las bases de datos de propiedades y usuarios, pudiendo asegurar la mejor protección para ellos.

Especialmente la parte que marqué con negrita.

Lamentablemente para su alto estándar de seguridad y para los usuarios que creen en ellos, las claves/passwords de usuario se guardan en la base de datos sin cifrar, es decir, cualquier persona que acceda a la base de datos podrá conocer las passwords.

¿Cómo saberlo?
No es necesario ser un experto informático ni hacker para darse cuenta, es bastante sencillo.
Hace unos meses me registré en ese sitio y luego de no entrar por mucho tiempo se me olvidó mi contraseña, por lo que me fui a la opción “Recuperar Contraseña” y mi sorpresa fue cuando me llegó el correo con la información solicitada: Me enviaron la password en texto plano!

Obviamente, la única conclusión que puedo sacar es que no están cifrando o hasheando la password usando un algoritmo one-way. Hay 2 opciones, o la cifran usando uno que permite descifrado o bien directamente no la están cifrando, cualquiera sea el caso, no es seguro.

Ahora apareció “Android Map“, que según su autor:

exposes the data that Google has been collecting from virtually all Android devices and street view cars, using them essentially as global wardriving machines.

Cómo funciona?

When the phone detects any wireless network, encrypted or otherwise, it sends the BSSID (MAC address) of the router along with signal strength, and most importantly, GPS coordinates up to the mothership. This page allows you to ping that database and find exactly where any wi-fi router in the world is located.

Es sencillo, imaginemos que una persona pasa por fuera de nuestra casa o lugar de trabajo con un telefono con Android, éste escanea las redes wifi y las envia silenciosamente a Google, junto con la posición y otros datos más.
De esta forma podemos armar mapas como los que conseguimos haciendo Wardriving:

Prueben ingresando al sitio de Android Map y pongan la MAC de su AP, verán como en la mayoría de los casos les dirá la ubicación.

no existe chat, no existe messenger, no existe mensaje de texto, ni llamada de telefono celular que no pueda ser intervenido

Para que no piensen que es una frase sacada de contexto, este personajo dijo tal frase haciendo referencia a que gracias a la intervención de esos medios de comunicación fue posible capturar a los “traficantes”.
Aun asi e independiente al fin, lo que acaba de decir este personaje es claramente un motivo más que suficiente para crear conciencia y que la gente prefiera siempre los medios de comunicación cifrados y seguros, donde si bien es posible interceptar el trafico y la conexion, no será posible leer el contenido del mensaje.
El hecho de que el gobierno o las “autoridades” tengan acceso y facultad de poder intervenir nuestras conversacoines y comunicaciones convencionales no es algo que ignoremos, de hecho, es algo que tenemos bien presente, pero no siempre se escuchan cosas como las que se dicen en el video de forma tan explicitas.

Medios y técnicas de comunicación seguros existen muchos, no es suficiente con solamente usar una conexion segura “ssl”. Es importante no solo cifrar las conexiones, sino tambien los mensajes usando por ejemplo llaves publicas/privadas. Tambien es importante que el servidor donde nos conectamos no guarde logs ni ningun registro de conexiones ni conversaciones, si queremos guardar logs lo hacemos de forma local (client-side) y nos aseguramos de cifrarlos.
Es preferible usar medios de comunicacion no tradicionales como IRC o Jabber que permitan una conexion segura y además con clientes que nos permitan cifrar las conversaciones, por ejemplo usar OTR (Off-the-Record Messaging).
Siempre hay que asegurarse que la otra persona con la que hablas realmente es quien dice ser, tener confianza en el servidor que se conectan para conversar o bien establecer conexiones sin un intermediario. Tambien es recomendble preferir softwares de código abierto donde puedas tener certeza de que realmente tu información no se está guardando ni enviando a algun lugar que no corresponda.

Como conclusión me gustaria dejar el siguiente mensaje:

Podrán intervenir nuestras conexiones y/o conversaciones, pero nunca sabrán lo que nos decimos!

La logica es bastante simple:

1. Cuando ingresamos (login) a nuestra cuenta desciframos el bash history usando nuestra clave privada
2. Cuando salimos (logout) ciframos el archivo con nuestra clave publica.

Para lograrlo vamos a necesitar tener una clave gpg y configurar el comportamiento del login y logout con unos scripts que les mostraré a continuación.

Vamos a usar el usuario “usuario” de prueba. Primero, creamos la clave GPG:

[usuario@belcebu ~]$ gpg --gen-key

En mi caso, generé una clave de 2048 bits con el UID Usuario de Prueba (Historial Cifrado) <test@zerial.org>

Editamos el archivo .bashrc y agregamos las siguientes lineas

gpg -d -r "Usuario de Prueba (Historial Cifrado) <test@zerial.org>" $HISTFILE >$HOME/._bash_history
mv $HOME/._bash_history $HISTFILE

Luego creamos el siguiente script, lo llamaremos .crypt_history.sh:

#!/bin/bash

sleep 2;
gpg -e -r "Usuario de Prueba (Historial Cifrado) <test@zerial.org>" $HOME/.bash_history
mv $HOME/.bash_history.gpg $HOME/.bash_history

Y agregamos la línea

nohup sh $HOME/.crypt_history.sh &

Al archivo .bash_logout

De esta forma, al ingresar como usuario se ejecutará automaticamente el comando que descifra el .bash_history y cuando salimos, será cifrado.

[root@belcebu ~]# cat /home/usuario/.bash_history
zå¬ÈùrèÿJx¨¸QÕ{¥ ±5#ºcHb¶÷çFÀ®ú4ÞÃØÝ­xbZúF çïkågµNÒ¸5îÅ£ ³KÝ0U¯º±YHú#ÙÞ©Ù&¶þ¢Lyug
þ
ÓL¹ðú®&°í¾vI?V\9Õx’{4hÐaÜdÛPÅ©²¦öcñm¾O’µÔ2ɪðá¸ó²ëÕÁ²NªOÈ`A²U´¬Uîkï
u:÷ÛASþdè¶]1ê¬GBXLT¥3þ0Ñ_8uóâEQ¯`.¾Kn3AÒy»çÌ¡øyà$ßÙkíKzܧ¸×’Øx¿S¥
ÂâÆâveó´Î/¸)aýü4µÅ:mCú}1Á$äãÑõæ>¥ÈM9IÈÛ³=PË^q{Ñ
3º ë]Å¿74ë*Ø
Öuå¦
[root@belcebu ~]#

Y si ingresamos como usuario …

gpg: encrypted with 2048-bit RSA key, ID C8F972E8, created 2011-02-03
“Usuario de Prueba (Historial Cifrado) ”
[usuario@belcebu ~]$ history
1 cat nohup.out
2 vim .bashrc
3 vim .crypt_history.sh
4 ls
5 history
6 ls -lia
7 history
[usuario@belcebu ~]$

Existe un pequeño detalle, es que el root puede ingresar como usuario y de esta forma poder el historial. Pero para esto, nosotros debemos proteger nuestro cifrado con un passphrase, asi cuando el root quiera ingresar como usuario, éste le pedira una clave para poder descifrar el archivo bash_history, si el root no maneja esa clave no podrá ver lo que hay.

Esto es solo una prueba de concepto (PoC), se puede hacer cualquier modificación a los scripts usados para adaptarlos a otras necesidades y obviamente mejorar el cifrado mismo del bash_history.
Nota: Existen varios peros en esta forma de cifrar, que obviamente pueden ser mejoradas, por ejemplo, podria existir algun conflicto cuando se inicia mas de una vez la sesion del usuario.

FeriaTicket se dedica a la venta de tickets/entradas de eventos de todo tipo y FeriaMix vende libros y música, mediante el registro de usuario es posible realizar compras en línea en ambas tiendas. Ambos sitios web, pertenecientes a la misma empresa, están desarrollados por la misma empresa usando el mismo sistema web (framework, cms o como quieran llamarlo) y así mismo, comparten los mismos bugs y vulnerabilidades.

La vulnerabilidad en común corresponde a una del tipo Cross-Site Scripting (XSS) al no validar los parametros de la URL, permitiendo la inyección de código html o javascript arbitrario.
Especificamente, se encuentra en el script wspd_cgi.sh al no validar el valor que se le entrega a la variable wspd_cgi.sh.

wspd_cgi.sh/WService=<código malicioso>

No está demas decir que la vulnerabilidad permite redireccionar a un sitio distinto al de FeriaTicket o FeriaMix, pudiendo robar las cookies y suplantar la identidad de los clientes, accediendo a información privada. A pesar de lo que la empresa declara en su página relacionada con la privacidad y la seguridad:

Compromiso con la Seguridad
En relación a nuestro sitio web (www.feriamix.cl), Empresas Feria hace esta declaración de seguridad y privacidad en orden a demostrar y comunicar su compromiso con una práctica de negocios de alto nivel ético y dotada de los controles internos apropiados.

Protección de Datos
Nuestro sitio está protegido con una amplia variedad de medidas de seguridad, tales como procedimientos de control de cambios, passwords y controles de acceso fí­sico. También empleamos otros mecanismos para asegurar que los datos que nos proporcionas no sean extraviados, mal utilizados o modificados inapropiadamente. Esos controles incluyen polí­ticas de confidencialidad y respaldo periódico de bases de datos.

Puedo asegurar que no están cumpliendo con lo que dicen.

Prueba de concepto FeriaMix:

Prueba de concepto FeriaTicket:

La empresa afectada fue avisada vía twitter al no encontrar ningun correo de contacto, pero no dieron respuesta.

Esta municipalidad convocó a postular a una beca y posteriormente publicó los datos personales de todos los que la ganaron.

Esta es la URL con la que podemos acceder al PDF donde aparece la lista de seleccionados:

Cada vez es menos la preocupación de la protección de datos de las personas, así jamás podremos confiar en quien tiene algo de información de nosotros.

Los datos que podemos ver son el rut de la persona, fecha de nacimiento, nombre completo, dirección, celular, nombre del “apoderado”, numero de telefono del apoderado, rut del apoderado, dirección del apoderado, entre otros.

Esto es un atentado contra la privacidad de las personas.

EDITADO (26 de Agosto):

El archivo que contenia la informacion personal de todos los alumnos, y ademas informacion de todos los estudios y carreras, tanto como horarios, horas asistidas, etc correspondia a un “dump” de una base de datos ubicado en:
http://cftlotarauco.cl/cas/devel/database/old_migracion/registro_data_dump_explotacion.sql
El cual ya ha sido removido.
Yo no accedí a ningun sistema de información, simplemente a una URL publica, sin ningún tipo de restricción ni protección.

Me contactó el responsable actual del sitio web y me explicó que estos registros pertenecian a una base de datos antigua (hace un par de años) explicado la negligencia que cometió el encargado anterior y comentarme que lo había solucionado. Tambien me contó que una persona había intentado lucrar con la información de mi blog y que gracias a ello se dió cuenta que había información sensible expuesta en el sitio web.

Me parece increible que exista gente que quiera lucrar con el trabajo de otros, este personaje, quien buscaba el lucro mediante mi post, se llama Joan Calderon y su correo electrónico es joan.calderon@quanti.cc

Alvaro Veliz me ha reportado el siguiente problema básico de seguridad en la plataforma de ingreso de alumnos. Esta plataforma llamada “Portal Estudiantil” dice ser una “Intranet solo disponible para alumnos regulares y egresados“, sin embargo, ellos mismos dan la opción de que no sea así y que cualquier persona pueda ingresar tan solo probando con RUTs al azar.

Podemos ver el mensaje en rojo que dice:

La clave que debes ingresar para acceder al Portal Estudiantil es 123456. Esta contraseña la debes cambiar en la pantalla siguiente tal como se te solicita.
IMPORTANTE: Al momento de cambiarla se te pide ingresar tu clave anterior, ésta es 123456, no lo olvides.

Me pregunto cuanta gente, hasta la fecha de hoy, ha ingresado al portal y ha cambiado su clave? Bastaría con generar un script que pruebe una lista de RUTs probables con una clave 123456 y ganar acceso al sistema, obtener informacion de los alumnos y crear dolores de cabeza a los administradores cambiandole todos los datos al usuario. Con estos hechos queda demostrada la poca o nula preocupación por las Universiades cuando se trata de proteger la información personal y la privacidad de sus alumnos.

Los errores más estúpidos comunes son validaciones mal hechas para ingresar a intranets, ficheros de respaldos visibles publicamente, directorios con información confidencial no protegidos, etc. Yo, como programador, se como funcionan estas cosas, los clientes quieren muchas cosas por muy poco dinero y, por ésto mismo, el programador decide optar por el camino más rápido posible. Por otro lado, sabemos que a los clientes no les importa mucho la seguridad y que cuando le dices que cobrarás un poco más por el hecho de agregarle seguridad al sitio o al sistema, ellos no lo entienden y prefieren el camino más barato. En fín, mientras no se invierta en seguridad, seguirán sucediendo cosas como las que les mostraré a continuación.

El primer caso (gracias a xwall o más conocido como El Arma Secreta, miembro del Hacklab por la información) es el del Instituto Chacabuco (del Colegio Maristas) quienes tienen una intranet donde podemos encontrar los datos de tosos los alumnos y apoderados. Estos datos son nombre, dirección, e-mail, número telefónico, etc.

Estos pantallazos pertenecen al area de administración de estudiantes (una intranet) que en teoría requiere un login, pero se puede bypassear fácilmente.

Este sitio además de poder mirar información, nos permite agregar, eliminar y modificar datos. Estoy seguro de que la misma forma que cometieron éste error, tienen otros más y que al agregar un usuario puedo adjuntar ficheros y lograr subir un archivo que me permita ejecutar código arbitrario en el servidor.

Pronto publicaré otro sitio con información expuesta.

En Chile lanzaron un proyecto de ley para la protección de datos personales, luego de diversos hackeos ocurridos, donde se “publicó” información de millones de chilenos desde sistemas de información del servicio electoral y junaeb, entre otros. Lo que quieren hacer con éste proyecto de ley, es “aumentar las sanciones a quienes resulten responsables” y “entregarles las facultades a las distintas entidades afectadas para que puedan dar garantías“. Irónicamente, la ley sólo protegerá a quienes hagan mal su trabajo y no a los afectados, las entidades públicas que no sepan proteger la información privada de las personas, tendrán ahora una ayuda desde el gobierno para que nadie pueda hacer públicas sus fallas y, por ende, las personas afecetadas jamás sabrán que sus datos son públicos.

Una de las preguntas que me hago es ¿Si son privados los datos, entonces por qué son de acceso público?
Existen muchas entidades públicas y privadas que simplemente no protegen la información, formularios sin captchas, acceso a información mediante el RUT o con usuarios y password basadas en el rut. Para los que no saben, el RUT cumple con un patrón y generar millones y millones de RUT es tan fácil como sumar dos números.

En un principio, fue la ” base de datos” del Servicio Electoral (servel) la que fue publicada, sin embargo, era posible acceder a ella sólo con el RUT. Cualquier persona puede probar distintas combinaciones de números e ir recolectando información manualmente, una persona con conocimientos más avanzados podrá crear un script que automatice ésta tarea de tal forma que recopile la información más rápido.

< ?
function valida_rut($r)
{
        $r=strtoupper(ereg_replace('\.|,|-','',$r));
        $sub_rut=substr($r,0,strlen($r)-1);
        $sub_dv=substr($r,-1);
        $x=2;
        $s=0;
        for ( $i=strlen($sub_rut)-1;$i>=0;$i-- )
        {
                if ( $x >7 )
                {
                        $x=2;
                }
                $s += $sub_rut[$i]*$x;
                $x++;
        }
        $dv=11-($s%11);
        if ( $dv==10 )
                $dv='K';
        if ( $dv==11 )
                $dv='0';
        if ( $dv==$sub_dv )
                return true;
        else
                return false;
}
$rut = 10000000;
$i = 1;
$dv = 0;
for($i = $i; $i < = 11; $i++)
{
        if($i == 11) $dv = "k";
        else $dv = $i;
        for($rut = $rut; $rut <= 20000000; $rut++)
        {
                $full_rut = $rut."-".$dv;
                if(valida_rut($full_rut) )
                        print $full_rut."\n";
        }
}
?>

Con este script generamos RUTs consecutivos con su respectivo dígito verificador, es decir, números RUT válidos.

[...]
10004366-1
10004383-1
10004397-1
10004402-1
10004416-1
10004433-1
10004447-1
10004450-1
10004464-1
10004478-1
10004481-1
10004495-1
10004500-1
10004514-1
10004528-1
10004531-1
10004545-1
10004559-1
10004562-1
10004576-1
10004593-1
10004609-1
[...]

Otro hackeo conocido fue el que se le ha hecho a la Junaeb en distintas oportunidades, tambien tiene relación con este tema, ya que es información obtenida en base al rut de las personas. Existen muchas páginas dónde podemos encontrar información “personal” ingresando sólo éste nombre, por ejemplo el de la autopista vespucio norte, que con sólo tener el rut es posible obtener los partes, patente y cuanto vehículos tiene una persona. Pueden ver el artículo que escribió Ivan al respecto: Bug en sitio de empresa avn.cl, Avenida Vespucio Norte.

Yo me sigo preguntando, ¿Si mis datos “personales” son “privados”, entonces por qué mierda son accesibles para cualquier persona?

El proyecto de ley que se está gestando busca aumentar las sanciones a las personas que hagan pública la información que, con mucho esfuerzo, recopilamos, pero lo que yo busco es que las sanciones sean para las personas que NO cuidan esta información, por negligencia. Deberían crear estándares para el manejo de información personal y privada de las personas y la gente que esté a cargo de éstos estándares deben ser personas altamente capacitadas.

Hace unos meses escribí sobre cómo obtener información en NIC Chile, pudiendo crear una base de datos nombre-rut. NIC Chile se descartó y dijo que correspondía a una caracteristica y no a un error, ni si quiera fueron capaces de poner captcha al sistema de registro de dominios.