25 abr. 2018

Reporte Anual 2018 sobre Ciberseguridad de Cisco

El Reporte Anual 2018 sobre Ciberseguridad de Cisco le ofrece información sobre el alcance de los problemas que usted enfrentará y de las herramientas que necesitará para detenerlas.

1. Los adversarios están llevando el malware a niveles de sofisticación e impacto sin precedentes. La evolución del malware fue uno de los desarrollos más importantes en el panorama de ataque en 2017.

La aparición de los cryptoworms ransomware basados en la red elimina la necesidad del elemento humano en el lanzamiento de campañas de ransomware. Y para algunos adversarios, el premio no es un rescate, sino la eliminación de sistemas y datos, como lo demostró Nyetya –borrado de malware disfrazado de ransomware–. El malware de autopropagación es peligroso y tiene el potencial de acabar con Internet, según los investigadores de amenazas de Cisco.

 2. Los adversarios son cada vez más expertos en la evasión y en usar como armas los servicios de la nube y otras tecnologías utilizadas con fines legítimos. Además de desarrollar amenazas que pueden evadir los entornos del sandboxing más sofisticados, los actores maliciosos están ampliando su adopción del cifrado para evitar la detección.

La encriptación está destinada a mejorar la seguridad, pero también proporciona a los actores maliciosos una poderosa herramienta para ocultar la actividad de comando y control (C2), lo que les brinda más tiempo para operar e infligir daños.
Los ciberdelincuentes también están adoptando canales C2 que dependen de servicios legítimos de Internet como Google, Dropbox y GitHub. La práctica hace que el tráfico de malware sea casi imposible de identificar. Además, muchos de los atacantes ahora están lanzando múltiples campañas desde un solo dominio  para obtener el mejor retorno de sus inversiones. También están reutilizando los recursos de la infraestructura, como las direcciones de correo electrónico de los subscriptores, los números de sistema autónomo (ASN) y los servidores de nombres.

3. Los adversarios están explotando grietas en la seguridad, muchas de las cuales surgen de la expansión del Internet de las Cosas (IoT) y del uso de los servicios de la nube. Los defensores están desplegando dispositivos de IoT a un paso rápido, pero a menudo prestan poca atención a la seguridad de estos sistemas. Los dispositivos IoT sin parche y no monitoreados brindan a los atacantes la oportunidad de infiltrarse en las redes.

Una investigación sugiere que las organizaciones con dispositivos IoT susceptibles a ataques también parecen desmotivadas para acelerar las correcciones. Peor aún, estas organizaciones probablemente tengan muchos más dispositivos IoT vulnerables en sus entornos de TI que ni siquiera conocen. Mientras tanto, Ias botnets del IoT se están expandiendo junto con el IoT y se están volviendo más maduras y automáticas.

A medida que crecen, los atacantes las usan para lanzar avanzados ataques distribuidos de la negación del servicio (DDoS). Los atacantes también se están aprovechando del hecho de que los equipos de seguridad están experimentando dificultades para defender los entornos del IoT y de la nube. Una razón de esto es la falta de claridad sobre quién es exactamente el responsable de proteger esos entornos.

Método de autenticación de acceso básica HTTP y OAuth 2.0

Apostar por un sistema de credenciales o autenticación óptimo es una de las claves más importantes para garantizar la seguridad de una interfaz de desarrollo de aplicaciones. OAuth 2.0 se ha convertido en el protocolo de seguridad básico en el desarrollo de APIs móviles y la entrega de credenciales para el lanzamiento de aplicaciones nativas. El método de autenticación de acceso básica HTTP no garantiza el mismo nivel de seguridad.

Cada vez más los desarrolladores de aplicaciones móviles están basando su lanzamiento de nuevos productos en el trabajo previo con APIs móviles que facilitan servicios necesarios para el desarrollo de sus creaciones. O bien se diseñan aplicaciones móviles que necesitan tener acceso a una API REST con servicios determinados o es necesario codificar una API REST que permita lanzar determinadas aplicaciones con unos servicios concretos. En cualquier caso, lo cierto es cada vez más se pide el desarrollo de APIs móviles dentro de los equipos. Su seguridad, como en el resto de APIs, se convierte en un elemento esencial.

A no ser que la API disponga de una acceso totalmente abierto, un aspecto extraño pero tampoco descabellado hoy en día, lo normal es que el profesional que quiera usarla necesite identificarse usando algún método específico. Apostar por un sistema de credenciales o autenticación óptimo es una de las claves más importantes para garantizar la seguridad de una interfaz de desarrollo de aplicaciones, ya sea una API tradicional de desarrollo de proyectos para escritorio o específica para apps móviles.

Métodos de autenticación con APIs móviles

En alguna otra ocasión hemos hablado de cómo han evolucionado a lo largo del tiempo los distintos métodos de autenticación con APIs, hasta evolucionar al más utilizado en la actualidad: el método OAuth, cuya última versión es OAuth 2.0. De hecho, en este site hemos analizado cómo las APIs abiertas basadas en OAuth 2.0 se han convertido en uno de los estándares del mercado actual de interfaces. ¿Es OAuth 2.0 el único método de autenticación? No, existe otro método conocido como autenticación de acceso básico HTTP basado en nombre de usuario y contraseña. Empezaremos a explicar este segundo por su simplicidad y menos uso hoy en día.

Autenticación de acceso básico HTTP

Este es el método más sencillo para cumplir con los requisitos de acceso a un servicio web. Es sencillo porque no requiere ninguno de los procesos habituales en un sistema de credenciales: cookies, identificadores de sesión o páginas de acceso. Todo el proceso de autenticación básica HTTP se basa en campos estándar en el encabezado HTTP. Se evita lo que se conoce, en terminología anglosajona, como handshaking (apretón de manos): el proceso automatizado por el que dos entidades establecen una comunicación autenticada antes de comenzar la comunicación normal por el canal establecido. Esto es lo que permite que un equipo establezca comunicación con un dispositivo externo sólo si existe una autenticación correcta: si no existe, el canal de comunicación no se crea. No existiría, por ejemplo, una conexión con un módem. La evolución segura del método de autenticación de acceso básica HTTP es HTTPs.

Para evitar que el método de autenticación de acceso básica HTTP provoque que el navegador lance con cada acceso la petición de nombre de usuario y contraseña, el navegador debe guardar en caché esa información durante un tiempo lo suficientemente prudencial para no rebajar en exceso la seguridad. Lo lógico es que esas credenciales de seguridad se guarden 15 minutos.

¿Cómo es este método de autenticación de acceso básica HTTP en el mundo real?

1. La credencial de acceso facilitada a terceros desarrolladores que desean conectar a una API móvil es un ID alfanumérico totalmente secreto.
2. Esa clave API alfanumérica se aloja en un espacio seguro del servidor.
3. El desarrollador que hace solicitudes de algún servicio concreto contenido en esa API debe colocar ese ID secreto dentro del encabezado HTTP de autorización junto con la palabra Basic. Ambos elementos juntos son los que permiten que el servidor reconozca la credencial alfanumérica y dé el acceso.
GET /privado/index.php HTTP/1.1
Host: example.com
Authorization: Basic ID alfanumérico

OAuth 2.0

OAuth supone un paso adelante en el uso de credenciales para la autenticación de usuarios de una API de servicios. Supone un gran avance con respecto al uso del método de autenticación básica HTTP. Hoy en día es casi el único método de seguridad en el que es posible confiar casi al 100%, una confianza basada en la creación de tokens de autenticación exclusivos por usuario. Si ese token de acceso se ve comprometido, se elimina y se da otro. Eso permite que las credenciales de la propia API queden a salvo.
El proceso de autenticación se produce de la siguiente manera:
  1. Un usuario lanza una aplicación nativa y se le pide un nombre de usuario o un correo electrónico y una contraseña para identificarle como usuario.
  2. El tipo de solicitud utilizado para enviar esa credencial a la API es una solicitud POST, aquella que garantiza el envío privado de datos secretos. Esa petición se envía a través del protocolo SSL/TLS, diseñado para permitir que las aplicaciones transmitan información de ida de forma segura. TLS/SSL facilita dar y recibir claves de cifrado entre aplicaciones.
  3. Esa solicitud posibilita que se validen las credenciales del usuario y se cree ad-hoc un token de autenticación o acceso que caduca con el tiempo o si el usuario o el desarrollador al cargo de la API creen que se ha quebrantado.
  4. Ese token de autenticación queda guardado en el dispositivo para facilitar el acceso a los servicios de la API que dan vida a la propia aplicación.
Si se comparan ambos métodos, OAuth 2.0 da mayores criterios de seguridad porque cualquier solicitud inicial de credenciales queda bajo el protocolo TLS/SSL y, además, el objeto del acceso garantizado es un token temporal. En el proceso de autenticación básica HTTP, el acceso a los servicios de la API dependen siempre del envío de las credenciales a través de la red, concretamente en el encabezado HTTP, lo que facilita mucho su vulnerabilidad por parte de terceros.

Fuente: BBVAOpen4U

Eternal Check: comprobar si una IP es vulnerable a Eternal Blue, Romance, Synergy y Champion

Eternal Check verifica si una ip específica es vulnerable a los exploits Eternal Blue, Eternal Romance, Eternal Champion y Eternal Synergy. Eternal Check usa los archivos ejecutables originales del leak de Shadow Brokers para verificar los objetivos, requiere wine de 32 bits instalado (no wine 64). Eternal Check también verifica que los pipes Smb son vulnerables en la máquina objetivo para ser explotados.

Eternal Check se puede descargar en: https://github.com/peterpt/eternal_check

Requisitos:
  • nmap
  • winbind
  • wine32
  • wget
Uso:
  • ejemplo 1 : ./echeck
  • ejemplo 2 : ./echeck 192.68.2.56
Referencias sobre las vulnerabilidades:
Fuente: HackPlayers

24 abr. 2018

Informe sobre los afectados por Facebook y Cambridge Analytica

La polémica de Facebook y Cambridge Analytica está lejos de terminar. Por medio de un comunicado, la empresa de Zuckerberg confirmó que se obtuvo y usó la información de 87 millones de sus usuarios de manera indebida, una cifra de casi el doble a la que se había planteado cuando se dio a conocer el escándalo.

En el documento se evidencia que Estados Unidos es el país con el mayor número de afectados (70.632.350 personas), seguido por Filipinas (1.175.870 usuarios) e Indonesia (1.096.666).
Cabe destacar que, entre los 10 países como más afectados, Brasil y México son las únicas dos naciones latinoamericanas.
Desde la empresa indicaron que una de las medidas que tomarán al respecto será informar a los usuarios de la cuentas afectadas, directamente en su pantalla, qué datos obtuvieron de ellos.

"A partir del lunes 9 de abril, mostraremos a las personas un enlace en la parte superior de su News Feed para que puedan ver qué aplicaciones usan y la información que han compartido con esas aplicaciones", indicaron.

Desde Facebook también adelantaron que tomarán nuevas medidas para hacer más segura la plataforma y restringir el acceso que los desarrolladores tienen a los datos de los usuarios, además de hacer más claros los avisos de privacidad y términos y condiciones, en los que las personas acuerdan dar acceso a terceros a ciertos de sus datos.

Fuente: Netmedia

Exploit para escalar privilegios en Windows 7 y Server 2008 R2 x64 mediante #Meltdown

¿Recuerdan Meltdown? Aplicaciones sin privilegios eran capaces de leer la memoria del kernel debido a una característica integrada en las CPUs... Microsoft la parcheó en enero pero al hacerlo abrió un agujero aún peor permitiendo que cualquier proceso pueda leer el contenido completo de la memoria (a velocidades de gigabytes por segundo), incluso escribir en ella.

No se necesitan exploits complejos: Microsoft ya hizo el arduo trabajo en Windows 7 x64 y Server 2008 R2 x64 de mapeo en la memoria requerida en cada proceso en ejecución. La explotación es solo una cuestión de leer y escribir en la memoria virtual en proceso ya mapeada. No se requieren API sofisticadas ni llamadas de sistema, ¡solo lectura y escritura estándar!

El bug radica en que se permite el acceso en user-mode a una entrada (0x1e8) de la tabla de paginado PML4 (Page Map Level 4), una de las cuatro que se utilizan para trasladar direcciones virtuales a físicas. Y aún peor, dicha entrada es usada en Windows 7 y Server 2008 R2 x64 como auto-referenciable (Self-Referencing) lo que significa que cualquier proceso de usuario puede ver y modificar la tabla PML4 y, de forma adyacente, la memoria física. Recomiendo echar un vistazo al artículo de Adam aka @_xpn_ donde lo explica perfectamente.

Una de las consecuencias de explotar este fallo es la posibilidad de escalar privilegios, como se puede observar en el siguiente vídeo de demo:
Para construir el exploit, "sólo" hay que desarrollar los siguientes pasos:
  • Crear un nuevo conjunto de tablas de página que permita acceder a cualquier dirección de memoria física.
  • Crear un conjunto de firmas que puedan usarse para buscar estructuras _EPROCESS en la memoria del kernel.
  • Encontrar la dirección de memoria _EPROCESS para el proceso en ejecución y para el proceso del Sistema.
  • Reemplace el token del proceso en ejecución con el de System, elevando a NT AUTHORITY\System.
Tenéis el código completo y funcional aquí.

Por último, Microsoft ha publicado el parche para esta vulnerabilidad, bautizada como CVE-2018-1038, así que toca parchear rápido:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-1038

Fuente: HackPlayers

Orangeworm: APT orientada al sector médico

Symantec ha descubierto un nuevo grupo de atacantes que se dirige de forma agresiva a las empresas y organizaciones de salud con el fin de realizar espionaje corporativo.

Denominado Orangeworm, este grupo carga malware en dispositivos que alojan software empleado para controlar máquinas de rayos X, Resonancia Magnética Nuclear (RMN), así como también dispositivos utilizados para ayudar a los pacientes a completar los formularios de consentimiento para procedimientos médicos.

El informe publicado por Symantec, revela que Orangeworm ha estado operando desde el año 2015 y su objetivo principal son las corporaciones internacionales con sede en Europa, Asia y Estados Unidos, enfocadas principalmente en el sector médico. En este sentido, la publicación afirma:
Creemos que estas industrias también han sido atacadas como parte de un ataque más grande a su cadena de suministro para que Orangeworm tenga acceso a sus víctimas previstas vinculadas con la atención médica.
El ataque ocurre de la siguiente manera: Luego de que los atacantes acceden a la red de las víctimas, cargan un troyano llamado Kwampirs, que se encarga de abrir una puerta trasera en los ordenadores comprometidos, permitiendo acceder remotamente a ellos y robar los datos confidenciales de las organizaciones que los atacantes han estudiado previa y cuidadosamente.

Las organizaciones de atención médica han surgido recientemente como un objetivo primordial para los delincuentes y atacantes gubernamentales, incluidos aquellos que realizan ataques de ransomware para generar ganancias. En este sentido, Symantec considera que los atacantes de Orangeworm no tienen otro objetivo más que el espionaje corporativo, como por ejemplo, el robo de secretos comerciales.

De momento, el mayor porcentaje de víctimas del ataque ha sido reportado en Estados Unidos, seguido de Arabia Saudita, Filipinas, India, Reino Unido, Hungría, Alemania, Turquía, Hong Kong, Polonia, Canadá, Francia, Suecia, entre otros.

Fuente: TekCrispy

23 abr. 2018

Es ley: tenencia de pornografía infantil se castiga con cárcel (Argentina)

La Cámara de Diputados convirtió en ley un proyecto consensuado que modifica el artículo 128 del Código Penal y sanciona con penas de entre tres y seis años de prisión la simple tenencia de material pornográfico infantil.

La norma fue aprobada por amplia mayoría -212 votos a favor y una sola abstención-, indicó el sitio Parlamentario.com. "No tenemos que tener temor y hay que decirlo con todas letras: el que tiene pornografía infantil es un pedófilo. Es un paso previo para la materialización del abuso sexual infantil", denunció la presidenta de la Comisión de Legislación Penal, Gabriela Burgos (UCR). Burgos advirtió que en Argentina "hay un negocio con ganancias de 250 millones de pesos anuales" en torno al material pornográfico de menores.

La Cámara de Diputados trasformó en ley la propuesta de modificación del artículo 128 del Código Penal para penalizar la tenencia de pornografía infantil, cualquiera sea su finalidad, y el agravamiento de las penas para que el delito no sea excarcelable.

El senador Julio Cobos (Cambiemos) destacó que "esta ley, surgió del acuerdo con legisladores de diferentes sectores políticos que entendimos la necesidad de lograr la protección integral de los jóvenes y de otorgar a la Justicia todas las herramientas para combatir la pornografía infantil en todas sus variantes".

Modificaciones al artículo 128

  • Reprimir con prisión de tres a seis años al que produzca, financie, ofrezca, comercie, publique o divulgue, por cualquier medio, toda representación de un menor de dieciocho años dedicado a actividades sexuales explícitas o toda representación de sus partes genitales con fines predominantemente sexuales, al igual que el que organice espectáculos en vivo de representaciones sexuales explícitas en que participaren menores.
  • Reprimir con prisión de cuatro meses a un año al que tenga en su poder representaciones de las descriptas en el párrafo anterior.
  • Reprimir con prisión de seis meses a dos años al que tenga en su poder representaciones de las descriptas en el primer párrafo con fines de distribución o comercialización.
  • Reprimir con prisión de un mes a tres años al que facilite el acceso a espectáculos pornográficos o suministre material pornográfico a menores de catorce años.
  • Además, todas las escalas penales previstas en este artículo se elevan en un tercio en su mínimo y en su máximo cuando la víctima fuere menor de trece años.
Actualización 23/04/208: el Gobierno publicó oficializó y reglamentó hoy le Ley 27.436 que penaliza la distribución y tenencia de pornografía infantil . La norma, que fue sancionada el 21 de marzo en Diputados, establece penas de hasta 6 años de prisión e implicó una modificación del artículo 128 del Código Penal.
Fuente: MDZOL

Ataques a los sistemas de pago con móviles

El pago en comercios a través del móvil se está popularizando gracias a las actualizaciones tanto en los smartphones como en los datáfonos de las tiendas. Facilita el pago pero hay que saber que tampoco es 100% seguro según la investigación "All your payment tokens are mine: Vulnerabilities of mobile payment systems" presentada en Black Hat Asia [PDF].

Los pagos móviles se están convirtiendo en una buena alternativa para pagar en diferentes locales y comercios que son compatibles con estos, y es que, al fin y al cabo es la forma de pagar más cómoda que hay, basta con sacar el terminal, desbloquearlo y ponerlo junto al datáfono.

Zhe Zhou, de la Universidad Fudan (China), experto en seguridad informática de la Universidad Fudan, explicaba hace poco en una charla cómo funciona el pago mediante este sistema. Sustituye al pago en efectivo y con tarjeta pero presenta vulnerabilidades que pueden derivar en que los datos del usuario sean robados, según explican en The Register.

El profesor explicó el funcionamiento de estos pagos móviles. Cuando el usuario introduce su tarjeta en una aplicación para realizar los pagos, se genera un número identificativo de la tarjeta llamado "token", que es el que llega al banco para cargarlo a la cuenta.

Cada pago utiliza un token único por lo que la forma de poder utilizar ese token es que la persona que quiere robar los datos impida que el susodicho llegue al servidor de pagos. Cada transacción usa un único token que sólo se puede usar una vez, y por ello, la única manera de poder usar el de otra persona fraudulentamente es impedir que llegue al servidor de pagos. Y hay smartphones con transmisión magnética segura que pueden hacer esto, emitiendo energía electromagnética a través de la bobina de la carga inalámbrica.

Zhe dijo que es posible hacerlo para los teléfonos inteligentes que pueden emular tarjetas de banda magnética. Los teléfonos inteligentes pueden llevar a cabo ese truco gracias a una tecnología llamada "transmisión magnética segura" (MST) que los ve emitir energía electromagnética de la bobina utilizada para la carga inalámbrica. Los teléfonos equipados de este modo envían a los dispositivos de punto de venta los mismos datos que esperan detectar cuando se pasa una tarjeta. Zhe dijo que se espera que el MST tenga un rango de siete centímetros, pero el kit comercial que cuesta US$ 25 pudo detectar la onda desde una distancia de dos metros. Al hacerlo, también detuvieron la señal llegando al punto de venta de terminales y obtuvieron el token no utilizado.
Los pagos con sonido, una técnica utilizada por el sistema "Tez" de Google India, pueden ser secuestrados de manera similar. Zhe dijo que los pagos de sonido se usan a menudo en las máquinas expendedoras y que no es difícil registrar los códigos, ya sea cerca de la máquina o con modificaciones inesperadas. Si la máquina expendedora utiliza una conexión inalámbrica para verificar el token, un jammer lo detiene. De nuevo, el atacante termina con un token válido.

El ataque más astuto de Zhe se enfocó en los códigos QR utilizados como tokens para algunos pagos. Su táctica para tales tokens fue encender subrepticiamente la cámara frontal de un teléfono inteligente para fotografiar el reflejo de un código QR en una cubierta protectora del escáner de punto de venta. Este ataque también detecta la configuración del código QR y cambia sutilmente su apariencia para hacerla ilegible. El malware que ejecuta el ataque en el teléfono inteligente, sin embargo, logra conservar un código QR perfecto y utilizable. La técnica también se puede usar para elaborar códigos QR maliciosos que, cuando se utilizan para pagos de teléfonos inteligentes a teléfonos inteligentes, se ve la máquina de la víctima dirigida para descargar y ejecutar malware.

El investigador dijo que reveló sus descubrimientos al proveedor de pagos móviles más grande de China, y que revocó rápidamente las versiones de sus aplicaciones y prometió asegurarse de que sus productos busquen y destruyan cualquier proceso utilizando las cámaras frontales de los teléfonos.

Concluyo recomendando que todos los intercambios de tokens para pagos móviles deben cifrarse y añadir un mecanismo de desafío y respuesta. También dijo que los tokens de pago móvil siempre están vinculados a una sola transacción, por lo que los tokens no se pueden reutilizar.

Fuente: Andro4All

La NSA explica cómo combate las vulnerabilidades Zero-Day

En la conferencia RSA que se celebró en San Francisco no solo exponen profesionales del sector privado, sino también del sector público, incluyendo la más que polémica NSA.
Dave Hogue, Director Técnico de la NSA, ha hecho una revisión de las mejores prácticas de defensa que llevan a cabo dentro de la organización. Una de las cosas que ha explicado es que cada vulnerabilidad o exploit nuevo descubierto solo tarda 24 horas como mucho en ser utilizado contra la propia NSA. Esto da al equipo de defensa de la agencia pública un margen pequeño para parchear comparado con la media del sector privado, que se puede tomar semanas e incluso meses para aplicación de medidas.

Hogue ha comentado que los ataques de phishing y los sistemas sin parchear siguen representando la mayoría de los ataques que hallan contra la NSA, siendo esta la razón por la que la agencia dice mantener sus sistemas lo más actualizados posible como "una de la mejores prácticas defensivas". Ser disciplinada en este punto le ha permitido no padecer ninguna intrusión mediante la explotación de una vulnerabilidad zero-day en los últimos 24 meses, así que los atacantes tendrían que tener en cuenta que sus probabilidades de éxito utilizando esta vía no son muy elevadas contra la NSA a menos que sean muy rápidos. La gran mayoría de los incidentes con los que lidia la NSA no son Amenazas Persistentes Avanzadas (APT) potentes y recientes, sino que el 93% en 2017 fueron totalmente preveniles mediante la puesta en práctica de sus mismas buenas prácticas.

Estos datos publicados por la NSA muestran lo importante que es tener el software actualizado para evitar las amenazas. De hecho, recordamos que WannaCry se propagó utilizando una vulnerabilidad de Windows que estaba parcheada por Microsoft, pero no aplicada por muchos mantenedores de sistemas.

Fuente: Naked Security

22 abr. 2018

Vulnerabilidad en función autocompletar de LinkedIn exponía datos de usuarios

Una nueva vulnerabilidad descubierta en la popular funcionalidad de 'Autocompletar' o 'Auto fill' que puede permitir el robo de datos por parte de terceros.

Esta funcionalidad proporciona que otros sitios web puedan permitir que los usuarios de LinkedIn puedan completar rápidamente los datos del perfil, incluyendo información sensible como nombre completo, número de teléfono. dirección de correo electrónico, código postal, empresa...etc en un solo clic.

Recientemente el investigador de seguridad Jack Cable de 'Lightning Security' descubrió que esta funcionalidad estaba plagadas de vulnerabilidades que permitiría a cualquier sitio web obtener los datos del perfil del usuario sin que el usuario se diera cuenta.

Un atacante puede hacer que la funcionalidad autocompletar en su sitio web cambiando algunas propiedades como la de extender esta funcionalidad a través de todo el sitio web para posteriormente hacerlo invisible, en el momento en el que el usuario haga click en cualquier parte de la web desencadenaría la ejecución de esta función y el envío de los datos albergados en la funcionalidad. Por pasos sería de la siguiente manera:

El usuario visita el sitio web malicioso, que carga el 'iframe' del autocompletar de LinkedIn.
  • El 'iframe' ocupa toda la página web y es invisible al usuario.
  • El usuario hace clic en cualquier parte de la web.
  • Los datos son enviados un sitio web malicioso.
Esta vulnerabilidad fue reportada e inmediatamente la compañía emitió una solución temporal a este posible ataque. La corrección restringe el uso de la función autocompletar a los sitios incluidos en la 'white list' o lista blanca.

El mismo investigador ha subrayado que el parche está incompleto y que aún permitiría usar esta características por los dominios incluidos en la lista blanca. Por lo tanto si cualquiera de estos sitios se viera comprometido, podría hacerse uso de este ataque.

Por parte de LinkedIn ya han lanzado el parche completo.

Fuente: Hispasec