Supongo que todos tenéis en mente la historia de Matrix en la cabeza. Ese mundo donde las máquinas han subyugado cuasi por completo al ser humano convirtiéndolo en un fuente de energía de alto voltaje a cambio de cumplir yo necesidad de libre albedrío en un entorno mucho más poderoso que el físico. Al final, la vida es sueño y los sueños sueños son así que qué más da donde el hombre yerre, mientras lo haga a su libre albedrío y bajo los más profundos defectos de nuestra esencia humana.
Figura 1: Y las máquinas doblegarán al hombre
En una entrevista hace tiempo dije que estamos ante una de las últimas generaciones de dispositivos en las que el que dirige las acciones de nuestra vida sobre él somos nosotros. Luego esto cambiará. Primero las agendas tomaron el control de nuestro tiempo con alertas que nos recuerdan qué hacer en cada momento, luego los juegos en mundos online tomaron el control de tu tiempo libre enviándote alertas que te indican que debes volver a jugar porque una raza de alienígenas venidos de Zircon 3 está invadiendo el mundo donde has construido las minas de Especia con las que comercializas en el Sector 5, luego fue Google Now diciéndote cuándo salir de casa, por donde ir y con quién debes encontrarte en el Metro.
Figura 2: No Lusers 178 - Google Now intentando controlar la vida de JoseMariCariño
Ese futuro apocalíptico, que muchos abrazarían contentos para conseguir que un filete vuelva a saber a filete aunque sea en la vida de sus sueños, puede llegar poco a poco si seguimos pidiendo a la tecnología que mejore nuestra vida con falsos valores de entrada y objetivos. Un algoritmo está pensado para resolver un problema, y por ello necesita saber los valores de entrada y cuál es el objetivo al que se quiere llegar, y eso no lo sabemos ni nosotros.
¿Cuál es el fin? ¿El amor? ¿La felicidad como combinación de múltiples factores? ¿Satisfacer nuestros instintos y necesidades más básicas? ¿La realización personal? ¿Cumplir fase a fase los peldaños de la pirámide de Maslow o de algún otro filósofo? No lo sabemos ni nosotros a ciencia cierta y por ende cualquier programación de un objetivo basado en datos de entradas puede llevar a situaciones nefastas donde el ser humano solo obtiene orden, paz y tranquilidad.
Decía Bill Gates hace poco en una sesión de "Pregúntame lo que quieras" que esta preocupado por la inteligencia artificial si sigue creciendo y generando una superinteligencia. Primero las máquinas harán el trabajo por nosotros, luego lo planificarán.. y un día descubrirán que el bug que hay en esta existencia es una bacteria llamada "Ser Humano" que lo jode todo con sus bajezas. Es lo he añadido yo al final.
Figura 4: Declaraciones de Bill Gates sobre la superinteligenia
Sí, somos la plaga de este mundo. La bacteria salvaje que se hace daño a sí misma. Esa en la que ni el equilibrio de las especies es capaz de explicar porque alguien hace daño a otro sin motivo, incluso que no sabe cómo y por qué vive. Que no entiende las decisiones que toma. Que de tan compleja que es en sí misma no deja de ser simple y absurda llegando a tomar decisiones que nos dañan. Somos así y esos bugs permitirán que las maquinas acaben doblegando al hombre... ¿o no?
Hace poco más de dos semanas Mark Burnett, investigador de seguridad, publicó un fichero con 10 Millones de usuarios y contraseñas que puedes descargar desde este Torrent. El fichero en sí no es más que la recolección de usuarios y contraseñas, anonimizados lo más posible, que han sido recolectados de Internet utilizando diferentes técnicas, y que se ponen a disposición de investigadores que quieran utilizarlos en sus estudios.
Figura 1: Aquí tienes millones de usuarios y contraseñas para "jugar"
Cuando digo que el investigador los ha "anonimizado" lo más posible, es porque ha quitado de ellos el dominio de la empresa de referencia para que no se pueda saber, al menos de forma directa, dónde eran válidas esas credenciales. Sí que es cierto que si se busca por algunos dominios conocidos sale información que hace presuponer dónde podrían haberse estado utilizando dichas credenciales.
Figura 2: Grep Facebook sobre el fichero de usuarios y passwords
Si quieres tener un buen diccionario de usuarios o passwords para hacer ataques de fuerza bruta, estudios o para probar las passwords suprayectivas de un determinado sitio, este fichero está perfecto. Yo por pura curiosidad maligna he buscado qué passwords ponían los usuarios "chema" dumpeados en esta base de datos. Las hay muy curiosas.
Hace unos días tuve la fortuna de poder obtener el DNIe 3.0 directamente desde las oficinas de la Policía, que amablemente nos abrieron un hueco para poder tenerlo lo antes posible. Esta colaboración con la Policía se debe a que, como ya hemos anunciado en la nota de prensa de Telefónica, hemos trabajado para poder dotar a los sistemas Microsoft Windows - tanto en entorno personal, como en entorno empresarial con Active Directory - de la capacidad de autenticar usuarios con el DNIe 3.0.
Figura 1: Autenticación fuerte en Windows sin contraseñas: DNIe 3.0, biometría o NFC
Smart ID: Autenticación robusta en Windows sin contraseñas
Este producto nos permite dotar a las empresas de un servidor de autenticación robusta sin contraseñas que combina una buena cantidad de posibilidades que el cliente puede decidir utilizar. Estas van desde biometría con la huella dactilar integrada en Active Dirctory, dispositivos NFC, tarjetas RFID, SmartCards o electronic-IDs basados en SmartCards con certificados digitales no "compliance".
Con SmartID, una empresa podría autenticar a sus empleados, además de todos los mecanismos que ya por defecto trae la plataforma Windows, con tarjetas SmartCard con certificados digitales nocompliance con el sistema Microsoft Windows. Estas tarjetas con certificados digitales no "compliance" son, por ejemplo, sistemas complejos como el DNIe o el DNIe 3.0 que como os podéis imaginar, no tienen los campos que Microsoft Windows Active Directory utiliza para autenticar usuarios y por tanto hay que hacer un enrollment especial.
Figura 2: Sistemas soportados de autenticación en Smart ID
Gracias a SmartID, una empresa podría utilizar el DNIe o el DNIe 3.0 como credencial robusta para sus empleados. Pero no solo eso, con SmartID también se puede utilizar cualquier combinación de tarjeta RFID o conexión NFC en conjunción con PIN, o sin él, o incluso la huella dactilar del empleado utilizando las características biométricas de SmartID.
Pero no solo eso, sino que además en conjunción con Latch para Active Directory, una persona podría usar su DNIe 3.0, su huella dactilar biométrica, su tarjeta RFID, un PIN o una SmartCard, protegida con Latch. Todo a elección de la configuración empresarial, que es al final la que elige el mecanismo de seguridad más robusto para cada empleado.
La autenticación usando el DNI 3.0
El DNIe 3.0 tiene dos formas de trabajar, por contacto o "contact-less". Cuando se utiliza el DNIe 3.0 por contacto, el sistema funciona igual que lo hacía el DNIe anterior, es decir, como si fuera una SmartCard. El acceso a los datos básicos del DNIe 3.0 en ese caso se hacen sin necesidad de utilizar el PIN cuando los datos son los básicos, y con PIN cuando se quiere hacer uso de las capacidades criptográficas del DNIe 3.0.
Por el contrario, cuando se quiere acceder a los datos básicos vía "contact-less", es decir, utilizando la nueva capacidad NFC del DNIe 3.0 es necesario establecer un canal seguro NFC que se necesita el código CAN o el código MRZ. El primero, el código CAN es el número que se puede ver en la parte frontal del DNIe 3.0. El código MRZ es el va por detrás del DNIe 3.0 y que es del mismo tipo que tiene el DNIe "clásico" por detrás.
Figura 3: Estructura del DNIe 3.0
Con una conexión NFC y, usando uno de estos dos códigos, se puede establecer un canal seguro para consultar los datos básicos. La forma en la que se crea ese canal no es igual dependiendo del código que se vaya a utilizar, pero esos son detalles técnicos que nosotros hemos tenido que resolver en SmartID para dar todas las posibilidades.
Por último, si quieres utilizar las capacidades criptográficas del DNIe 3.0 por medio de NFC, además de establecer el canal seguro con el CAN o el código MRZ, tendrías después que proporcionar el PIN del DNIe 3.0 para poder usar las claves de firma.
Smart ID + Latch
Por supuesto, para que esto acabe de ser robusto y sin contraseñas, además de SmartID en la autenticación Windows para usar biometría, RFID, NFC, DNIe o DNIe 3.0 se puede proteger todo con Latch, haciendo que el uso de la identidad esté controlada. Y todo esto, es lo que tenéis en el siguiente vídeo que os hemos preparado en 5 minutos esta mañana en Eleven Paths.
Figura 4: Vídeo demostrativo de SmartID con DNIe 3.0, RFID, NFC, Biometría y Latch
Si quieres verlo en detalle, esta semana estaremos en el Mobile World Congress de Barcelona en el Stand de Telefónica, así que te pasas por allí, buscas un gorro y te hacemos una demo en el momento.
Se acerca la fecha de comienzo de la semana de la RootedCON y con ella el comienzo de los RootedLabs, donde como ya os anuncié planificamos siete seminarios sobre seguridad informática y técnicas de hacking. A día de hoy, actualizado hace unos minutos, el número de plazas disponibles es solo de 10, pero si vas a venir a la RootedCON, te merece la pena aprovechar esta oportunidad, ya que conseguir estos seminarios de nivel técnico tan algo en el futuro y a estos precios va a ser complicado.
Figura 1: Solo 10 plazas disponibles en los rootedLabs
Si estás planificando una semana de formación, aún puedes apuntarte a un seminario el lunes otro el martes y otro el miércoles, pero debes darte mucha prisa en el registro de las plazas. Como veis, aún quedan plazas en el de Pentesting y Hacking con Python, en el Laboratorio de Metasploit, en el que se ha dedicado a la Automatización del procesamiento de OSINT para Vigilar Internet y en el de Construcción de una Antena Robotizada WiFi, para los especialistas en pentesting y amantes de la auditoría WiFi.
Figura 2: Distribución de plazas disponibles en RootedLabs
Toda la información de registro la tienes en la web de los RootedLabs, pero recuerda que quedan muy pocas plazas y muy poco tiempo para que comiencen. Reserva tu plaza cuanto antes. Nos vemos en la RootedCON.
Hace tiempo atrás hablaba acerca de los peligros que se pueden ocasionar al dar permisos a una aplicación en Facebook y sobre cómo una aplicación puede quedar vulnerable al contener el dominio de la misma un bug de XSS, ya que podría permitir a un tercero poder redireccionar un Access_Token a otro sitio. Siguiendo con este mismo tema, es decir, el de los permisos que se les dan a las distintas aplicaciones, hoy os vengo a contar un caso de una aplicación en particular de Instragram, en la que muchos usuarios han confiado, y le han dado los permisos necesarios para realizar las acciones básicas como dar me gusta, empezar a seguir a un usuario, dejar de seguir a otro, comentar etc...
Figura 1: Growth Hacking en Instagram: Cómo robarle followers a las apps
Una mala gestión de la seguridad en las apps de Instagram podría permitirte ser popular en Instagram sin ni si quiera postear fotos sexy.
Growth Hacking en servicios online
Las técnicas de Growth Hacking se hicieron populares tiempo atrás desde que algunas personas como Mark Zuckerberg, aprovecharon sus conocimientos de hacking para hacer popular sus servicios. Esto lo hizo en sus inicios el creador de Facebook para conseguir que sus portales tuvieran datos de los estudiantes a los que iba dirigido su servicio. Desde entonces, hay muchos que han buscado cómo hacer popular servicios en la red, como el caso de la empresa que vendía Likes de Facebook y que llegó a cambiarse el nombre por el de Mark Zuckerberg, o los que se dedican a vender followers en Twitter. Por supuesto, los equipos de seguridad de Twitter, Facebook, etcétera, intentan detectar este tipo de prácticas y bloquearlas.
Figura 2: El "empresario" que vendía likes que se cambió el nombre a Mark Zuckerberg
Por supuesto, muchos de esos crecimientos no valen nada más que para alimentar el ego o hacer un marketing, pero también sirven para manipular índices de popularidad y salir en otras recomendaciones que puedan atraer más followers reales. Todo cuenta cuando se quiere obtener la máxima difusión de algo en todas las redes. En el caso de hoy, vamos a ver un ejemplo en el que se puede ver cómo un fallo de seguridad en las apps de Instagram pueden hacer que cualquiera se aproveche de ellas, y los usuarios que han dado confianza a las apps acaben siguiendo a gente que no desean.
Un ejemplo de Growth Hacking en Instagram por culpa de una app
El desarrollador de esta app de Instagram en concreto, parece que se ha olvidado que un Access_Token entregado desde una cuenta de Instagram es un código de acceso que se genera cuando un usuario le da permiso a una aplicación para realizar determinadas acciones y que si alguien ajeno a la aplicación consiguiera tal código, éste podría realizar esas acciones a su gusto, tomando control sobre las acciones permitidas por ese usuario.
Realizando unas investigaciones, se me cruzó la idea de que haciendo un poco de Hacking con Buscadores, podría llegar a generar una búsqueda con parte de la query que se utiliza cuando se quiere obtener ciertos datos con un Access_Token desde una API. Como era de esperar, la búsqueda arrojó bastantes resultados pero no solo eso… En los resultados obtenidos se pueden ver Access_Tokens en texto plano, todos indexados por Google y todos provenientes de un sitio en particular, algo bastante curioso.
Figura 3: Access_Tokens en los resultados de Google
Está claro que Instagr.in tiene problemas con la indexación en los buscadores al igual que le pasó a Facebook. Ingresé en algunos de los enlaces mostrados en los resultados de la búsqueda de Google - que como veis hay millones, y echándole un ojo al código de fuente pude localizar en el parámetro next_url de una de ellos un Access_Token. Lo curioso recargando la pagina aparecía otro distinto al anterior. Es decir, era como si dinámicamente se mostrase un Acces_Token distinto cada vez que se realiza una petición al sitio.
Figura 4: Access_Token de Instagram en el código fuente en el parámetro next_url
El único detalle es que no se obtiene el Access_Token del perfil el cual se navega, sino más bien uno aleatorio, o al menos eso es lo que parece. En cualquier caso, solo quedaba comprobar que estos códigos de Access_Token fueran validos y que no hubieran expirado o sido cancelados aún.
Figura 5: Validación del Access_Token en el API de Instagram para desarrolladores
Para ello me dirigí a la API para desarrolladores de Instagram, e hice un GET con el Access_Token obtenido sobre alguna de las acciones permitidas, devolviéndoseme como resultado un OK de parte de la API, pudiendo así, si hubiese querido, realizar acciones con la cuenta de quien fuera el usuario correspondiente a tal Access_Token. Esto es igual de malo, que cuando las apps llevan los tokens de las cuentas hardcodeados.
Prueba de Concepto de Growth Hacking con Instagram
Conociendo esto, se podría hacer un script que pida el código HTML de la pagina y una vez obtenido se la extraiga de ella el valor mostrado de Access_Token y así ir almacenando códigos en una base de datos. Luego, quien sabe, tal vez ofrecer un servicio de seguidores de Instagram, lanzar un mensaje masivo, darle presencia a algún perfil, etcétera. He hecho un pequeño vídeo de prueba con este script en el que se puede ver cómo una cuenta, sin ningún comentario, va siguiente de Followers.
Figura 6: Prueba de Concepto de Growth Hacking en Instagram
Con esto visto, se podría hacer un proceso para construir una base de datos en la que se averigüe a quién pertenece cada Access_Token. Basta con crear una cuenta en Instagram sin ningún follower, usar el Access_Token para seguir a la cuenta y ver quién es el nuevo follower de esa cuenta. Hecho esto, se podría tener bien segmentada la base de datos con las propiedades de todas las cuentas que tal vez como tú, tus amigos o personas de empresas, han confiado los permisos de su cuenta a este tipo de aplicaciones. Ten cuidado con las aplicaciones que aceptas en Instagram o en cualquier otra de tus identidades. Autor: Ariel Ignacio La Cono Email: msignataur@hotmail.com Twitter: @IgnacioLaCono
Las técnicas para sacar información de los terminales smartphone son cada vez más singulares. La búsqueda de side-chanels que permitan medir efectos para poder extraer sus causas llevan a que, por ejemplo, se puedan crear huellas digitales por medio de los acelerómetros, o a que se pueda crear un canal de comunicaciones por medio de impulsos magnéticos. Ayer, el estudio que me leí, y que me encantó, hablaba de cómo crear un canal paralelo midiendo el consumo de batería de un terminal para saber exactamente en qué ubicación GPS se encuentra un smartphone en un determinado momento.
Figura 1: Como una app puede espiar tu ubicación por el consumo de batería de tu smartphone
La técnica se ha llamado PowerSpy y la han publicado este mes de febrero un grupo de investigadores de la Universidad de Stanford y se basa en el concepto de que un dispositivo consume más o menos batería dependiendo de lo lejos que se encuentra de la antena de comunicaciones con la que está conectado
Figura 2: Paper que describe el estudio de PowerSpy
Es decir, si está lejos de la antena se preocupa de emitir una señal mayor, lo que provoca un mayor consumo de batería y cuando está cerca, reduce la potencia de la señal, consumiendo menos batería por tanto. En la siguiente imagen se puede ver como mediciones en días distintos hacen que los resultados sean consistentes.
Figura 3: Mediciones en días distintos dan resultados estables
Lo que los investigadores hicieron medir en un campus el consumo de batería que se producía en rutas marcadas entre distintos puntos. En estas mediciones, realizadas con una app instalada en el dispositivo, lo más importante es conocer el incremento o decremento en el consumo, ya que cada terminal podría tener un consumo absoluto mayor o menor en función de las apps que estuviera ejecutando o las conexiones de red que tuviera activas (Bluetooth, WiFi, etcétera).
Figura 4: Para dos móviles iguales y dos móviles distintos, el consumo es similar en la misma ruta
Una vez medidas estas curvas de consumo, con una app instalada en un nuevo dispositivo se puede saber en qué sitio exacto se encuentra en función de cuál es el patrón de consumo de batería, pudiendo medir no solo su ubicación, sino la ruta completa que esté realizando.
Figura 5: Cálculo de las rutas seguidas en función de las mediciones de batería
Cómo crear servicios de tracking con Apps que midan el consumo de batería
Esto abre una nueva forma de, por ejemplo, tracking de usuarios en un centro comercial con una app, o para conocer dónde se encuentra una persona concreta si eres capaz de realizar estas mediciones masivamente. Es decir, imaginad que alguien con una app muy popular que tuviera acceso al GPS - a la que llamaremos APP_MEDIDORA - decidiera realizar mediciones masivas de consumo de baterías para vincular el consumo de batería a ubicaciones GPS - por ejemplo Facebook -.A partir de ese momento tendrían el patrón exacto de consumo en cada ubicación almacenado en un Big Data que podrían comercializar por medio de un servicio.
Figura 6: Esquema de espionaje con medición de consumo de batería
La idea es que una app que quisiera espiarte - a la que llamaremos APP_ESPÍA - solo debería medir el consumo de la batería de tu terminal y enviarlo al servicio que comercializa la APP_MEDIDORA para recibir una ubicación GPS concreta. Es decir, te estaría espiando sin levantar la más mínima sospecha.
Conclusión
Visto esto, pronto tendremos que ver cómo reaccionan los fabricantes de sistemas operativos móviles - Android, iOS, Windows Phone, etcétera - para restringir los permisos, pero también afecta, por supuesto, a sistemas más privados tipo BlackPhone ya que cualquier app podría estar revelando tu información con solo realizar mediciones de consumo de batería. ¿A cuántas apps le das permiso de acceso a GPS? A algunas. ¿Cuántas miden tu consumo de batería? ...
Hace ya varios días que anunciamos cuáles fueron los ganadores del Latch Plugin Contest, pero quería esperar un tiempo para construir un artículo con más información sobre los trabajos que se han publicado, que han sido de grandísima calidad y originalidad. Este es un resumen de cuáles son los que al final se llevaron los dólares del concurso, y algunos otros más que también participaron y merece la pena que los conozcáis, aquí van.
Figura 1: Los Plugins de Latch que se llevan los premios y más hacks
El Primer Premio, dotado con 10.000 USD se lo entregamos a Carlos Rodriguez, por hacer una Gema para poder integrar Latch en las aplicaciones construidas con Devise en Rails. Como ya se explicó, de este trabajo nos gustó mucho la calidad de la integración y lo bien hecho que estaba. Ahora estamos trabajando en procesos de QA internos para que pase a ser un plugin oficial de Latch en los próximos días.
El Segundo Premio se lo dimos a Gregorio Juliana, por haber hecho una integración de Latch con el sistema de autenticación y apertura electrónica de puertas en ubicaciones compartidas. Este entorno permite la autenticación con dispositivos NFC o con el DNIe y ahora está integrado con Latch. Hecho en la universidad, nos pareció una idea muy curiosa y muy hacker de integrar la tecnología por parte de los estudiantes.
El Tercer Premio se lo dimos a Javier, por hacer una integración muy profesional y trabajada de Latch para la plataforma LifeRay. Si en tu empresa estáis utilizando este gestor de contenidos, desde ya puedes utilizar este plugin. Estará disponible en la web de Latch en unos pocos días.
Figura 2: Protección de entornos de LifeRay con Latch
Aunque los premios eran solo tres, al final, como la deliberación fue complicada, acabamos por dar una mención especial de cuarto premio a la integración que hizo David Garduño de Latch en la Asterisk Server. Con esta integración se pueden controlar las llamadas que se realizan gestionando los permisos de la centralita desde Latch. Aquí en el vídeo podéis ver un ejemplo de su funcionamiento.
Figura 3: Controlando llamadas VoiP en Asterisk con Latch
El número de plugins e integraciones fue bastante alto y hubo algunos muy originales que nos llamaron la atención. Como ya os digo, no fue nada fácil el momento de dar los premios. Juan Berzal, utilizando el plugin de Latch para Symfony2 hicieron una demostración de cómo controlar un juego en web con Latch. Enrique Mendoza y el equipo de Cuaqea hicieron una integración de Latch para controlar aplicaciones Play. Ezequiel Tavella hizo una integración de Latch con Hostapd para controlar los accesos a las redes WiFi mediante el uso de Latch, aquí podéis ver le vídeo con una demostración.
Figura 4: Control de accesos a redes WiFi con Hostapd y Latch
Joan nos hizo un hack a la app de Android para controlar la apertura y cierre de los cerrojos de nuestra app de Latch para Android dependiendo de la ubicación GPS en la que te encuentres, que también nos encantó. Carlos Martín, del equipo de OpenNebula (el fantastico proyecto OpenSource para la creación de entornos de Cloud Privada), nos hizo un driver de autenticación Latch en la plataforma de gran calidad, aquí podéis ver la explicación del funcionamiento.
Figura 5: Integración de Latch en OpenNebula
La lista es larga. También se incluyó como plugin de autenticación en la plataforma OSClass, y podéis ver los vídeotutoriales de Instalación, de administración y de uso de Latch en OSClass. Antonio Sánchez Padial nos hizo una original integración de Latch con un mod de MineCraft, Francisco Muñoz hizo una integración de Latch en Windows para controlar el acceso a las carpetas y a los dispositivos USB mediante el uso de Latch e Ignacio Cabra un integración con el Firewall de Windows perfecta para ponerse en modo "Do not Disturb" o para habilitar el control parental del uso de Internet. Al estilo de la integración que hicimos nosotros con IPTables en Linux.
Figura 6: Control del Firewall de Windows con Latch
Aún fueron más, pero he querido hacer una selección de algunos de ellos. A todos los que habéis participado con vuestras implementaciones e ideas, os agradecemos el esfuerzo y el cariño que habéis puesto. Nos alegra ver la cantidad de cosas que se pueden hacer con nuestra plataforma Latch y el tiempo que le habéis dedicado a construir vuestros plugins. El más sincero agradecimiento del equipo de Eleven Paths y el mío en particular.
La intención de este articulo no es otra que la de alertar y concienciar sobre la cantidad de datos que almacenan sobre nosotros a los usuarios de los servicios que ofrece Google, mediante unos consejos prácticos para evitar que un posible atacante, ante el robo de una cuenta de Google, se haga con la menor cantidad de información posible de nuestros historiales. Hay que tener presente que las cuentas de Google se pueden robar en situaciones de bugs o descuidos en el uso de redes inseguras - como el ejemplo de un ataque Bridging HTTP(IPv6)-HTTPs(IPv4), con un ataque de WPAD que hacía Evil FOCA, etcétera... -, y que las medidas basadas en características de conexión que pueden llevar a que al atacante se le bloquee el acceso no son difíciles de saltar.
Figura 1: Cómo eliminar y desactivar el Historial de Navegación de tu cuenta Google
Lo mejor es que pongas Google Authenticator en tu cuenta, pero aún así, ninguna medida es 100 % segura, así que aquí van unos consejos para limpiar los datos que estén almacenados en tu cuenta sobre tu navegación.
El Historial de Navegación de Google
Todo aquel que tenga una cuenta Google sabe o debería de saber, que existe un registro de la actividad que realizamos a diario vía web como la que realizamos desde nuestros dispositivos móviles Android o Google Chrome, si tenemos la sesión de Google abierta. Esto lo convierte en una fuente de información muy valiosa para un atacante a la hora de realizar ataques de ingeniería social o watering hole, pero especialmente para que afecte a tu privacidad personal muy seriamente. Si quieres saber todo lo que Google guarda en ese historial, solo debes ir a https://history.google.com/history y comprobarlo.
Figura 2: Historial de Navegación Web en tu cuenta Google
Aparte de tener acceso al uso de la cuenta con un robo de credenciales, habría que sumarle el acceso total al historial de la actividad en la web. Por el mero hecho de no borrarlo y desactivarlo por completo, se le esta facilitando al máximo el trabajo a un atacante dando así rienda suelta a realizar un estudio mucho mas profundo que si no lo tuviera, de todos y cada uno de los sitios que hayamos visitado desde que se creó la cuenta hasta el día de hoy.
Todo muy bien detallado y clasificado por secciones, por año, día, hora, minutos y segundos además de por supuesto la geolocalización. Con estos datos se puede averiguar, nuestros gustos, amistades, otras cuentas online de las diferentes redes sociales en las que podamos estar registrados, etc...
Figura 3: Actividad reciente de tu cuenta, almacenado desde el inicio
Por eso es importante tener contraseñas diferentes para cada cuenta, incluso, varias cuentas de correo electrónico diferentes para cada fin en las que se maneje información mas sensible a lo normal, como por ejemplo la de una empresa o negocio. Reutilizar contraseñas puede hacer que con la información de una cuenta robada - como por ejemplo este historial - puedan ir cayendo todas en serie.
Borrar y desactivar el Historial de Navegación
La eliminación y desactivación definitiva del registro del historial de tu cuenta Google se puede hacer desde esta misma parte de tu cuenta Google, aunque he de decir que no va a ser una labor fácil y rápida, sino todo lo contrario. Si por suerte o por desgracia hace mucho tiempo que posees la misma cuenta, se puede convertir en algo bastante tedioso, monótono y aburrido al mismo tiempo, así que paciencia que es la madre de las ciencias. Si de lo contrario hace poco que la creaste como yo, pues en mi caso, llegue hasta septiembre del 2010 si no recuerdo mal.
La manera de hacerlo es ir la opción en la parte superior derecha donde hay un botón de configuración en forma de engranaje allí puedes seleccionar la última opción para borrar todos los elementos de una sola vez. Una vez hecho esto, entra en la primera 'Configuración' para deshabilitar el guardado de estos datos en el futuro.
Figura 4: Configuración para desactivar el historial de navegación en tu cuenta Google
Te mostrara una imagen con la opción de desactivar el registro del historial de navegación de Google Chrome, marca la casilla 'Incluir el historial de Chrome...' esto es opcional, pero si recomendable ya que de no hacerlo dejarías el proceso a medias, y luego pulsa en 'Detener' la imagen se pondrá en blanco y negro.
Figura 5: Detener el Historial de Navegación Web
Ahora pulsa en la opción 3 donde dice, 'Administrar historial' para retroceder al panel principal y deberás ver el cuadro de diálogo que puedes ver a continuación y que te invita a activarlo. Ya lo tienes desactivado.
Figura 6: Administración del Historial de Navegación Web
Siguientes pasos
Una vez hecho todo esto, te preguntarás... ¿ya esta? Más o menos has conseguido quitar una parte de tu historial de datos, pero con esto solo se da por concluido el proceso de eliminación del historial de Google asociado a tu navegación. Pero todavía hay muchos datos tuyos en tu cuenta, y si quieres dejar la menor cantidad de información disponible deberías hacer lo mismo con tus cuentas de correo, y no almacenar ningún mensaje que contenga información sensible en el servidor Gmail. Yo recomiendo descargar lo que quieras guardar a tu equipo personal en un sitio seguro, por ejemplo en un HDD externo cifrado. Recuerda que lo puedes administrar y automatizar vía IMAP.
Realizando todo este proceso no quiere decir que con ello consigamos borrar o evitar que se siga registrando nuestra huella digital online, y solo tiene como objetivo que en caso de robo de una cuenta Google una atacante se haga con la menor cantidad de información en la medida de lo posible.
Sin lugar a dudas, Python se ha convertido en un lenguaje de referencia en el mundo de la seguridad informática y el hacking. Cada vez es más común que herramientas que se usan en el mundo profesional estén escritas en Python, debido a la cantidad de librerías existentes hoy en día y la facilidad que tiene el lenguaje para ser escrito y comprendido. Estas navidades pasadas en 0xWord publicamos el libro de Python para Pentesters, que ayuda a conocer el lenguaje desde un punto de vista de seguridad, y ahora ampliamos la cobertura a este lenguaje con un texto para los que quieran seguir sacándole partido con Hacking con Python.
En este libro, de casi 300 páginas, el autor toca cuatro grandes temas con Python. El primero de ellos explica algunos conceptos de Ataques de Red en el Segmento Local y como gestionar VPNs o Shells ICMP para trabajar en un ataque. El segundo bloque está dedicado a Fuzzing y Depuración de Software, donde habla de cómo hacer hooking de funciones, como hacer debugging de aplicaciones, como analizar un binario con Cuckoo Sandbox o eludir las firmas de los antivirus. El Tercer bloque del libro está dedicado al Anonimato, en donde se explica como trabajar con la red TOR, Freenet o I2P. Por último, el bloque cuarto está centrado en los APTs (Advanced Persistent Threats). Para que podáis echar un vistazo en más detalle al contenido concreto del libro, os he subido el índice de contenidos del libor a SlideShare, así que lo podéis ver punto por punto.
Si queréis saber más de Python y sacarle todo el partido, Daniel Echeverri va a dar un seminario en los tres días de los RootedLabs, de los que ya quedan muy pocas plazas. Ahora mismo solo quedan disponibles los siguientes seminarios:
Hace unos días un lector - gracias Juan - me contó que se había topado con un mensaje de error en un servidor web que mostraba mucha más información que la deseada. Como nosotros tenemos un plugin de detección de leaks de información en mensajes de error dentro de nuestra plataforma de pentesting persistente Faast, le pedí a mi equipo que lo añadieran, al mismo tiempo que miré por Internet a ver si localizaba algo más de información para escribiros este post.
Figura 1: Un leak de información en un Servidor Web CGI de más de 20 años
Cuando vi la URL del leak de información me llamó mucho la atención, pues como podéis ver en la imagen siguiente se produce al pasar un parámetro erróneo a un fichero Server-Side con extensión .EXE. Si llevas tiempo en la web, probablemente te habrás dado cuenta de que no es muy habitual que una aplicación de lado del servidor tenga extensión .EXE. La explicación es bastante sencilla, es un motor de aplicaciones en modo CGI (Common Gateway Interface) que se ejecuta sobre un servidor Windows.
Figura 2: El mensaje de error al recibir un parámetro erróneo
El uso de este tipo de aplicaciones Server-Side en modo CGI no son muy comunes hoy en día, y ya han jugado malas pasadas a los administradores este tipo de prácticas debido a los ataques de Remote Command Injection, como se vio en el caso de PHP corriendo en modo CGI. Me llevó unos segundos más de lo habitual el localizar la web de la empresa que fabrica este software ya que, como podéis ver, lleva desarrollándose desde antes de Windows 95. Es decir, tiene 21 años de antigüedad.
El leak de información no es muy raro, no solo muestra lo que se ve en la Figura 2, sino que si haces scroll sale mucha más información del resto del sistema, pudiendo conocer en detalle todas las variables de entorno y rutas del servidor. Esto es probablemente porque este software inicialmente correría en Intranets muy cuidadas y no en el Internet beligerante de hoy en día donde cualquier detalle puede ser utilizado por un atacante en tu contra.
Figura 4: Datos de las variables en entorno CGI en el mensaje de error
Esto no debería ser así, y es verdad que en algunas de las instalaciones que he visto en Internet estaba protegido, pero no en todas, siendo casi como el PHP Info de las arquitecturas LAMP que tantas veces nos encontramos haciendo pentesting.
Figura 5: Variables de entrono del servidor web mostradas en el mensaje de error
Hacer un dork para localizar estos sitios y hacer hacking con buscadores es bastante sencillo, pero me llamó la atención la cantidad de sitios que lo utilizan, ya que hay más de 10.000 URLs indexadas en el índice primario de Google. No debe funcionar nada mal este sistema, ya que no muchos programas pueden presumir de aguantar tanto tiempo.
Figura 6: Dork para localizar servidores TradeWinds
La noticia de ayer sin duda fue la publicación de John Matherly de que había ,descubierto que un fabricante de routers de comunicación estaba sirviendo a empresas Telcos e ISPs routers con una clave de cifrado SSH por defecto. Entre las empresas afectadas por este problema se encuentra Telefónica de España y por eso John había tenido la deferencia de comunicarse conmigo por Twitter y contármelo. Por supuesto, desde primera hora de la mañana los equipos que llevan la relación con los proveedores de routers y los que se ocupan de la seguridad en Telefónica de España se pusieron manos a la obra para medir el alcance del problema.
Figura 1: Routers Comtrend VG8050 con claves SSH duplicadas
Yo os hablo en este post como usuario y cliente de Telefónica de España, y no como portavoz de nada, ya que a pesar de que trabajo en el Grupo Telefónica, mi responsabilidad no recae en la parte de seguridad interna de las conexiones donde hay ya equipos largo tiempo trabajando. Aún así, como os podéis imaginar me preocupa e interesa cualquier tema como éste, así que le eché un ojo.
La clave duplicada
Como se puede, el fabricante proveedor de routers ha utilizado una clave generada para SSH antes de hacer la imagen que montar en los routers, haciendo que todos los equipos con el mismo firmware estén usando el mismo sistema de cifrado. Como se puede ver, esto está sucediendo por muchos lugares del mundo.
Figura 2: Claves SSH duplicadas en las imágenes de ese fabricante proveedor de routers
Como la clave privada se encuentra en todos los routers, cualquiera que tenga uno de esos routers puede dumpear de la imagen del sistema la clave privada del demonio SSH. Con esa clave, podría descifrar cualquier comunicación SSH que se haga con cualquier router de que use esa clave.
Consecuencias directas
El impacto es evidente, se acaba de convertir el SSH en un Telnet, así que cualquiera de los equipos que están en esa lista podríamos decir que pasan de ser routers que se administran por SSH a routers que se administran por Telnet, algo que debería evitarse, aunque por desgracia sigue siendo práctica habitual que muchos dispositivos vengan con Telnet habilitado y con usuarios por defecto.
Impacto en routers de Telefónica
Si tras leer la noticia has intentado conectarte por SSH a los routers de Telefónica, verás que la gran mayoría están bloqueados por el sistema de administración remoto de routers, es decir, que aunque tenga el demonio abierto, están filtrados por dirección IP para que solo se puedan conectar los técnicos que dan soporte. Esa protección existe, ya que, por motivos de administración, muchos de esos equipos tienen usuarios y contraseñas por defecto que se usan para poder gestionar los routers de los clientes, que es la principal barrera para evitar que alguien se conecte a tu equipo remotamente.
Figura 3: Conexiones ssh filtradas por firewall
Un atacante remoto que haga un man in the middle a una conexión remota SSH podría robar las contraseñas del técnico de administración, pero no necesitaría hacerlo, ya que cualquiera que haya hecho un dump del firmware sabe cuáles son los usuarios por defecto que vienen en las imágenes de los routers, y por eso se han filtrado las conexiones WAN a solo los centros de soporte.
Hardening de tu router
Si eres usuario de Telefónica y tienes el router gestionado por el servicio técnico no deberías preocuparte por esto. Es responsabilidad de ellos evitar las conexiones desde Internet a tu router que no venga de ninguna dirección IP que no sea el centro de soporte y evitar man in the middle cuando ellos se conecten, y para eso se utilizan las capacidades de operador de telecomunicaciones que tiene Telefónica de España.
Figura 4: El router afectado es el modelo Comtrend VG-8050
Si gestionas tu él router y has cambiado los usuarios por defecto del sistema, entonces deberías tener cuidado con esto, ya que si te conectas desde una red donde te hagan un man in the middle alguien te podría robar las nuevas credenciales. Para evitar eso, métele mano a tu SSH, cambia las claves, fortifícalo y si te animas, métele Latch.