Archivo de la categoría ‘Seguridad’

eMail: SPF+DKIM = DMARC

Una pequeña reflexión antes de empezar

No sé como evolucionará la tecnología en el modo que nos relacionaremos unos con otros digitalmente dentro de unos años, pero me gustaría pensar que el eMail seguirá teniendo ese papel imprescindible. No son pocos los que año tras años auguran su muerte en pos de la mensajería instantánea. Es cierto que para la mayoría de adolescentes y jóvenes, el uso que puedan darle al correo electrónico es anecdótico, y generalmente para realizar reservas, compras y otros. Llamadme nostálgico o de la vieja escuela, pero pese a las virtudes que nos brinda la mensajería instantánea (la cual por supuesto uso de forma constante), lo único que supera a un buen correo electrónico cargado de contenido es una carta matasellada. Por supuesto no entramos en el mundo laboral/escolar/empresarial, donde a día de hoy el eMail sigue siendo completamente indiscutible.

Dicho esto, recordemos que el eMail no es algo nuevo, que data al menos desde 1970!! y poco cambiado desde entonces. Eso son casi 50 años, y evidentemente desde entonces todo ha cambiado.

 

Como funciona a groso modo el eMail

Como siempre, antes de entrar en materia “pesada”, para los que aun andan un poco despistados, un pequeño resumen rápido de como funciona el eMail, importantísimo para comprender la importancia de tecnologías como SPF, DKIM o DMARK.

El eMail, pese a que pueda parecer algo complejo es un sistema de mensajería tremendamente sencillo, se basa posiblemente en unos de los protocolos más simples que podemos encontrar a día de hoy como puede serlo SMTP. Otra cuestión que la mayoría desconoce es que pese a que tenemos proveedores de eMail a lo largo y ancho de todo el mundo, en realidad cualquiera puede enviar un eMail sin tener siquiera una cuenta propia, y que incluso podría crearse una sin demasiada complicación. Esto es así porque el eMail se creó como modo de comunicación sencilla, sin mirar cuestiones de seguridad o las posibilidades en la suplantación de identidad o…

La Wikipedia nos deja una imagen que ilustra bastante bien el funcionamiento del eMail:

correo

Un usuario envía un texto correctamente formateado a un servidor SMTP para que realice el envío (1), indicando entre otras cosas quien lo manda y a quien se lo mandamos. Este servidor SMTP lo primero que hace es consultar el destino de dicho correo, para lo cual lee el realm de la dirección de destino, es decir, el dominio al cual se envía, la parte derecha de la dirección, y realiza una consulta DNS al registro MX de dicho dominio, pues dicho registro se usa precisamente para ello, para conocer donde se encuentra el servidor de Correos de dicho dominio (2). El servidor DNS de dicho dominio devuelve la dirección de su servidor de correos (3) al servidor SMTP. Este al conocer ya el servidor al que debe de enviarlo, conecta directamente con el y entrega el correo en dicho servidor (4). Dicho servidor debería de reconocer la dirección de correo a la que está destinado, así que lo colocaría en su bandeja, a la espera de que el destino lo reclamase por medio de POP/IMAP (5).

Esta otra imagen muestra lo que sería un esquema más real de todo ello, más completo (no tenía muchas ganas de crear un esquema propio, así que espero que no se moleste oasis-open.org)

howemailworks

El usuario envía un correo a través del MUA (el cliente email que use) y posiblemente a través de SMTP a su MTA/MDA (Mail Transfer/Delivery Agent). Aquí se almacenará posiblemente en su bandeja de enviados, y como dijimos anteriormente se resuelve la dirección de destino y se procede a su envío, conectando al MTA de destino y entregando el mensaje allí. El MTA de destino lo manda ya por su red al buzon correspondiente y el destino lo recoge de ahí.

No obstante, este funcionamiento tan sencillo deja la puerta abierta a muchas preguntas concernientes a la seguridad de los propios correos electrónicos. Algunas cuestiones de gran importancia:

-Los correos no se mandan cifrados? No, por defecto el correo es un texto plano, si se quisiese cifrar se debería de realizar de un modo punto a punto, con tecnologías como PGP o similar, que a día de hoy siguen sin ser usadas de forma global por la complicación que implica el “compartir” las claves públicas. Lo mismo sucede si mandamos un archivo protegido por contraseña la otro extremo, tendríamos que mandarle la contraseña para poder ver dicho archivo. Eso significa que quien accediese tanto a nuestra bandeja de entrada como la de salida podría ver siempre el contenido de los correos.

-La comunicación se realiza de forma segura?? En su modo más simple no, al ser un texto plano, en cualquier punto se podría escuchar la comunicación y con ello el mensaje. La mayoría de servidores SMTP a día de hoy permiten realizar las conexiones por medio de TLS/SSL, pero… resuelve esto completamente el problema?? Tampoco, el mensaje podría llegar de forma segura al MTA, pero para que TODA la comunicación fuese segura, el MTA debería de mover el correo por su propia red de forma segura también, y transmitirlo al MTA destino de forma segura (que no todos los MTA origen/destino permiten), y el MTA destino por su parte volver a moverlo en su red interna de forma segura, y por último el destinatario recibirlo en su MUA por medio de POP/IMAP usando TLS/SSL. Por lo general el único dato que ve el usuario es si se conecta al servidor SMTP de forma segura o no, pero nada más, y eso es sólo el primer salto.

Pero quizás, el principal problema que se abre en el eMail, es la capacidad de poder crear un eMail desde el remitente que se quiera y poder enviarlo al destinatario que se quiera, es decir, la posibilidad de suplantar la identidad del remitente. Uno podría pensar que para que eso fuese posible se tendría que poder hackear/acceder a la cuenta de un usuario para poder enviarlo desde su cuenta, pero nada mas lejos. Sí, necesitaríamos acceder a la cuenta de un usuario para poder enviar un correo desde dicha cuenta DESDE EL MTA DE SU PROVEEDOR, pero… y si nos saltamos los pasos 1, 2 y 3 de la primera imagen?? Podemos consultar directamente el servidor de correo de cualquier dominio, es algo público, y podemos conectarnos a él directamente para dejar en su bandeja de entrada el correo que queramos, usando de remitente lo que nos de la gana. Y sí, es así de sencillo, tal y como suena. No hace falta decir la importancia de esto, de poder suplantar la identidad de un correo… es decir, poder mandar un correo a quien queramos haciéndonos pasar por cualquier otro..

Debido precisamente a esto, empezó una larga guerra contra el SPAM y el fraude, y se empezaron a crear mecanismos para combatir esto, lo que al final nos llevará a DMARC. Sí, es importante que la comunicación sea segura, pero cuando tenemos encima de la mesa la posibilidad de poder engañar a quien queramos, todo se centró en ello. Recordemos que hace ya tiempo escribí un artículo precisamente hablando de todo esto, de la suplantación del eMail que podemos ver AQUI. Así que hoy veremos precisamente lo contrario, como evitarlo en la medida de lo posible. Para ello vamos a ver las “armas” más habituales de las que disponemos:

  • “Filtro” IP del origen: Listas negras/grises/blancas
  • SPF
  • DKIM
  • DMARC

Antes de seguir, todo lo que veremos a continuación es interesante sobre todo desde el punto de vista de proveedores de correo de nuestros propios dominios. Es aplicable igualmente a los proveedores “públicos” como Gmail, Hotmail… pero estos sistemas son configurados y gestionados por ellos, con lo que usen o no SPF, DKIM, DMARC… no podremos hacer nada, no es algo que podamos habilitar o deshabilitar. Eso sí, recomiendo en este caso usar proveedores que realmente se tomen la seguridad en serio y apliquen los máximos estándares de seguridad.

 

Listas Negras/Blancas/Grises en función del Origen de la IP

Estas listas se llevan usando desde hace ya muchísimos años, y prácticamente todos los proveedores conocidos las usan de un modo u otro. No obstante, aun existen muchos correos empresariales o “domésticos” que carecen de ellas, y aun así, su utilidad como veremos es relativa.

La idea es muy simple… si en teoría cualquiera puede conectarse al MTA de cualquier dominio, vamos a configurar esos MTA para que sólo acepten conexiones desde IPs que ellos consideran legítimas. El problema es que Internet es dinámico, y que no puedes crear una lista blanca rigurosa, porque a fin de cuentas Internet también es “abierto” y cualquiera podría legítimamente querer enviar un correo desde su propio servidor a otra dirección. Así que estas listas se sostienen un poco siempre por pelos, aplicando reglas muy generalistas.

Por ejemplo, casi siempre se impide el entregar un mensaje a cualquier IP que en una de sus listas esté identificada como “dinámica”, pues se supone que si es una IP dinámica debe de ser un usuario malicioso desde su conexión el que quiere entregar el mensaje, y no un MTA legítimo. Otra norma habitual es meter en listas blancas los MTA mas conocidos de los proveedores de correo para asegurarse que estos no se filtren nunca, o meter en lista negra aquellas IPs o rangos IPs que se conocen que proceden de servidores con una fama bastante importante en el uso de SPAM y otros.

Pero como digo estas listas son de todo menos fiables, tal es el caso que por lo general puedes acceder a las web donde las gestionan para indicar falsos positivos, o registrar tu propia IP en caso de ser legítima, o que un rango que antes era sospechoso ahora es válido, o al contrario… Además estas listas no evitan el uso de conexiones Proxy desde otros lugares, es decir, un atacante podría estar realizando la conexión usando un tunel o un proxy o cualquier otra técnica desde servidores o redes que no estén filtradas, y creerme… no suele ser nada complicado encontrar una red o host que puda evadir estas listas.

Un ejemplo de estas listas son las que proporciona Spamhaus, pero hay muchas otras. Estas se implementan a nivel del MTA, comprueba la IP de la conexión que se está realizando y la cruza. Si esa IP intenta entregar un mensaje en dicho MTA y está en una de sus listas negras, denegará directamente la entrega. El mensaje no es que termine en SPAM, es que no atravesará siquiera el MTA de destino. Es un modo muy eficaz de filtrar, pero por desgracia no es muy efectivo cuando uno sabe bien lo que está haciendo. .

Además, este sistema tiene otro problema añadido… un usuario podría estar usando un proveedor de correo legítimo, y usar una conexión SMTP a su proveedor para colocar el mensaje en otro MTA modificando el remitente del correo. Este tipo de correos pasarían completamente este filtrado basado en listas, ya que la IP de origen sería la del MTA legítimo.

 

SPF

LLegamos a la primera gran parte de este artículo.

Pese a que la mayoría ni siquiera sabrá que existe, gracias a SPF me atrevería a decir que más del 80% de los correos SPAM y fraudulentos, acaban precisamente en las bandejas de SPAM, y no penetran a nuestras bandejas de entrada. Se creó como sistema de defensa ante precisamente los intentos de suplantación de correos. Por supuesto tiene sus puntos débiles y SPF no nos protege de todo, pero respecto a aquello para lo que fue diseñado, desempeña su papel muy bien.

Al contrario de como sucedía en el sistema de listas, SPF requiere de cierta configuración/preparación no sólo por parte del MTA de destino, que debe como es natural ser compatible con esta tecnología y poder tomar decisiones en función de SPF, sino que además el dominio del remitente del eMail debe de estar configurado y preparado para ello. Es necesario así un trabajo conjunto de las dos partes. El resultado en cambio es sorprendente. Aquí no se protege realmente a las cuentas de destino propiamente dicho, sino lo que se intenta es que a las cuentas de los destinatarios no lleguen correos que suplantan la identidad de otros dominios, con lo que realmente se está protegiendo a los dominios que quieren usar para suplantar.

Con las listas teníamos el problema de no saber nunca bien si la IP de quien enviaba el correo era legítima o no… SPF viene a solucionar este problema de raíz. Básicamente de lo que se trata es de configurar el servidor DNS del dominio de origen de los correos para indicar precisamente desde que direcciones IP/dominios se permiten enviar dichos correos. Esto puede sonar un poco lioso, pero es muy simple, veamos un ejemplo sencillo:

Sin SPF:

Digamos que Pedro, cuya dirección de correo es pedro@pedrito.com, usa Paypal para realizar compras, algo muy habitual a día de hoy. Bien, pues un atacante quiere intentar engañar a Pedro, y para ello quiere enviar un correo a Pedro haciéndose pasar por Paypal. Es muy facil, saca la dirección del MTA de pedrito.com con una consulta a su registro MX, y se conecta directamente al MTA para redactar su mensaje, y escribe lo siguiente:

mail from: Servicios Paypal <servicio@paypal.es>
rcpt to: Pedro <pedro@pedrito.com>
data

from: Servicios Paypal <servicio@paypal.es>
to: Pedro <pedro@pedrito.com>
subject: Verificación de contraseña

Por favor verifique su contraseña en el siguiente enlace, bla bla bla
.

Aun cuando el MTA de Pedro usase listas, si el atacante es listo habrá sabido como evitarlas, así que a todos los efectos el correo parece legítimo, a fin de cuentas cuando Paypal manda un correo legítimo a Pedro puede ser de echo exactamente igual. El correo podría entrar en la bandeja de entrada perfectamente, y Pedro hacer caso de lo que dice el correo, a fin de cuenta el remitente está claro que es Paypal.

Con SPF:

Supongamos el mismo caso, pero en esta ocasión el dominio paypal.es tiene configurado SPF. Evidentemente es igualmente importante que el MTA de Pedro sea compatible con SPF. Bien, Paypal que sabe la importancia y lo que le interesa de que nadie suplante sus correos, hace una pequeña modificación en su servidor DNS, y establece que sólo las IPs 100.100.100.0/24 (por poner un ejemplo) tienen autorización para mandar mensajes.

El atacante escribiría lo mismo y enviaría el mensaje, y se frotaría las manos pensando que lo ha triunfado. No obstante una vez enviado, el MTA que usa SPF, realiza la rutina pertinente. Lee el realm del remitente y anota la IP de este, en este caso paypal.es y pongamos que la IP del atacante fuese 1.1.1.1. Conecta a su servidor DNS (al de paypal.es) y busca a ver si existe un registro TXT que identifique como un registro SPF. Lo encuentra, y obtiene que sólo el rango IP 100.100.100.0/24 tiene autoridad para enviar correos con ese dominio. El MTA compara las dos IPs, ve que la IP del atacante no está dentro de las que el servidor DNS le ha dicho. Paypal indicaba una política estricta SPF (aparece en el mismo registro DNS), así que como no se cumple el criterio establecido, el MTA manda sin pensarlo el correo a la bandeja de SPAM de Pedro, y marca el mensaje con un FAIL en SPF.

 

Gracias a SPF los administradores de los dominios pueden garantizar, hasta cierto punto, que los correos que dicen ser de ellos, sean realmente de ellos, y que de lo contrario sean tratados como SPAM, o sometidos a un escrutinio mayor. La ventaja de SPF es que requiere de muy poco para cualquier dominio implementarlo, no requiere una configuración especial en su MTA, sólo requiere el poder añadir un registro TXT en su servidor DNS. La otra mitad será tarea del MTA de destino, que por cierto a día de hoy la inmensa mayoría usan

Como se hace?? Los registros DNS SPF son sencillos. Lo que necesitamos es crear un registro TXT con el siguiente formato:

"v=spf1 [IP/Dominios permitidos] [Politica a aplicar si no está en permitidos]"

Por ejemplo, si el correo de nuestro dominio está gestionado por Google Apps y queremos añadir como protección SPF, tendremos que crear un registro SPF que permita el envío de los correos por los servidores de Google Apps. Google nos dice que ellos aúnan todos sus rangos bajo el dominio _spf.google.com, así que si añadimos dicho dominio a nuestro registro SPF, realmente estaríamos añadiendo todos los rangos IP que existiesen en el registro SPF de dicho dominio. Pero esto sólo no sirve, con eso tendremos las direcciones que están permitidas, así que hay que decidir que se quiere hacer con aquellas que no cumplen dicho criterio

“v=spf1 include:_spf.google.com ip4:100.100.100.0/24 ~all”

“include:_spf.google.com” indica a otros MTA que reciban un correo de su dominio, que lo acepten si el origen de él está dentro de los registros SPF de _spf.google.com

“ip4:100.100.100.0/24” a lo anterior, se suma a aquellos correos cuyo origen se encuentre entro de ese rango IP

“~all” indica al MTA de destino que hacer con esos correos que lleguen de parte de su dominio en caso de no coincidir con alguna IP anterior. En este caso la tilde expresa un softfail, un fallo, pero no “radical”, a modo que el MTA destino lo tenga en cuenta a la hora de decidir si lo manda a SPAM o no. Si se usase un signo menos, sería un FAIL estricto. Por lo general suele ser más seguro un softfail, por si las políticas del MTA de destino son muy estrictas y eliminan directamente el correo, a fin de cuenta el administrador del dominio de origen podría a ver olvidado alguna IP o malconfigurado el registro SPF. También se podría usar el signo + para identificar un PASS o un ? para indicar un “Neutral”.

El MTA, en función de la política indicada por el dominio marcará dicho correo como Pass, Neutral, Softfail, Fail… y en función de dicho “marcado” actuará de un modo u otro, ya sea entregando el correo en la bandeja de entrada por creerlo legítimo, marcarlo como SPAM, simplemente ignorar SPF y usar otros modos AntiSPAM…

La mayoría de proveedores de correo usan SPF para aplicar diferentes políticas de SPAM. Por lo general cualquiera puede comprobar esto, sólo tiene que mirar la cabecera de cualquier correo que le llega. Tomemos por ejemplo uno de Paypal, y encontramos lo siguiente en su cabecera:

Received-SPF: pass (google.com: domain of servicio@paypal.es designates 173.0.84.226 as permitted sender) client-ip=173.0.84.226;

Es decir, Google ha marcado como Pass dicho correo, puesto que la IP del emisor, 173.0.84.226, dice estar dentro de las permitidas por el dominio origen, Paypal.es. Si mirásemos el registro TXT de Paypal, nos encontraríamos con un registro SPF donde se encontraría incluida dicha IP. Es decir, dicho correo ha sido enviado por un equipo que tiene permitido enviar correos en nombre de paypal.es, Google lo reconoce y lo trata como un correo legítimo.

SPF funciona francamente bien, no obstante no soluciona algunos otros problemas. Por ejemplo SPF no puede garantizar la integridad del mensaje, y basa “solo” su legitimidad en el origen de la IP, que como siempre puede ser relativo. Con esto en mente nació DKIM

 

DKIM

DKIM no viene a sustituir SPF, sino más bien a complementarlo, aplicando una capa de seguridad diferente. DKIM lo que realiza es básicamente un firmado digital del correo que se envía, de modo que el MTA de destino puede verificar su autenticidad leyendo la firma DKIM incluida en la cabecera del correo. Además, no solo puede verificar el dominio emisor, sino también si el mensaje ha sido modificado en lo más mínimo, ya que aunque se modificase una sola coma, la firma se invalidaría, con lo que también garantiza su integridad.

DKIM hace uso de infraestructura de clave pública (cifrado simétrico) para realizar el firmado. Debido a esto, por desgracia, no sólo nos vale con añadir una entrada en el servidor DNS, como hacíamos con SPF, sino que nuestro MTA debe de permitir DKIM, puesto que deberá de firmar todos los correos que enviemos con él. Si nuestro MTA no permite DKIM no podremos hacer uso de esta tecnología.

Como cualquier infraestructura de clave pública, para que funcione el sistema se requiere de una clave publica y una privada. En este caso nuestro MTA generará ambas, guardará de forma segura la clave privada y nos dará a nosotros la clave pública para que la pongamos en el servidor DNS a modo de registro TXT. La idea es simple… el MTA firmará con la clave privada todos los mensajes que enviemos, de tal forma que tan solo la clave pública asociada a nuestra clave privada podrá verificar la firma. Esto requiere que los MTA de destino puedan tener acceso a nuestra clave pública, así que esta es “publicada” en nuestro servidor DNS, a modo similar que se hacía con SPF.

Como toda firma digital, esta no solo verifica que el emisor del correo es efectivamente quien dice ser, sino que si en cualquier momento existe cualquier modificación del mensaje, la firma quedaría rota, con lo que el cliente podría darse cuenta.

Por supuesto tiene sus defectos, de ahí que lo ideal sea combinarlo junto a SPF. Por ejemplo, alguien podría interceptar el mensaje, modificarlo, cambiar el dominio de origen de la firma y volver a firmarlo con una clave privada propia. El MTA de destino podría ver que la firma proviene efectivamente de donde dice venir y la verificaría con su clave privada, mientras que el remitente seguiría siendo el del origen. Pero si se está aplicando al mismo tiempo SPF, este no daría por válido el origen de dicho correo, pues pertenecería a otra IP de las permitidas (a menos que dicha IP se recogiese también en SPF)

En este caso, no se usa DKIM tan extensamente como SPF para clasificar el correo como SPAM, pero sí para crear dominios de… “confianza”. Los MTA ponderan muchas variables a la hora de determinar si un correo es SPAM o no, ó peor incluso, si es un Phising/Scam. DKIM es el modo que tenemos de decir: Ei, este dominio es mío realmente y todos mis correos que voy a enviar van a ir firmados. Eso crea una cadena de confianza, y garantiza en la medida de lo posible que nuestro dominio no sea objeto de suplantaciones.

Como se configura un dominio para usar DKIM?? Bueno, como he dicho son dos partes. En primer lugar se debería de poder configurar el MTA para firmar los correos con DKIM. No todos los proveedores lo permiten, aunque la mayoría de ellos (al menos los más importantes) sí. Tomemos por ejemplo Google Apps, una vez configurado un dominio allí podremos instruir a Gmail para firmar los correos que enviemos desde nuestro dominio. El primer paso por tanto es iniciar la autentificación para dicho dominio que realmente lo que hará será crear las claves públicas y privadas, mostrándonos la clave pública que deberemos añadir a nuestro dominio en forma de registro TXT. Con dicha clave pública, tan solo tendremos que crear un registro TXT asociado a un selector concreto. Por normativa, DKIM almacena en el servidor DNS la entrada TXT bajo el subdominio asociado a dicho selector con el siguiente formato: selector._domainkey.midominio.es.

En “selector” podremos por lo general poner lo que deseemos, incluso podemos usar diferentes selectores, pero el resto es invariante. Esto es así porque cuando nuestros correos se firmen el MTA de destino debe de conocer donde mirar para obtener la clave pública, y el único dato que se suministra en la firma es el selector. Es decir, si usamos en Google Appls como selector “google”, tal como estoy diciendo, la clave pública se podría consultar mirando los registros TXT del dominio en cuestión en google._domainkey.midominio.com. Hagamos la pruena… cojamos cualquier correo que nos hayan enviado desde Gmail y miremos su cabecera. Ahora busquemos en la cabecera la firma, puesto que por suerte y por seguridad todos los correos de gmail se firman, y nos encontramos con esta sección:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
        bh=nzLCaIESeBg8KtAGcaKCJbAggDVfBjZVSa6oLSVMOfU=;
        b=HBNSvMfDejs8TIHnh3vtDeXrtYuRKNivRUm4WMlBo7HWc7+ClZTVosOwheoajzuXZ8.. 

la d indica que dominio está firmando el correo, la s es el selector, la bh el hash del cuerpo del mensaje, la b la firma… Con esos datos, el MTA de destino puede acceder a la clave pública asociada a la clave privada que firmó el correo:

dig 20120113._domainkey.gmail.com txt

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;20120113._domainkey.gmail.com. IN      TXT

;; ANSWER SECTION:
20120113._domainkey.gmail.com. 299 IN   TXT     “k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87…”

Como digo, cualquiera puede hacer la prueba, y ver si los correos que le mandan usan DKIM o SPF, o ambos. Os sorprendería ver la cantidad de proveedores que incluso a día de hoy no usan estos sistemas. Esto toma aun importancia mayor en el mundo empresarial, por lo general usan proveedores o servicios de correo muy deficiente y con unos estándares de seguridad de risa. El uso de DKIM o de SPF debería de ser de obligado cumplimiento para cualquier administrador más o menos competente.

Por desgracia no siempre es viable DKIM. Mientras que por lo general SPF suele ser bastante simple de implementar y general pocos problemas (algunos sí), DKIM es más limitado. Muchas veces no sólo usamos nuestros MUA o el acceso web para enviar correos desde nuestro dominio, muchas veces hacemos uso de herramientas como PHP Mail() que suele ser raro que firmen los correos y además conocer bien el dominio de origen, o usamos forwarders de correo para enviarlos de un lado a otro con lo que no siempre se respeta las cabeceras  o a lo mejor una suite AV en el servidor del trabajo que analiza todos los correos al llegar y modifican su cuerpo indicando que ha pasado ciertos controles, rompiendo también DKIM. Y todo ello sin contar con la aun gran cantidad de servidores que no lo usan, ya sea porque no pueden configurarse para firmar los correos o ya sea porque cuando les llegan correos firmados no realizan ningún tipo de verificación.

 

DMARC

Por último, llegamos al némesis del SPAM y de la suplantación de correo. En realidad DMARC es más la unificación de SPF+DKIM trabajando juntos que una tecnología propia. SPF es muy efectivo para filtrar los correos ilegítimos, DKIM es un genio validando los correos y asegurando si integridad… los dos juntos pueden hacer muy complicada la labor al hacker de turno poder usar un dominio protegido correctamente con fines de SPAM o suplantación de identidad. DMARC no requiere de ambos modos, pude usar uno, el otro o ambos, a fin de cuenta como hemos dicho no siempre puede usarse SPF y no siempre puede usarse DKIM. Hay que entender que nosotros con nuestro dominio podemos enviar un correo desde el mediante infinidad de formas como se ha dicho… podríamos enviar un correo del modo tradicional por SMTP, podría enviarlo el servidor Web que tenemos para enviar notificaciones, podría ser usado nuestro dominio para usar listas de distribución usando servicios externos, o usar servcios de correo marketing como MailChimp para el envío masivo de correos, y todos ellos usarían direcciones de nuestro propio dominio!! Es decir, a veces algunos de los correos incluso que mandemos de forma legítima no seremos capaces de protegerlos mediante SPF y DKIM. DMARC pude ser suficientemente inteligente para entender estos pormenores.

Pero al margen de este baile entre SPF y DKIM, DMARC tiene algo que no tiene ninguno de los sistemas vistos hasta ahora. DMARC está preparado para que sí así lo configuramos, indicar al destinatario que si no es capaz de lograr un “pass” en DMARC, el correo lo tome por ilegítimo y LO ELIMINE. Es decir, no a SPAM, no a devolver, simplemente eliminación silenciosa de él. Os lo imagináis?? Si por un momento todos los proveedores de correo usasen correctamente DMARC y Paypal usase esta tecnología correctamente, cualquier que intentase falsificar un correo haciéndose pasar por paypal cuya dirección de correo fuese loquesea@paypal.es, jamás llegaría a su destino, el dominio de Paypal quedaría prácticamente blindado y nadie podría usarlo de forma ilícita. Sí, podría usar otro correo parecido, pero no el mismo dominio.

Otra característica especial de DMARC que lo hace único, es que se diseñó de tal modo que los MTA de destino compatibles con DMARC generan reportes diarios que envían al origen del dominio indicando datos valiosísimos, como por ejemplo la cantidad de emails que ha llegado a sus puertas usando dicho dominio, cuantos lograron pasar DMARC y si pasaron SPF o DKIM o ambos… y todo esto es de forma casi automática, el MTA de destino cuando lee un correo con DMARC (y si es compatible con él), además de leer los datos SPF  y DKIM también accede al servidor DNS para recuperar los datos relativos a DMARC, y de allí saca la política a aplicar y como tratar DKIM y SPF de dicho correo, y por supuesto la dirección de correo a la que enviar los reportes diarios. Nada se escapa a DMARC.

Como de útil es esto de los reportes?? Esencial. Los MTA de destino no tienen por qué ser compatibles con DMARC y por tanto generar reportes, pero si tenemos en cuenta que la mayoría de cuentas a día de hoy son correos tipo Gmail, Hotmail, Yahoo… y que todos ellos lo hacen, podemos tener una visión bastante buena de si se están usando nuestros dominios para fines de suplantación o no. Si a esto le sumamos que existen herramientas que nos permiten centralizar todo esto y ordenar y analizar nuestros reportes, el resultado es más que interesante. A continuación algunas imágenes de unos cuantos dominios que tengo que usan DMARC (Y SPF/DKIM):

En primer lugar, para los que creen que eso de suplantar identidades es cosa del pasado y que nadie se centra en hacer estas cosas… esta primera imagen da una visión general, y viene a decirnos que sí, que es necesario usar este tipo de tecnologías:

Captura

Como vemos en la leyenda, en verde tendríamos aquellos correos que fueron enviados y el MTA de destino pudo dictaminar que pasaban DMARC, y por tanto eran legítimos. En un porcentaje pequeño lo que llamamos forwarders, por lo general son correos legítimos pero que son reenviados por diferentes hosts para fines diversos. Y por último en rojo aquellos que fueron enviado supuestamente en nombre de nuestros dominios, pero que al comprobarlos los MTA de destino dictaminaron que no podía pasar DMARC. En todos los casos esta información se extrae de los reportes generados por los MTA de destino, y aunque en dichos reportes no se indica como es natural destinatarios o cuerpos de mensajes o… si se indica las direcciones IP de origen, entre otras cosas, con lo que podemos ver también que host/dominio está enviándolos. Como vemos, en estos 7 días de intervalo seleccionado, yo diría que un 40% han sido correos no legítimos. Dado que ninguno de mis dominios usa actualmente una política DMARC de rechazo, esos correos posiblemente lleguen aun todos ellos a los destinos, aunque casi seguro siempre a la bandeja de SPAM. Con el tiempo, cuando cambie a una política más restrictiva, ninguno de esos correos llegará siquiera a los destinatarios.

En segundo lugar vemos realmente todos los correos que se han enviado clasificados según su origen, y a la derecha un dato interesante… todos ellos pasaron DMARC, pero no significa que todos pasasen simultaneamente SPF y DKIM. Dado que las reglas de mis dominios son “laxas” DMARC puede pasar cuando uno de ellos falla.

Captura2

Por ejemplo, vemos que los que se origina en Godaddy cumplen el 100% SPF, pero no se firman. En cambio con MailChimp pasa exactamente lo contrario, todos son firmados pero SPF no pude verificarse… esto sucede porque MailChimp usa varios dominios como origen, y aunque se pueden añadir las diferentes IPs, el dominio emitido por MailChimp no coincide con el usado en el remitente real, así que SPF falla.

Podemos ver algo similar con los Forwarders:

Captura3

Los Forwarders reenvían los correos, generalmente esto no es malo, lo que pasa es que no todos funcionan igual. Por ejemplo hay Forwarders que preservan la firma y no la alteran, mientras que otros alteran el cuerpo del mensaje de algún modo y rompen la firma.

Y para acabar, por supuesto, tenemos aquellos que quieren usar nuestros dominios como origen de correos fraudulentos:

Captura4

Y no, no son pocos.

 

Desde el punto de vista del administrador del dominio, no requiere nada para habilitarlo en su dominio, sólo crear la entrada TXT correspondiente en su servidor DNS, similar a como se ha realizado anteriormente. Eso sí, si el MTA de destino no es compatible con DMARC simplemente ignorará las directrices configuradas en el registro TXT del servidor de correo, y tampoco generará reportes.

Un ejemplo real de esto.. supongamos q pedro@pedrito.com usa DMARC, y manda un correo a lacasito@gmail.com. Gmail es compatible con SPF, DKIM y DMARC. Pedro firma su correo por DKIM y también usa SPF y DMARC. Cuando el correo llega a Gmail: a) Verifican que SPF es correcto como hemos comentado antes, y lo marca como superado (Pass). b) Verifica la firma y la integridad del correo como hemos dicho anteriormente, como es correcto de nuevo lo marca como superado (Pass). Por último, mira las políticas DMARC que hace Pedro, y lee algo como:

“v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com”

Dado que tanto SPF como DKIM han dado de resultado un superado (Pass), y no hay nada que impida en las políticas DMARC de pedrito que falle DMARC, DMARC se marcará igualmente como superado, y Google enviará un correo a reportes@pedrito.com al final del día con todos los correos que fueron enviados por direcciones de pedrito.com a sus servidores.

Pero que pasaría si DKIM o SPF fallan?? Bueno, aquí depende de como se configuren las políticas. Por defecto, son relajadas, si fallase alguna de las dos por lo general DMARC seguiría siendo superado, aunque como digo esto puede configurarse. Y que pasa si DMARC falla?? Si falla se aplica la política que hay en el registro DNS. En el caos anterior aplica la política “reject”, es decir… si DMARC falla el MTA de destino debe de borrar el correo, rechazarlo. Se podría usar none, y simplemente DMARC no haría “nada”. Esto es muy útil sobre todo al principio de implementar DMARC, a fin de cuenta si de primeras decimos que se rechacen, posiblemente perderíamos muchos correos legítimos por una mala configuración de DKIM/SPF o de alguno de nuestros servicios. Es práctica común usar “none” durante un tiempo de meses, comprobar que funciona todo bien, y pasar poco a poco a rechazarlos.

El formato a usar en el servidor DNS es similar a los anteriores, aunque en este caso de nuevo por normativa se usa el subdominio _demarc. Es decir, que la entrada DNS irá ubicada en _dmarc.midominio.es. Hemos visto arriba como sería, en su versión más simple:

“v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com”

Donde p es la política y rua la dirección de correo para los reportes.

Cualquiera que mire la cabecera de un correo que le ha llegado, pude igualmente ver si su MTA verifica de algún modo estas tecnologías. Por ejemplo si miramos un correo entrante de una cuenta de google.coml, vemos algo así (aunque sería similar en las de GMAIL)

Authentication-Results: mx.google.com;
       dkim=pass header.i=@google.com;
       spf=pass (google.com: domain of ...;
       dmarc=pass (p=REJECT dis=NONE) header.from=google.com

Vemos que Google, en los correos de sus dominios si fuerza una política de Reject. Esto hace que si alguien intenta usar su dominio para falsificar una dirección de correo en su remitente, el MTA de destino si es compatible con DMARC lo eliminará instantáneamente. Vemos igualmente que ese correo ha logrado pasar DKIM, SPF y por tanto DMARC


 

Conclusiones

De verdad aun hay quien cree que no necesita saber nada sobre SPF/DKIM/DMARC?? Está claro que para los usuarios que usen correos ordinarios tipo gmail, hotmail y otros no es tan importante, además ellos no pueden configurar nada, solo tener la esperanza que sus proveedores usen los mejores estándares de seguridad. En este caso Gmail posiblemente es pionero, mientras que Hotmail por ejemplo no los firma y bla bla bla. Pero para el resto de usuarios que usan cuentas personalizadas, o empresariales, o de cualquier otro tipo, es aun más importante usar estas tecnologías. A fin de cuentas, al final, cualquier usuario puede crear una cuenta de gmail o hotmail para enviar o intentar enviar correo falsificado a otra cuenta con el mismo dominio, pero nadie puede crear cuentas de un dominio propio. Además, es evidente que es mucho más… jugoso para los hackers/spammers y otros atacar cuentas personales/profesionales independientes, sobre todo a la hoar de intentar suplantar la identidad de alguien.

Router Mitrastar HGW-2501GN-R2: Shell e Ingeniería inversa (para crear firmwares modificadas, por ejemplo) (Actualizado)

mitrastar
Introducción

La historia es sencilla. Aunque en la medida de lo posible siempre uso mis propios dispositivos, me gusta igualmente exprimir cualquier otro chisme que tenga por casa. Unos fuman… yo cacharreo.

En este caso, este fue el router que me entregó el ISP para mi conexión de Fibra, Mitrastar HGW-2501GN-R2. Duró conectado a la línea el tiempo de irse el instalador, pero lo saqué recientemente del “trastero” al ver por los foros de soporte oficiales (y no oficiales) que estaba dando un sin fin de problemas a los usuarios. Como siempre he dicho, opinar podemos hacerlo todos, pero si queremos dar soluciones que sean lo más acertadas posibles, es mejor comprobar las cosas por uno mismo y poder estudiarlas como dios manda. Así que le saqué el polvo y me puse a desentrañar sus más y sus menos.

Un dispositivo es bueno o malo sencillamente a razón de dos cuestiones sencillas, y es lo bueno o malo que sea su hardware y su software. Si el hardware es “malo” las ataduras de manos siempre son mucho peores, porque salvo modificaciones directamente en el hardware poco podemos hacer. Un hardware bueno tampoco hace del dispositivo algo bueno, es fundamental el Software, y sobre el software podemos decir lo mismo.

En el caso del Mitrastar, tenemos un poco de todo. Respecto al hardware no es ni mucho menos de lo peor que podemos encontrarnos en un router como muchos puedan pensar, pero eso no quiere decir que no se hubiese podido mejorar sustancial, sobre todo lo referente a su interfaz wifi. Eso no podemos cambiarlo, tenemos que aguantarnos con lo que hay. No he conectado aun el router por puerto de serie ni lo he sacado de su carcasa, así que los siguientes datos pueden no ser exactos del todo. Por lo que podemos saber el hardware se compone de una arquitectura MIPS:

CPU1: Ralink RT63368F (En Placa)/RT63365 (En Software)
Switch: Realtek RTL8368MB
Wl0: Ralink RT5392
RAM: 128MB
Flash: 64MB

El Switch debe de contar con unos 7 puertos diferentes, apoyado principalmente por el SOC RT63365. El adaptador inalámbrico dista mucho de ser una maravilla, nos encontramos ante un disposotivo 802.11n de dos streams unibanda. Por otro lado contamos con una cantidad más que suficiente de RAM y Flash para todo, lo cual siempre se agradece el no ir siempre bajo mínimos.

El principal problema que se ha tenido es que el software del router (la firmware) ha estado lejos de ser aceptable, salvaguardando por supuesto las propias limitaciones del hardware. Entre las quejas más frecuentes han sido los enormes problemas de batería causados por el router a dispositivos portátiles, la interfaz web de configuración con constantes problemas… En un mundo ideal, como se trata de Software, en el peor de los casos podríamos decir: “Pues si no quieren hacer ellos su trabajo, al menos voy a ver si puedo yo mejorar o corregir alguno de esos problemas de software”. Pero nunca suele ser tan sencillo, las firmwares y los sistemas se protegen precisamente para impedir cualquier tipo de modificaciones al software, siguen sin entender que cuanto más abierto sea un software más probabilidad hay que funcione mejor y con menos fallos/problemas.

 

Acceso Básico

Manos a la obra, partamos desde cero. Instalamos el router, lo tenemos todo funcionando… ¿ahora que?. Aquí entra en juego el primer escollo, y la culpa de esto la tiene principalmente los ISP, nada que ver con los fabricantes del hardware o el software que se instala (por lo general). Los dispositivos que nos entregan actualmente (No solo Movistar) vienen precargados con una configuración básica por defecto con los ajustes básicos de la compaña, como puedan ser los SSID, ajustes de WAN… ahora debido a los servicios avanzados como VoIP o IPTV suele ser necesario además de todo esto ajustes adicionales específicos para cada cliente, así que el router está preparado para conectar a los servidores de ellos después de un reset o cada X tiempo para reconfigurarse con los datos de la línea del cliente. Esto es perfecto porque evita configuraciones manuales uno a uno.

Lo primero que quiero o puede querer cualquiera es realizar pequeños ajustes a nuestro router, ya sea abrir un puerto, configurar una IP diferente… eso lo hacemos como toda la vida de dios, lo más básico y sencillo: La interfaz web del Router. El problema aparece porque la mayoría de los ISP se preocupan y hacen TODO LO POSIBLE para que el usuario, el cliente, tenga acceso a cuantas menos funciones posible del router mejor. Esto se hace por lo general con la creación de usuarios con permisos mucho más restrictivos a los usuarios tipo admin/root con acceso completo. Estos usuarios que crean tienen al final acceso para modificar 3 parámetros y medio y no poder consultar muchas otras configuraciones que pueden ser de interés, con lo que nos limita enormemente, incluso a usuarios con un perfil básico. Esto es algo que la mayoría no toma en cuenta cuando contrata un ISP u otro, pero para mí es esencial y marca mucho el tipo de compañía que tienes delante. Muchos de los amigos que me leen saben mi opinión sobre Apple, y se resumen sencillamente en que no permito que una compañía me diga que puedo hacer o no hacer con mi hardware.

Dependiendo del dispositivo que tengamos instalado y dependiendo del ISP, podremos acceder de mejor modo o no la configuración de nuestro router. En el caso concreto del Mitrastar, tengo que decir sinceramente que chapó por Movistar, ha hecho lo que tenía que haber echo hace tiempo y hacer TODOS. El Mitrastar, como viene siendo ya costumbre desde hace tiempo en los dispositivos de Movistar tiene dos interfaces web, una sencilla para usuarios nóveles que quieren cambiar 3 cosas (llamada Movistar Home Station, aka mhs, y una avanzada. El Mitrastar posee 3 usuarios (en realidad son 4, pero el usuario samba lo obviamos), cada uno con permisos diferentes enfocados a necesidades diferentes:

-“admin”: La contraseña de este usuario podemos encontrarla debajo del router en una pegatina. Este usuario y contraseña nos da acceso a las dos interfaces del router. Es el acceso normal a la interfaz mhs, y si accedemos a la avanzada a través de mhs (o a través de la dirección http://IP/cgi-bin/main.html) nos encontraremos con limitaciones en cuanto que podemos modificar. Esta cuenta por otro lado carece de acceso por terminal (SSH/Telnet…)

-“1234”: La contraseña coincide con la contraseña anterior, y en este caso sería lo más similar a un usuario root. Tiene acceso completo a las opciones de configuración de la interfaz, y es la cuenta que usa el portal Alejandra igualmente para configurar de forma remota nuestros dispositivos (si los tenemos asociados al portal).

-“supervisor”: La contraseña en este caso es siempre la misma, zyad1234, y posee permisos similares al usuario 1234, con el añadido de que con este usuario se tiene acceso por la interfaz web a poder modificar los permisos de los otros usuarios y de sus contraseñas igualmente.

mhs
web

Ahora entenderéis porqué digo que en este caso chapó por Movistar. Cualquiera puede tener acceso completo (al menos por web) al Mitrastar, sin hacer cosas extrañas, sin tener que pelearse, sin acudir a… dicho de otro modo, los técnicos de Movistar no tienen un mejor acceso que nosotros. Gracias a estos usuarios podremos no sólo consultar la mayoría de todas las configuraciones del router, sino que también ajustarlas a nuestro antojo.

Por otro lado, lo primero que se le ocurre a cualquiera es ver como son los archivos de configuración (backup) del router, así que como primer paso para entender un poco todo lo que cualquiera haría sería descargar dicho archivo desde mantenimiento, quizás sea legible o haya algo o algún ajuste que pueda ser de interés. El archivo de configuración del Mitrastar, por suerte, no está cifrado y parece ser un xml totalmente legible, pero que algunas opciones curiosamente las enmascara, todas aquellas donde hay contraseñas. Por qué es esto interesante?? Bueno, yo he dicho que la contraseña de admin y 1234 es la misma, pero a veces no es tan sencillo como prueba/error, o mejor dicho… a veces es más sencillo no tener que estar probando… pero como vemos el archivo de configuración no permite ver estos datos. En cualquier caso, vemos que estos campos llamados “encrypted” comienzan todos por: “41455300”, casualidad que 41 45 53 = AES, lo cual nos daría a pensar que el resto es posible que sea el texto codificado en AES.

 

Acceso Limitado por Terminal

El 99% de las veces nos sobra la interfaz web, pero que pasa cuando nos gustaría poder modifica o consultar cualquier cosilla que no esté presente o tengamos acceso por la interfaz web?? A fin de cuenta presuponemos que nuestro router estará corriendo algún tipo de Linux debajo de él. Para eso es indispensable acceso mediante SSH o Telnet. El problema es que como aplican la mayoría de fabricantes, para negarnos la posibilidad de toquetear las tripas, lo que nos dan es acceso es a una shell limitada… muy limitada. Así, en el caso del Mitrastar si intentamos acceder mediante supervisor o 1234, nos encontramos ante un panorama… “triste”:

ssh

Así pues podemos acceder con las credenciales por defecto, pero los únicos comandos que nos muestra la interfaz como válidos son: ?, exit, save, sys, restoredefault, lan, igmp, wlan, nat. La mayoría de todos ellos tienen subcategorías. No hay nada interesante a priori que podamos hacer desde la shell que no podamos hacer desde la interfaz web. Dos comandos “al azar” muestran dos resultados interesante: mtd y sh, ninguno de los dos listados en los comandos disponibles. El primero nos devuelve que el comando está prohibido, el segundo directamente que introduzcamos una contraseña… ¿quizás existe una contraseña para poder acceder a la shell que hay debajo? Por descontado ninguna de las contraseñas que disponemos es aceptada como válida.

Algo relativamente común a las shell limitadas es que permiten realizar copias de la configuración. A priori podríamos pensar que esos “dump” son iguales que los que podemos obtener desde la interfaz web, pero… que pasa si introducimos por shell limitada “sys dumpcfg”?? Sí, nos devuelve en la consola exactamente el archivo de configuración que pudimos descargar con anterioridad… pero con una salvedad, en esta ocasión los campos de contraseña están en texto plano. Bingo!!

username=”supervisor” web_passwd=”zyad1234″ console_passwd=”zyad1234″

La contraseña es la misma, pero en cambio en el archivo de configuración cifrado vemos que el “resultado” es diferente. Asumimos que además de poder estar cifrado con AES usa algún tipo de SALT, y no sólo una key cualquiera. Aun así esto tampoco nos abre la puerta a mucho más, esta contraseña es de hace mucho conocida y compartida en muchos productos.

 

Acceso a la Shell que hay debajo

Lo que nos interesa es acceder detrás de la shell limitada a la que tenemos acceso. Parece que para esto existe directamente un medio para hacerlo, a través del comando “sh” desde la shell limitada, pero esto nos solicita una contraseña que es totalmente desconocida para nosotros. Aquí empieza realmente el trabajo duro, ingeniárselas de algún modo para poder acceder debajo, aunque sólo sea una vez, y poder echar un vistazo desde una shell completa. No voy a detallar, por cuestiones de seguridad, como logré ese primer acceso, pero sí de que se trata.

Presuponemos que tenemos Linux debajo, con lo que realmente lo primero que desearíamos sería echarle un ojo al archivo /etc/passwd y/o /etc/shadow. Estos dos archivos, en linux, son los que contienen las credenciales de los usuarios y sus contraseñas (cifradas claro está). Pero además contienen la shell que será ejecutada a cada usuario. Es posible que el router posea otro usuario/contraseña que desconocemos o a saber…

Pongamos que gracias a la interfaz web logramos ejecutar de algún modo algún comando dentro de la shell y sacar los datos por el navegador. “cat /etc/shadow” cat /etc/passwd” sería sin duda alguna las primeras pruebas, y pongamos que en un momento dado la interfaz web nos devuelve lo deseado, nada para shadow, y para passwd:

1234:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
admin:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/sh
supervisor:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
samba:$1$$xxxxxxxxxxxxxxxxxxxx:500:500:Linux User,,,:/home/samba:/bin/sh

Bingo!! (de nuevo). Parece ser que además de existir un cuarto usuario, samba, el usuario 1234 y el usuario supervisor (que son los dos únicos que tienen acceso por shell) ejecutan una shell extraña llamada “cmdsh”. Sea como sea, si logramos ejecutar con suerte cat, podríamos igualmente intentar sobrescribir el contenido del archivo, igual no existe una protección contra escritura… como dicen, probar no cuesta nada… usando incluso de nuevo cat, se puede enviar el mismo archivo pero modificando la shell a ejecutar, en vez de /bin/cmdsh, /bin/sh. Lanzamos la petición, volvemos a lanzar otra para ver el contenido y… se ha modificado!!. Ejecutemos de nuevo una sesión Telnet/SSH, usuario 1234 (es al usuario que le cambie la Shell), su contraseña… y efectivamente no más shell limitada:

login as: 1234
1234@192.168.1.1’s password:
# ls
bin      boaroot  dev      etc      lib      linuxrc  proc     sbin     sys      tmp      userfs   usr      var
# uname -a
Linux MitraStar 2.6.36 #1 SMP Thu Aug 13 14:04:19 CST 2015 mips unknown
#

 Llegados a este punto ya lo tendríamos todo?? Sí y no. Esto habría que repetirlo siempre, porque si reiniciásemos el router veríamos que el cambio que habíamos realizado al archivo passwd se perdería, teniendo que repetir todo el proceso constantemente. Aun así al menos ya habríamos logrado acceder a la Shell de debajo con plenos permisos administrativos. ¿Podemos mejorar esto? Por supuesto.

Lo primero que viene a la cabeza es: Bien, puedo acceder gracias un exploit, pero parece ser que la shell cmdsh tenía un comando “sh” que solicitaba una contraseña para acceder, y no hay que ser muy listo que lo que permite es acceder precisamente a una shell completa. ¿Donde puede estar esta contraseña? Personalmente el primer lugar donde miraría, teniendo en cuenta que no parece existir otros usuarios en el archivo /etc/passwd, es en el binario de la propia shell, o sino este sabrá de donde obtenerla, dado que es esta shell la que lo solicita. Ya sabemos donde está, así que sólo tenemos que extraerlo. Esto puede hacerse de mil y una forma, dependiendo de las herramientas que tengamos disponibles claro está en la firmware del router:

-ssh/sftp/ftp/scp
-curl/wget
-netcat/nc
-base64
-usb
-…

Cualquier sistema nos vale para enviar donde queramos el archivo en cuestión y poder manipularlo en condiciones, la elección de un sistema u otro dependerá de las utilidades que tenga la firmware y de lo sencillo o no que nos resulte a nosotros mover los archivos. Una vez tengamos el archivo, tan solo tendríamos que decompilarlo y echar un vistazo rápido. Vamos a lo sencillo, si cuando introducimos a través de sh una contraseña cualquiera recibimos: “Password incorrect !” Podemos empezar buscando por ahí, o mirar directamente las posibles funciones… eso nos lleva al siguiente trozo de código:

diss

Curiosamente, justo unas líneas de ahí encontramos una extraña cadena alfanumérica. Bueno, además de que el código en ensamblador es bastante legible, lo que está claro es que compara un string (lo que introducimos por teclado) con el string “c93vu02jp4z04“. Si la comparación es incorrecta, vemos que salta a la posición 0x00402408 (=contraseña incorrecta), mientras que salta a otra posición en caso de que la comparación sea acertada. Dicho y hecho, tan solo tenemos que verificar que ese string es realmente la contraseña para acceder a la shell completa desde la shell limitada. Y no hace falta decir que efectivamente esa es la contraseña de acceso a la Shell.

Llegados a este punto lo tenemos todo, hemos podido acceder gracias a un exploit, hemos podido extraer la contraseña que nos da acceso a la shell completa, con lo que podemos ya hacer con nuestro router lo que deseemos… ¡No tan rápido! ¿Seguro que ya tenemos total libertad?.

 

Acceso (y modificación) a la “nvram” – Autentificarse

Como vimos en la parte del exploit, y si empezamos a jugar con la shell interna, antes o después nos topamos con un problema bastante importante. Sí, podemos usar todas las utilidades de nuestro router, podemos añadir reglas a iptables, ver el estado de todo, controlarlo todo!! ¿Pero como podemos hacer para que los cambios que hagamos sean persistentes?

Vimos que si intentábamos modificar el archivo passwd este volvía de nuevo a su “ser” al reiniciar. Esto nos dice que al menos la raiz de la firmware está protegida contra escritura de algún modo, y de echo no hay que ser demasiado imaginativo para ir entendiendo que el sistema de archivo del router usa SquashFS, un sistema de archivos de sólo lectura que se monta en cada inicio. Ademeás, si miramos realmente la ubicación de la carpeta /etc tenemos esto:

# ls -la /etc
lrwxrwxrwx    1 1234     root            8 Aug 13  2015 etc -> /tmp/etc

La carpeta /etc desde la cual accedemos a /etc/passwd ni siquiera se encuentra en el sistema de archivos SquashFS, sino que el bootloader/kernel genera el archivo de algún modo en cada inicio, por eso pudimos modificarlo con el exploit entre otras cosas, está fuera de la “prisión” de SquashFS. Se genera en cada inicio, con lo que nuestros cambios se pierden. Pero sabemos que todo no es tan negro, porque en realidad debe de existir una zona o partición donde se puedan inscribir datos y estos sean persistente, o algún sistema para poder hacerlo, ya que a fin de cuenta podemos configurar el router a través de la interfaz web, y los datos son persistentes a cada reinicio. Si cambiamos por ejemplo la contraseña del usuario 1234 dicho archivo al iniciar será diferente al original y reflejará el cambio que hicimos por la interfaz Web. Quizás no podamos modificar el sistema de archivo raiz (lo haremos, pero más adelante), pero cuanto menos en teoría deberíamos de ser capaces de realizar cualquier cambio persistente que permita la interfaz web, y eso como mínimo, porque es de suponer que esté donde esté ese “espacio” contendrá quizás otros datos de interés.

Así es realmente como funcionan la mayoría de dispositivos. Los routers suelen tener una zona llamada nvram (RAM no volatil), que contiene parámetros que pueden ser leídos y almacenados con independencia del sistema de archivos. Esto es necesario para poder realizar configuraciones de cualquier tipo, pero incluso el propio router necesita este “espacio” para poder funcionar y configurarse a sí mismo. En muchos dispositivos es bien conocida la herramienta “nvram”, pero si lo intentamos veremos que aquí al menos no disponemos de una herramienta similar. Así que queda hacer un poco de detective y ver si disponemos de alguna utilidad que nos brinde algo similar.

Como podemos acceder a la shell podemos recorrer rápidamente los directorios donde sabemos que es más que posible que se encuentren: /bin, /sbin, /usr/bin… la mayoría de todas las utilidades podemos conocerlas los amantes de linux y muchas otras deducirlas. Otras en cambio podemos ir directamente probando a ver que pasa. Si no damos con la “tecla”, tenemos otro sistema sencillo para hacernos una idea… si la interfaz web cambia los ajustes, la interfaz web debe de saber o tener idea de como realizar esto. Antes o después llegaremos a la conclusión de que hay ciertos binarios que parecen ser los encargados de manejar todo esto, aquellos que empiezan por “tc” que es el acrónimo de TrendChip. Si nos movemos por las carpetas de la interfaz web (/boaroot) veríamos también rápidamente las referencias constantes a tcwebapi, y mira tu por donde tenemos un binario llamado: “tcapi”. Si lo invocamos:

# tcapi
set unset get show commit save read readAll staticGet

 Parece ser que hemos dado con la interfaz que interactúa con la nvram. Con un poco de paciencia y de estudio aprendemos a usar esta interfaz. tcapi funciona de un modo similar a nvram, con show podemos mostrar lo que deseemos (no existe un show all), pero tenemos que especificar que nodo queremos visualizar. Los nodos son precisamente las etiquetas xml que están dentro de nuestros archivos de configuración. Si miramos nuestro archivo de configuración veremos por ejemplo uno de los primeros nodos, “Wan”, así que “tcapi show Wan” nos devuelve efectivamente todo lo almacenado en ese nodo. Podemos pensar que esto no tiene demasiada utilidad ya que a fin de cuenta tenemos el archivo de configuración, pero no hay que ser muy listo para presuponer que el archivo de configuración es sólo una parte de todo. De echo podemos almacenar los valores que queramos en la nvram existan o no existan en el arcivo de configuración, o modificar cualquier otro.

Si alguien ha usado anteriormente nvram (la utilidad) sabrá que para que los cambios se apliquen hace falta realizar un “commit” y seguido de un “save” si se quiere que los cambios se guarden (aplicar no significa guardar, y viceversa). Aquí tenemos lo mismo. “tcapi save” guarda todos los cambios realizados en la nvram, mientras que “tcapi commig nodo” aplica los cambios efectuados al nodo citado. Cuidado!! Estamos modificando la nvram, si guardamos los cambios y estos han sido incorrectos podemos encontrarnos en que sea necesario resetear el router para que vuelva a sus ajustes por defecto.

Quien llegue a este punto se habrá dado cuenta que, de echo, aunque puede usar show, no puede realizar un save y peor aun, un set, devolverá lo mismo que sucedía cuando intentábamos teclear mtd. El acceso por alguna razón a ciertos comandos, incluso teniendo permisos administrativos y a la shell completos, siguen estando restringidos, hace falta algo más para desbloquear esto. Aquí tendríamos de nuevo que empezar a investigar donde buscar y encontrar esto. Podríamos empezar por cmdsh y encontraríamos referencias a un supuesto archivo llamado “/tmp/Authentication”. Antes o después (grep es un gran amigo), daríamos con el binario /usr/bin/syscmd. Si decompilamos y echamos un ojo llegaríamos pronto a una sección bastante interesante:

auth

Vemos demasiada información, pero todo de gran utilidad. Por un lado vemos que aparece de nuevo el archivo nombrado, pero esta vez precedido de un comando completo, y además curiosamente justo encima vemos un “Correct Key imput. Auth…”. Eso ya nos está diciendo que el sistema parece importarle más que el usuario esté “autentificado” ante ciertos comandos que cualquier otra cosa, y que parece que lo verifica seteando el archivo /tmp/Authentification con authenticated. Podríamos hacer la prueba: “echo authenticated > /tmp/Authentication” y veríamos que funcionan mágicamente a partir de este momento tcapi set/save y otros

Antes de irnos a otro lado, podemos ver igualmente en el trozo desensamblado de nuevo la contraseña de acceso a la Shell, y un “EncryptKey” y un “Account_Common”. Quien haya estado ya jugando con la nvram sabrá que en esta se separan los nodos de otros subnodos con guiones, así que por curiosidad si miramos la información del nodo “Account_Common” con tcapi:

# /userfs/bin/tcapi show Account_Common
EncryptKey=MSTC

El resultado es un string: MSTC, que según aparece en la nvram es un “EncryptKey”. Demasiado cerca del código que hace estar autentificado para no tener nada que ver. Si vemos desde la shell que podemos hacer con syscmd, vemos que existe curiosamente un comando que es authKey, y que efectivamente:

# syscmd authKey
Error!
# syscmd authKey MSTC
Correct key input. Authentication done.

Así que en realidad el proceso “real” implicaría autentificarse a través de syscmd con la EncryptKey almacenada en la nvram, MSTC, y eso a su vez produce que el sistema setee el archivo anteriormentes citado. Así que en realidad podríamos realizar la autentificación de cualquiera de las dos maneras: por lo “legal” y a lo “bruto”. Ahora sí, después de esto, podríamos usar algunos de los comandos más particulares (y también peligrosos), como puedan ser: sys memwl, sys memww, sys erase, sys romd, tcapi set, tcapi save…

La nvram permite acceder a todos los parámetros almacenados en nuestra configuración, y además acceder a otros parámetros que podrían ser interesantes, pero eso para otro día. Veamos mejor que más podemos hacer… podemos modificar la nvram, podemos ejecutar cualquier herramienta que tengamos dentro del router, ahora iremos un pasito más, esta vez como poder “modificar” lo que nos queda, el sistema de archivos, e incluso poder instalar/actualizar componentes en ella.

 

Ejecución de comandos desde el archivo de configuración (Nuevo)

Por azares de la vida, me topé días después con que resultaba relativamente sencillo realizar ejecución de código directamente desde el archivo de configuración del router, que no deja de ser gran parte de la nvram. El secreto reside en el nodo “Autoexec”, que si miramos en nuestro archivo tan sólo existe como cierre.

El cfg_manager, por suerte para nosotros, parsea el cfg en cada inicio para cargarlo a la nvram. Al llegar a dicho nodo, si no está vacío, pasa TODO lo que hay en él (sin el nombre de la entrada, sólo los valores de estas) a un archivo llamado autoexec.sh en /etc/, le da permisos de ejecución y acto seguido lo ejecuta. Dicho de otro modo, podemos añadir todo el código que queramos ahí, que será ejecutado al inicio en el Router. Evidentemente de saber esto anteriormente, el proceso de acceso inicial al router hubiese sido mucho más sencillo.

El potencial de esto ya no está realmente en los expertos que sepan modificar la firmware o entrar y salir del Router de forma sencilla, sino que el usuario novel puede de forma sencilla gracias a esto solucionar problemas que pueda tener en el router, o aplica ajustes concretos especiales.

El formato que siguen estas instrucciones es similar al de otros nodos:

<Autoexec>     <Entry
arp_fix=”sysctl -w net.ipv4.neigh.br0.mcast_solicit=0″
dhcp_fix=”echo ‘* * * * * ebtables -D FORWARD -p ipv4 –ip-proto 17 –ip-source-port 67:68 -j DROP’ &gt; /etc/admin; crond -c /etc/” />
</Autoexec>

Ese por ejemplo sería el bloque modificado para realizar dos fixs a la firmware B21, uno el problema de la batería y otro el problema que posee el router que bloquea todo el tráfico DHCP que no sea el suyo propio. Es sólo un ejemplo sencillo, en realidad podríamos realizar casi cualquier cosa. Como vemos la entrada en sí no importa su nombre, es su contenido el que será pasado al archivo autoexec.sh. Tan sólo hay que añadir el bloque que queramos, guardar, cargar la configuración y solucionado.

 

 

Modificando el sistema de archivos raíz

El router usa como hemos dicho SquashFS para montar su raíz. El problema que esto nos origina es que no podemos realizar cambios en él directamente. Para poder hacer esto, en principio, lo que se necesita es modificar directamente la imagen SquashFS con los cambios que deseemos y volver a cargarla. En un sistema más potente o con otras herramientas podríamos incluso pensar hacer el proceso directamente bajo la misma shell, pero aquí estamos limitado tanto en espacio, herramientas y memoria del router, con lo que esta opción no es muy viable. La opción que nos queda es realizar la modificación fuera del router, y volver a escribir el sistema de archivos de vuelta al router.La teoría en realidad es sencilla, la práctica es algo más complicada porque hay que ver como podemos hacer esto.

A priori se me ocurren dos formas. Una, extrayendo en la partición que se encuentre (en caso de ser así) el sistema de archivos, modificarlo, copiarlo de nuevo dentro y volver a copiarlo a su partición con dd/mtd (lo cual puede resultar bastante peligroso si hacemos algo mal y tampoco tengo claro que pueda realizarse sin hacerlo desde el bootloader), o aprovecharnos del propio sistema de actualización de firmware del router, es mucho más seguro pero implica conocer bastante bien como es la imagen de actualización, para poder no solo modificarla, sino también hacer que el router la acepte. Yo he tomado la segunda opción, no quiero tener que llamar a Movistar para decirles que misteriosamente el Mitrastar ha muerto.

Dicho esto, se abren por desgracia una serie de puntos que pueden ser “largos”, pero necesarios. Si queremos modificar la firmware, lo primero que necesitamos es precisamente al firmware, el binario de actualización, y dado que las actualizaciones se realizan por telecarga puede no ser tan sencillo tener una copia de ella, a menos que conozcamos a algún amigo de un amigo que buenamente nos la suministre. Por suerte… hoy tenemos respuestas y medios para todos.

 

Estructura interna de las particiones de memoria

Antes que nada hay que “estudiar” como está organizada la memoria flash del router, hay que ver realmente que particiones hay:

# mount
/dev/mtdblock3 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00020000 “bootloader”
mtd1: 00020000 00020000 “romfile”
mtd2: 0014e7e3 00020000 “Kernel_main”
mtd3: 01090000 00020000 “Rootfs_main”
mtd4: 00006292 00020000 “Defcfg_main”
mtd5: 01d40000 00020000 “Tclinux_main”
mtd6: 0014e7e3 00020000 “kernel”
mtd7: 010b0000 00020000 “rootfs”
mtd8: 00006292 00020000 “defcfg”
mtd9: 01d40000 00020000 “tclinux”
mtd10: 00020000 00020000 “romd”
mtd11: 00020000 00020000 “second_romfile”

Con eso tenemos una visión más que completa del mapa del router, de como se compone internamente.Efectivamente comprobamos que la partición raiz es SquashFS, las particiones /sys, /proc son las habituales. A parte de ello se monta una partición como “ramfs” que como vimos contenía el archivo /etc/passwd, y por otro lado uan con el extraño nombre “usbfs”… es posible que el router tenga internamente puertos USB después de todo, y de echo la interfaz tiene configuraciones para SAMBA.

Lo que se refiere al particionado de la Flash, vemos hasta 12 particiones, y por suerte para nosotros los nombres son relativamente descriptivos. Vemos además que las particiones mtd2-5 estan duplicadas, o al menos eso parece, lo que nos hace pensar en un sistema de doble imagen, muy usado en los sistemas para evitar una mala actualización. Bootloader, kernel, rootfs y rom/cfg parecen evidentes su contenido, mientras que tenemos otra partición algo más extraña con el nombre de tclinux. El tamaño de las diferentes particiones también nos dan otra idea, siendo tclinux la partición más grande con diferencia, más que la suma de las demás, lo que posiblemente nos indique que tclinux es de algún modo “todo”, y de echo, lo es.

Pero pongamos por caso que tenemos la imagen de actualización, nos será más sencillo para explicar su estructura, y más adelante veremos como poder extraerla si queremos desde el router, que es secundario.

 

Estructura de la imagen de la firmware

Actualmente tan sólo existe una firmware completamente oficial, la B14, aunque la B21 se ha distribuido a muchos usuarios debido a los problemas ocasionados por la B14:

Mitrastar b14 113WJI0b14.bin b79d53bb663cbae480532942cc0e961a
Mitrastar b21 113WJI0b21.bin 770a5a52069066dc87978dba949cb1fd

Tomemos la segunda por caso. En lo personal, me gusta siempre antes de cualquier otra cosa, echarle un vistazo a través de un editor hexadecimal a ver que veo. Haciendo un barrido sin demasiada observación, vemos en primer lugar lo que parece claramente una cabecera al comiendo de la imagen, y curiosamente al final de todo el archivo nos encontramos también que termina con “</ROMFILE>” que es precisamente como termina también nuestro archivo de configuración. Si hacemos una pequeña búsqueda con esto, podemos localizar también el inicio de esta parte, que parece que tiene una pequeña cabecera que lo precede especificando que está comprimido y el tamaño que posee, eso lo vemos en el offset 0x011d27d6.

firmware

Como sabemos también que se supone es una imagen SquashFS, podemos buscar su cabecera y ver si se encuentra alguna correspondencia, buscando por los valores “68737173”, y sí… encontramos también una correspondencia de este en el offset ox0014e7e3, que termina de echo justo cuando comienza el archivo de configuración antes citado. Con esto tenemos prácticamente, y sin necesidad de usar ninguna utilidad, el contenido completo de la firmware (aunque queda ver y analizar aun unas cuantas cosas). Lo único que nos queda es una parte, que se encuentra después de la cabecera y antes de la imagen squashfs. Teniendo en cuenta que tenemos la información anterior de las particiones mtd, la respuesta es evidente: Es el kernel. Recordemos que en las particiones teníamos 3 en concreto que estaban duplicadas con el mismo nombre, con la única diferencia a priori de que las particiones más bajas tenían la coletilla main. Bien, por pura lógica asociamos defcfg al archivo de configuración que hemos encontrado, roofs a la imagen squashfs y el otro pedazo que nos queda es el Kernel. Además, como tenemos el tamaño de las particiones vemos también que efectivamente, si dividimos cada parte independientemente, corresponden sus tamaños a los tamaños de las particiones (ojo que dado que el tamaño de erasesize es de 0x00020000, el espacio de las particiones es múltiplo siempre de este valor, con lo que el tamaño excedente se rellena). Con este pequeño análisis, podríamos ya extraer la imagen squashfs a nuestro equipo, y a priori modificarla como nos diese en gana, volver a crear la imagen squashfs y ver como poder volver a montar la imagen de actualización con todo sin romper nada.

 A partir de aquí, tendríamos el trabajo farragoso. Es necesario comprender las cabeceras, el contenido tan sólo es lo sencillo. Diseccionar las cabeceras es un trabajo más meticuloso y estar haciendo comprobaciones, sumas, cuentas, mirar binarios del router en busca de más información… es tedioso. En mi caso empiezo siempre desde el comienzo, identifico lo que parecen ser los “Magic Number”, cadenas de texto descriptivas que pueden indicar versiones, conjuntos de bytes que indiquen tamaños y desplazamientos, checksums… en definitiva, lo que se puede esperar de cualquier cabecera. Diseccionar totalmente la cabecera (las dos que hay) fue lo que más tiempo me llevó. Os desgloso lo que sería la estructura integral de la firmware, incluyendo por supuesto la estructura de su cabecera. Digamos que la imagen de actualización se compone de tres “partes”. La cabecera, la firmware en sí (compuesta de kernel+rootfs/sistema_archivos) y el archivo de configuración:

0x00000000 Header
    0x0000 Cabecera “Magic Number” 04 D0 FC 9C
    0x0004 chipID = “36 33 33 36 38 00 00 00” = 63368 (8Bytes)
    0x000C Padding (16 Bytes)
    0x001C ModelID = 5A596004 (4Bytes)
    0x0020 Tamaño total archivo .bin, incluído cabeceras (4Bytes)
    0x0024 Offset en Memoria rootfs (0x40000 + offset bin) | 0x40000 = Bootloader 0x20000 + romfile 0x20000
    0x0028 Tamaño Rootfs (4Bytes)
    0x00CC Offset en Memoria Kernel
    0x0030 Tamaño Kernel (4Bytes)
    0x0034 Offset en Memoria cfgfile
    0x0038 Tamaño cfgfile (4Bytes)
    0x003C ¿Magic Number?? 01 00
    0x003E Tipo de imagen | main (0x0003),  esclava (0x0002), bin de actualización (0x0001)
    0x0040 Versión Firmware (32Bytes)
    0x0060 Descripción Firmware (32Bytes)
    0x0080 Checksum Rootfs (4Bytes)
    0x0084 Checksum Kernel (4Bytes)
    0x0088 Checksum cfgfile (4Bytes)
    0x008C Padding

0x00000100 Firmware
    0x00000000 Header
        0x000 Cabecera “Magic Number” 32 52 44 48 (4Bytes)
        0x004 Tamaño de cabecera (4 Bytes)
        0x008 Tamaño de la “Firmware” incluyendo su cabecera
        0x00C checksum SquashFS, las particiones _main no llevan CRC, la firm no lo computa en cualquier caso.
        0x010 versión de 2rdh?? Termina con salto de linea (32Bytes)
        0x030 “Salto de linea”/padding (32Bytes)
        0x050 Offset squashfs/tamaño kernel (4Bytes)
        0x053 Tamaño squashfs (4Bytes)
        0x058 Padding
        
    0x00000100 Kernel, lzma
    0x0014e6e3 rootfs Squashfs 4.0 lzma | Sistema de archivos

0x011d27d6 Configuración romfile
    0x0000 Header
    0x0028 romfile comprimido.  ¿Algoritmo fastlz?

 

 Modificación/Creación de una firmware nueva

Bien, teniendo toda la estructura de la imagen de actualización, debería de ser trivial realizar cualquier cambio (añadir, eliminar, modificar) dentro de la firmware. Con linux tan sólo necesitaremos tener las herramientas para crear y extraer squashfs, teniendo en cuenta que la imagen original fue creada en SquashFS 4.0+, usando la compresión LZMA. Esto significa que si no usaron un SquasFS modificado tuvieron que usar SquasFS 4.1, 4.2 o 4.3, ya que hasta la versión 4.1 no se dio soporte oficial a LZMA. Yo lo he realizado todo con SquasFS 4.3, usando como compresor LMZA el SDK de 7zip. Es necesario eso sí, modificar el makefile para habilitar lzma.

Extraída la imagen en nuestro equipo y modificada a voluntad (o añadido los archivos/paquetes que deseemos…) volvemos a empaquetar nuestra imagen squashFS. De nuevo, recordemos que debemos de usar LZMA y realizar la creación sin el padding a 4K. Llegados a este punto, como tenemos toda la estructura de como tiene que la estructura de la imagen de actualización, tan sólo tenemos que realizar el proceso inverso y corregir todas las cabeceras que sean necesarias. Sería muy sencillo crear una pequeña utilidad que pasándole la imagen modificada, el kernel y el archivo de configuración nos crease el archivo final de actualización con todas las cabeceras corregidas. Pero ni he tenido tiempo ni tengo ganas de hacerlo. Así que sigamos.

Con la imagen SquashFS ya modificada, podemos empezar a empaquetar nuestra nueva imagen de actualización. Por suerte para nosotros, la cabecera de la sección perteneciente al kernel+rootfs no se verifica en ningún momento, y aunque podemos por supuesto calcularla, no es necesario ser muy rigurosos. La parte más tediosa es el cálculo del checksum, así que podemos establecerlo tan ricamente como “00 00 00 00” y no pasa nada.

Añadimos al final de la imagen squashfs el archivo de configuración previamente extraído de la imagen inicial. Añadimos encima de este el kernel, y encima del kernel la cabecera secundaria. No es necesario, pero por tener un mínimo de decencia corregimos en esta el tamaño de la “firmware” (que es el tamaño de la cabecera secundaria+kernel+squashFS), el checksum no nos complicamos y lo dejamos en 00 00 00 00, el offset de squashfs no ha cambiado con lo que lo dejamos igual y modificamos el nuevo tamaño que tiene nuesetra imagen squashfs (ahora sí, tan sólo el tamaño de nuestro squashfs modificado)

Por último queda realmente lo que es más delicado, que es reconstruir realmente la cabecera que va a judgar si nuestra firmware es válida, por no decir que si metemos la pata siempre podemos bloquear e inutilizar el router, así que cuidado aquí. Los valores a modificar en realidad son pocos, si tan sólo hemos tocado el sistema de archivos:

    0x0020 Tamaño total archivo .bin -> Es necesario modificarlo porque el tamaño de nuestro squashFS será diferente
    0x0028 Tamaño Rootfs -> El valor es el mismo que se puso en la cabecera secundaria, y hay que modificarlo por lo mismo que el anterior
    0x0034 Offset en Memoria cfgfile -> Al cambiar el tamaño del rootfs, el offset del archivo de configuración cambia. Recordemos que hay que sumar siempre 0x40000
    0x0080 Checksum Rootfs (4Bytes) -> Que checksum??

Bien, tenemos todo menos el checksum de rootfs, el resto son los mismos porque no hemos realizado ninguna modificación. La pregunta del millón es como diablos calcula Mitrastar este valor, puesto que ha podido usar cualquier técnica conocida o desconocida. La mala noticia es que usa un algoritmo propio para calcularlo, la buena noticia es que ya lo tengo recreado, y la mejor noticia es que incluso nos podemos ahorrar su cálculo si sabemos donde mirar (una pena que descubriese esto último más tarde, pero al menos tengo igualmente el algoritmo.

El checksum usado por Mitrastar es una modificación al conocido CRC32, usando una lockup table para agilizar los cálculos, y podemos encontrarlo en el binario cfg_manager. Se puede buscar la función y decompilarla. Es necesario este valor porque el bootloader y el propio cfg_manager comprobarán dicho valor, y si no corresponde al que ellos calculan, el router rechazará dicha imagen. No sólo se usa este checksumo para verificar la firmware, igualmente se verifican tamaños y otros, pero ya hemos dado por supuesto que la cabecera la hemos calculado bien.

Bien, he dicho que aunque tengo creado el algoritmo para calcular el crc32 modificado no es necesario. Esto es porque por suerte para nosotros ya lo calcula el cfg_manager por nosotros. Cuando actualizamos el router (o lo intentamos), justo antes de que este se reinicie (sea la firmware válida o no) escupe en la consola de registro los cálculos pertinentes, sacando por pantalla los checksum calculados y los que tenemos en nuestra firmware. Dicho de otro modo… si actualizamos aun con la cabecera con los checksum incorrectos, y mientras esta el proceso miramos el registro con dmesg, obtendremos algo como esto:

***** MitraStar Confidential Firmware *****
compressedLen = 25194
pTag->kernelChksum = 11b8cc8b
pTag->rootfsChksum = da3878fa
pTag->defcfgChksum = 35842e0b
cal kernelChksum = 11b8cc8b
cal rootfsChksum = da3878fa
cal defcfgChksum = 35842e0b

pTag->modelId = 5a596004
pTag->chipId = 63368
len = 011d8a68
mrd->modelId = 5a596004
mrd->chipId = 63368

Update slave image version

Ready to flash image…

Si los checksum calculados no se corresponden a los nuestros, el proceso fallará, pero podremos anotar el crc calculado, modificar los nuestros para que correspondan y volver a actualizar. Eso le quita a cualquiera tener que decompilar el código en cfg_manager, extraer el algoritmo de verificación y recrearlo en C o en el lenguaje que le guste. Por supuesto el echo de que se calcule el CRC no hay que verlo sólo como para impedir que se realicen modificaciones, sino para garantizar la integridad de estas y evitar una mala actualización.

Si todo ha ido bien, el cfg_manager copiará la imagen de actualización a 4 particiones esclavas, mtd6-9, cada una con su contenido. Al reiniciar el router, el bootloader realizará comprobaciones similares a las realizadas por cfg_manager, y si todo es correcto procederá a copiar las particiones esclavas mtd6-9 a las principales mtd2-5. Si el router se reiniciase (funcionando) sin aparentemente ningún cambio efectuado, posiblemente el bootloader encontró algún problema en la firmware modificada y anuló la copia a las particiones principales, con lo que habría que ver el problema, solucionarlo y volver a cargarla.

Si todo ha sido correcto, llegados a este punto, tendríamos nuestra propia firmware modificada con lo que necesitásemos, ya fuesen arreglos de los problemas que tiene la firmware oficial o nuestros propios añadidos.

Recordemos que dije que no es necesario tener una imagen de actualización. Podemos extraerla a partir de las particiones mtd5 o mtd9, tan sólo con una apreciación: Las particiones mtd5 y 9 estarán posiblemente padeadas para rellenar el resto del erasesize, con lo que hay que eliminar dicho bloque. Por otro lado hay que modificar un byte en la cabecera que especifica el “tipo de partición”. El archivo de actualización tiene que estar en 01, no en 02 o 03. Quitando estos dos cambios, el resultado será una copia 1:1 (exacta) del archivo de actualización original. No es mal truco después de todo.

 

¿Instalación/Actualización de componentes y otros paquetes?

Ahora mismo no he añadido ningún componente extra, pero es más que factible. Hay que tener en cuenta que el router usa una arquitectura MIPS, y que tendríamos que recompilar cualquier paquete o binario para esta arquitectura. Aquí la idea he de decir que no fue mía y me llegó leyendo a un blogero en algún lado, y es que el router usa uClibc como motor, y el proyecto uClibc posee por suerte para nosotros imágenes listas para iniciar desde linux en las que podremos tener las herramientas necesarias para compilar el códígo y paquetes que deseemos, y una vez realizado sacarlo de ahí y meterlo en nuestra firmware modificada:

http://www.uclibc.org/downloads/binaries/0.9.30/


 

Conclusión

Bien, creo que eso ha sido todo. Sin duda alguna un buen entretenimiento del que siempre se aprende, y yo el primero. Quizás lo más útil en este caso no es instalar paquetes o actualizar otros (al menos en principio), pero puede que sí lo sea el poder realizar pequeños cambios aquí y allá, instalar algunos binarios extras como tcpdump, aplicar configuraciones específicas, filtros… tenemos espacio en memoria de sobra a fin de cuenta, y posiblemente tardemos nosotros mismos menos tiempo en corregir algunos de los problemas de la firmware, que esperar que Mitrastar los arregle por nosotros y que Movistar la distribuya.

Por ejemplo, para corregir el problema de la batería de los ARP en la B21, bastaría en principio con hacer el siguiente cambio permanente:

echo 0 > /proc/sys/net/ipv4/neigh/br0/mcast_solicit

Aunque como digo, tan solo es un ejemplo más…

Cronicas desde la Playa: Fallo de seguridad en iOS6+ y como robarles las cuentas de Microsoft (Hotmail, Outlook, live…) por medio de un sencillo MitM

Introducción

Con la llegada del buen tiempo y los períodos vacacionales, no somos pocos los que emigramos a la playa para descansar, relajarnos y olvidarnos de todo durante unos días. En un mundo movido por la tecnología parece casi de obligado cumplimiento ir a donde quiera que vayamos con nuestros dispositivos, y por supuesto proveernos con conexiones datos móviles, y cuando podemos conectarnos a redes WIFI externas. Y de eso vamos a hablar hoy, de algo que parece no entrarle en la cabeza a muchos, “Conexiones WFI de terceros”.

Todos preferimos como es natural conexiones WIFI a conexiones de datos, ya sea en dispositivos móviles y ordenadores. El problema fundamental es que si nos conectamos a una red que NO CONTROLAMOS no podemos saber que está pasando realmente en ella en gran medida, y eso nos deja (o puede dejar) totalmente vendidos, como veremos más adelante. La regla debería de ser muy sencilla: Si nos conectamos a una red desconocida, no quejarse de las consecuencias, y eso va por todos aquellos que les gusta llegar a cualquier sitio y buscar alguna red abierta o alguna red segura de la que pueda obtener la contraseña.

En teoría, en un mundo perfecto, todas las comunicaciones deberían de ir cifradas punto-a-punto para que fuese imposible interceptar dicha comunicación. Ese es el planteamiento inicial de los protocolos seguros como TLS/SSL, que nacieron de la necesidad de poder enviar y recibir datos a través de Internet sin miedo a que un tercero pudiese interceptar dicha comunicación. En las redes privadas/públicas (ya sean WIFI o Ethernet) esto toma un cariz muy especial, dado que la mayoría de las veces a nuestra misma red están conectados otros usuarios, ya sean nuestros propios familiares en caso de una red doméstica, ya sea algún vecino que logró obtener nuestra clave WIFI, ya sean todos los alumnos de la red de una universidad… etc etc etc. En estas redes, cualquiera de ellos podría ser un “tercero” que malignamente quisiese interceptar la comunicación de uno de los usuarios de dicha red. Si todo el tráfico fuese en texto plano (sin cifrar), ese usuario malvado podría sin ningún esfuerzo espiar TODAS las comunicaciones desde y hacia Internet de ese usuario. La implementación de protocolos seguros como TLS/SSL imposibilita esto dado que toda la información que sale del dispositivo del usuario se manda y recibe cifrada, y la codificación se realiza en el mismo dispositivo. ¿Pero es esto fiable? Bien implementado y con políticas de seguridad correctas debería de serlo… pero ahí es donde entran los expertos en seguridad para dar tirones de oreja a los programadores, que como personas humanas cometen errores de seguridad.

Para no alarga demasiado la historia, voy a resumir muy brevemente como es posible la comunicación TLS/SSL para garantizarnos la seguridad. Quien sepa como funciona que salte la sección si lo desea.


TLS/SSL

TLS/SSL es posible a lo que podemos llamar cadenas de confianzas de certificados. Un servidor posee un certificado de seguridad que además de servirle para todas las tareas de cifrado lo identifican de forma inequívoca. De este modo cuando un usuario quiere realizar una conexión segura hacia él, lo primero que hace este servidor es enviar este certificado como carta de presentación. El dispositivo del usuario por su parte (el navegador, aplicación…) antes de realizar la configuración del canal seguro, verifica como es natural la legitimidad de dicho certificado. Si todo es correcto se crea un canal seguro de comunicación, si la aplicación que sea detecta un error en dicho certificado (ya sea por que ha sido alterado, haya caducado, sea incorrecto, se desconozca el emisor…) la comunicación debería de cerrarse de forma automática, o al menos advertir de ello con un gran “WARNING!!”

Si un tercero intentase interceptar la comunicación sencillamente “pinchando” la línea, tan solo vería pasar por él datos sin sentido, cifrados. Pronto aparecieron vectores de ataques para que este usuario (que llamaremos a partir de ahora hombre en medio y de ahí este tipo de ataques Man-In-The-Middle, MitM) pudiese intentar sortear estas medidas de seguridad. Quitando ataques conocidos a SSL/TLS y fallos de implementación existentes (como el famoso heartbleed de hace unas semanas), es imposible poder descifrar los datos que circulan por dicho canal sin poseer la “llave” de ellos. La llave de la cual depende todo en última instancia es el certificado que envía el servidor al usuario (la clave privada de este que celosamente guarda el servidor en cuestión y que jamás sale de él y que evidentemente nunca podremos obtener).

conexionnormal

Como hemos dicho, cuando el sistema funciona correctamente y no hay flecos, tan solo obtendríamos datos sin sentido de dicha comunicación. Pero… que pasaría si un atacante se colocase en medio de la comunicación de ambos e intentase impersonar/suplantar el servidor de destino de cara al usuario y impersonar/suplantar al usuario de cara al servidor?? En este nuevo modelo, el usuario sin saberlo se estaría conectándose al equipo del atacante, y sería a este al que le solicitaría el servicio (por ejemplo una web) que desearía tener acceso, en vez de al servidor real. Llegado a este punto, el atacante tan solo debería de proveer con un certificado propio al usuario ingenuo, y si la conexión se estableciese correctamente, luego por otro lado, el atacante se conectaría al servidor legítimo para “pasar” dicha información a él. Es decir, el atacante establecería en este caso dos comunicaciones seguras, una con el usuario y otra con el servidor legítimo. El usuario no podría saber que está conectado realmente al atacante en vez de al servidor legítimo, y el servidor legítimo tan solo tendría una conexión normal en sus redes con lo que tampoco podría sospechar nada. Dado que el atacante generó su propio certificado que envía al usuario, posee también su clave privada y por ello puede decodificar la información que PC Usuario<->PC MidM generan. Del mismo modo como es este quien se conecta de forma legítima al servidor externo, también posee la clave de sesión de dicha conexión, y por tanto también puede descifrar los datos entre PC MidM<->Servidor.

El nuevo modelo por tanto sería algo así:

conexionmidm

El atacante (MidM) en este caso podría ver todo el tráfico que circulase por él, aunque fuese cifrado punto a punto… o más correctamente, en este caso no sería cifrado punto a punto, sería un cifrado usuario-MidM MidM-servidor.

Esto en teoría no debería de ser posible. Para evitar precisamente este tipo de técnicas, se hace uso de la propiedad que tienen los certificados para verificar no solo su integridad, sino su autenticidad. Esto es posible gracias a que cada certificado debe de estar firmado por otros agentes certificadores, generalmente por un CA (Autoridad de Certificación) que será quien en última instancia emite dicho certificado para dicho servidor. Dicho certificado digital es firmado por el CA de tal modo que cualquier alteración revocaría su validez. Pero la dependencia de un CA no solo elimina la posibilidad de que el certificado original sea modificado, sino que además garantiza que el certificado que el emite es genuino para el servidor concreto.

Sin poder modificar el certificado original (dado que automáticamente el software del usuario rechazaría la conexión) solo queda la opción de emitir un certificado propio. El problema es que el certificado que podríamos emitir evidentemente no vendría firmado por un CA reconocido. Esto es posible porque los programas que usamos ya sean aplicaciones, gestores de correos, navegadores… poseen una base de datos que se va modificando día a día con futuras versiones de un listado de entidades certificadores de confianzas, de tal modo que si un certificado que nos haga llegar un servidor está firmado por un CA que tenemos en lista, automáticamente se da por genuino. Es algo así como un sello de calidad. Nosotros podemos crear en cualquier momento un certificado totalmente válido y supuestamente para cualquier dominio, pero ninguna entidad de certificación fiable lo firmaría. Tan solo podríamos firmarlo nosotros mismos. ¿Esto anula el certificado? No realmente, el certificado es totalmente válido de cara a cualquier software, pero dependiendo de la política que cada software aplique al encontrar un certificado firmado por CA que NO TIENEN EN SU BASE DE DATOS sucederá una cosa u otra.

Todo el mundo sabe lo que sucede en la mayoría de navegadores Webs cuando esto sucede. Aparece un cartel de advertencia avisando de que el certificado no es válido, pero nos suelen dar la opción de continuar navegando. Esto es debido a que en realidad existen muchas webs totalmente genuinas (sobre todo webs de administraciones públicas) que usan infraestructuras propias de certificación y que los navegadores aun no tienen en sus bases de datos. Si no instalamos los certificados raíces (CA) el navegador nos bombardeará con avisos constantemente. En los navegadores Webs normalmente es suficiente con una advertencia de seguridad, y es el usuario quien debe de escoger que hacer… aun así suele ser muy tedioso porque por lo general el usuario no suele entender dicho mensaje o advertencia… y generalmente rechaza la conexión aunque sea una web legítima… y luego las miles de quejas en las administraciones públicas de que los procesos en los que se hace uso el certificado digital personal solo da problemas y errores.

¿Pero que pasa con los móviles y tablets? Aquí la cosa es más compleja. Tenemos cientos de aplicaciones constantemente conectadas a Internet, y evidentemente si queremos un mínimo de seguridad presuponemos que la mayoría de esas conexiones son cifradas, y evidentemente los protocolos TLS/SSL es lo que se usa en su 95%. ¿Que política aplican los dispositivos móviles? No hay ninguna política concreta, y depende de cada Sistema Operativo o aplicación.

Por ejemplo, por lo general tanto en Android como en iOS existe un almacen de certificados digitales al estilo de los navegadores Webs, en los que se puede añadir un certificado si se desea. Por defecto ambos sistemas operativos deniegan cualquier tipo de conexión que realicen las aplicaciones si estas reciben un certificado firmado por una entidad que no tienen registrada. No obstante, ambos igualmente poseen en sus API de programación modos para evitar esta salvaguarda, de modo que una aplicación podría ser programada para que en caso de inconsistencia del certificado o de firmado por un CA que no se tenga, aceptar la conexión de todos modos. Por ejemplo, imaginar que el creador de la aplicación no usa un certificado firmado por un CA que los dispositivos tengan en su BD!! Es necesario que tengan un modo de sortear esta seguridad.


La Crónica Contada

Dicen que la curiosidad mató al gato, y a mi no me gusta quitarle vidas. Y como tantas otras cosas todo comienza por un: “Que pasaría sí…” en mi caso fue un:

“Cuantos incautos se conectarían a mi Router si añado una red WIFI abierta?” Mirándolo por el lado bueno estás prestando un “servicio” y dando WIFI a quien quiera, por otro lado esos usuarios deberían de saber que no puedes fiarte de NINGUNA conexión WIFI que no controles… y muchas veces las que controlas si no están bien aseguradas tampoco. El resto es sencillo… desvincular por seguridad la red secundaria WIFI de la primaria, redirigir todo el tráfico desde dicha interfaz del router hacia mi propio equipo en el que levanté un servidor proxy transparente para poder ver/manipular/inyectar el tráfico que quisiese y una pequeña infraestructura igualmente para inyectar certificados firmados por un CA inventado.

Es decir, todo el tráfico que se generase por usuarios conectados a mi punto de acceso “libre” pasaría por mi PC antes de llegar a su destino. Con ello automáticamente ya podría tener acceso a todo el tráfico no cifrado sin que los usuarios pudiesen hacer nada, simplemente por conectarse a un punto de acceso que no estaba protegido por una contraseña. Solo con esto podríamos escribir todo un libro sobre fallos de seguridad de tantas webs que envían en texto plano contraseñas, usuarios y datos de todo tipo… pero eso lo dejaremos para otro día, hoy se trataba de analizar tráfico cifrado.

Para poder “ver” el tráfico cifrado sin complicaciones mayores o trucos de cualquier tipo que al final puede ser culpa del usuario picar o no picar, la idea era comprobar la solidez de las aplicaciones a la hora de manejar certificados válidos firmados por CA desconocidos. La lógica dice que tan solo algunas aplicaciones móviles permitirían dicha conexión cifrada, mientras que la inmensa mayoría ni siquiera advertirían al usuario de un error de certificado y denegarían la conexión… lo cual es igualmente malo, puesto que para el usuario tan solo tendría la sensación de que algunas cosas le funcionaban y otras no.

Como era de esperar, en tan solo unos minutos ya tenía unos cuantos usuarios conectados a mi AP, la mayoría hay que decir que el tráfico era generado de forma automática por aplicaciones de fondo instaladas y otros servicios en dispositivos móviles, como evidentemente comprobaciones de correo, actualizaciones de redes sociales, datos de localizaciones… mirando el tráfico en los primeros 5 minutos algo inexplicable, la conexión realizada por un iPad en la comprobación del correo electrónico de una cuenta de hotmail… contenido protegido como era de esperar por TLS/SSL, pero la conexión no se estaba rechazando. Esto es lógico de ver en aplicaciones que no podemos tildar de “importantes”, pero si hablamos del correo electrónico la importancia es en mayúsculas:

(Nota: Como es lógico he eliminado los datos sensibles de dicho usuario)

POST /Microsoft-Server-ActiveSync?User=usuario@hotmail.com&DeviceId=AppTATATATATA190&DeviceType=iPad&Cmd=MoveItems HTTP/1.1
Host: dub405-m.hotmail.com
X-MS-PolicyKey: 0
Accept-Language: es-es
User-Agent: Apple-iPad3C6/1104.167
Accept: */*
Content-Type: application/vnd.ms-sync.wbxml
Connection: keep-alive
Cookie: laquesea
Authorization: Basic dXN1YXJpb0Bob3RtYWlsLmNvbTpwYXNzd29yZA==
Content-Length: 130
MS-ASProtocolVersion: 14.0
Accept-Encoding: gzip, deflate

Solo con la cookie de sesión sería suficiente para poder acceder al correo electrónico, aunque sería imposible conocer la contraseña de dicha cuenta como es natural. Lo que más me sorprendió fue ver que tanto el correo como la contraseña de la cuenta estaban siendo enviadas en texto plano!! En la propia cabecera del paquete en una conexión cifrada por un certificado de un CA falso. Si vemos en la cabecera del paquete:

“Authorization: Basic dXN1YXJpb0Bob3RtYWlsLmNvbTpwYXNzd29yZA==”

Para cualquiera que sepa un mínimo de codificación digital, sabrá que eso no es más que una codificación en Base64, revertido: “usuario@hotmail.com:password”.


Conclusiones

Este tipo de fallos de seguridad es muy común verlos como digo en servicios de poca confiabilidad, pero no es algo que sea ni mucho menos normal encontrar en servicios de uno de los grandes, y lo digo tanto por parte de Apple como por parte de Microsoft. Esto puede parecer un poco enrevesado y complicado, pero pensemos realmente en ello.

No tengo ahora mismo un iPad para probar, pero por el User-Agent del paquete puedo deducir que el usuario en concreto no usó la aplicación concreta del AppStore, sino que usó el gestor de cuentas por defecto en iOS para configurar su cuenta de Hotmail. Si esto es así, el fallo de seguridad recae en Apple, dado que es iOS quien en su gestor de cuentas de Hotmail no rechaza por defecto las conexiones potencialmente fraudulentas. Esto es un fallo de seguridad bastante importante!! Pensar que el primer dispositivo iOS (y el único) que se ha conectado a mi AP ya me estaba dando automáticamente su cuenta al completo (usuario y contraseña) sin que él pudiese hacer nada ni se enterase de nada. ¿Cuantos usuarios de iOS usan Hotmail?? Siempre hablando en hipotéticos, sería tremendamente sencillo robarle la cuenta de Hotmail a cualquier usuario de iOS, dado que además las comprobaciones de correo se hacen de fondo… Lo más preocupante de todo ello es si este problema no solo afecta realmente a Hotmail, sino que es un problema del gestor de correos de iOS y afecta igualmente a otros proveedores…

Existe una alternativa a ello. Que dicho usuario estuviese usando la aplicación de Microsoft y no el gestor propio de iOS, que es otra opción. En este caso la responsabilidad recaería íntegramente en Microsoft, puesto que habrían sido sus programadores los que permisivamente no ajustaron bien las políticas de seguridad.

En cualquier caso es algo realmente bochornoso y preocupante. Como digo es algo que puedes esperarte de empresas que no tienen como es natural los mismos recursos o pueden ser más… “despistados”, pero en el caso de Apple o Microsoft es algo totalmente inexcusable.

Para colmo de males, no solo se trata de que sea posible realizar un ataque MidM, sino que la aplicación (Apple o Microsoft) envía en plano la contraseña en el paquete. Sí, evidentemente se supone que es suficiente con TLS/SSL, pero a día de hoy esto es de bien sabido no ser suficientemente seguro. Tal es así que los servicios realmente decentes usan además de conexiones fiables TLS/SSL otros modos de enmascaramiento de contraseñas. Por ejemplo, habría sido tan sencillo como expresar la contraseña como un Hash MD5/SHA1 (o lo que se prefiera) con lo que habría sido imposible revertirla. Es preocupante ver que quitando el amparo de TLS/SSL los datos altamente sensibles viajan tal cual…

En comparación, Google, aun cuando uno interceptase su propio tráfico y abriese absolutamente todas las conexiones TLS/SSL instalando el certificado CA pertinente, no podría ser posible acceder a la contraseña de dicho usuario en ninguno de sus servicios dada la alta codificación de los datos fuera ya del amparo de TLS/SSL. Vale, eso no significa que sea imposible a lo mejor robar una cookie de sesión o intentar obtener más información… pero al menos la contraseña el atacante no la obtendría.

Es sumamente importante concienciar a los usuarios que aun cuando una red WIFI pueda ser tentadora, puede esconder un peligro mucho mayor de lo que uno pueda imaginar. En este caso con los datos del corroe de dicha persona podría entrar no solo impunemente en su correo, sino a cada uno de los servicios asociados a él: Paypal?? Redes Sociales? Tiendas Online? Servicios de Geolocalización si los tiene?? Agenda? No creo que sean cosas que se deban de tomar a risa o a la ligera, y mucho menos creer en la seguridad que incluso esos que llamamos “los grandes tecnológicos” nos dan. La mayor seguridad la da el sentido común señores, y por mucho que prefiramos una conexión WIFI frente a una de datos, ya no solo veamos siquiera el daño o no daño que podemos provocar a la otra persona si es una “conexión wifi robada”, sino que la peor parte nos la llevamos nosotros mismos por regla general. No pensemos nunca que somos los más listos del mundo, que tenemos aplicaciones y utilidades para robar contraseñas WIFI, que hemos tenido suerte de encontrar una red Abierta, que… porque os puedo asegurar que siempre hay alguien más listo detrás aprovechándose de todo ello.

Por supuesto la infraestructura que he levantado en 5 minutos es infinitamente mejorable, para empezar sería treméndamente sencillo enviar a cualquier usuario que se conectase a un portal de captación en el que se obligase a los usuarios a instalar un certificado para “navegar” y que dicho certificado fuese realmente el certificado del CA creado… con lo que de instalarlo el dispositivo quedaría totalmente abierto hacia el atacante, y todo el tráfico cifrado sería descifrado dado que de cara al dispositivo dicho CA sería igual de válido que cualquier otro.

Suma y sigue… suma y sigue.

El fallo ya lo he notificado a Microsoft y Apple igualmente… aunque para el caso que suelen hacer…

Feliz Primavera amigos.

La cadena de texto “de la muerte” de iOS y OSX: سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ

Por desgracia no he tenido tiempo antes para hablar sobre la ya famosa “cadena de la muerte” que afecta a los productos de Apple, así que aprovecho para dedicarle unas cuantas letras a ello, puesto creo sin duda alguna que merece la pena por lo absurdo del caso. Pero antes que nada hagamos un poco de recapitulación para aquellos que no saben nada de ello.

¿Algún usuario de iPhone ha observado últimamente que sus aplicaciones se cierran sin mucho sentido?

Hace ya más de 6 meses, expertos de seguridad reportaron a Apple un fallo crítico en sus sistemas operativos, tanto iOS como OSX, afectando en ambos casos incluso sus versiones más actuales. El fallo provoca un ataque de denegación de servicio (DoS) producido por el motor de renderizado de texto del sistema operativo ante una cadena unicode concreta: “سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ”. En términos profanos, cada vez que cualquier dispositivos de Apple (iPhone, iPod Touch, OSX…) tiene que renderizar (dibujar/interpretar) en pantalla dicha cadena de texto (pues usa el motor de texto del OS), la aplicación que esté en primer plano que esté accediendo a dicho texto se cerrará. Si mandamos un WhatsApp con dicha cadena, el usuario de iOS no podrá abrir WhatsApp (por poner un ejemplo sencillo)

En primer lugar, encontrar un fallo en cualquier aplicación que pueda producir un DoS en ella, no es algo demasiado extraño. Encontrar un fallo en un OS que pueda producir un DoS en él es algo que suele ser mas extraño pero todos los años solemos tener unos cuantos. Lo que realmente hace peculiar este fallo (y de ahí su gran importancia) es el método para “dispararlo”, puesto que tan solo es necesario una sencilla cadena de texto unicode que cualquiera puede enviar, copiar/pegar… o hacer el uso que sea de ella. No es necesario dispararlo por medio de un exploit complejo, no es necesario un conocimiento avanzado informático, no es necesario ser un experto… cualquier persona puede producirlo en un dispositivo objetivo, sencillamente haciendo llegar al objetivo dicha cadena de texto. Tan simple como eso.

En segundo lugar, otra cosa que hace de este fallo crítico en los productos de Apple algo tan severo, es la inacción por parte de Apple (como de costumbre) ante un fallo de seguridad o de cualquier otra índole en su software y sistema operativo. El error fue reportado hace más de 6 meses, 6 meses en los que cualquiera ha podido estar explotando dicha vulnerabilidad a su antojo. Pero aun peor que todo ello, es que después de que hace una semana saltara en todos los medios de noticias, Apple sigue sin hacer absolutamente nada, siendo afectados todas las versiones de iOS (exceptuando la beta de iOS 7) y prácticamente todas las versiones de OSX.

Para cualquier usuario de iOS (y mayoría de OSX) no pueden hacer sencillamente nada. Si el texto es puesto en cualquier sitio y sus dispositivos lo reciben, la aplicación que lo muestre en pantalla se cerrará sin remedio alguno. Esto es un problema, porque incluso el simple echo de escribir un artículo con ello, provocará que a los usuarios de iOS/OSX se les cierre el navegador web si abren mi blog. Para tener constancia de la gravedad de ello, voy a exponer unos sencillos ejemplos y el efecto que tendría en los dispositivos de Apple. Otro gran problema de todos los ejemplos que veamos, es que el usuario de Apple ni siquiera será consciente de que ha pasado o porqué sus aplicaciones no funcionan correctamente.

-En una página web

El navegador del dispositivo se cerrará cada vez que se intente acceder a dicha web, puesto que la cadena de texto hará por mostrarse en él. La única solución pasa por no acceder a dichas webs, lo cual es complicado, cualquier webmaster podría poner la cadena de texto en cualquier parte de su web/blog/foro… En este caso el ataque sería indiscriminado, no iría dirigido concretamente a nadie.

-En un correo electrónico

En el caso sencillo, bastaría incluir la cadena de texto en el cuerpo de cualquier correo electrónico dirigido a cualquier usuario de Apple. Este al abrir dicho corro provocará que el gestor de correo electrónico o el navegador web (en caso de acceso por web) se cierre.

Un caso más maligno de este sería usar dicha cadena de texto como asunto y no como cuerpo de mensaje. En este caso, dado que los gestores de correo y los webMail tienen a mostrar directamente el asunto del mensaje SIN NECESIDAD de abrir el correo, sería suficiente de nuevo para provocar el cierre del navegador web o del gestor de correo.

Usado de forma “maligna”, cualquier usuario de forma muy muy sencilla podría dejar inutilizable de un modo efectivo el gestor de correo de los usuarios de iOS o de OSX (puesto que por lo general el asunto se muestra directamente lo cual provocaría el cierre de la aplicación), y de forma menos agresiva también el navegador cuando se acceda por webMail

En este caso, tan solo sería necesario conocer el correo electrónico del usuario al que dirigirse.

-Facebook, Twitter, Google+…

Independientemente de si se accede a estas aplicaciones desde una aplicación móvil o desde el navegador, parece evidente pensar que pasaría si se publicase en las redes sociales dicha cadena de texto, y el efecto que tendría a todos los usuarios de Apple. Este pensamiento no son pocos los que lo han tenido… y muchos los que lo han hecho. Así pues, son muchos los que han twitteado el mensaje, haciendo que a los usuarios de Apple les fallase tanto la aplicación como e navegador web al intentar visualizar dichos Twitts.

En caso de Facebook, estos bloquearon prudentemente la posibilidad de poder escribir dicha cadena de texto de forma directa, pero existen multitud de formas de evadir este sistema, como por ejemplo estableciendo manualmente como ubicación de la publicación la cadena de texto, pero las opciones son múltiples. La cuestión siempre es la misma, cuanto más ingenioso se sea a la hora de exponer la cadena de texto…

En este caso, se podría usar las redes sociales sin tener un objetivo concreto, o por supuesto bastaría con poder enviar un mensaje o publicar lo que fuese en el perfil del usuario.

-HangOut, SMS, WhatsApps…

A nadie se le escaparía tener en cuenta la mensajería instantánea y los SMS. En estos casos posiblemente el vector de ataque sería mucho peor.

En el caso de los SMS el daño a provocar es evidente, tan solo basta con mandar un SMS a cualquier iPhone para bloquear de forma sencilla la aplicación iMessage del dispositivo. Si la aplicación realiza un pequeño preview del texto maligno, será suficiente para provocar el cierre de la aplicación, y de volver a intentarlo el resultado sería el mismo. En este caso tan solo sería necesario tener el número de teléfono de la persona a afectar.

En el caso de WhatsApp las opciones son múltiples. En primer lugar sería suficiente con mandar un WhatsApp a cualquier dispositivo. Esto provocaría que al abrirse (o incluso en la previsualización) fuese suficiente para provocar la inutilización de WhatsApps. El usuario se vería forzado a tener que reinstalar WhatsApps en algunos casos. Otra opción de WhatsApps sería establecer el texto como mensaje de estado, un sistema pasivo que provocaría que cualquier usuario que nos tuviese en su lista de contactos (usuario de iPhone) no pudiese acceder a su lista de contactos, puesto que cargaría nuestro estado y de este modo WhatsApp se cerraría. Como tercera opción en WhatsApp, y la más efectiva, pasaría por crear un grupo de WhatsApp y establecer en su nombre el texto dañino. Dado que los grupos se regrean aun cuando WhatsApp se reinstala, a cualquier atacante le bastaría el número de telefono de cualquier usuario con iPhone para crear un grupo de WhatsApp, establecer el nombre a la cadena de texto dañina y añadir a dicho miembro al grupo. Dado que el nombre del grupo es visible en la lista misma de WhatsApp, el usuario de iPhone no podría abrir WhatsApp, y aun cuando reinstalase los grupos se recrearían igualmente, haciendo muy complicado evitarlo. De este modo se quedaría totalmente inutilizada la aplicación, se cerraría nada más abrirla constantemente.

En realidad, cualquier sistema de mensajería instantanea los efectos serían similares. La diferencia quizás radica en quien puede o no mandarnos mensajes. En el caso de los SMS por ejemplo, cualquiera con nuestro teléfono puede mandarnos uno. En caso de WHatsApp cualquiera con nuestro número puede hacerlo… esto hace de este fallo de Apple un problema en mayúsculas sin duda alguna.

 

Podríamos expandir la lista todo lo que quisiésemos. Desde establecer el SSID de nuestra red WIFI al texto en cuestión y ver que le ocurre a los iPhone cercanos, códigos QR, firmas… en realidad cualquier sitio donde podamos escribir un texto en unicode y que vaya a ser leído por el usuario en sus pantallas.

Lo peor de todo ello como ya he dicho, es que al contrario de otros fallos de seguridad, en este caso puede dispararse el error sencillamente con una cadena de texto, lo cual no solo hace que el vector de ataque sea increiblemente grande, sino que cualquiera puede explotar esta vulnerabilidad. Si a eso le sumamos que Apple continúa sin solucionar este problema que se conoce desde hace más de 6 meses…

Cada cual que haga sus propias conclusiones… o pruenas

Un saludo amigos, y ser buenos… no seamos demasiado… “traviesos” con los fanboys 🙂

Privacidad en aplicaciones móviles: Cual es el precio que estamos pagando por el uso de muchas aplicaciones para móviles?

privacidad

 

A día de hoy, el uso de las aplicaciones en nuestros dispositivos móviles se ha convertido en algo totalmente normal, tan normal que la gran mayoría de los usuarios de teléfonos de este tipo usaran entorno a 5-10 aplicaciones diarias distintas como mínimo: Correo electrónico, navegador, juegos, agendas, redes sociales, mensajería instantánea… y todas ellas, o la inmensa mayoría al menos, hacen uso de Internet de una forma totalmente activa o pasiva. Quien quiera la conclusión de este artículo, puede ir directamente al final de este y echar un vistazo a las “tablas” con los datos expuestos, quien quiera leer un poco más, puede empezar desde aquí… como es ya costumbre en “Alma Oscura”.

En un mundo perfecto en el que todos tuviésemos buenas intenciones, en el que nuestros datos fuesen solo nuestros, en el que todos los sistemas informáticos funcionasen perfectamente… en ese mundo perfecto posiblemente el usuario no tendría que preocuparse de tener un dispositivo que está conectado 24 horas al día a la red de redes, enviando y recibiendo datos de ella sin parar, y lo que es peor… sin saber en el 99% de los casos que información se está recibiendo y que información se está enviando. En cambio, muchas personas parecen haber aceptado el echo (o al menos así puede interpretarse de sus acciones) de que no les importa que información puedan saber de él o de su entorno. Quiero pensar que en realidad nunca se pararon a pensar que tipo de información envían y reciben constantemente de y hacia Internet, y que simplemente actúan así (o no actúan mejor dicho) por desconocimiento. Y eso es lo que me gustaría hacer un poco de hincapié hoy.

Por otro lado siempre tendremos a los conspiranoicos, personas que llevan el asunto de la privacidad a límites que solo ellos saben, con el “Nos vigilan” como lema, con que las grandes empresas o gobiernos saben todo lo que hacemos, hablamos, a donde vamos… No se puede ser un irresponsable con los datos privados de cada uno, pero tampoco podemos radicalizarnos y pensar que todo es una conspiración contra nuestros intereses. Es necesario siempre llegar a un término medio que aúne ambas filosofías de ver el asunto de la privacidad y de la vida personal de cada uno. Tampoco hay que perder de vista que el uso de la tecnología misma implica evidentemente hacer sacrificios en este aspecto, no podemos pretender vivir en un mundo totalmente adaptado tecnológicamente a nuestras necesidades y pretender que esto no tenga ningún coste a nuestra privacidad. Un ejemplo muy sencillo sería una simple cámara de seguridad, nos da seguridad en nuestro hogar es evidente, pero al mismo tiempo al grabarnos nos está restando una parte de nuestra privacidad.

Volviendo al tema principal de hoy, nuestro problema es diferente. Quien instala una cámara de vídeo sabe perfectamente a que se expone, bueno y malo, en cambio quien instala una aplicación en su dispositivo rara vez sabe realmente a que se está exponiendo, o hasta que punto dicha aplicación puede resultar ser más dañina que positiva (con respecto a su privacidad por supuesto). Lo cierto es que cualquier aplicación que se conecte a Internet puede potencialmente comunicar datos nuestros con o sin nuestro consentimiento explícito. Es cierto que tanto Android como iOS ponen especial hincapié en que permisos y a que tiene acceso cada aplicación por sí misma, pero aun cuando Android o iOS (Especialmente Android) especifique con pelos y señales que permisos serán concedidos a la aplicación en cuestión (y por consiguiente a que datos tiene acceso dicha aplicación), el usuario irresponsable lejos de leer generalmente las advertencias de seguridad y pararse medio segundo a recapacitar sobre ello, tiende a aceptar todo. Esto es lógico, si no acepta que la aplicación tenga acceso a dichos permisos, no es posible instalarla, y casi como robots y lobotomizados solo sabemos aceptar aceptar y aceptar.

El principal y fundamental problema es evidentemente que la aplicación tenga acceso a la red, ya sea por WIFI o por datos. Es evidente, una aplicación puede tener acceso a todos nuestros datos, pero si no puede transmitirlos de algún modo son totalmente inservibles para quien quiere obtenerlos. Podríamos añadir a esto los SMS o las llamadas de teléfono, pero francamente existen muy pocas aplicaciones que tengan este tipo de comportamiento (aunque son evidentemente factibles, y seguro que alguna existe). Lo paradójico del caso es que aunque es cierto que muchas de nuestras aplicaciones requieren de una conexión permanente a la red para poder hacer uso del servicio que sea, muchísimas otras en realidad no lo requieren. Permitidme que categorice la necesidad de acceso a Internet de las aplicaciones de este modo:

  • Acceso a servicios
  • Publicidad
  • Recopilación de datos de forma lícita o no

 

Acceso a Servicios

Posiblemente a este grupo pertenezcan la gran mayoría de aplicaciones que requiera de conexión a la red. Básicamente muchas de las aplicaciones que usamos constantementes (y muchas de ellas de forma ininterrumpida) requieren de una conexión permanente, puesto que precisamente la gran utilidad que tienen para nosotros es poder disponer de una conexión permanente. Así por ejemplo, podríamos citar tanto los servicios de sistema del propio terminal (servicios de actualización, localización…), el correo electrónico, servicios de mensajería instantánea tipo HangOut o WhatsApp, redes sociales como Google+ o Facebook…

Por por supuesto también meteremos en el mismo saco aquellas que aunque no requieren de una conexión constante y permanente, sí que requieren de una conexión desde el momento que dichas aplicaciones son pasadas a un primer plano, puesto que dependen de datos actualizados o se busca realizar una conexión puntual a algún servicio. A este grupo tendríamos por ejemplo aplicaciones como Mapas y navegadores GPS, exploradores Web para navegar por Internet, aplicaciones que nos dan el tiempo o datos sobre la bolsa, juegos Online o basados en Web…

Esto no implica ni mucho menos que dichas aplicaciones estén extensas de transmitir datos privados sin que lo sepamos, eso lo discutiremos más adelante, lo que quiere decir es que las aplicaciones de este grupo requieren sí o sí acceso a la red, es imprescindibles para ellas y si no disponemos de una conexión no funcionarán. En este caso es siempre imperativo ser muy conscientes de que permisos tienen concedidas dichas aplicaciones, y si fuese posible conocer realmente que datos transmiten a/desde Internet. A fin de cuenta si disponen de una conexión, pueden enviar y recibir de la red los datos que quieran, siempre y cuando la aplicación tenga permisos concedidos (y por tanto acceso) a los datos que quiera transmitir. Evidentemente por mucha conexión a la red que pueda tener una aplicación, si la aplicación no fue diseñada para tener acceso a nuestra agenda (y por tanto no tiene permisos para acceder a ella), no podrá nunca transmitirla.

 

Publicidad

Prácticamente la totalidad de aplicaciones que muestran publicidad de un modo u otro en las aplicaciones, requieren de una conexión a la red para mostrarla. A diferencia del primer grupo, estas pueden funcionar (en casi todos los casos) sin ningún tipo de conexión, y generalmente los programadores no bloquean su uso si no se detecta una conexión, en el peor de los casos suelen poner un banner genérico, aunque muchas veces simplemente no aparece publicidad sencillamente si no hay acceso a la red. Por supuesto si la aplicación en cuestión requiere para su uso una conexión a la red para hacer uso de cualquier servicio, sencillamente formaría parte del primer bloque, aunque igualmente muestre publicidad.

El asunto de la publicidad en las aplicaciones es mucho más controvertido y complicado de analizar de lo que uno pueda imaginarse. Es evidente que para el usuario de la calle cualquier tipo de publicidad es negativa, no solo consumen datos, sino que es molesta, a veces totalmente abusiva, ralentiza nuestros terminales, consumen a veces una parte de la pantalla importante en la aplicación, requieren de permisos extras en las aplicaciones… y generalmente incluso va unida al robo de información. Por otro lado, hay que entender que muchas de las aplicaciones que disponemos a día de hoy son mantenidas gracias a ellas, que son los programadores los que han invertido muchas horas en muchos casos en hacer llegar dicha aplicación a los usuarios sin ningún coste monetario para ellas! Y quitando contadas excepciones os puedo garantizar que ningún programador se hace rico ni mucho menos por ella.

 Por tanto, no podemos recriminar tan alegremente que algunas aplicaciones tengan publicidad porque creo que es totalmente legítimo y entendible. En cambio si soy el primero que recrimina la publicidad abusiva que tenemos en muchas aplicaciones, en las que el mismo terminal y la aplicación en sí sufre considerablemente en rendimiento, un aumento considerable de la batería, consumo de datos excesivo en algunos casos, publicidad altamente intrusiva y molesta… sin contar que muchos programadores aun siendo la aplicación de pago inserta publicidad. Creo que hay que tener una medida con todo.

La publicidad por desgracia conlleva muchas veces el “robo” de información de nuestros dispositivos, a veces información que es totalmente comprensible y necesaria para la publicidad en sí misma, y otras veces totalmente absurda. Puedo entender que un servicio de publicidad necesite de mi terminal la resolución de la pantalla para saber cual es el mejor tipo de banner a mostrar, incluso puedo entender que quiera saber mi ubicación APROXIMADA (a nivel de ciudad por ejemplo) para poder ofrecer una oferta más dirigida, pero lo que no puedo tolerar es que una agencia de publicidad de dispositivos portátiles quiera mi IMEI, mi localización EXACTA (ya sea WIFI, GMS o GPS)… hay cosas que son totalmente inexcusables, y como he dicho abusivas.

 

Recopilación de Datos

Por último, tenemos aquellas aplicaciones que requieren (o quieren mejor dicho) una conexión a la red para recopilar datos nuestros y transmitirlos a sus proveedores, dueños, agencias de publicidad, sistemas estadísticos… Por supuesto una aplicación de este tipo puede formar parte al mismo tiempo del bloque anterior o incluso de los dos bloques anteriores de forma simultánea.

Generalmente encontramos que prácticamente la totalidad de aplicaciones que solicitan una conexión a la red (ya sea de forma permanente o no, para mostrar publicidad o no) hacen algún tipo de recopilación de datos. La cantidad de datos que pueden recopilar de nosotros como hemos dicho dependerá del acceso que tenga dicha aplicación, pero pueden ser desde sencillamente conocer que versión de Android tenemos instalada (o de iOS), a recopilar nuestras cuentas de correo, agenda completa, localización GPS, fotos… si tienen permisos de acceso a ciertas funciones, potencialmente pueden recopilar información sobre ellas y transmitirlas.

De nuevo, tampoco es tan sencillo judgar estas recopilaciones de datos, muchas veces es incluso necesaria para el correcto funcionamiento de un servicio, y muchas veces lo único que recopilan es información técnica vital para el desarrollador de la aplicación sin que exista ningún tipo de datos privados que puedan causarnos ninguna molestia real. Pero al igual que con la publicidad, el problema está en los excesos y en no advertir al usuario de forma clara. En el caso de la publicidad la mayoría de las veces no suele ser demasiado abusiva, pero en el caso de la recopilación de datos generalmente ES MUY ABUSIVA.

Puedo comprender que una aplicación como pueda ser Google Now necesite cada X tiempo acceso a mis coordenadas geográficas para conocer mi posición porque le servicio depende de ello, al igual que entiendo y puedo comprender que Google esos datos también le sirve para tener una mejor precisión en sus sistemas de localización. No solo soy consciente de ello sino que Google es el primero que requiere de autorización EXPLICITA del usuario para activar dichos servicios, mostrando y explicando CLARAMENTE cual es el tratamiento que se le van a dar a los datos. Por poner un segundo ejemplo igualmente necesario, pongamos por caso la recopilación de datos que pueda hacer Mozilla en Firefox en Android, la primera vez que lo abres posiblemente te preguntará si permites (de nuevo una pregunta EXPLICITA) cierta recolección de datos, informando en todo momento que datos se transmitirán o no, si tienen fines estadísticos o de reporte de rendimiento… estos dos ejemplos es lo que podríamos llamar una recopilación de datos lícita y comprensible, en el caso de Google Now necesaria y en el caso de Firefox datos que ayudan a la fundación Mozilla a mejorar la aplicación. Para mí es lícita y comprensible por dos sencilla razones. La primera es que al margen de que la aplicación nos advierta claramente a que tendrá permiso de acceso dicha aplicación, la misma aplicación nada más abrirla nos explicará de forma clara que datos quiere transmitir y la razón de ello. La segunda es que EN TODO MOMENTO podemos deshabilitar dicho reporte y recopilación de datos. Esto otorga a los programadores confianza, y soy el primero que cunado una aplicación me explica el uso que le va a dar a mis datos y son lógicos, creedme que los permito.

Por desgracia, la mayoría de las veces nos encontramos en la otra cara de la moneda. La aplicación es cierto que especifica los permisos cuando se va a instalar, pero el usuario de calle jamás sabrá que datos está transmitiendo, ni la finalidad de dichos datos, ni el tratamiento que se le van a dar, ni a cuantas empresas se van a ceder dichos datos… ni siquiera una sencilla opción para deshabilitar dicha recopilación de datos. Esto y no otra cosa, es lo que me ha hecho volver hoy a estas letras, este abuso desconmensurado y totalmente inexcusable. Si los usuarios supiesen la ingente cantidad de datos que recopilan algunas aplicaciones y el uso que le dan (venderlos, spam, publicidad, control…), más de uno estoy seguro que cogería el móvil y lo haría trizas. Esto sucede en absolutamente TODAS las plataformas por igual, que es lo peor, si usas aplicaciones en tu dispositivo móvil… Por eso no puedo sino reírme cuando me encuentro con personas que son a priori super celosas de su intimidad, de sus cosas… algunos incluso paranóicos con asuntos de seguridad o privacidad!! y en cambio tiene aplicaciones que usa a diario que transmiten más información de él a cientos de empresas que la que pueda dar a conocer en toda su vida de forma directa. Es de chiste, pero está pasando a día de hoy.

 

No hay que diabolizar a los programadores ni a las empresas, tenemos gracias a dios una gran cantidad de estos que se toman la privacidad y la recopilación de datos de los usuarios de forma muy seria y responsable, y es algo que te das cuenta perfectamente cuando analizas las aplicaciones. Ves perfectamente quien realmente recopila datos de una forma aceptable y de forma inteligente para no “dañar” de modo alguno la privacidad del usuario, y ves perfectamente a quien le importa bastante poco la privacidad de los usuarios y miran exclusivamente por sus intereres, “robando” toda la información que puedan de estos sin la mayor preocupación. Lo peor es que estas empresas y programadores son los que dan mala reputación al resto, que como digo hay muchos que respetan esto y lo toman muy en serio. Se puede recopilar perfectamente datos estadísticos, de rendimiento, de uso de… de forma responsable.

Para reflejar este comportamiento y que el usuario pueda tener una visión mucho más amplia de todo, me he tomado la libertad de tomar 6 de las aplicaciones más exitosas de Play Store y analizar que datos envían a Internet, como los transmiten (de forma segura o no) o que tipos de servicios usan para la recopilación de dichos datos, es decir, si es la misma empresa la que recopila los datos o dependen de empresas de terceros para ello. Hay que tener en cuenta y bien presente que como digo no he tomado aplicaciones extrañas o poco confiables, hablamos supuestamente de empresas serias donde las haya, por tanto es de esperar que su comportamiento sea igualmente ejemplar:

  • Angry Birds (Versión 3.2.0): Juego que la gran mayoría conoce bien, de 100 a 500 millones de instalaciones.
  • Facebook (Versión 3.5): Red Social que tampoco creo que requiera una descripción concreta, de 100 a 500 millones de instalaciones.
  • Marvell War of Heroes (Versión 1.4.1): Juego de cartas coleccionables, aplicación en el primer puesto (del mundo) por ingresos, de 5 a 10 millones de instalaciones.
  • Pandora Internet Radio (Versión 4.4): Aplicación para escuchar música (y comprar si se desea) en forma de “estaciones de radio”. No disponible en España, pero esta en las primeras posiciones tanto en ingresos como en usada, de 50 a 100 millones de instalaciones (teniendo en cuenta de nuevo que no está disponible en muchos países).
  • Instagram (Versión 4.0.2): Red Social para compartir fotos que tampoco requiere de mucha descripción, de 100 a 500 millones de instalaciones.
  • Google+ (Versión 4.0.2.488): Red Social de Google, tampoco requiere descripción, de 100 a 500 millones de instalaciones

Como podemos ver, no es que haya optado por aplicaciones extrañas que nadie instala, la que menos usuarios posee es un Juego, que es comprensible si tenemos en cuenta que es un juego muy específico con una temática muy muy clara, y aun así es la que está en número uno por ingresos. Evidentemente es solo una lista de 6 aplicaciones, y aunque me hubiese gustado poder crear una lista mucho más extensa con grandes candidatos que evidentemente faltan, se requiere de “bastante” tiempo para analizar el tráfico de las aplicaciones, aislarlo, lidiar con encriptaciones… Tampoco he puesto de ejemplo ninguna aplicación de pago, todas como vemos son gratuitas. Esto no es casualidad. Podría haber usado aplicaciones de pago igualmente populares, pero por un lado la tasa de instalaciones sería mucho menor, por otro el lector solo podría comprobar dichos datos sin comprarla (y siempre me gusta que el lector pueda comprobar cada punto y coma que escribo por si mismo si así lo desea), y para finalizar, las aplicaciones de pago he de decir que suelen ser INFINITAMENTE más respetuosa que las gratuitas, EXCLUYENDO a las empresas realmente serias que respetan la privacidad del usuario. Aun así, como veremos, nadie se salva por un lado o por otro… dicho de otro modo, siempre pueden mejorar (en el mejor de los casos, en el peor de los casos veremos el abuso desproporcionado).

Dado que la mayoría de las aplicaciones usan varios proveedores diferentes para la publicidad y otros, cada aplicación especificará a que hosts conectan y el tipo de información que transmiten y de que modo. La mayoría de ellos son proveedores de publicidad… lo cual no es que sea una novedad. Al final del todo sencillamente incluiré una tabla resumen de todas ellas. Por supuesto todos los datos se refieren al terminal propio.

 

Angry Birds

  • a.jumptap.com: Navegador Web predeterminado, Versión de Android, Marca y modelo, Firmware y versión, IP, Idioma y País, tipo de conexión (WIFI/3G), Operador móvil -> Publicidad y Estadísticas
  • ads.mp.mydas.mob: Listado de nuestros sensores, Idioma y Pais, Marca y modelo, Versión de Android, tipo de alimentación (Cargando/Batería) -> Publicidad y Estadísticas
  • androidsdk.ads.mp.mydas.mobi: Listado de nuestros sensores, Idioma y Pais, Marca y modelo, Versión de Android, Firmware y versión, tipo de alimentación (Cargando/Batería) -> Publicidad y Estadísticas
  • an.appads.com: Marca y modelo, versión de Android, Firmware -> Publicidad y Estadísticas
  • neptune.appads.com: Marca y modelo, versión de Android, Firmware, Operador móvil, Idioma y País, Hash del IMEI, Hash de la dirección MAC, resolución de pantalla, otros -> Publicidad y Estadísticas
  • data.flurry.com: Marca y modelo, Versión de Android, Firmware y versión -> Estadísticas
  • media.admob.com: Idioma, tipo de conexión, tiempo de encendido (desde que se reinició), tipo de audio (auricular o altavoz), tipo de aplicación (móvil o escritorio), Operador móvil, otros -> Publicidad y Estadísticas

Al menos 7 host diferentes a los que se les manda información de nuestro dispositivo, 5 empresas diferentes (jumptap, Mydas, appads, flurry, admob). Absolutamente todo el tráfico se realizó sin el uso de protocolos seguros (TLS/SSL), con lo que cualquiera en la misma red podría interceptar dichos datos. Al menos el IMEI y la dirección MAC es transferida tan solo como Hash, usados como identificadores únicos de dispositivo, pero dado que es un Hash podemos decir que el reporte de los datos es anónimo, no es posible del Hash obtener el IMEI o la dirección MAC. Algunos datos son lógicos para crear estadísticas o publicidad, en cambio en ningún momento se permite al usuario evitar este envío de de datos anónimos

 

Facebook

  • graph.facebook.com/api.facebook.com (TLS/SSL): País e Idioma, ID único del dispositivo (no es un Hash, calculado a partir del IMEI), Resolución de pantalla, Marca y Modelo, Versión de Android, Listas de cuentas (correo electrónico) añadidas en el dispositivo, Usuario y contraseña de acceso a Facebook en texto plano, Código de verificación cuando se tiene activada la autentificación en dos pasos en texto plano, tipo de conexión (WIFI/3G), Operador Móvil, Coordenadas Geográficas lo más exactas posibles (GSM, WIFI Y GPS), Agenda (De tener activada la opción de sincronización de contactos), Otros…

La aplicación de Facebook tan solo conecta a dos host diferentes para toda la transmisión de información. En este caso la conexión a Facebook desde la aplicación se realiza de forma íntegra por TLS/SSL, lo que hace que el tráfico no pueda ser interceptado a priori. La mayoría de los datos recopilados y transmitidos tienen sentido como un ID único, resolución marca modelo… pero es totalmente inexcusable que se transmita de nuestro dispositivo la lista de cuentas añadidas a nuestro dispositivo!! Es decir que si en mi dispositivo tengo añadido 5 cuentas de correo electrónicos, la aplicación de Facebook transmitirá dichos datos a Facebook, algo totalmente innecesario. Por otro lado también transmite el operador móvil que tampoco posee explicación, y mientras que la transmisión de coordenadas geográficas tiene sentido CUANDO SE USASE LA OPCIÓN de adjuntar ubicación a una publicación, no tiene ninguna razón de ser que aun cuando no se escriba absolutamente nada, la aplicación trasmite igualmente de forma periódica dichos datos.

Por último, es totalmente inexcusable que los datos de acceso como el usuario y contraseña sean transmitidos en texto plano, aun cuando se está usando TLS/SSL para la conexión, puesto que aun así se podría intentar interceptar la conexión (es difícil pero es posible). Una contraseña siempre, siempre siempre… ya sea incluso transmitida por protocolos seguros, debe de ir cifrada de algún modo, aunque sea un hash, ni siquiera el servidor de destino tiene que saber que contraseña de acceso tenemos, tan solo una representación de esta en forma de Hash. Esto es el ABC de la seguridad. Aunque es de todas las aplicaciones probadas la que menos conexiones realiza en cuanto hosts diferentes, es una de las más invasivas por la sencilla razón de que los datos transmitidos son en muchos casos totalmente innecesarios.

 

Marvell War of Heroes

  • webview.mobage.com, ultimate-i.cygames.jp, ultimate-a.cygames.jp, play.mobage.com, ava-a.mbga.jp, assets.mobage.com: Marca y Modelo, Versión de Android, Firmware y versión de esta, País e Idioma -> Requerido por la misma aplicación.
  • service.sponsorpay.com: Dirección MAC, IMEI, ID único del teléfono, Marca y modelo, versión de Android, Idioma -> Publicidad supuestamente
  • data.flurry.com: Marca y modelo, Versión de Android, Firmware y versión, ID único del teléfono -> Estadísticas
  • d1.appredeem.com: IMEI del teléfono, ID unico del teléfono -> Publicidad e ingresos indirectos
  • cvt.mydas.mobi: IMEI
  • control.kochava.com: IMEI, Dirección MAC, ID único del teléfono, Pais e Idioma, Marca y modelo, Versión de Android, Firmware y versión -> Estadísticas y seguimiento
  • api2.playhaven.com: Pais e Idioma, Marca y modelo, Versión de Android, Firmware y versión, Resolución de Pantalla, Tipo de conexión -> Estadísticas
  • api.w3i.com: IMEI, dirección MAC -> Publicidad y Estadísticas
  • ads2.greystripe.com: IMEI -> Publicidad
  • a.jumptap.com: Navegador Web predeterminado, Versión de Android, Marca y modelo, Firmware y versión, IP, Idioma y País, tipo de conexión (WIFI/3G), Operador móvil -> Publicidad y Estadísticas
  • app.mobage.com (TLS/SSL): Marca y Modelo, Versión de Android, Firmware y versión de esta, País e Idioma, correo electrónico asociado a la aplicación, usuario y contraseña de la aplicación en texto plano -> Requerido por la aplicación
  • 22 hosts adicionales con los que de momento no transmite datos personales, demasiados para listarlos todos

Si hay una aplicación que se lleve la palma de oro en cuanto a abusos se refiere es esta. Situada en el número uno por ingresos, no es de pago pero permite compras in-app para comprar cartas y otros, lo que le ha dado ese primer puesto. Pese a esto, Mobage, lejos de tener suficiente con esto añade a la misma hasta 6 proveedores de publicidad diferentes, otros cuentos proveedores diferentes de estadísticas, más de 22 hosts diferentes a los que transmite datos a priori no personales… y eso sin contar con por supuesto con el tipo de información que transmiten, que si bien es cierto que no transmiten datos como la agenda de uno, transmite al menos a 6 hosts diferentes el IMEI de nuestro terminal! en algunos casos la dirección MAC de este. Recordemos que tanto lo uno como lo otro puede identificar perfectamente el terminal del usuario, no es lo que llamamos reporte anónimo ni mucho menos como pudiese ser por ejemplo el caso de Angry Birds. Creo que tener más de 6 proveedores de publicidad y otros tantos para la recopilación de datos estadísticos y otros… es abusar. Eso sin contar que la aplicación recauda por otro lado, que es imposible impedir la recopilación de datos, que la aplicación funciona PERFECTAMENTE si se bloquean prácticamente todos los hosts citados, que incluso la transmisión del IMEI y la MAC se realiza a través de conexiones HTML estándar y en texto plano… tan solo la conexión establecida a app.mobage.com y bank.mobage.com de la aplicación se realiza por TLS/SSL, pero no por cuestiones de proteger los datos de sus usuarios, sino para evitar en la medida de lo posible que pueda encontrarse un agujero de seguridad que permita el acceso no autorizado a la base de datos de ellos y con ello poder obtener privilegios especiales en el juego.

Francamente me parece bochornoso. Usan TLS/SSL cuando les conviene o les preocupa a ellos, los datos de los usuarios les importa poco, y la proporción de publicidad y datos que se transmiten no tienen igual.

 

Pandora

  • tuner.pandora.com: Marca y modelo, versión de Android, Firmware y versión, resolución de pantalla -> El buen funcionamiento de la misma aplicación
  • tuner.pandora.com (TLS/SSL):  Marca y modelo, Versión de Android, Resolución de Pantalla, Operador Móvil, Contraseña de la cuenta Pandora (cifrada) -> El buen funcionamiento de la misma aplicación
  • settings.crashlytics.com (TLS/SSL): No transmite datos personales aparentemente -> El buen funcionamiento de la misma aplicación
  • stats.pandora.com: Marca y modelo, versión de Android, Firmware y versión -> Estadísticas
  • autocomplete.pandora.com, cont-sv*-*.pandora.com, audio-sv*-t*-*.pandora.com: Marca y Modelo, versión de Android -> El buen funcionamiento de la misma aplicación
  • lt.andomedia.com: Versión de Android, código postal y año de nacimiento (datos ingresados en la cuenta de Pandora -> Publicidad
  • b.scorecardresearch.com: Marca y modelo, Versión de Android, Resolución de Pantalla -> Estadísticas
  • ad.doubleclick.net: Marca y modelo, versión de Android, Firmware y versión, resolución de pantalla, código postal y año de nacimiento, tipo de conexión, IMEI -> Publicidad

En este caso vemos una empresa/compañía mucho más seria en cuanto a como tratan los datos del usuario. todas las conexiones que pudiesen ser realmente relevantes a sus servidores van bajo TLS/SSL, y la contraseña a su vez va cifrada, no se transmite en texto plano. La mayoría de los datos personales que se transmiten son relativamente comprensibles para usos estadísticos no abusivos. La publicidad que incorpora no llega a ser abusiva y comprensible, teniendo en cuenta que ofrecen igualmente servicios premium sin ella. La oveja negra la pone doubleclick.net al recopilar el IMEI. Otros datos como el código postal, operador o edad tienen sentido si tenemos en cuenta que la aplicación está totalmente prohibida en la inmensa mayoría de los países, aunque esto no es tampoco excusa dado que el principal método de detección que dispone la aplicación es la IP del terminal para saber desde donde se realiza la conexión.

Aun así, dentro de lo malo no es lo más malo.

 

Instagram

  • instagram.com: Marca y Modelo, Versión de Android, Resolución de Pantalla, País, nombre de usuario de la cuenta de instagram -> Necesario para la propia aplicación
  • instagram.com (TLS/SSL): Marca y Modelo, Versión de Android, Resolución de Pantalla, País, nombre de usuario y contraseña de la cuenta de instagram -> Necesario para la propia aplicación
  • images.ak.instagram.com: Marca y Modelo, Versión de Android, Resolución de Pantalla, País, nombre de usuario de la cuenta de instagram -> Necesario para la propia aplicación
  • *.cloudfront.net: Marca y Modelo, Versión de Android, Resolución de Pantalla, País -> Necesario para la propia aplicación

Este es el primer ejemplo que vemos de aplicación que no transmite datos con fines estadísticos evidentes ni publicidad. No podemos decir que sea “perfecto” ya que el nombre de usuario de Instagram se transmite constantemente en conexiones no cifradas y es fácilmente interceptado. El correo electrónico asociado y la contraseña se transmiten en texto plano, aunque lo hacen en una conexión cifrada TLS/SSL ya hemos dicho que una contraseña jamás debe de transmitirse en texto plano, ni siquiera los servidores deben de conocerla, y esto es un error enorme. El resto de los datos que se transmiten están dentro de lo que puede ser comprensible no obstante. Hace un uso “responsable” de nuestros datos. pero ojo, no ovlidemos que Instagram pertenece a Facebook, lo que no recopilan por un lado, lo hacen sin duda por otro 😉

 

Google+

  • *.googleusercontent.com (TLS/SSL): Marca y modelo, Versión de Android, País -> Necesario para la propia aplicación
  • android.clients.google.com (TLS/SSL): Cuenta asociada al servicio, País e Idioma, sistema operativo del dispositivo (iOS, Android…) -> Necesario para la propia aplicación
  • www.googleapis.com (TLS/SSL): Marca y modelo, Versión de Android, País, sistema operativo del dispositivo, Tipo de conexión -> Necesario para la propia aplicación

 Lo primero que vemos es que todas las conexiones se realizan mediante TLS/SSL sin excepción, lo que hace realmente complicado a cualquiera que esté conectado a la misma red o en cualquier otro punto interceptar la conexión. Lo segundo que llama la atención es que no hay nada que nos indique que hay una recolección de datos estadísticos ni publicidad, al igual que pasaba con Instagram. Lo tercero es que Google no transmite la contraseña de nuestra cuenta de ninguna de las maneras, aun siendo todas las conexiones cifradas por TLS/SSL. Google usa en este caso un sistema de tokens de seguridad para autorizar el acceso al servicio, lo que hace de la aplicación de Google+ realmente segura y confiable para el usuario. En el caso de ser capaz de interceptar la conexión cifrada (que de por sí es complicado), cualquiera que la interceptase tan solo tendría acceso a los tokens de autentificación, lo cual implica no solo que dicho asaltante jamás podría conocer nuestra contraseña, sino que en el mejor de los casos solo podría acceder a nuestra cuenta de Google+ durante un breve período de tiempo con dichos tokens de seguridad clonando la sesión.

Los datos recopilados restantes, están dentro de lo normal teniendo en cuenta que el propio servicios los necesita. En este caso vemos que aunque Google+ hace uso evidentemente de datos de geolocalización, Google+ no recolecta dichos datos a menos que el usuario los necesite en el momento concreto. Recordemos que Facebook los envía simplemente con entrar en la aplicación, con independencia de que deseemos añadir nuestra ubicación o no.

De las 6 aplicaciones, Google con Google+ es la única empresa que se toma en serio la recopilación de datos, el tratamiento que les da y como los recoge.

 

Si recogiésemos en una tabla los datos expuestos y puntuásemos de forma global cada una de ellas, esto es lo que tendríamos:

Aplicación Número de Hosts Tipo de Conexión Datos Accedidos Cod. Datos Sensibles Valoración Total
Google+ 3 Segura Razonables Cifrados Muy Alta
Instagram 3 Parcial Razonables Texto Plano Alta
Pandora 6 Parcial Irrazonables Cifrados Media
Angry Birds 7 Insegura Razonables Texto Plano Media
Facebook 2 Segura Irrazonables Texto Plano Baja
Marvell War Heroes 38 Parcial Absurdos Texto Plano Muy Baja

 

Es cierto que no vemos una flagrante recolección de datos en cuanto acceso a la agenda, registro de llamadas, correos electrónicos… pero no olvidemos que estamos hablando de aplicaciones y empresas que están en lo más alto.

¿Si empresas como Facebook recopilan de forma indiscriminada datos como ubicaciones geográfica sin ser necesarias (hablamos de datos que dicen donde está el usuario en cada momento!!) o el listado de las cuentas de correo que tenemos en nuestro dispositivo simplemente por que sí (porqué tiene que saber Facebook las cuentas de correo que tengo o no), si empresas como Mogabe (de Marvell War Heroes) no tienen escrúpulo alguno con compartir nuestro IMEI (que identifica inequívocamente nuestro dispositivo) o nuestra dirección MAC (que también identifica nuestro dispositivo de forma inequívoca) con montones de servicios y proveedores que no conocemos… no se le pone los pelos de punta a más de uno saber que harán otras empresas o programadores que no están tan en el ojo del huracán?

Evidentemente es imposible testear cada aplicación y saber con exactitud que datos comparte. En cambio, sí podemos conocer que permisos requieren una aplicación, y con ello potencialmente que datos nuestros podrían compartir. Hay dos soluciones a esto. La primera y universal, si no entiendo el motivo por el cual una aplicación requiere acceso a mi agenda o a mis cuentas de correo o a… sencillamente no la instalo!! Me da exactamente igual lo útil que sea dicha aplicación o no lo sea, no puedo sencillamente fiarme de una aplicación (y evidentemente la empresa que está detrás) que no tiene que hacer uso de dichos permisos y los integra. Por suerte hay muchos programadores y empresas que se toman esto en serio, y son los primeros que en la medida de lo posible restringen siempre al máximo el acceso de su aplicación, intentando siempre usar los mínimos permisos posibles. Otros en cambio hacen totalmente lo contrario, añadir más y más…

La primera regla de oro es bien sencillo: Si crees que los permisos son abusivos intenta enterarte si son justificados, y si no logras una respuesta que te satisfaga o sencillamente no tienes respuesta alguna, no instales nada.

Los usuarios de Android si poseen su terminal rooteado tenemos herramientas auxiliares para mitigar en la medida de lo posible estas prácticas. Como dije al principio, una aplicación puede requerir permisos de acceso a todo si lo desea, pero si le bloqueamos el acceso a la red esos datos jamás podrán transmitirlos, con lo que el problema se soluciona de golpe. Hay dos formas efectivas de realizar esto, y en iOS es igualmente posible hacerlo en algunos casos (siempre que el terminal esté Jailbreak).

  • Usando un Firewall: En Android tenemos programas tan sencillos y simples como WallDroid (por poner un buen ejemplo) que nos permiten configurar listas blancas o negras de nuestras aplicaciones, de modo que si usamos por ejemplo una lista negra, cualquier aplicación marcada en ella tendrá denegado el acceso a internet. Eso sin contar que es posible seleccionar incluso si deseamos bloquear el acceso por WIFI o por datos, o los dos evidentemente. De este modo podemos bloquear cualquier aplicación que sabemos no requiere de Internet, mientras que podemos mantener todas las aplicaciones de sistemas o las que sabemos que son seguras conectadas. Este sistema es muy útil, pero tiene una deficiencia, y es que si la aplicación requiere para su funcionamiento conexión a internet no podremos usarla si la bloqueamos.
  • Modificando el archivo Hosts del sistema: Este es uno de los trucos más viejos que existe en el mundo para filtrar publicidad y otros. A día de hoy la inmensa mayoría de los sistemas poseen un archivo llamado hosts, este archivo no es más que un listado de resolución DNS prefijado, de modo que cuando hay que resolver la dirección IP de un host, si está en dicho archivo el sistema usa la especificada en dicho archivo. Esto es una herramienta potentísima, y su uso es muy extendido en muchos entornos.

    Gracias a este archivo podemos por ejemplo hacer que cada vez que nuestro navegador web pida ir a la web yahoo.com nos envíe realmente a google.es. ¿Como es esto posible? Muy sencillo, en cuanto solicitamos acceder a yahoo.com se envía una petición de resolución DNS que nos devolverá la IP de yahoo.com, que será del modo que accederemos a dicha web. Pero si en mi archivo hosts tengo una línea que diga lo siguiente:

    173.194.34.247 yahoo.com

    Lo que sucederá es que no habrá realmente una petición DNS que resuelva la IP de yahoo, sino que se usará la IP que está especificada en el archivo hosts cada vez que haya que resolver el dominio yahoo.com. El truco que existe es muy sencillo, y se usa para bloquear cualquier dominio concreto. Sencillamente se mapea el dominio que se quiera bloquear a la dirección de loopback (127.0.0.1). La dirección de loopback es la dirección de sí mismo. Es decir cuando un sistema usa la IP 127.0.0.1 en realidad se está llamando a si mismo. Si se redirige un dominio al propio dispositivo (dado que el dispositivo no posee los recursos que se están solicitando) el efecto es sencillamente que el acceso a dicho dominio se bloquea.

    El uso es evidente. Podemos crear un listado todo lo grande que queramos de dominios bloqueados. De este modo si sabemos que la aplicación A requiere acceso a los servidores X, Y y Z para su correcto funcionamiento y que adicionalmente accede a los servidores N, M, O para publicidad y recolección de datos, solo tenemos que añadir a nuestro archivo host 3 líneas, redirigiendo los 3 servidores a la dirección de loopback. De este modo no se bloquea la conexión completa de la aplicación, se bloquea la comunicación de nuestro dispositivo con ciertos servidores/dominios. La inmensa mayoría de aplicaciones usan siempre los mismos proveedores de publicidad o estadísticas, con lo que realmente bloquear uno para una aplicación implica del mismo modo que cualquier aplicación que use el mismo dominio también lo tendrá bloqueado, lo cual es doblemente provechoso.

    No obstante para el usuario medio esto tiene una complicación más grande que el uso de un Firewall (o IPtables), y es que el usuario tiene que saber que dominios bloquear o cuales no, y esto puede ser complicados para muchos. Existen multitud de listados en la red por suerte que los mantienen más o menos actualizado para bloquear estos proveedores y de paso bloquear igualmente la publicidad de las aplicaciones, pero si estoy en contra de los abusos de muchas compañías, creo que también es un abuso tomar medidas tales teniendo en cuenta que muchas empresas y particulares que usan la publicidad de un modo responsable se ven damnificados por ello. Si queremos un juego justo y limpio por parte de ellos, hay que jugar limpio tambien por nuestro lado, con lo que no recomiendo bloquear indiscriminadamente cualquier publicidad o servidor que recolecte datos, solo aquellos que realmente abusan (que son muchos muchos muchos).

 

Siempre que existan abusos hay que luchar de forma activa contra ellos, pero igualmente sin abusos. Una de las cosas que a día de hoy tiene más valor son los datos de los usuarios, y estos se han convertido en moneda común de cambio y venta, y es vergonzoso. Los usuarios parecen no importarles muchas veces esto, son inconscientes o simplemente están malinformados… pero la verdad es que se está llegando un punto en que los propios usuarios exponen su vida totalmente al público (o a empresas, el caso es el mismo). El mejor ejemplo es Facebook, las personas comparten lo que quieren, escriben, fotos, comentarios… y la mayoría cuando les dices: “Sabes que Facebook tiene propiedad sobre TODO lo que escribes y publicas en él?” se quedan sorprendido, no lo saben, pero tampoco hacen nada! Así la mayoría de las personas no tienen políticas de restricción de acceso a los datos, parece que es al revés! que los usuarios quieren que sus fotos, comentarios, vídeos… estén a disposición de todos, de amigos, de amigos de amigos… e incluso muchas veces de acceso público. Para mí eso es vender la vida de uno mismo a precio de saldo.

No estoy en contra de compartir de forma responsable nuestros datos, eso hace que podamos usar servicios que hace unos años sería imposible siquiera de imaginar! Vivimos una explosión tecnología sin precedentes… pero todo hay que hacerlo de forma responsable. Raro es el día o la semana que no nos enteramos de algún caso de imágenes comprometidas publicadas, frases o comentarios que transcienden por cualquier motivo… entonces es cuando todo el mundo se queja y pone el grito en el cielo, es cuando uno tiene un problema cuando parece que todo funciona mal!! Cuando en realidad el 99% de las veces es responsabilidad directa del usuario. No nos quejemos entonces si mañana o pasado en una entrevista de trabajo saben todo de nosotros, si transciende información que parecía imposible que nadie más conociese… porque a día de hoy TODA esta información, se compra y se vende. Facebook tiene derecho si así lo desea de vender los datos de cualquiera de sus usuarios a empresas de publicidad, de marketing… y a quien le de la gana, por la sencilla razón de que es dueño de todo lo que el usuario ha publicado o realizado en su red social, es así de sencillo. Las bases de datos de las empresas van aumentando día a día con nuestros datos, nuestras costumbres, nuestras preferencias… los productos que compramos, las web que visitamos…  y ahora las aplicaciones móviles les brindan la información que les faltaba!! Que dispositivo tiene, donde viven… si tienen el IMEI pueden incluso saber nombre y apellidos del usuario si tienen acceso a las bases de datos de IMEI (y por descontado que tendrán acceso de forma legítima o no).

¿Conclusión? Antes de quejarnos, cerremos la boca y entonemos un mea culpa, pongamos la medidas que realmente tenemos que poner, sin llegar por supuesto al fanatismo o a la obsesión.

Un saludo amigos.

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.