Ahora Google audita cómo te atacan localmente en Gmail

Buena entrada del maligno:

Cuando un servidor web quiere comunicarse con un web browser utilizar los HTTP Headers. Es en ellos donde puede configurar propiedades de funcionalidad o seguridad que quiere que se apliquen en el cliente o darle información sobre el tipo de contenido que se le está enviando y en qué formato. Esto le permite a los creadores de aplicaciones web controlar el entorno completo para, por ejemplo, hacer más difíciles los ataques locales a sus clientes, y Gmail ha comenzado a utilizarlas para ver cómo se está atacando su aplicación.

Figura 1: Google audita Gmail usando CSP

Entre la larga lista de cabeceras HTTP que se utilizan hoy en día, hay algunas estandarizadas y otras que son utilizadas por la industria en base a una necesidad puntual. Estas últimas, con el paso del tiempo, a veces acaban siendo estandarizadas para que todos los navegadores las tengan que implementar en sus características.

HTTP Headers no estándar para seguridad

Las cabeceras HTTP que no son estándar se identifican por medio de una X al comienzo del nombre. Así, por ejemplo, la HTTP Header X-Frame-Options que se utiliza para evitar que una página web de una determinada URL sea metida dentro de un frame para realizar un ataque de click-jacking, está aún sin estandarizar, aunque está implementada por la mayoría de las aplicaciones web - y por supuesto de Gmail -.

Otra de estas cabeceras de seguridad es la famosa X-XSS-Protection, utilizada para activar o desactivar el filtro Anti Cross-Site Scripting de los navegadores evitando situaciones en las que un usuario tenga un entorno inseguro o permitiendo al servidor deshabilitarlo puntualmente para evitar un fallo de funcionamiento.

Figura 2: X HTTP Headers de seguridad en Gmail

Otra muy común, tampoco estandarizada, es X-Content-Type-Options con valor nosniff, que le dice al navegador a evitar el reconocimiento de tipos MIME automático. Es decir, por defecto si un fichero es entregado desde el servidor como un Content-Type: Text/plain, y el contenido es una página HTML, los navegadores lo van a interpretar como un HTML y van a renderizar el código. Esto puede generar problemas de seguridad cuando alguien envía un fichero HTML malicioso como adjunto como fichero .TXT. Para evitar que el navegador haga ese descubrimiento automático de Content-Types, se utiliza, simplemente un HTTP Header como:

X-Content-Type-Options:nosniff.

Para terminar, no me quiero olvidar de las etiquetas que se utilizan para comunicarse con un cliente muy particular, como es el bot de Google y comunicarle cuáles son los deseos en cuanto a la indexación y cacheo, como ya vimos en los casos de Facebook o Gmail, mediante el uso de X-Robots-Tag.

Content Security Policy & Strict Transport Security

Este conjunto de propiedades, antes de estandarizarse podría encontrarse como X-Content-Security-Policies e incluso como X-Webkit-CSP. Después del proceso de estandarización, las HTTP Headers para reducir la superficie de ataque en el cliente son conocidas como CSP o Content Security Policy. Estas etiquetas permiten configurar muchos más detalles del cliente, orientados a evitar, por ejemplo, el uso de código Script en el medio del código HTML. Esto fuerza al desarrollador a colocar todo su código Script al principio, pero evita que se pueda explotar cualquier bug de XSS.

Figura 4: Configuración de CSP en Facebook

También se puede elegir de dónde se puede cargar el contenido externo de la web en el cliente, lo que reduce todos los posibles entornos de ataque por carga de contenido de terceros, o elegir qué tipo de plugins pueden ser ejecutados, lo que evita la explotación de bugs en plugins vulnerables - como algunas versiones de Flash que pudieran ser utilizadas hasta para hacer robo de cookies HTTP-Only -. El siguiente ejemplo le dice al cliente desde donde se pueden cargar los códigos script en una web desde el mismo código de la web y desde una URL concreta.

Content-Security-Policy: script-src 'self' https://js.misite.com

Se puede configurar un nivel de granularidad tal, que permitiría a un servidor web decidir desde que ubicación se pueden utilizar cada uno de los tipos de contenido y hasta cómo se pueden utilizar los WebSockets, anulando muchos de los ataques que necesitan controlar un padding en el cliente para atacar conexiones HTTPs. Todo esto se configura mediante un sencillo conjunto de variables y en HTML5 rocks tenéis muchos ejemplos de configuración granular. 

Figura 3: Política HSTS en Gmail

Otra de las características que se puede configurar con una etiqueta estándar conocida como Strict-Transport-Security HSTS es si el contenido está siendo mostrado sobre HTTPs o no, lo que anula muchas de las herramientas de SSLStrip para hacer ataques de red que no están teniendo en cuenta la limpieza de estas HTTP Headers.

CSP en modo reporting

Una de las características de las Content Security Policy es que no es necesario cambiar el funcionamiento de la aplicación si no estás seguro de haber configurado en las CSP Headers todo de forma correcta, y puedes establecer una etiqueta en modo reporting, como ha hecho Gmail. Esto se establece mediante un header de tipo Content-Security-Policy-Report-Only donde se establecen todos los parámetros de configuración de seguridad en el navegador.

Figura 5: CSP en modo Reporting en Gmail

Al final de esa etiqueta se le indica en el parámetro Report-URI la URL a la que se quiere que el navegador informe mediante un POST a esa dirección cada vez que se incumpla la política, pero que no bloquee ningún funcionamiento. Esto es para auditar si están bien configuradas las CSP y para descubrir qué partes de la aplicación son las que no cumplen.

Nosotros, por supuesto, en nuestro sistema de Pentesting Persistente Faast, buscamos desde hace tiempo todas las etiquetas citadas aquí, para informar a nuestros clientes cada vez que una web no está fortificada correctamente. Esto no siempre es un fallo de seguridad, pero sí que es una buena recomendación de seguridad para evitar la explotación de otros fallos más comunes.

Figura 6: Ver HTTP Headers de una petición

Si quieres ver los HTTP Headers que se envían en cada petición web, con Google Chrome puedes usar las Herramientas del Developer, entrar en Network, seleccionar un elemento y en el panel de la derecha seleccionar Headers.

Saludos Malignos!

Fuente: http://www.elladodelmal.com/2014/12/ahora-google-audita-como-te-atacan.html

MITM & SSL Strip con Meterpreter en remoto a través de VPN

 Hoy proponemos utilizar uno de los módulos de Borja Merino, que ha realizado para la comunidad Metasploit, y el cual nos permite montar una VPN entre la máquina atacante y víctima con el fin de que el tráfico de la máquina víctima pase por la del atacante consiguiendo un MITM. La idea es que la máquina del atacante pueda estar en otra red, en cualquier punto de Internet, y automáticamente el tráfico de la víctima, cuando quiera ir a Internet se envíe por el túnel VPN a nuestra máquina (atacante). Una vez el tráfico llegue a nuestra máquina la reenviaremos a Internet, pero de esta forma se puede visualizar el tráfico que se envía. Además, se puede utilizar la técnica SSL Strip con el fin de poder cambiar el protocolo HTTPS de la víctima por HTTP, y conseguir credenciales de Gmail, Outlook, etcétera. 

¿Qué necesitamos? Lo primero es instalar el servicio pptpd en nuestra máquina Kali. Para ello ejecutamos la sentencia apt-get install pptpd. Una vez instalado el servicio debemos tener en cuenta que el tráfico de la víctima pasará por nosotros, a través de un túnel VPN, por lo que necesitamos habilitar ip forwarding, como puede verse en la imagen. En el archivo pptpd.conf debemos habilitar el direccionamiento IP que se otorgará a los clientes, e indicar que dirección IP tendrá el host que hace VPN server, en este caso nosotros. 

Figura 1: Instalación y configuración del servicio

Además, debemos tener en cuenta que hay que configurar el usuario y la contraseña con la que se configura el servicio. Cuando el cliente quiera conectarse a la VPN deberá introducir el usuario pablo y la contraseña metasploit. Ahora que tenemos preparado el servicio, debemos configurar unas reglas en iptables para que todo quede configurado.

Se necesitan 3 reglas, las cuales tenemos en un fichero denominado reglas. La primera enmascara todo lo que sale por la interfaz de red "normal" de la máquina del atacante, en otras palabras realiza el cambio de dirección IP. La segunda regla hace un forward entre interfaces, todo lo que llega por la interfaz ppp0, la que conecta la VPN entre víctima y atacante, se reenvía a la interfaz de salida eth0 de la máquina del atacante. La tercera regla es la operación inversa de la segunda, todo lo llega desde Internet, con destino a la máquina víctima, se reenvía por ppp0. Básicamente esto es lo que está ocurriendo en iptables.

Figura 2: Configuración de reglas en iptables

El escenario es de post-explotación, es decir, necesitamos disponer de una sesión en una máquina remota para poder ejecutar esta técnica. Por esta razón, y como se puede ver en la imagen, necesitamos saber qué identificador de sesión disponemos en la máquina remota. En este caso, la sesión tiene id 1. 

Figura 3: Sesión de Meterpreter en una máquina remota

Una vez disponemos de la sesión en la máquina remota debemos ejecutar un background para no perder la sesión abierta. Con el comando use cargamos el módulo post/windows/manage/pptp_tunnel disponible en Metasploit. Si ejecutamos el comando show options podemos visualizar las diferentes opciones básicas que dispone el módulo. En este caso necesitamos configurar el usuario y contraseña y la dirección IP perteneciente a VPNHOST, que será nuestra dirección IP. 

Una vez configurado debemos ejecutar el comando run, y podemos visualizar como se establece la conexión desde la máquina vulnerada al servidor de VPN (nosotros). En este instante el MITM lo tenemos configurado, y el tráfico de la máquina remota pasará por nosotros. 

Figura 4: Configuración y ejecución del módulo post/windows/manage/pptp_tunnel

Si analizamos la máquina remota y las rutas configuradas (métricas) podemos observar que gracias a la ejecución del módulo se han añadido nuevas rutas con métricas bajas que salen por la interfaz de red que hemos configurado. Si nos fijamos en la interfaz 192.168.0.234, que corresponde con la interfaz de red de la VPN, sería la interfaz que la máquina vulnerada utilizará para salir a Internet. Gracias a esto se ha logrado el MITM en remoto. 

Figura 5: Rutas en la máquina remota

Si abrimos Wireshark en la máquina Kali (atacante) y configuramos el filtro HTTP, podemos ver que el tráfico de navegación de la máquina remota pasa por nosotros. En la captura que se muestra en la imagen podemos ver como el origen es la dirección IP 192.168.0.234 (máquina Windows remota) con destino Internet, en este caso el sitio web El Otro Lado, y se puede visualizar el usuario y contraseña introducido por la víctima.

Figura 6: Tráfico HTTP a través del MITM con la VPN

Como podemos ver, podríamos visualizar el tráfico HTTP, pero ¿Qué ocurre con el tráfico HTTPS? Fácilmente podemos acoplar la técnica SSL Strip en este caso, para ello debemos añadir una regla a iptables que es la siguiente iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 10000. El puerto 10000 puede ser sustituido por otro, en función de cómo configuremos el script de sslstrip. Ahora ejecutamos el comando sslstrip -w [fichero]. 

Figura 7: SSL Strip satisfactorio 

Tal y como puede visualizarse en la imagen, encontramos un usuario y contraseña en la máquina remota. El dominio es outlook, el cual en condiciones normales seríamos redirigidos a HTTPS, pero con esta técnica mantiene a la víctima en un contexto HTTP. Si la víctima no se da cuenta de este hecho, será víctima de un robo de identidad. Para aprender más sobre Metasploit y sus secretos os recomiendo el libro de Metasploit para Pentesters.

Fuente: http://www.flu-project.com/2014/12/mitm-ssl-strip-con-meterpreter-en.html

RPEF: la herramienta para backdoorizar routers domésticos

Seguro que todavía resuenan en vuestros oídos noticias sobre la presencia de backdoors en muchos modelos de routers. D-Link, Netis, Netgear, Linksys, Belkin, TRENDnet, MediaLink, Sercomm ... la lista es muy larga. 

Si tu también quieres hacerte el "chino" y vender en eBay tu viejo router con un regalo sorpresa añadido (es broma, no seais malos), puedes usar RPEF...

En la Defcon 20, Michael Coppola presentó una herramienta en Python llamada RPEF (Router Post-Exploitation Framework) con la que automatiza el proceso para añadir un backdoor en un buen número de firmwares para distintos modelos de routers SOHO:

- Belkin: F5D7230-4_v1xxx
- D-Link: DIR-601_1.01NA y DIR-601_2.01NA
- Linksys: WRT120N_1.0.07_(Build_02)
- NETGEAR: WGR614v10_1.0.2.26NA, WGR614v9_1.2.30NA, WNDR3700v1_1.0.16.98NA, WNDR3700v2_1.0.0.12 y WNR1000v3_1.0.2.26NA
- TRENDnet: TEW-651BR_v2.2R_2.00B12 y  TEW-652BRP_v3.2R_3.00B13

La sintaxis básica del script (python 2.6) es:

 

./rpef.py <firmware image> <output file> <payload>

 

Una vez que el firmware malicioso está actualizado/instalado y funcionando en el router, el atacante tendrá a su disposición un sniffer de red desde la línea de comandos o un bot que se puede conectar a un canal IRC especificado para lanzar una herramienta DDoS... interesante ¿verdad?

Página del proyecto: https://github.com/mncoppola/rpef

Fuente: http://www.hackplayers.com/2014/12/rpef-la-herramienta-para-backdoorizar-routers.html

70 Libros de Metal hallados en Jordania Podrían Cambiar la Historia Bíblica

---

3:06:55 PM

Un descubrimiento que puede ser el más grande desde el hallazgo de los Rollos del Mar Muerto, ha puesto en alerta a los estudiosos de la historia bíblica. Una antigua colección de 70 libros diminutos, encuadernados con alambres, podrían develar algunos de los secretos de los primeros días del Cristianismo.

Los especialistas están divididos en opiniones en cuanto a su autenticidad, pero comentan que de verificarse como auténticos pasarían a ser uno de los descubrimientos más importantes que rivalizaría en importancia con el de los Rollos del Mar Muerto en 1947. En páginas no más grandes que una tarjeta de crédito, se encuentran imágenes, símbolos y palabras que parecen hacer referencia al Mesías y, posiblemente, a la crucifixión y resurrección. Además, algunos de los libros se encuentran sellados, despertando la duda en los académicos sobre si podrían ser en realidad la colección perdida de códices mencionada en el Libro de las Revelaciones de la Biblia. Los libros fueron hallados hace 5 años en una cueva sita en una remota parte de Jordania donde se sabe que los refugiados cristianos huyeron luego de la caída de Jerusalén en el 70 d.C. Documentos importantes del mismo periodo han sido previamente descubiertos en la zona. Las pruebas metalúrgicas iniciales indican que algunos de los libros se remontarían a alguna fecha cercana al primer siglo Después de Cristo. Esta estimación se basa en la forma de corrosión que se presenta, la cual los expertos dicen que es imposible lograr artificialmente. Si esta fecha se verifica, los libros serían de los primeros de la Era Cristiana, anteriores a los escritos de San Pablo. El prospecto que podría contener historias contemporarias de los días finales de la vida de Jesús, ha entusiasmado a los estudiosos – aunque siguen tomando el tema con pinzas debido al hecho que previamente hubo casos de falsificaciones bastantes sofisticadas. David Elkington, un británico erudito en historia antigua de las religiones y arqueología, y uno de los pocos en examinar los libros, declaró que bien podrían ser “el descubrimiento más grande en la historia del Cristianismo”. “Es emocionante pensar que tenemos en las manos objetos que pudieron haber sido sostenidos por los primeros santos de la Iglesia”, agregó.

Pero los misterios que se encuentran en sus ancestrales páginas, no son el único acertijo a resolver. Hoy en día, sus orígenes también son un enigma. Luego de su descubrimiento por parte de un beduino jordano, el tesoro fue adquirido por un israelí, quien dijo haberlos contrabandeado fuera de la frontera hacia Israel, donde aún permanecen. De todas formas, el gobierno jordano se encuentra en tratativas desde los más altos niveles para repatriar y salvaguardar la colección. Philip Davies, profesor emérito de estudios bíblicos en la Universidad de Sheffield, declaró que había evidencia sólida que los libros tenían un origen cristiano debido a placas que muestran un mapa de la ciudad santa de Jerusalén. “Cuando vi eso me quedé estupefacto”, dijo. “Es claro que se trata de una imagen cristiana. Hay una cruz en primer plano, y detrás de ella lo que sería una tumba [de Jesús], un pequeño edificio con una apertura, y tras ello los muros de la ciudad. En otras partes de los libros también se describen murallas y es casi seguro que se refiere a las de Jerusalén. Es una crucifixión que se lleva a cabo fuera de los muros de la ciudad”, explicó el profesor. El equipo británico actual encargado del descubrimiento teme que su presente “guardián” israelí pueda pensar en vender algunos de los libros en el mercado negro, o peor… destruirlos. Pero el hombre que tiene los libros lo niega y afirma que han estado en su familia por 100 años. La Dra. Margaret Barker, ex presidente de la Sociedad para el Estudio del Antiguo Testamento, dijo: “El Libro de las Revelaciones habla sobre libros sellados que solo eran abiertos por el Mesías. Otros textos del mismo periodo cuentan historias sobre libros sellados conteniendo gran sabiduría y una tradición secreta pasada por Jesús a sus discípulos más cercanos. Ese es el contexto de este descubrimiento”

Fuente: http://mparalelos.com/site/70-libros-de-metal-hallados-en-jordania-podrian-cambiar-la-historia-biblica/

Cisc0wn: el 0wner/script para Cisco SNMP

Cisc0wn es un sencillo script que permite la enumeración SNMP, fuerza bruta, descarga de configuración y cracking de contraseñas de dispositivos con Cisco IOS. 

Fue publicado hace un par de años por NCC Group Plc bajo licencia AGPL y sigue siendo bastante efectivo. Requiere Metasploit, John the Ripper y snmpwalk (se recomienda usarlo en BT5 o Kali) y tiene las siguientes características:

- Comprueba si SNMP está habilitado en el router
- Realiza ataques de fuerza bruta para obtener comunidades de sólo lectura y de escritura (se puede editar el diccionario a utilizar en la cabecera del script)
- Enumera la información como la versión de IOS, nombre de host, tabla Arp, tabla de enrutamiento, lista de interfaces y las direcciones IP utilizando la cadena de comunidad RO o RW.
- Si se encuentra la comunidad RW entonces descarga la configuración del router de forma automática.
- A continuación, busca y muestra cualquier enable o contraseñas de telnet en texto claro.
- Si encuentra cualquier contraseña en tipo 7 la decodifica automáticamente.
- Muestra las contraseñas de tipo 5 y trata de crackearlas.

Uso:
git clone https://github.com/nccgroup/cisco-SNMP-enumeration.git
./cisc0wn.sh

 

Fuente: http://www.hackplayers.com/2015/03/cisc0wn-el-0wnerscript-para-cisco-snmp.html

Ravan: Hash Cracking distribuido en JavaScript

Ravan de Attack & Defence Labs es un crackeador de hashes distribuido que corre en JavaScript. Con esta herramienta cualquiera puede subir un hash para crackearlo y utilizar su navegador web compatible con HTML5 para buscar por fuerza bruta basándose en un charset configurable.

Además otros usuarios o workers pueden contribuir con su CPU para asistir en el proceso de cracking de tu hash, todos ellos manejados por supuesto por un servidor o master a través de un backend web. Esto es especialmente interesante si tienes múltiples equipos o un montón de amigos que quieran ayudarte ;-).

Actualmente soporta versiones plain o salted de los algoritmos MD5, SHA-1, SHA-256 y SHA-512.

Más información aquí.

 

Fuente: http://www.hackplayers.com/2010/12/ravan-hash-cracking-distribuido-en.html

IoT: ¿En qué punto estamos?

Cuando hemos oído hablar del Internet de las Cosas, siempre nos han contado que todo estará interconectado proporcionando un nuevo modelo de sociedad, dónde veremos nuevas ciudades, con nuevos servicios y posibilidades infinitas. Viendo algunos ejemplos de ciudades inteligentes en las que en función de la persona que se acerca a un cartel se cambia la publicidad que se muestra, un servicio de basuras en el que los contenedores avisan a las centrales de cuando los límites del contenedor están cercanos, un despertador que nos despierta y se conecta a la nevera para saber si tenemos que comprar comida y, además, se conecta a nuestro coche para saber si debemos echar gasolina, o un sistema de riego el cual funciona de forma inteligente en función de la temperatura que se tiene en la ciudad. Todos tenemos claro que el Internet de las Cosas está cambiando, y terminará cambiando la sociedad tal y como la conocemos, pero también debemos tener en mente que existen unos riesgos que debemos entender y a los que debemos enfrentarnos. Algunas de las cosas mencionadas ya existen, otras terminarán llegando, pero tenemos la tecnología para que sea posible.

Principalmente, y esto es una opinión que cada uno puede tener, podemos visualizar riesgos que afectan a la privacidad del consumidor y riesgos que afectan a la seguridad de la sociedad como ente consumidor. Muchos de los dispositivos que empezamos a tener conectados a Internet, como neveras, televisiones inteligentes o relojes, envían información de los hábitos de uso de sus propietarios con lo que se puede realizar una recolección de información y un profiling muy valioso para empresas, entidades de marketing, incluso gobiernos. Como ejemplo podemos incluir el de los casos de Smart TV que envían información de los programas que ven sus propietarios, de la navegación que realiza con la televisión, incluso se accede a los nombres de los archivos de los discos duros que se enchufan al televisor. Este ejemplo se destapó en el año 2013, cuando la marca LG aceptó que recopilaban este tipo de información, incluso cuando la función de recolección de información estaba deshabilitada. Esto supuso un gran escándalo, ya que aunque el usuario no quisiera compartir dicha información, ésta se compartía. 

En Junio del 2014 se publicó un ataque a Smart TV que podía afectar a millones de televisiones inteligentes. La condición es que fueran hbbTV y el ataque se conoció como botón rojo. El paper indica que el ataque no es de alto coste, ya que se necesitarían alrededor de 400 dólares, y tendría un alcance de 20.000 dispositivos. La idea fundamental es la inserción de código en cualquier sitio web a elección del usuario malicioso, haciéndose pasar por un proveedor. En términos simples, el ataque consiste en interceptar la señal que viaja por el aire del proveedor, manipularla y volver a emitirla para que llegue a los televisores. No se puede verificar la política del mismo origen. Estaríamos en un escenario de MiTM, el cual se puede juntar con un drone para barrer un área grande y realizar un ataque masivo contra televisiones inteligentes. 

El mes pasado, a principios de Febrero de 2015, nos hicimos eco de una noticia que salpicaba a la marca Samsung y sus televisores inteligentes. La funcionalidad que permite a los usuarios ejecutar acciones simplemente indicando a la televisión acciones con la voz, hace que la televisión esté constantemente escuchando lo que el usuario dice. Además, estos comandos de voz no son solo procesados por la televisión, ya que son enviados a servidores de terceros, lógicamente con otros fines. Si comparamos con los smartphones o con nuestros portátiles están realizando más o menos la misma función, ya que cuando nosotros estamos teniendo una conversación vía teléfono o vía skype, por ejemplo, nuestros dispositivos también nos escuchan. El problema viene que seguramente no sabemos cuando nos están escuchando, o que hacen con la información que escuchan. Por ejemplo, el sistema Siri de Apple puede estar constantemente escuchando con la opción "hey siri" u "oye siri". Además, la aplicación de Facebook puede habilitarnos el micrófono en cualquier momento mientras estemos utilizando la aplicación. No solo con lo que hablamos, si no también con lo que escribimos, el tema de la publicidad de Facebook o Gmail, parece que nunca estamos solos. Samsung indicaba en su política de uso que enviarían los datos a un tercero, la empresa Nuance, la cual convertía la voz a texto. Es cierto que Samsung promete que elimina esta información de inmediato, aunque la mayoría de las empresas que hacen esto almacenan la información durante gran cantidad de tiempo en sistemas de Big Data. Por supuesto, almacenar esta información puede ser un gran riesgo, ya que cada día observamos incidentes de seguridad y acceso a información privada y de consumidores. ¿Están las empresas haciendo un mal uso de la información? ¿Están las empresas poniendo en riesgo la información de sus consumidores? Samsung cita en su política de privacidad:

Por favor, tenga en cuenta que si sus palabras habladas incluyen información confidencial personal o de otro tipo, será capturada y transmitida a un tercero a través de Internet y se hará reconocimiento de voz sobre ella.

Figura 1: Política de privacidad

No todo son televisiones, hoy en día han entrado ya en juego, y mucho, los coches. Los coches más inteligentes que ya se encuentran en el mercado aportan funcionalidades para recoger información como velocidad, posición del volante, presión de neumáticos, presión del pedal, rutas por las que viaje el coche, etcétera. Son datos que pueden resultar de más o menos interés, pero que se recogen, y que para un profiling de una persona puede ser utilizada. Además, existen otras funcionalidades que ya pueden hacerse en remoto, como es la apertura de puertas del coche, encender un vehículo, o conectar otros dispositivos al vehículo. ¿Dónde está el limite con la seguridad de los ocupantes del vehículo? 

Podemos también comentar sobre relojes inteligentes, pulseras que recopilan información de nuestro ritmo cardíaco, que trackean por dónde nos movemos, por dónde salimos a correr, las calorías perdidas, etcétera. Después, esta información es subida a Internet y perdemos el control sobre ella. Además, en muchas ocasiones esta información es pública sin que el usuario sepa que esto ocurre, y poniendo en riesgo la privacidad de sus itinerarios por los que sale a correr.

Sí, el IoT afecta a la privacidad del consumidor debido a la recopilación de información de éste, de sus hábitos, de sus acciones, de sus gustos, esto puede afectar a la generalización del modelo IoT, ya que un usuario puede perder la confianza. La pérdida de confianza puede provocar que IoT no llegue a amoldarse en nuestras vidas, aunque las grandes marcas están haciendo grandes esfuerzos por introducir este tipo de dispositivos que conforman parte del ecosistema IoT. La seguridad es el otro gran factor que IoT debe cumplir, una seguridad por diseño que esté presente en la construcción de los sistemas y dispositivos que formarán parte de este gran ecosistema ubicuo. Hoy en día, existen empresas que no tienen en cuenta este requisito de la sociedad y, seguramente, serán penalizadas con la pérdida de confianza por parte de los usuarios. La seguridad poco a poco se ha convertido en un requisito innegociable, tanto para empresas como para usuarios de a pie. En la parte de seguridad tenemos a proveedor de Software y Hardware con gran cantidad de años de ventaja en estos desarrollos, los cuales aportan su experiencia, pero por el contrario tenemos a nuevos desarrolladores y empresas que se introducen en este mundo sin experiencia previa, y no tienen la seguridad de los dispositivos entre sus principales objetivos. Por otro lado, otra de las cuestiones a tener en cuenta es que algunos de los dispositivos son pequeños y tienen recursos muy limitados, por lo que su capacidad de cómputo y recursos son bajos, y en muchas ocasiones su bajo coste hace que sean desechables, teniendo una difícil actualización en caso de encontrarse una vulnerabilidad en alguno de ellos.   

Por supuesto, algunas de las cosas que se piden a las empresas es que utilicen lo que se conoce como seguridad por diseño y utilicen buenas prácticas en el ciclo de desarrollo del software o de los componentes. Otra de las cosas que se piden es minimizar la exposición de datos de los consumidores, o que se utilicen algunas medidas que hagan transparente el cómo se utilizan los datos de los usuarios. 

Como conclusión humilde, sencilla y simple, ¿Deberíamos regular los sistemas que escuchan? ¿Deberíamos regular el uso de la información que estos sistemas que nos rodean realizan de nuestras conductas, de nuestros hábitos, de nuestra forma de vida? Quizá hay demasiados agentes a nuestro alrededor recopilando información sobre lo que hacemos en el día a día, empezamos con ordenadores, continuamos con los smartphones y se han ido incorporando las televisiones, neveras, vehiculos... Suficiente información como para realizar un profiling de una persona exhaustivo, ¿Fantasía o realidad? 

Fuente: http://www.flu-project.com/2015/03/iot-en-que-punto-estamos.html