Nuevamente en la mira el portal de pagos “más seguro” de chile, Servipag.com. Ayer durante el día en el twitter de Servipag, @ServipagOnline, publicaron una frase que me llamó la atención, en la que le decian a sus followers o clientes que todos sus datos y transacciones estaban correctamente asegurados ya que utilizan la tecnología SSL

Lo unico que hace Servipag con este comentario es generar una falsa sensación de seguridad, les voy a decir por qué …

Primero que todo, esa tecnología SSL de la que hablan significa que, mediante un certificado, cifran la información que viaja desde el servidor hasta los usuarios, permitiendo una comunicación segura y que -en teoría- no puede ser interceptada. Además le entrega una identidad de confianza al dominio. En la practica suena muy bonito y considerando lo que estos amigos de Servipag nos dicen, podriamos estar 100% confiados de que nuestra información está debidamente protegida y que nuestras transacciones jamás podrían ser interceptadas, sin embargo, esto no es así.

Exiten distintas formas de romper la comunicación segura entre el cliente y el servior, como por ejemplo ataques mediante SSLStrip o bien aprovechandose de los certificados débiles realizando ataques B.E.A.S.T/C.R.I.M.E, pero lo que mostraré en este post es mucho más simple y no hay que ser un hacker ingenioso para poder entenderlo ni ponerlo en practica, lo único que hacemos será usar Google.

Lo que vamos a hacer es sencillo, simplemente le diremos a Google que busque dentro del sitio de Servipag.com las palabras “Tx”, “Rut” o “Rut2″ en la URL.
En el resultado de una de las busquedas, encontramos lo siguiente:

En estos resultados podemos ver en la URL el RUT de una persona asociado a un correo electrónico y a un “banco”. Por ejemplo, ingresamos al segundo resultado cuya URL es https://www.servipag.com/browse.asp?pagina=servipag/inter_bcobci.htm&usuario=EXPRESS&banco=16&tipo=1&cuenta=0000&rut2=0XX043687X&mail=rockXXXXXX@live.cl (algunas letras han sido reemplazadas por X por seguridad). Si se fijan lo que viene despues de “browse.asp?pagina=” dice “inter_bcobci“, por lo tanto ya sabemos que el rut XX.043.687-X tiene cuenta en correo BCI y su dirección de correo electrónico es rockXXXXXX@live.cl. Todos sabemos lo fácil que es obtener el nombre completo de una persona solo con su rut, en este caso este rut corresponde a Patricia L. M. Rodriguez (omití el segundo nombre y primer apellido). Bien, gracias a Servipag tenemos el RUT, correo, banco y nombre completo de uno de sus usuarios, información necesaria para realizar algun tipo de fraude.

Otro ejemplo es usar Google para buscar cupones de pago o deudas a pagar. Servipag incrusta en algunas urls la variable “idTx” para hace referencia al ID de una transacción, por lo tanto vamos a buscar lo que Google nos entrega si le decimos que nos busque “idTx” dentro de Servipag.com:

Si pinchamos el resultado, nos lleva a la URL https://www.servipag.com/BotonPago/BotonPago/MediosPago?idTx=00800000006031000000303102&rut=XX767822X&nombre=marcelaXXXXXtoledo (algunas letras han sido reemplazadas por X por seguridad), donde podemos ver el ID de la transacción, el RUT y el nombre de quien realizó el pago. Y lo peor, es que al ingresar a ese link nos indica que cuenta estamos pagando y el valor

Gracias a esto, tenemos la siguiente información: RUT y nombre del deudor, monto exacto de la deuda y el servicio al cual corresponde la deuda. Información suficiente para poder engañar el usuario y generar algun tipo de fraude.

Y podría seguir con muchos otros ejemplos …

Lo más irónico de todo esto, es que en el mismo portal de Servipag ellos indican que cumplen con los más altos estandares de segurida da nivel internacional y los datos y transacciones son 100% seguros y 100% privados. Aqui pueden leer el chiste: https://www.servipag.com/Portal-De-Pagos-En-Linea/Home/Seguridad. Espero que aprendan que la seguridad al 100% no existe.

La vulnerabilidad afecta al plugin WP Banners Lite, tiene más de 16 mil descargas y está  bien valorado por los usuarios. Segun una búsqueda rápida, el plugin está siendo usado por lo menos en 200 sitios. Dentro de los afectados encontramos a un banco, sitios de noticias y al menos 8 sitios web del gobierno de Ecuador.

Intenté reportar la vulnerabilidad al desarrollador del plugin mediante el link de contacto de su sitio web, pero solo recibí la respuesta automatica de wordpress que acusaba recibo del mensaje de contacto y que se contactaría conmigo lo antes posible, pero eso nunca pasó.

La vulnerabilidad corresponde al tipo Cross-Site Scripting y, como decia anteriormente, afecta principalmente a los siguientes sitios:

www.defensa.gob.ec
www.agricultura.gob.ec
www.industrias.gob.ec
www.deporte.gob.ec
www.inclusion.gob.ec
www.sectoresestrategicos.gob.ec
www.desarrollosocial.gob.ec
www.justicia.gob.ec
www.ironbank.com
www.the-news.co
www.forexlistings.net
web.casinodesalamanca.es

El problema está en el archivo wpbanners_show.php, específicamente en las lineas 8 y 9, donde el programita recibe la variable “cid” directamente desde la URL mediante GET, sin ser parseada correctamente. El único filtro que se aplica a la variable es remover las comillas simples (‘).

Posteriormente, en la línea 51, imprime el valor de la variable directamente con un echo.

Esto nos permite inyectar código html o javascript arbitrariamente, más conocido como Cross-Site Scripting o XSS.

Como ya conocemos el nombre del plugin, archivo afectado y nombre de la variable que nos permite realizar la inyección de código, entonces podemos buscar los sitios afectados con el dork inurl:wp-banners-lite inurl:wpbanners_show filetype:php, obteniendo el siguiente resultado:

Para hacer la prueba de concepto, tomamos cualquier resultado como por ejemplo http://noticiasdedeanfunes.com, ingresamos al link el cual nos llevará a http://noticiasdedeanfunes.com/wp-content/plugins/wp-banners-lite/wpbanners_show.php?id=1&cid=a_0c8ce55163055c4da50a81e0a273468c, donde nos mostrará lo siguiente:

Segun el codigo fuente que vimos anteriormente, en la línea 51 imprime el valor jQuery(‘# concatenado con la variable cid, que finalmente lo concatena con ‘).replaceWith(‘ <valor de variable banner>‘), por lo tanto, el valor que muestra despues del símbolo #, es el que la entregamos por URL, si lo modificamos laURL de la siguiente forma:

http://noticiasdedeanfunes.com/wp-content/plugins/wp-banners-lite/wpbanners_show.php?id=1&cid=a_PRUEBA

Nos muestra el siguiente resultado

Entonces ahora nos sentimos libres de modificar la URL para inyectar el código html o javascript que nosotros queramos

HTML Injection: http://noticiasdedeanfunes.com/wp-content/plugins/wp-banners-lite/wpbanners_show.php?id=1&cid=a_%3Cbody%20bgcolor=black%3E%3Cfont%20color=00ff2a%3ELoooooooL%3Cfont%20color=black%3E

Cross-Site Scripting (XSS):  http://noticiasdedeanfunes.com/wp-content/plugins/wp-banners-lite/wpbanners_show.php?id=1&cid=a_%3Cscript%3Ealert%28/XSS%20Proof-of-Concept/%29%3C/scri%3E

La vulnerabilidad no ha sido corregida y ha sido probada en las versiones 1.29, 1.31 y 1.40.

En el post anterior ya vimos cómo el mismo sistema de servicios de impuestos internos (SII) violaba la seguridad de nuestras contraseñas; en este nuevo post comentaré las recomendaciones de seguridad que aparecen publicadas en el sitio web del SII y tambien analizaré el manual de configuracón para la utilización de ingreso mediante certificado digital o firma electrónica.

En este link, pueden ver las Recomendaciones de Seguridad, donde dan los siguientes consejos:

• Nuestro Servicio sólo envía correos de carácter informativo, no se adjunta ningún link o documento que deba descargar.
• El Servicio nunca solicitará respuesta a los correos electrónicos.
• Nunca se solicitará datos personales, rut ni su clave secreta.
• Si le solicitan este tipo de información puede estar siendo víctima de un fraude, provocado por un phishing, virus o troyano.
• Escriba la dirección completa www.sii.cl en su navegador de internet y asegúrese de hacerlo en lugares conocidos.
• Mantenga su computador actualizado con sus parches y antivirus al día para protegerlo de software malicioso.
• Si su navegador (Firefox, Explorer, Chrome u otro) le ofrece “volver a recordar clave”, no lo acepte nunca.
• No permita que otros vean su clave secreta.
• No ocupe la misma clave del SII para otros sitios en Internet.

Por otro lado, Servicio de Impuestos Internos nos entrega el siguiente manual para realizar la configuración óptima de nuestro certificado digital: Instalación del Certificado Digital y Configuración del Computador.

Un análisis paso por paso de este manual de configuración:

Paso 1

Lo primero que nos indica es que solo soporta sistemas operativos de Microsoft y navegadores de la familia Internet Explorer. Otro detalle, que aparece en los parentesis, es que para poder utilizar el sistema necesitamos tener privilegios de administrador en el sistema operativo. Claramente esto indica que “algo raro” hace el sistema en nuestro computador.

Paso 2 Este paso lo omitimos ya que hace referencia a la instalación del plugin para visualizar PDF.

Paso 3

En este punto nos indican que debemos verificar e insiten en que la aplicación (sistema web) no funciona si no somos administradores o no contamos con dichos privilegios. ¿Se imaginan que algun plugin de  chrome o firefox nos obligue a ser “root” para poder instalarse?

Paso 4

En este paso nos “recomiendan” deshabilitar los niveles de seguridad de Internet Explorer. Es decir, la seguridad del plugin o el funcionamiento de este sistema es tan baja, que debemos desactivar las configuraciones de seguridad de nuestro navegador. Aunque nos indican que previo a la configuración de la firma electrónica debemos restaurar los valores de seguridad, nos estan diciendo que para poder configurar e instalar este medio de autentificación debemos remover la seguridad, es decir algo “trucho” quiere hacer con nuestro computador. ¿Alguien sabe que cosa hace REALMENTE este bicho de la firma electrónica o todos simplemente han seguido las instrucciones y lo han instalado?

Paso 5

En este paso nos indican que descarguemos y ejecutemos un archivo, el cual realiza modificaciones en el registro de Windows. En ningún lugar nos advierten los cambios que se realizaran, simplemente nos dicen “Ejecutalo”. ¿Alguien se ha preguntado que opciones y que modificaciones hace este archivo .reg? Afortunadamente este archivo corresponde a un archivo Windows Registry Editor Version 5.00, el cual modifica el registro de windows para añadir sii.cl a dominios de confianza, tanto http como https.
Se han reportado vulnerabilidades XSS en el sistema del servicio de impuestos internos que, al tenerlo como sitio de confianza, sería mucho más fácil realizar fraudes.

Paso 6 y 7 omitidos, no tienen relevancia

Paso 8

Nos está solicitando  que desactivemos el bloqueo de “elementos emergentes” o popups, es decir, nos está solicitando que bajemos aún más el nivel de seguridad con el cual navegamos en internet. El bloqueo automático de popups o elementos emergentes se utiliza para bloquear popups con publicidad, prevenir la instalación de algun tipo de malware o plugin malicioso, entre otras cosas. Con esta instrucción el SII nos está exponiendo en la red.

Hasta el momento tenemos nuestro computador configurado de la siguiente manera:

• Navegador Web con Nivel bajo o nulo de Seguridad
• Sitio web HTTP y HTTPS de sii.cl agregado a sitios de confianza.
• Bloqueo de elementos emergentes o popups desactivado.

Es decir, desactivamos todas las medidas básicas de seguridad que un navegador nos entrega, todo esto para poder usar la famosa firma electrónica o certificado digital.

Paso 9

Nos recomiendan volver a las configuraciones previas al paso6, es decir, restaurar los niveles de seguridad pero aún asi continuamos con los elementos emergentes o popups desbloquedos y con el sitio web sii.cl en nuestra lista de sitios de confianza.

Según mi opinión, la única razón para tener que agregar un dominio a un sitio de confianza (algo asi como una whitelist) es porque se que no tiene la suficiente seguridad, por lo tanto cualquier bloqueo o protección mínima de seguridad no me permitiría utilizar el sitio como corresponde.

Tener la seguridad deshabilitada, bloqueo de popups desactivado y sii.cl agregado a sitios de confianza, nos expone a que nos hagan un ataque a nivel de dns spoofing o suplantación de dominio.

En resumen, para poder utilizar la firma electrónica necesitamos:

• Microsoft Windows
• Internet Explorer
• Usuario o privilegios Administrador
• Bajar la protección de seguridad del navegador
• Desactivar el bloqueo de popups
• Agregar un sitio web a nuesrtos sitios de confianza.

Algo anda mal …

El sistema en línea del Servicio de Impuestos Internos estuvo bajo mantención durante la noche redireccionando a todos los usuarios a http://www.sii.cl/pagina/actualizada/suspension/hpi_suspension.htm. El problema es que el mensaje no se desplegaba al momento de ingresar al sitio, sino que luego de iniciar la sesión o más bien, luego de enviar el formulario de inicio de sesión o de intentar ingresar mediante certificado.

Cuando ingresabamos a http://www.sii.cl se veía todo normal, la página de inicio, con el formulario para iniciar sesión, etc

Los usuarios no se daban cuenta que el sistema estaba en mantención hasta que intentaban ingresar con sus credenciales de acceso, por ejemplo intentaremos ingresar con el RUT de pruebas 12345-5

Y usaremos la contrasña “sii_inseguro” para esta prueba de concepto. Seguimos el flujo normal y presionamos el botón Ingresar, veremos el siguiente mensaje

Hasta el momento para todos los usuarios era un mensaje ya conocido, que al intentar ingresar al sistema les advertían que el sistema estaba en mantención hasta cierta hora del día siguiente, pero el detalle está en la URL, si se fijan se expone la clave que nosotros ingresamos de pruebas

El otro detalle es que la URL no está bajo SSL o HTTPS, por lo tanto podría ser interceptada por algún intruso. En los logs del  sistema o del servicio http ya quedó registrada nuestra contrasña.

El problema era que el formulario de login enviaba los datos del formulario vía GET a la URL de mantención, sin embargo, la URL de mantención se mostraba a todos, indiferente si el usuario y contraseña eran válidos o no. No entiendo por qué hicieron eso …

De todas formas, el problema fue comunicado al Jefe del Departamento de Informática quien dijo que remitiría el problema al área correspondiente. Esperemos que para la próxima mantención no se vuelva a repetir.

VTR es un proveedor de servicios de telefonía, internet y televisión, que desde hace un tiempo está instalando en los domicilios el famoso modem Arris WTM652, como el de la foto de a continuación

Como todos los routers o modem, este dispositivo tiene varias opciones de configuración ya sea para la red cableada como al wireless. Entre las opciones está reiniciar el router, volver a los valores por defecto,  modificar la configuración de la red WiFi pudiendo incluso dejarlo sin servicio.
Si el acceso a la configuración de este dispositivo estuviese correctamente configurada y solo permitiera ingresar desde una red privada, no habría ningun problema, pero no es así.

Existen muchos modems que estan accesibles desde Internet, mediante la IP pública que VTR les asigna. Por ejemplo vamos a tomar el caso de pc-110-182-120-200.cm.vtr.net:

1. Abrimos el navegador y escribimos la direccion http://pc-110-182-120-200.cm.vtr.net/.

Ya logramos acceder al router de manera sencilla, sin usuario, password ni ningun mecanismo de control.

2. Vamos a la configuración de la WiFi pinchando en Wireless Setup

Nos pide una contraseña para poder entrar a la administración, pero abajo aparece un tip “Default = leave blank”, entonces …

3. Dejamos el campo password en blanco y presionamos “submit”

Listo. Ya estamos dentro de la configuracion de la red inalambrica. Incluso si vamos a la seccion “Security” podemos ver la clave de la red inalambrica

Como se dan cuenta, el hostname corresponde al reverso de cada dirección IP que VTR le asigna a sus clientes, por ejemplo si un cliente de VTR tiene la dirección IP 190.45.100.86, el reverso corresponderia a pc-86-100-45-190.cm.vtr.net. Está bajo el dominio vtr.net, por lo tanto ya podemos filtrar una busqueda por ejemplo en Google para que nos liste todos los clientes de VTR a los cuales podemos acceder a sus modems, obeniendo un listado como el siguiente:

http://pc-89-187-164-190.cm.vtr.net

http://pc-211-9-86-200.cm.vtr.net/

http://pc-247-226-83-200.cm.vtr.net/

http://pc-205-73-104-200.cm.vtr.net/

http://pc-60-166-104-200.cm.vtr.net/

http://pc-125-182-120-200.cm.vtr.net/

http://pc-25-233-46-190.cm.vtr.net/

http://pc-61-6-44-190.cm.vtr.net/

http://pc-110-182-120-200.cm.vtr.net/

http://pc-119-30-44-190.cm.vtr.net/

http://pc-250-57-214-201.cm.vtr.net/

http://pc-162-128-45-190.cm.vtr.net/

http://pc-86-100-45-190.cm.vtr.net/

No estoy seguro si el responsable de esto es VTR o los clientes, pero si estoy seguro que muchos de estos usuarios afectados no tienen idea de que la configuración de su modem y red inalambrica está abierta al publico.

Prey es una herramienta que permite el rastreo de computadores y dispositivos móviles, pensado para encontrar tu portátil, tablet o teléfono móvil cuando se te pierde o te lo roban.

Basicamente, y como todo software o herramienta de rastreo, lo que hace es enviar información a un servidor centralizado con la ubicación y otros datos que te pueden ayudar a identificar dónde está tu dispositivo. Lo que me llamó la atención fue querer conocer cómo envia la información y cómo funciona la “api” de comunicación, por lo que me lo descargué y comencé a analizar el código.
La versión analizada es la 0.5.9 (md5: 1ff6cb6bb0de36415fde3382e72a8a6d), pero imagino que la información que voy a exponer afecta a todas las versiones anteriores.

El principal problema es que el protocolo que se pensó para la interacción entre los usuarios y el servidor centralizado es demasiado básico y no cuenta con los controles de seguridad necesarios.

Primero, para entender un poco como funciona de manera simple, los clientes (usuarios) interactuan con el servidor control.preyproject.com, habilitado bajo los protocolos HTTP y HTTPS. Se comunica bajo el User-Agent=Prey Configurator/Version y se envían los parámetros  requeridos mediante POST. Las peticiones se envian a distintos archivos xml bajo el subdominio de control; por ejemplo users.xml, devices.xml, prey-last-response.xml o “device_key“.xml. Este último, se remplaza device_key por la llave o identificador del dispositivo.

Segundo, existen parámetros de autenticación que se envian en las cabeceras de la petición http. Corresponden al mecanismo de autenticación HTTP mediante la cabecera Authorization. Aquí está el primer problema y debilidad de la herramienta: Se envían cifrados en Base64.
Todos sabemos que base64 es un algorítmo de doble vía, que permite cifrar y descifrar sin mayores esfuerzos, por lo que no se recomienda utilizarlo como medida de seguridad para claves o tokens.

Existen distintos tipos de autentificación http, el que implementa Prey es el más inseguro y el menos recomendado, su nombres es “Basic“. Los datos enviados mediante el mecanismo básico de autenticación puede ser fácilmente interceptado y descifrado, permitiendo conocer la ApiKey y que, capturando los datos enviados por POST, ya tenemos toda la información para hacer consultas sobre el o los dispositivos de nuestra víctima.
Por ejemplo, esta es una petición enviada al servidor de control de Prey, usando un ApiKey aleatorio:

Si desciframos la segunda linea, despues de “Basic”, obtenemos lo siguiente: syrjbqk7z6w:x. El primer elemento, antes de los dos puntos (:) corresponde al usuario y el segundo a la clave.
Algunos pueden pensar que si el tráfico va por SSL no deberíamos poder leerlo, sin embargo, aquí existe otro problema mas.
El segúndo problema es que las peticiones que hace Prey a su servidor “seguro” son de forma insegura, aceptando certificados inválidos, permitiendo a un atacante realizar ataques Man-in-the-Middle al protocolo HTTPS y conocer el contenido de la petición sin ningun problema. Por ejemplo, esta es una de las llamadas que hace la herramienta usando cURL:

command = '/usr/bin/curl -A "' + USER_AGENT + '" -i -s -k --connect-timeout 5 ' + CONTROL_PANEL_URL_SSL + '/' + path + data

El parámetro “-k” de cURL significa: aceptar certificados inválidos. La línea corresponde a la número 479 del archivo platform/linux/prey-config.py.

El impacto de estas vulnerabilidades o debilidades es que por ejemplo si tienes Prey instalado en tu celular o en tu notebook y te conectas a una red publica (con o sin clave) como la de un café, centro comercial, bar o lo que sea, toda la información que Prey envía sobre tu ubicación puede ser intersectado por un tercero. Además, esa persona podría quedarse con tus tokens y consultar la ubicación y los datos de los dispositivos registrados cuando quiera.

La tercera vulnerabilidad, afecta al proceso de registro de un nuevo usuario o dispositivo. Para realizar este proceso se envia una petición a users.xml pasando mediante POST las variables name, email, password y password_confirmation. No cuenta con ningún tipo de control de seguridad, lo que permite registrar tantos usuarios como queramos, pudiendo saturar el servidor si se realizan miles de peticiones de forma simultanea. Esta información fue obtenida del archivo platform/linux/prey-config.py, función create_user.

def create_user(self):
self.email = self.text('email')
params = urllib.urlencode({'user[name]': self.text('user_name'), 'user[email]': self.email, 'user[password]': self.text('password'), 'user[password_confirmation]' : self.text('password_confirm')})
# params = 'user[name]='+self.text('user_name')+'&user[email]='+self.email+'&user[password]='+self.text('password')+'&user[password_confirmation]='+self.text('password_confirm')
result = self.make_request('users.xml', params, None, None)

if result.find("<key>") != -1:
self.get_api_key(result)
self.device_key = ""
elif result.find("Email has already been taken") != -1:
self.show_alert(_("Email has already been taken"), _("That email address already exists! If you signed up previously, please go back and select the Existing User option."))
return
else:

Por ejemplo, en la siguiente Prueba de Concepto (PoC) crearé 10 nuevos usuarios y el sistema me devolverá sus respectivas llaves. Usando cURL de la siguiente forma:

for num in $(seq 1 10); do curl -A "Prey Configurator/222 (Linux)" https://control.preyproject.com/users.xml -d "user[name]=user_$num&user[email]=correodeprueba$num@gmail.com&user[password]=123456&user[password_confirmation]=123456"; done

Obtenemos: Con esto hemos creado los usuarios user_1, user_2, user_3, user_4, user_5, user_6, user_7, user_8, user_9 y user_10 con los correos respectivos correodeprueba1@gmail.com, correodepruebaN@gmail.com. El servidor devolvió los siguientes tokens:

• hjxdp3k46u2j
• v6lijlbx3tc8
• qow7eih39ymb
• cvrealg9vu09
• t5nd017drwmi
• irsiauu5msc2
• t8u9jrtvmxbh
• 31gqe0h3fiy2
• glua8bsl8wtg
• 295y3at88e0w

Los cuales cumplen el mismo patrón: Largo 13 caracteres, numeros y letras en minusculas. Ahora podemos generar tokens aleatorios segun este patron e ir probando. Con esto ya tenemos nuestra cuarta vulnerabilidad que debido a la fatla de controles de seguridad es posible realizar fuerza bruta y obtener las ApiKey de los usuarios. Si hacemos una petición a devices.xml entregando mediante la cabecera de autentifiación básica un token aleatorio el servidor nos devolverá el código 401 Unauthorized, de lo contrario nos devolverá 200 OK. De esta forma podemos enviar tantas peticiones queramos hasta obtener el codigo 200. Como podemos ver en la función verify_keys() del archivo core/pull, si el servidor devuelve 200 OK o 404 Not Found, significa que la ApiKey es válida, de lo contrario nos dice que es incorrecta:

if [[ "$response_status" == "200" || "$response_status" == "404" ]]; then

log  ' ** API key is valid. Your user account is correctly set up.'

Por lo tanto, lo único que debemos hacer es un script que genere strings alfa-numéricos en minúsculas de largo 13 y que haga las peticiones correspondientes hasta dar con un token valido.

Con el siguiente script hacemos la prueba de concepto:

for x in $(cat keylist.txt);
do
echo "Trying $x ..."
response=$(curl --write-out %{http_code} --silent --output /dev/null http://control.preyproject.com/devices.xml -u $x:x);
if [ $response -eq 200 ]; then
echo "Found: "$x;
fi;
if [ $response -eq 404 ]; then
echo "Found: "$x;
fi
done

Y este fue el resultado:

De los 20 tokens aleatorios probados, encontró 3:

• Found: s3519t12vsch
• Found: irsiauu5msc2
• Found: 717i8cmeq698

En resumen, la implementación del protocolo de Prey tiene bastantes debilidades como el uso de mecanismos de autentificacion demasiado basicos y falta de mecanismos de control como por ejemplo manejar el throttling de peticiones.

Antes de publicar este artículo, me contacté con el equipo de PreyProject para hacerles llegar la información y que tuvieran tiempo para poder analizar y solucionarlo. Tomás Pollak, la persona que responsable de Prey, respondió lo siguiente:

1) El uso de -k en un llamado a Curl en el configurador de Linux: 100% de acuerdo y para serte honesto esta se me pasó. Hace unos meses subí un cambio precisamente para dejar de hacer esto esto en las llamadas HTTP que hace el cliente (commit e7cff53d90ea4d8f1f2adfb89f34f1e37648ebc0). Acabo de arreglar esto.

2) La posibilidad de crear múltiples cuentas sin limitar: He estado pensando sobre esto y sinceramente no veo por qué podría ser una falla de seguridad. Hace harto tiempo pensamos en implementar un límite a la cantidad de consultas — para hacérsela más difícil a las empresas que crean múltiples cuentas para evitar pagar por una cuenta Pro — pero terminamos decidiendo no hacerlo al final. A la larga lo que nosotros queremos es, precisamente, que se creen más cuentas.

3) Autenticación con la llave API: Cuando leí la parte de HTTP Basic me sorprendí un poco, porque el uso HTTP Basic para el envío de credenciales en una API es algo súper común (creo que 37 Signals lo popularizó), y el uso de Base64 es parte del protocolo de HTTP Basic, no es algo que nosotros hayamos decidido. De todos modos queremos pasar a OAuth2 en el futuro una vez que hayamos lanzado el nuevo panel y cliente en que hemos estado trabajando.

4) Bruteforce: Sobre el brute force para las llaves APIs, tienes razón, y es precisamente por eso que en el XML de respuesta no entregamos ningún dato del usuario, para que incluso habiendo pillado una llave API válida un tipo no pueda hacer mucho. Al final, la llave API es realmente útil usada en conjunto la llave del dispositivo ya que eso es lo que permite activar Prey, guardar reportes, etcétera.

Mi respuesta a este correo de Tomás, fue que respecto al punto 2) y 4) deberían implementar una especia de Request Throttling ya que arriesgan ataques de DDoS, respecto al punto 1) muy bien al reconocer el problema y modificar a la brevedad las llamdas a cURL con el parametro -k, respecto al punto 3) le comenté que existen mecanismos de autenticación http más seguros que el Basic, como por ejemplo Digest o NTLM.

Tomás muy agradecido se despide y responde:

Hoy mismo actualizamos las reglas de IPTables y agregamos un throttle para limitar el número de consultas HTTP, con lo que debiera disminuir el riesgo de un DDoS para la creación de cuentas o el brute force para las llaves API.

En cuanto a la autenticación, NTLM suena como una buena idea. Voy a echarle un vistazo.

Este es un ejemplo de como deben reaccionar las pequeñas y grandes empresas ante reportes de incidentes de seguridad.

Me atrevería a decir que en chile, estos dos bancos (que en realidad son lo mismo) son los únicos que no implementan un login con seguridad HTTP+SSL o más conocido como HTTPS.
Una implementación segura de este protocolo necesita que tanto el formulario de inicio de sesion como la URL de destino del formulario esten bajo HTTPS, de lo contrario perfectamente mediante un ataque MITM u otro tipo de ataque un atacante podría modificar los parámetros del formulario que está sin seguridad.

El pensamiento para implementar HTTPS de ambos bancos es: “Hagamos el login sin https, pero cuando el usuario presione ‘entrar’ se envie el formulario a un sitio con https“.

El primer problema de todo esto, es que cuando intentamos ingresar mediante HTTPS a los sitios de los bancos, nos muestra lo siguiente

Ambos nos muestran el mensaje “Error 403–Forbidden“, es decir, nos tienen prohibido ingresar al sitio forzandolo a una conexión segura, obligandonos a entrar sin el HTTPS.

Ahora vamos a revisar el login de cada banco. En el caso del BCI iniciamos sesión mediante la URL no segura http://www.bci.cl/personas/nuevologin.html y nos muestra el formulario de inicio de sesión de forma satisfactoria

Sin emargo, si lo forzamos a una URL segura como https://www.bci.cl/personas/nuevologin.html pasa lo siguiente

En TBanc pasa exactamente lo mismo. El login se encuentra en la página principal y tal como mostré en la imagen de más arriba, al intentar entrar a la página principal son HTTPS nos muestra el error 403.

Dentro de OWASP (the Open Web Application Security Project) existe un documento que define las mejores prácticas para la implementación SSL, donde dice claramente:

Rule – Use TLS for All Login Pages and All Authenticated Pages

The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the “login landing page”, must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user’s credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user’s authenticated session.

Que exactamente se refiere al problema que tienen estos dos bancos. El no tener la página donde se encuentra el formulario de inicio de sesión bajo HTTPS, permite a un atacante modificar los parámetros del formulario como por ejemplo la dirección donde se envian los datos de inicio de sesión (RUT y clave).

Algo no menos preocupante, es la respuesta que tienen los canales de atención y respuesta al público, donde hacen sentir una falsa sensación de seguridad a sus clientes, por ejemlo mediante la cuenta twitter:
Un cliente le pregunta por el problema del login con https y esta fue la respuesta por parte de Tbanc:

Y esta es la respuesta a otra discusión con BancoBCI

Si ambos bancos cuentan con altos estándares de seguridad, entonces me imagino que realizan auditorías de seguridad periódicas y si en estos análisis periódicos no reportaron este fallo en la implementación de HTTPS tan fácil de detectar, quizas que otra cosa no han detectado… Lo dejo en el aire.

Para que tengan alguna referencia de cómo un atacante puede aprovecharse de esta mala implementación de conexión segura, los invito a que lean respecto a los ataques Man-In-The-Middle (MITM), que en simples palabras permite a un atacante situarse entre la víctima y el gateway, permitiendo ver y modificar todo el tráfico que pasa entre ambas partes y como en este caso el tráfico del formulario de login va en texto plano, mucho mejor.

Es más común de lo que piensan que los usuarios suban archivos “basura” a servidores en producción/explotación. Muchas veces son distintos usuarios los que tienen acceso al directorio público de un sitio web, ya sea todos accediendo desde el mismo usuario o cada uno con su usuario.
El problema es cuando no tenemos control sobre las cosas que se suben a producción, por ejemplo como administrador de sistemas a muchos nos ha tocado que debemos crear cuentas de usuario ftp con acceso a subdirectorios de un sitio web, uno intenta aplicar todas las medidas de seguridad posible y hacer cumplir todos los procedimientos necesarios, como por ejemplo que un “usuario normal” no puede subir archivos a produccion vía FTP sin que sean correctamente validados ni filtrados, sin embargo, a ellos no le sirve. Otro ejemplo es cuando los desarrolladores tienen que subir desarrollos nuevos o actualizaciones, ya sea mediante un control de versiones o suciamente directamente desde ftp o ssh, nunca se controla qué tipo de archivos están subiendo, exponiendo nuestros servicios y servidores.

Hace un año aproximadamente, cuando trabajaba de administrador de sistemas, intenté implantar un procedimiento de pasos a producción en el cual se pudiese revisar los archivos de cada control de cambio, simplemente para revisar que no se estén subiendo archivos sensibles como el típico respaldo de la base de datos, respaldos de código fuente, etc. Pero no funcionó ya que decian que lo único que hacia era “entorpecer el proceso”.

Cuento esta historia a modo de introducción para lo que van a leer más abajo; les mostraré los errores más comunes al momento de desarrollar y poner en internet un nuevo sitio o aplicación web.

El primer error que les voy a mostrar, es cuando se suben archivos de “respaldo” con la extensión modificada sin que el motor http sepa si debe interpretarlo o no, por lo tanto muestra el código fuente. Dentro de lo más típico es renombrar archivos antes de modificarlos y dejarlos como por ejemplo usuarios.phpOLD, usuarios.php.old, usuarios.php_, etc. Con este ejemplo, podemos ver que renombraron el archivo Reserva.php a Reserva.php__, y si ingresamos y vemos el código fuente, podemos ver el php sin interpretar:

URL http://www.campamentosdeingles.es/Reserva.php__

Otros casos reales:

• Wissnet: http://wissnet.com.ar/moregroupware/modules/webmail2/inc/webmail2_settings_editaccount.php__
• Gruenes Presse: http://www.gruenes-presseportal.de/index.php__
• Cencosud Chile: http://www.cencosudshopping.cl/portalnunoa/components/com_mirador/views/mirador/tmpl/default.php__

Hay que tener mucho cuidado con este punto, ya que muchas veces son archivos de configuración como conex.php, db.php u otro que revelan usuarios y passwords de bases de datos, ftp, etc.

El segundo error es cuando suben archivos comprimidos o empaquetados. Lo descargamos, desempaquetamos y listo, tenemos el código fuente. Por ejemplo lo que sucede con el sitio http://www.emc.mil.cl/ que nos permite descargar el sistema de captcha que utilizan mediante www.emc.mil.cl/sgs_1022/captcha/captcha.zip.

El tercer error son los archivos logs . Yo puedo entender a quienes suben logs para que otros los descarguen y luego se les olvide eliminarlos, o bien que respalden logs para descargarlos con posterioridad, pero no entiendo a quienes configuran Apache para que almacene los logs dentro del directorio público y sin las medidas de seguridad necesarias. Los logs divulgan información sensible como direcciones IP, directorios, nombres de usuarios, etc. Dentro de los logs públicos más comunes estan el del WS_FTP y los logs del apache.
Un ejemplo del log de transacciones WS_FTP lo pueden ver en el siguiente link http://www.biogoldsa.cl/pdf/WS_FTP.LOG:

Un ejemplo de un log de Apache lo pueden ver en http://www.gescomltda.cl/intranet/logs/access.log:

Otros ejemplos:

• http://www.mmaya.gob.bo/webpncc/biblio/WS_FTP.LOG
• http://entidades.sicoes.gob.bo/lib/WS_FTP.LOG
• http://tecsa.cl/swf/_notes/WS_FTP.LOG
• http://www.facilito.cl/web2/publicidad/basura/WS_FTP.LOG
• http://puracarne.cl/rticket/config.log
• http://www.cde.cl/webServices/sqlnet.log

Aunque no es muy común, tambien nos encontramos con servidores que publican logs de transacciones de Transbank o Webpay, como por ejemplo lo que sucede con el sitio de Swift.cl:

El cuarto y último error son los famosos dump de bases de datos. ¿Quien no ha hecho un mysqldump , pg_dump o lo que sea y ha subido el archivo a un servidor? El problema es cuando se nos olvida eliminarlo y queda accesible para cualquier persona. Aunque no lo parezca, es muy común. Preguntele a la gente de Nescafé que publican bajo elmonentofeliz.cl la base de datos de todos los concursantes

El archivo elmoment_feliz.sql tiene 7,3Mb de información con registros de la base de datos del portal web. Otros ejemplos:

• http://www.circulomayor.cl/wp-content/backup-db/1312804068_-_circulomayor.sql
• http://www.mmaya.gob.bo/separatas/concurso.sql

Como solución a mi problema como adminsitrador de sistemas y encargado de seguridad, la única opción que me dejaron los usuarios fue que yo periódicamente realizara busquedas de archivos comprometedores como *.sql, *.bak, *.old, *.php__, etc y los moviera fuera del directorio público.

SO.CL es el nombre de la red social de Microsoft la cual permite, mediante una vulnerabilidad que afecta a uno de sus servidores, usar una IP de Microsoft como proxy.
La vulnerabilidad afecta al servicio que genera las minuaturas (thumbnail) de las imagenes que suben los usuarios a la red. Al insertar o enlazar una imagen, la red social llama a http://cdn2.so.cl/handlers/thumbnail entregandole mediante GET la URL de la imagen a mostrar. Este sistema de thumbnails no valida correctamente los parametros permitiendo generar request a servidores remotos de manera arbitraria.

La vulnerabilidad en si es un poco compleja de explotar, ya que no devuelve ningún valor, pero realizando algunas pruebas de concepto con un servidor de pruebas podemos analizar el comportamiento e imaginar distintas formas de explotarla.

La primera prueba a realizar será entregarle directamente una imagen en formato gif para que genere el thumbnail, usaremos la URL de pruebas http://zerial.org/socl.gif.

El sistema alojado en cdn2.so.cl generó el thumbnail correspondiente generando el siguiente request en el servidor zerial.org:

 168.62.163.190- - [30/Dec/2012:03:00:38 -0300] "GET /socl.gif HTTP/1.1" 200 160834

La dirección IP  168.62.163.190 desde la que se hizo el request corresponde a Microsoft Corporation. De esta forma, generamos un request desde el servidor de Microsoft a mi servidor de pruebas.

Hasta ahora está todo normal, ya que el servicio de thumbnails ha funcionado bien, fue a buscar la imagen desde la URL que le entregamos, la redimensionó y la mostró.

Ahora vamos a intentar con la misma imagen, pero modificando su extensión a .html.

El resultado es el mismo, indiferente si la extensión es html, gif, mp3 o cualquier otra, el servidor de microsoft realiza la petición al servidor remoto y nos muestra la miniatura.
Este es el primer problema, no valida correctamente la extensión del archivo. Si es un sistema para generar thumbnails debería validar al menos la extensión del archivo.

Ahora vamos a intentar generar un thumbnail de un archivo que no sea una image, por ejemplo un mp3. Probaremos con el archivo de audio http://zerial.org/ghost.mp3.

No nos muestra nada, ya que obviamente no puede generar un thumbnail de un mp3, sin embargo, si genera el request en el servidor de pruebas:

168.62.163.190 - - [30/Dec/2012:03:17:38 -0300] "GET /ghost.mp3 HTTP/1.1" 200 3901240

Desde la misma dirección IP que el request anterior cuando abrimos un archivo de imagen. El sistema no muestra ningun mensaje de error ni nada por el estilo, por lo tanto me atrevo a asumir que está intentando generar el thumbnail y como no puede, muestra la página en blanco.

Lo que haremos ahora es encontrar la forma de poder explotar esta vulnerabilidad para poder realizar ataques a otros sistemas. A modo de pruebas seguiré usando zerial.org pero llamaré a un archivo php simulando tener un sql-injection

Nuevamente nos devuelve una página en blanco pero nos genera el request en el servidor de pruebas

168.62.163.190 - - [30/Dec/2012:03:22:56 -0300] "GET /fake.php?id='%20or%20'1'='1 HTTP/1.1" 200 1476 "-"

De esta forma, si nuestro archivo fake.php fuese vulnerable a sql injection, estaría recibiendo la inyección ‘ or ’1′=’1 desde la dirección IP de Microsoft.

Con el siguiente ejemplo podemos determinar el tiempo de timeout que tiene el servidor de microsoft, por ejemplo creamos un archivo php con una llamada a la función sleep(5), para que “espere 5 segundos”. Para poder tomar el tiempo de ejecución usaré cURL por la línea de comandos junto con time:

Podemos ver en la primera linea (real) que dice que el tiempo de ejecución fue 5,419 segundos. De esta misma forma, si ponemos un sleep(10) el tiempo de ejecución será 10 y así …

Con esto ya tenemos una información interesante, podemos ejecutar inyecciones SQL que tarden 10 segundos en ejecutarse.

¿Cual es el real alcance de esta vulnerabilidad?

Si bien podemos enviar request a sitios remotos y llenar los logs de un servidor con accesos desde la dirección IP de Microsoft o bien ejecutar llamadas a sitios con vulnerabilidades de inyección sql, yo creo que el real alcance de esta vulnerabilidad está en saber como explotar un SQL Injection explotando esta vulnerabilidad de SO.CL.
Por ejemplo, si conocemos un sistema que sea vulnerable a inyección sql que permita eliminar todos los registros de una base de datos, podemos fabricar una URL especialmente para ese ataque y que en los logs de acceso de la empresa afectada aparezca la IP de Microsoft como origen del ataque.

Disclaimer

Esta vulnerabilidad fue reportada al Microsoft Security Response Center (MSRC) siguiendo las instrucciones publicada por ellos mismos en su sitio web, el día 21 de Mayo del 2012. Sólo tuve respuesta del bot que recibe los incidentes, asignando el caso MSRC 12574. Respondí el correo para conocer el estado del incidente el día 4 de Junio del 2012 obteniendo la siguiente respuesta el 6 de Junio:

We are currently reviewing the issue to determine root cause and perform variant analysis.

ACTUALIZADO

La respuesta final por parte de los ingenieros de Microsoft, enviada el día 11 de marzo del 2013, fue:

Thank you for reporting this behavior to us. After further analysis, our team found the issue to be by design. There were various solutions discussed and we found the current implementation meets the current needs for this feature at the scale required. In the future, we will implement a solution which will provide a key for every thumbnail creation request, which will address the specific issue you reported.

Este post es para presentarles un nuevo proyecto chileno de Shinee Labs, que busca acercar a padres e hijos al uso seguro de internet. Esto incluye el uso de redes sociales, navegacion segura, mecanismos de control y vigilancia, etc.

s-Safe4kids es un espacio creado con la finalidad de acercar a padres e hijos al uso seguro de la Internet.
El mayor poder existente es estar informado, esto nos ayuda a prevenir y tomar acciones en pro del bienestar de nuestros hijos.

La comunidad usualmente desconoce el poder de la tecnología y de los riesgos que por malas practicas se corren. Informar y crear conciencia es un paso importante en la lucha contra el acoso infantil.

La evolución en la Tecnología debe ir de la mano con la responsabilidad de quien la ocupa, cada vez es mas común ver a niños tener acceso a Internet por diferentes dispositivos a más temprana edad.

Si te interesa apyar esta iniciativa visita y difunde el sitio web http://www.e-safe4kids.org/ y síguelos en twitter @esafe4kids.

En el post anterior se expuso a una empresa que almacenaba en sus servidores registros de un KeyLogger. La empresa es INFOMIN y presta servicios a grandes mineras del país.
En el post se menciona el hecho de espionaje informático a un empleado de la empresa. La publicación repercutió en distintos medios sociales como twitter y facebook, hasta que llegó a uno de los responsables de la empresa INFOMIN, quien vía correo electrónico y luego vía telefónica, se contactó conmigo y luego de una larga conversa, creo que es necesario emitir las siguientes aclaraciones:

• La afectada es una persona que no trabaja en INFOMIN, familiar de uno de los encargados de la empresa.
• La empresa NO espía a sus empleados ni a sus clientes.
• Los registros del KeyLogger, donde se elmacena todos los usuarios y claves, almacenados en el directorio collahuasi/ no tienen relación con la Minera Collahuasi. Es simplemente un directorio que tenia los permisos de escritura donde el atacante decidió guardar los datos de su víctima.
• La empresa inició una investigación interna mediante la cual busca aclarar los hechos para determinar responsables y afectados. Estudiarán la posibilidad de una denuncia a cibercrimen para determinan responsabilidades a otro nivel.

Como punto a parte, la persona con la que hablé me reconoció no haber tomado en cuenta el correo que se le envió el día 6 de Diciembre porque lo encontró poco serio. Esto nos deja dos moralejas:

• Nosotros: Tomar contacto de una manera más seria (buscar como hacerlo)
• Ellos: Tomar en cuenta los correos con avisos de seguridad independientemente si el remitente es de hotmail, gmail u otro. Siempre puede ser interesante.

Espero  que esto sirva de aclaración y de ejemplo para quienes no toman en serio la seguridad informática y la privacidad de las personas. Más vale tarde que nunca. Muy bien INFOMIN por haber reconocido el incidente y actuar de forma correcta.

ACTUALIZADO

Finalmente Google eliminó los resultados de sus busquedas y me contactaron de INFOMIN para comunicarme que hicieron la denuncia respectiva en fiscalía.

Un KeyLogger es una herramienta que permite almacenar todo lo que un usuario escribe con el teclado, permitiendo almacenar contraseñas, nombres de usuarios, datos bancarios, textos, etc. Ser víctima de esta herramienta es potencialmente peligroso, ya que por lo general se oculta entre los procesos y no nos damos cuenta de que alguien está registrando todo lo que hacemos y enviandolo a un servidor externo.

La empresa INFOMIN, dedicada a otorgar servicios de consultoría tecnológicas a las mineras de chile, está almacenando en sus servidores información obtenida desde un KeyLogger aparentemente de un empleado. La información corresponde al año 2012 y recocleta todo tipo de información como usuarios y contraseñas de Facebook y tiendas comerciales, entre otros. Un claro espionaje de la empresa (o alguien de la empresa) hacia los empleados.

El aviso me lo dió @Shinee_, luego de intentar contactarse con la empresa mediante el correo info@infomin.cl, el cual publican ellos mismos en el footer de su sitio, sin obtener ningun tipo de respuesta.

Los archivos son de acceso publico, sin contraseñas ni ningun mecanismo de protección. Incluso son indexados por los motores de búsquda, como por ejemplo Google. Usando una simple busqueda como “site:infomin.cl filetype:txt” obtenemos el resultado de los archivos que estan dentro del directorio collahuasi:

Y como si fuera poco, el directorio /collahuasi tiene Directory Listing

Analizando sólo alguno de los archivos encontrados, obtenemos datos como credenciales para acceder a cuentas bancaria de banco BCI, tiendas comercials CMR y La Polar.

¿Quien debe encargarse de este tipo de acciones de espionaje dentro de una empresa?

El aviso fue enviado a INFOMIN el día 6 de diciembre del 2012, sin recibir ninguna respuesta.

Necesitaba encontrar los subtitulos para unos videos bastante rebuscados, no encontraba ninguno que se adaptara a la versión que había conseguido, tampoco queria editarlos. Entre navegar y navegar, encontre varias herramientas y finalmente me quedé con subdownloader.

Subdownloader es una “rápida y fácil” herramienta para descargar subtitulos. La herramienta obtiene un hash de tus películas y luego va a buscar los subtitulos que coincidan con ese hash a un repositorio de subtitulos en internet: Open Subtitles.

La herramienta está escrita en python, puedes descargar los paquetes para Debian, Archlinux, Gentoo, MacOSX y tambien para Wilson Windows. Obviamente tambien puedes descargar el source para cualquier otra distribución.

Simplemente tienes que instalar y ejecutar. Automáticamente se abre una interáz para navegar entre tus directorios

Seleccionas el directorio o el archivo y automaticamente subdownloader calculará el hash e irá a internet a buscar el subtitulo que coincida con dicho archivo. Seleccionas el idioma

Y el archivo se descargará al directorio actual. Como dicen ellos mismos, la herramienta se basa en el principio KISS (Keep It Simple, Stupid)

El sitio oficial de Subdownloader es http://www.subdownloader.net.

Muchas veces nos preguntamos por quien es el responsable al momento de encontrar una vulnerabilidad en un sitio web que expone información de las personas, si quien hace publico el hallazgo o bien quien comete el errror de dejar esa vulnerabilidad. La verdad es que obviamente es una responsabilidad compartida, pero cuando los encargados de resguardar dicha información no hacen bien su trabajo y no implementan ningún tipo de medidas de seguridad, la responsabilidad -creo yo- corresponde a quien comete el error de dejar la puerta abierta.
Tambien es cierto que existe una gran diferencia entre romper un sistema informático para acceder a información confidencial y encontrar todo abierto, donde es llegar y descargar información donde incluso los motores de busqueda son capaces de indexar dicha información. En este caso en particular, yo me referiré al segundo caso: Cuando dejan todo abierto.

La idea de este artículo no es exponer información confidencial ni mucho menos, simplemente hacer una comparativa de casos en la vida real e internet.

Hace una semana aproximadamente, se dio a conocer en los distintos medios de comunicación, una noticia relacionada con la filtración de documentos médicos o clínicos de los pacientes de un hospital en una comuna de Santiago. En estas fichas médicas existian datos personales de cientos de personas como el nombre del paciente, RUT, dirección e incluso información sobre la enfermedad de cada uno.

Una persona que iba caminando tranquilamente por la calle, se dio cuenta de la presencia de estos documentos y comenzo a grabarlos, luego envio el video a distintos canales de televisión. Esta persona no cometió ningun delito, simplemente grabó algo que le pareció interesante y al darse cuenta la magnitud del asunto, decidió hacerlo publico.

Hace un par de dias, caminando por una conocida calle de Santiago, me encontré con unos documentos clínicos que pertenecían a personas menores  y mayores de edad, donde se exponía el tipo de examen clínico, nombre de la persona, rut, dirección, etc.

Estos documentos pertenecen al Hospital Clínico Universidad de Chile y estaban en la calle.

¿Quien es responsable por esto?

En un sistema informático esto es muy parecido, por no decir igual. Un equipo de personas o una empresa encargada de desarrollar un sistema que debe tener la seguridad necesaria para que la información no sea expuesta a terceros, muchas veces no cumple ni con la más mínima protección. No me refiero a que un usuario mal intencionado haga un ataque a una clínica u hospital explotando vulnerabilidades de manera sofisticada, sino a un hecho tan simple de que la información privada no sea indexada por los motores de busqueda, que al menos tengan una protección de usuario y contraseña, que al menos intenten validar que la persona que realiza la solicitud sea quien dice ser, etc.

Por ejemplo, hace un par de meses el centro de salud MaipoSalud otorgaba acceso a examenes médicos a quien tuviera la URL, y no sólo eso, sino que al modificar el “id” del examen, podrías acceder a información de otros pacientes. Este caso fue publicado en el blog de secureless y ya fue resuelto, pero de todas formas nadie es capaz de decirnos cuantas personas accedieron a toda esa información o quien es el responsable por el acceso ¿no autorizado? a esos examenes.

Este tipo de información, sea expuesta de manera digital o fisica, es útil para los ataques de ingenieria social o los conocidos ataques del “cuento del tío“, donde se utiliza información de la víctima para ganar su confianza y luego aprovecharse de la víctima.

Lo que aparece en el video mostrado mas arriba, pienso yo, que es exactamente el mismo caso de lo que pasó con la publicación en secureless, sin embargo, la primera no es mal vista.

DineroMail es una plataforma de pagos, con presencia en Argentina, Brasil, Chile, Colombia y México, que te permite cobrar y recibir pagos online.
Como es comun con este tipo de medios de pago, las empresas o tiendas comerciales implementan el típico “botón de pago” mediante el cual realizan el pago. El proceso de pago se realiza mediante el subdominio checkout.dineromail.com, al cual se le entregan distintos parametros mediante GET y POST con la información de la transacción.

Con una simple busqueda en Google podemos obtener un listado completo con información de las transacciones realizadas, muchas de ellas corresponden a transacciones de prueba pero existen algunas que no parecen serlo, aunque de todas formas ¿por qué hacen pruebas en producción?

Para poder acceder a este listado de transacciones debemos buscar en Google site:checkout.dineromail.com y analizar los resultados, por ejemplo analizamos un par de resultados obtenidos:

URL indexada: https://checkout.dineromail.com/CheckOut?country_id=1&merchant=1427800&language=es&currency=ars&payment_method_available=ar_dm&item_currency_1=ars&item_name_1=Cuenta%20Premium%20DepositFiles%2014%20Dias&item_quantity_1=1&item_ammount_1=3500&seller_name=MegaCuentas.com

Corresponde a una transacción de pago del vendedor MegaCuentas.com por un valor de ARS$35,00

URL indexada: https://checkout.dineromail.com/CheckOut?country_id=1&seller_name=Fundaci%C3%B3n%20Nordelta&item_name_1=Donaci%C3%B3n&item_quantity_1=1&item_ammount_1=500.00&item_currency_1=ars&payment_method_available=ar_tnaranja,1;ar_cabal,1;ar_tshopping,1;ar_italcred,1;ar_visa,1;ar_master,1;ar_amex,1;&tool=button&merchant=donacion@fundacionnordelta.org&change_quantity=0&language=es

Corresponde a una transacción aparentemente de donación por el monto de ARS$500 a la Fundación Nordelta, quien tiene el correo de contacto donacion@fundacionnordelta.org.

Tambien podemos ingresar a estados de pagos pendientes,

Claramente corresponde a usuarios de prueba, ya que segun la URL desde donde accedemos: https://checkout.dineromail.com/CheckOut?merchant=1721561&country_id=1&payment_method_available=all&item_name_1=Ejemplo+DVD&item_quantity_1=1&item_ammount_1=12050&payment_method_1=ar_pagofacil&buyer_name=Juan+L.&buyer_lastname=Perez&buyer_sex=m&buyer_document_type=dni&buyer_document_number=12345678&buyer_phone=12345678&buyer_email=dineromail.text.checkout.002@gmail.com, el nombre del item es “Ejemplo DVD”, el correo del comprador es dineromail.text.checkout.002@gmail.com y con numero de documento y teléfono de pruebas 12345678.

Google indexa aproximadamente 150 direcciones (segun sus resultados)

Es importante que las empresas que manejan este y otro tipo de información protejan correctamente los datos de sus usuarios.