Las noticia de los últimos días en los medios especializados hablan sobre las vulnerabilidades  Meltdown y Spectre que parecen afectar a una amplia gama de CPU actuales, particularmente en procesadores Intel que datan desde 1995 en adelante. La parte interesante de la historia es cómo funcionan estas vulnerabilidades y saber si existen PoC (Proof Of Concept) o exploits que hagan uso de las mismas. Además es interesante saber cómo fue posible que estas vulnerabilidades pasaran desapercibidas durante tanto tiempo sin que nadie lo notara.

De las dos vulnerabilidades Metldown, es la más fácil de comprender, implementar y aparentemente protegerse contra ella. Se deriva de la forma en que un procesador moderno intentará ejecutar programas más rápido mediante el uso de la “ejecución especulativa“. Si Ud. sabe cómo funcionan las CPU en el nivel más simple, se sorprenderá al descubrir cuán sofisticado se ha vuelto un procesador moderno. Por ejemplo, la mayoría de las CPU modernas ejecutarán código en paralelo, incluido el código que quizás nunca se necesite. El ejemplo más habitual es la predicción de bifurcación. Si el flujo de control se divide en una instrucción IF, entonces puede optimizar el uso del microprocesador, ejecutando la rama que considera más probable antes de realizar la evaluación de la condición de salto. Luego de la evaluación de la condición lógica puede resultar que evaluó la rama incorrecta, entonces descarta el código ejecutado y en su lugar ejecuta la otra rama del IF.

Todo esto parece muy inocente y la idea de la ejecución especulativa no parece ser un riesgo de seguridad. ¿Qué podría salir mal?

Pero existen mentes muy creativas, especialmente la de los “hackers” pueden ser capaces de transformar hasta la característica más inocente en una vulnerabilidad y así es como ocurrió con la ejecución especulativa. Supongamos que se escribe un código que carga algunos datos que se encuentran en un área protegida del sistema operativo, el espacio del kernel y utiliza estos datos para calcular la dirección de un elemento en una matriz, un código tan inocente como este:

data = getByte (kernalAddress)
variable = probeArray (datos)

La instrucción getByte devuelve un valor en el rango de 0 a 255 y esto se usa para acceder a un elemento de probeArray, que tiene 255 elementos de longitud. Si esto funciona, habría leído con éxito un byte de datos del espacio del kernel, algo que se supone que no deberíamos hacer porque se trata de datos privados y poe lo general es alli dónde se almacenan contraseñas, claves de cifrado, etc. De hecho, no funciona porque la memoria kernel está protegida y la instrucción getByte fallará con una excepción de tiempo de ejecución y el resto del programa terminará. Por lo tanto tú nunca podrías acceder al elemento de la matriz probeArray en función del valor de la variable data.

Ahora añadamos a este simple código descrito líneas arriba la ejecución especulativa. Es muy probable que el procesador haya ejecutado el acceso probeArray especulativamente antes de que se produzca la excepción; las excepciones son complejas y lentas. Esto todavía no es un problema de seguridad porque los resultados especulativos se descartan y no están disponibles en el espacio del usuario.

No se debería producir ningun daño ya que la ejecución especulativa finalmente no ha hecho ningún cambio en el sistema.

Pero lo anterior no es del todo cierto porque se ha accedido a un elemento de probeArray y ahora está en la memoria caché del CPU. Si antes de ejecutar el programa nos aseguramos de que ninguno de los elementos de probeArray estuviera en el caché del CPU. Entonces, ahora todo lo que tenemos que hacer es leer cada elemento de probeArray y medir cuánto tarda el acceso. El acceso que es más rápido que el resto es el elemento que fue almacenado en caché por la ejecución especulativa. Una vez que sabemos qué elemento se almacenó en caché, sabremos qué valor existe en esa posición relativa del espacio de kernel.

La ejecución especulativa cambió el estado de la arquitectura del CPU y esto proporciona un canal secreto a través del cual podemos leer los datos protegidos en el espacio de kernel.

Para entenderlo mejor veamos el siguiente diagrama extraído del paper oficial de Meltdown:

Esto significa que ahora podemos leer cualquier ubicación de memoria del espacio de kernel y descubrir qué se almacena allí simplemente tratando de ejecutar un acceso ilegal y haciendo uso de la ejecución especulativa y el almacenamiento en caché para encontrar qué datos se habrían recuperado si no hubieran sido ilegales.

Con algunas adiciones al sencillo código anterior, que básicamente es agregar el código para el manejando la excepción de tiempo de ejecución de falta de privilegios, es cómo los investigadores de Google Project Zero implementaron un código que permite verificar la existencia de Meltdown. Aquí el texto que aparece en el paper:

Con el manejo de excepciones, logramos velocidades de lectura promedio de 123 KB/s cuando se filtran 12 MB de memoria del kernel. De los 12 MB de datos del kernel, solo el 0.03% se leyeron incorrectamente. Por lo tanto, con una tasa de error de 0.03%, la capacidad del canal es 122 KB/s.

Meltdown, no funciona en los procesadores AMD y ARM en el sentido de que no recupera ningún dato válido, sin embargo, se demostró que el principio general funciona en ambas arquitecturas y estas ejecutaron instrucciones más allá de la instrucción ilegal. Una de las razones por las cuales se especula que Meltdown no funciona en AMD y ARM podría ser el momento exacto de la excepción y que todo lo que se necesita para que funcione es algún ajuste del código para conseguir un mejor timing del mismo.

La solución para Meltdown es deshabilitar cualquier asignación de memoria entre kernel y memoria de usuario, aparte de las áreas que necesitan compartirse, por ejemplo, tablas de interrupción. Esto se hace mediante el parche KAISER que está disponible para Linux. Una protección más avanzada y mejor requiere el uso de la indirección para ocultar las direcciones del kernel – código de trampolín. El gran inconveniente de estas soluciones es que vuelve más lentos a los programas que hacen un uso intensivo del CPU.

Aquí cómo lo explica el equipo que descubrió esta vulnerabilidad:

Meltdown cambia la granularidad de ser comparativamente baja espacio/temporalmente hablando, por ejemplo, de 64 bytes cada pocos cientos de ciclos para los ataques de caché, a una granularidad arbitraria, permitiendo que un atacante lea cada bit. Esto es algo contra lo que ningún algoritmo (criptográfico) puede protegerse. KAISER es una solución de software a corto plazo, pero el problema que descubrimos es mucho más significativo.

Se puede culpar a Intel y a los otros fabricantes de microprocesadores si es que lo deseamos, pero diseñar hardware para que ofrezcan un gran rendimiento es un trabajo difícil. Si el enfoque del diseño es el rendimiento, entonces debemos aceptar como un efecto colateral que la seguridad se verá afectada,  es tal vez por ello que los descrubridores de Meltdown nos dan finalmente un mensaje positivo de cada al futuro:

Esperamos que Meltdown y Specter abran un nuevo campo de investigación para descubrir en qué medida las optimizaciones de rendimiento cambian el estado microarquitectónico, cómo este estado se puede traducir en otro estado arquitectónico y cómo se pueden prevenir tales ataques.

Aquí algunos links de fuentes usadas para este post sobre Meltdown:

• Meldown paper oficial.
• Spectre and Meltdown: How cache works.
• How Meldown works.
• Spectre & Meltdown – Computerphile.
• Google Makes Disclosure About The CPU Vulnerability Affecting Intel/AMD/ARM.
• Meltdown Proof-Of-Concept.

Incluso después de muchos esfuerzos realizados por Google el año pasado, las aplicaciones maliciosas siempre logran introducirse en la tienda de aplicaciones de Google, el muy conocido Play Store.

Los investigadores de seguridad ahora han descubierto un nuevo tipo de malware, denominado GhostTeam, en al menos 56 aplicaciones en el Google Play Store que están diseñadas para robar credenciales de inicio de sesión en Facebook y mostrar agresivamente anuncios emergentes a los usuarios afectados.

GhostTeam ha sido descubierto de forma independiente y simulatánea por dos firmas de seguridad informática, Trend Micro y Avast, las aplicaciones maliciosas se disfrazan como varias utilidades (entre ellas por ejemplo como una aplicación de linterna, escáner de código QR o como una brújula), utilidades de aumento de rendimiento (como transferencia de archivos y purga de archivos antiguos), entretenimiento, estilo de vida y por supuesto aplicaciones para descarga de video.

Al igual que la mayoría de las aplicaciones de malware, estas aplicaciones de Android no contienen ningún código malicioso a simple vista, esta es la razón por la cuál son admitidas en el Play Store de Google.

Una vez instalado, primero confirma si el dispositivo no es un emulador o un entorno virtual (para evitar ser detectados por una auditoría automatizada) y luego de ello descarga el malware como una actualización, es en este momento que solicita a la víctima que apruebe los permisos de administrador del dispositivo para ganar persistencia en el dispositivo.

En el blog de Trend Micro se menciona el siguiente App de descarga de video cómo una de las afectadas por GhostTeam:

De acuerdo al informe de Avast: “La aplicación de descarga recopila información sobre el dispositivo, como ID de dispositivo único, ubicación, idioma y parámetros de visualización, […].La ubicación del dispositivo se obtiene de la dirección IP que se utiliza al contactar servicios en línea que ofrecen información de geolocalización para direcciones IP.”

Tan pronto como los usuarios abren su aplicación de Facebook, el malware inmediatamente simula una desconección y solicita volver a verificar la cuenta de inicio de sesión en Facebook. En lugar de explotar alguna vulnerabilidad del sistema la aplicación maliciosa utiliza el clásico esquema de phishing para realizar el trabajo de robo de contraseña.

Estas aplicaciones falsas simplemente lanzan un componente WebView con una página de inicio de sesión similar a Facebook y le piden a los usuarios que inicien sesión. Aparentemente, el código de WebView roba el nombre de usuario y contraseña de Facebook de la víctima y los envía a un servidor remoto controlado por hackers.

Los investigadores de Trend Micro advierten que estas credenciales robadas de Facebook pueden reutilizarse posteriormente para entregar “malware mucho más perjudicial” o “amasar un ejército de cuentas en redes sociales zombis” para difundir noticias falsas o distribuir malware de minería de criptomonedas.

Según los investigadores de seguridas de ambas empresas, coinciden en señalar que la mayoría de los usuarios afectados por el malware GhostTeam residen en países emergentes como: India, Indonesia, Brasil, Vietnam y Filipinas.

Además de robar las credenciales de Facebook, el malware GhostTeam también muestra anuncios emergentes agresivamente manteniendo siempre el dispositivo infectado en alerta al mostrar anuncios no deseados en el backgroud, con lo cuál la batería del dispositivo se descarga más rápidamente de lo usual y el plan de datos es consumido muy rápidamente. Si Ud. sufre estos síntomas es muy probable que su smartphone Android haya sido infectado por GhostTeam.

Luego de que los investigadores de seguridad informaran a Google del descubrimiento de este malware, esta ha eliminado todas las aplicaciones del Play Store. Sin embargo, los usuarios que ya hayan instalado una de esas aplicaciones en sus dispositivos deben asegurarse de tener habilitada Google Play Protect. Si no tienes habilitado Google Play Protect y no deseas hacerlo porque piensas que puede espiarte, entonces la única forma segura de deshacernos del malware es remover la aplicación y luego aplicarle al smartphone un factory reset.

Para los usuarios que no hayan oído hablar de ella, la función de seguridad Play Protect utiliza aprendizaje automático y análisis de uso de la aplicación para eliminar (es decir, desinstalar) las aplicaciones maliciosas de los teléfonos inteligentes Android de los usuarios, en un esfuerzo por evitar cualquier daño adicional.

Aunque las aplicaciones maliciosas que flotan en la tienda de aplicaciones oficial son una preocupación interminable para Google, la mejor manera de protegerse es siempre estar alerta cuando se descargue aplicaciones y siempre verificar los permisos y revisiones de la aplicación antes de descargar una.

Además, les recomiendo que tengan habilitado en Facebook el two-factor-authentication, de esa manera a pesar de que su password sea robado, este no podrá ser usado por los ciberdelincuentes.

Espero que este post les haya sido de utilidad.

Cuando Google presentó sus smartphones Pixel 2 y Pixel 2 XL en octubre, la compañía mostró una nueva característica de realidad aumentada llamada AR Stickers. Ahora esa característica ya se está distribuyendo a los usuarios de estos smartphones, entre los cuales me encuentro. Los AR Stickers permiten ubicar personajes 3D en entornos del mundo real usando la aplicación de la cámara.

En este momento sólo está disponible para los smartphone Pixel (2/2XL) con Android 8.1 para poder usar estas etiquetas de realidad aumentada. No está claro si esta característica llegará a dispositivos de terceros o cuándo estará disponible para el resto de smartphones Android que usen la versión 8.1.

Tal vez una de las razones por la cuales esta característica no se incluye en otros dispositivos es porque puede hacer uso del hardware dedicado al procesamiento de imágenes en inteligencia artitificial incorporado en los Pixel de segunda generación llamado Pixel Visual Core.

Así es como funcionan las etiquetas de realidad aumentada (AR Stickers). Se encienda la aplicación de la cámara del Pixel, se selecciona el modo de etiqueta del menú deslizable del smartphone (es una nueva opción que inicie de la misma manera que el modo vertical) y elija uno de los paquete de stickers disponibles, las dos mas saltantes son el de Star Wars y Stranger Things. Luego puedes colocar el sticker en la escena de la cámara.

Si no te queda claro, aquí un video de cómo hacerlo:

 

 

Los AR Stickers usa la tecnología ARCore de Google para que quepan en una escena. Debido a esta tecnología los personajes podran caminar por el suelo o sobre una mesa proyectando sombra y simulando estar dentro de la imagen.

Creo en lo personal que si este tipo de tecnología hubiera estado disponible cuando Google Glass se lanzó por primera vez, los dispositivos portátiles de estilo de realidad aumentada se habrían puesto de moda mucho más rápido.

Por lo pronto creo que esto inspirará muchos filtros de Instagram, que de alguna manera pueden simular esto. La gran ventaja de los AR Stickers es que puedes hacer videos de cómo interactuas con ellos, no sólo tomar una fotografía.

Millones de dispositivos Android corren un grave riesgo ante una nueva vulnerabilidad crítica de este sistema operativo móvil que permite a los atacantes sobrescribir secretamente las aplicaciones legítimas instaladas en los smartphones con una versión maliciosa de la aplicación.

Esta vulnerabilidad ha sido llamada Janus, y permite a los atacantes modificar el código de las aplicaciones ya instaladas en tu smartphone Android sin afectar los certificados de verificación de firmas, lo que finalmente les permite distribuir actualizaciones maliciosas para aplicaciones legítimas, que se ven y funcionan igual que las aplicaciones originales.

La vulnerabilidad (CVE-2017-13156) fue descubierta e informada a Google por investigadores de seguridad de la empresa de seguridad móvil GuardSquare este verano y Google afortunadamente la ha parcheado, lo sabemos ahora porque figura entre cuatro docenas de vulnerabilidades parchadas como parte del último boletín de seguridad para Android del 5 diciembre.

Sin embargo, la parte preocupante es que la mayoría de los usuarios de Android no recibirán estos parches durante los próximos meses, hasta que los fabricantes de sus dispositivos (OEM) publiquen las actualizaciones personalizadas para ellos, aparentemente dejando a un gran número de usuarios de smartphones Android vulnerables a los cibercriminales.

La vulnerabilidad afecta a las aplicaciones que utilizan el esquema de firma de APK v1 que está instalado en los dispositivos que ejecutan las versiones de Android 5 (Lollipop) y 6 (Marshmallow). Si tu disposivo usa Android 7 (Nougat) o superior esta vulnerabilidad no afecta a tu equipo.

¿Cómo funciona Janus?

De acuerdo a lo explicado en el blog de GuardSquare, la vulnerabilidad reside en la forma en que Android maneja la instalación de un APK para algunas aplicaciones, dejando la posibilidad de agregar bytes adicionales de código al archivo APK sin afectar la firma de dicha aplicación.

Antes de seguir adelante, necesita conocer algunos conceptos básicos sobre un archivo APK.

Un archivo APK válido es un tipo de archivo, como Zip, que incluye el código de la aplicación, los recursos, los assets, firmas, certificados y el manifiesto de archivos.

Las versiones anteriores del sistema operativo Android 5.0 (Lollipop) y 6.0 (Marshmallow) también admiten una máquina virtual de proceso que ayuda a ejecutar archivos APK que contienen una versión compilada del código y los archivos de la aplicación, comprimidos con formato de archivo DEX (Dalvik EXecutable).

Al instalar una aplicación de Android o su actualización, usualmente un dispositivo Android verifica la información del encabezado de la APK para determinar si el archivo contiene código en los archivos DEX comprimidos.

Si el encabezado dice que el archivo APK contiene archivos DEX, la máquina virtual de proceso descompila el código en función de la plataforma y lo ejecuta; de lo contrario, ejecuta el código como un archivo APK normal.

Dado que un archivo APK puede contener archivos DEX y código de aplicación regular simultáneamente, sin afectar su validez y firmas. Es debido a esto que la vulnerabilidad ha recibido el nombre de Janus, el dios romano de la dualidad y los inicios, Janus por lo general es representado tendiendo dos caras. Esta vulnerabilidad muestra esa misma dualidad, ofrece una cara familiar e inocente al usuario, pero por otro lado hay una cara oculta que es la forma como un ciberdelincuente puede tomar control de nuestro equipo.

Los investigadores encontraron que esta capacidad de agregar bytes adicionales de código y a la falta de comprobación de integridad de archivos, se podría permitir a los atacantes agregar código malicioso compilado en formato DEX en un archivo APK que contenga código legítimo con firmas válidas, eventualmente engañando al proceso de instalación de la aplicación para ejecutar ambos códigos en el dispositivo objetivo sin ser detectado.

En otras palabras, el ataque no requiere que los atacantes modifiquen el código de las aplicaciones legítimas (lo que hace que las firmas sean inválidas); en su lugar cambio, la vulnerabilidad permite a los autores de malware simplemente agregar algunas líneas maliciosas adicionales de código a la aplicación original.

Un gráfico tomado del blog de GuardSquare muestra claramente el problema:

Después de crear versiones maliciosas pero válidas de aplicaciones legítimas, los hackers pueden distribuirlas mediante diversos vectores de ataque, incluidos correos electrónicos no deseados, tiendas de aplicaciones de terceros que ofrecen aplicaciones y actualizaciones falsas, ingeniería social e incluso ataques de intermediarios. De alli la constante recomendación de sólo instalar aplicaciones directamente desde el Play Store o tiendas oficinales como las de Amazon.

Según los investigadores puede ser “relativamente fácil engañar a algunos usuarios porque la aplicación todavía puede verse exactamente como la aplicación original y tiene la firma adecuada“.

Un escenario incluso más preocupante sería un ataque de hombre en el medio (man in the middle), ya que podría permitir a los cinberdelincuentes redireccionar nuestro DNS por ejemplo para apuntar a un falso Play Store y llevar a cabo una instalación maliciosa para las aplicaciones diseñadas para recibir sus actualizaciones a través de una conexión HTTP no encriptada.

El blog de GuardSquare nos hace la siguiente advertencia:

Cuando el usuario descarga una actualización de una aplicación, en tiempo de ejecución, Android compara su firma con la firma de la versión original. Si las firmas coinciden, en tiempo de ejecución, Android procede a instalar la actualización.

La aplicación actualizada hereda los permisos de la aplicación original. Los atacantes pueden, por lo tanto, usar la vulnerabilidad Janus para engañar al proceso de actualización y obtener un código no verificado con poderosos permisos instalados en los dispositivos de usuarios desprevenidos.

Para los expertos, las herramientas comunes de ingeniería inversa no muestran el código inyectado. Los usuarios siempre deben estar atentos al descargar aplicaciones y actualizaciones

Aunque es desafortunado, pero si el fabricante de su dispositivo móvil no ofrece parches de seguridad ni la última versión de Android, entonces no debe instalar aplicaciones o actualizaciones desde fuera de Google Play Store para minimizar el riesgo de ser infectado.

Los investigadores también aconsejaron a los desarrolladores de Android que siempre apliquen el esquema de firma v2 para asegurar que sus aplicaciones no puedan ser manipuladas.

 

 

Si posee una computadora Mac y esta ejecuta la última versión del sistema operativo de Apple, el macOS High Sierra, debes tener mucho cuidado con tu computadora.

Se ha descubierto una grave pero estúpida vulnerabilidad en macOS High Sierra que permite a los usuarios que no son de confianza obtener rápidamente control administrativo (o de root) sin restricciones en una Mac sin ninguna contraseña o control de seguridad, lo que puede poner en riesgo los datos del equipo.

Descubierto por el desarrollador Lemi Orhan Ergin el día de ayer (28 de noviembre 2017), la vulnerabilidad solo requiere que cualquier persona con acceso físico a la computadora objetivo ingrese “root” en el campo de nombre de usuario, deje la contraseña en blanco y presione Enter varias veces, ¡y Voila!

En palabras simples, esta falla permite a un usuario no autorizado que tiene acceso físico en una computadora Mac obtener de inmediato el mayor nivel de acceso a la computadora, conocido como “root”, sin escribir ninguna contraseña.

No hace falta decir que esta vulnerabilidad de Mac tan fácil de explotar, permite hacer cosas realmente aterradoras.

Esta vulnerabilidad es similar a la de un parche de Apple el mes pasado, que afectó a los volúmenes cifrados mediante APFS, donde la sección de contraseña sugerida mostraba la contraseña real del usuario en texto plano.

Si posees una Mac y desea probar este exploit, sigue estos pasos desde una cuenta de invitado:

• Abra las Preferencias del sistema en la máquina.
• Seleccione Usuarios y Grupos.
• Haga clic en el ícono de candado para hacer cambios.
• Ingrese “root” en el campo de nombre de usuario de una ventana de inicio de sesión.
• Mueva el cursor al campo Contraseña y presione el botón Entrar varias veces, dejándolo en blanco.

Debido a lo serio de esta vulnerabilidad y los peligros que tiene para los usuarios de este sistema operativo, se espera un parche de parte de Apple muy pronto. Pero por el momento, la única solución al problema es habilitar el usuario “root” y asignarle una contraseña, aquí como hacerlo:

• AbraSystem Preferences  y seleccione Users & Groups.
• Haga click en el ícono de candado e ingrese su nombre de administrador y contraseña allí.
• Haga click en “Login Options” y seleccione “Join” en la parte inferior de la pantalla.
• Seleccione “Open Directory Utility”.
• Haga click en el icono de candado para hacer cambios y escriba su nombre de usuario y contraseña allí
• Haga click en “Edit” en la parte superior de la barra de menú
• Seleccione “Enable Root User” y establezca una contraseña para la cuenta de usuario raíz

Con los pasos descritos anteriormente evitará el acceso usando la cuenta de “root” con una contraseña en blanco.

Una vez más la compañía de la manzana está demostrando un pobre control de calidad del software y por qué una política de seguridad por oscuridad no funciona en el largo plazo.

En un intento de proteger a los usuarios de Android contra el malware, Google ha estado trabajando continuamente para detectar y eliminar aplicaciones maliciosas de sus dispositivos utilizando su servicio recientemente lanzado Google Play Protect.

Google Play Protect, es una funcionalidad de seguridad incorporada en Android que usa aprendizaje automático y análisis de uso de aplicaciones móviles para identificar las que son potencialmente dañinas. Uno de sus más recientes logros es que ayudó a los investigadores de Google a identificar una nueva familia de spyware de Android que estaba robando mucha información a los usuarios de Android.

Descubierto en los dispositivos móviles de países africanos, Tizi es un backdoor Android con muchas funciones maliciosas entre las cuales tenemos la instalación de software espía en los dispositivos de las víctimas para robar información confidencial de populares aplicaciones como Facebook, Twitter, Whatsapp, Viber, Skype, LinkedIn y Telegrama.

Google ha declara en una publicación de su blog de seguridad, qué:

“El equipo de seguridad de Google Play Protect descubrió esta familia en septiembre de 2017 cuando los escáneres de dispositivos encontraron una aplicación con capacidades de rooteo que explotaban vulnerabilidades antiguas.

El equipo utilizó esta aplicación para encontrar más aplicaciones en la familia Tizi, la más antigua de ellas es de octubre de 2015”.

La mayoría de las aplicaciones infectadas con Tizi se anuncian en sitios web de redes sociales y tiendas de aplicaciones de terceros, tratando de engañar a los usuarios para que las instalen.

Una vez instalada, la aplicación de aspecto inocente obtiene acceso de root del dispositivo infectado para instalar un spyware, que luego se pone en contacto con sus servidores de comando y control enviando un mensaje de texto SMS con las coordenadas del dispositivo, obtenidas a través del GPS a un número específico.

Tizi para obtener acceso root,  usa varios exploits de puerta trasera revelados previamente por Google, es decir son vulnerabilidades conocidas y para las cuales ya existen parches. El problema está en que muchos fabricantes no han parchado los dispositivos más antiguos y son ellos los que en su mayoría se han visto afectados. Las vulnerabilidades usadas principalmente para escalar privilegios y obtner el acceso de root son: CVE-2012-4220, CVE-2013-2596, CVE-2013-2597, CVE-2013-2595, CVE-2013- 2094, CVE-2013-6282, CVE-2014-3153, CVE-2015-3636 y CVE-2015-1805.

Si la puerta trasera no puede tener acceso de root en el dispositivo infectado debido a todas las vulnerabilidades enumeradas que están siendo parcheadas, Google también advirtió que “todavía intentará realizar algunas acciones a través del alto nivel de permisos que le pide al usuario que le otorguen, principalmente en lectura y envío de mensajes SMS, así como de monitoreo, redireccionamiento y prevención de llamadas salientes“.

El software espía Tizi también se diseñó para comunicarse con sus servidores de comando y control a través de HTTPS regular o mediante el protocolo de mensajería MQTT para recibir comandos de los atacantes y subir los datos robados en servidores remotos.

La puerta trasera Tizi contiene varias capacidades comunes al spyware comercial, tales como:

• Robando datos de plataformas populares de redes sociales como Facebook, Twitter, WhatsApp, Viber, Skype, LinkedIn y Telegram.
• Grabación de llamadas de WhatsApp, Viber y Skype.
• Enviando y recepción de mensajes SMS.
• Acceder a eventos del calendario, registro de llamadas, contactos, fotos y lista de aplicaciones instaladas.
• Robo de claves de cifrado de Wi-Fi.
• Grabación de audio ambiental y toma de imágenes sin mostrar la imagen en la pantalla del dispositivo.

Hasta el momento, Google ha identificado 1,300 dispositivos Android infectados por Tizi y ha eliminado la aplicación.

La mayoría de ellos se ubicaron en países africanos, específicamente Kenia, Nigeria y Tanzania.

¿Cómo podemos proteger a nuestro dispositivo Android de los hackers?

Recordemos de lo expuesto que este spyware para Android suele instalarse de tiendas de terceros o a través de APKs directamente descargado. Así que le recomendamos encarecidamente que siga estos simples pasos para protegerse:

• Asegúrese de que ya haya optado por participar en el programa Google Play Protect.
• Descargue e instale aplicaciones solo desde la tienda oficial Google Play Store, y siempre verifique los permisos para cada aplicación, antes de su instalación.
• Habilite la función ‘verificar aplicaciones’ desde la configuración.
• Proteja su dispositivo con un bloqueo de PIN o contraseña para que nadie pueda obtener acceso no autorizado a su dispositivo cuando permanece desatendido.
• Mantenga las “fuentes desconocidas” deshabilitadas mientras no sea necesario.
• Mantenga su dispositivo siempre actualizado con los últimos parches de seguridad.

Si cree que un sitio web cuyo valor es de más de $500 mil millones no tiene ninguna vulnerabilidad, entonces estás equivocado.

Pouya Darabi, un desarrollador web iraní, descubrió e informó una vulnerabilidad crítica pero directa en Facebook a principios de este mes que podría haber permitido a cualquier persona eliminar cualquier foto de la popular red social.

La vulnerabilidad reside en la nueva función de encuestas de Facebook, lanzada a principios de este mes de noviembre, para publicar encuestas que incluyen imágenes y animaciones GIF.

Darabi analizó la función y descubrió que al crear una nueva encuesta, cualquier persona puede reemplazar fácilmente la ID de la imagen (o el URL de la misma) en la solicitud enviada al servidor de Facebook con la identificación de imagen de cualquier foto en la red social.

Aquí un video dónde se detalla cómo explotar la vulnerabilidad:

 

 

Ahora, después de enviar la solicitud con otra ID de imagen de usuario (cargada por otra persona), esa foto aparecerá en la encuesta.

“Cada vez que un usuario intente crear una encuesta, se enviará una solicitud que contenga la URL de la imagen o la identificación de la imagen, poll_question_data [options] [] [associated_image_id] contiene la identificación de la imagen cargada“, dijo Darabi. “Cuando este valor de campo cambie a cualquier otra identificación de imágenes, esa imagen se mostrará en la encuesta“.

Aparentemente, si el creador de la encuesta la elimina, como se demostró en el video anterior, eventualmente eliminará también la foto de origen, cuya ID de imagen se agregó a la solicitud, incluso si el creador de la encuesta no es el propietario de la foto.

El investigador dijo que recibió $ 10,000 como recompensa por haber descubierto la vulnerabilidad, después de que informara de manera responsable de la misma a Facebook el 3 de noviembre. Facebook corrigió este problema el 5 de noviembre.

Esta no es la primera vez que se descubre que Facebook se enfrenta a este tipo de vulnerabilidades. En el pasado, los investigadores descubrieron e informaron varios problemas que les permitian eliminar videos, álbumes de fotos y comentarios o modificar mensajes desde la plataforma de Facebook.

Darabi también ha sido galardonado previamente por Facebook con una recompensa de caza de errores de $ 15,000 por eludir sus sistemas de protección contra falsificaciones de solicitudes entre sitios (en 2015) y otro de $ 7,500 por un problema similar (en 2016).

Hace dos semanas publicamos un post titulado “Si usas procesadores Intel, tienes un gran problema“, al parecer nuestro temor era más que fundado ya que el día de ayer Intel finalmente aceptó que sus procesadores eran vulnerables.

Aquí la traducción de lo publicado ayer en Tom’s Hardware sobre el tema:

En los últimos meses, los investigadores de seguridad de Purism, Positive Technologies e incluso Google han encontrado formas de desactivar el firmware privativo del Management Engine (ME) en los procesadores Intel. Esto parece haber impulsado a Intel a hacer una revisión de su firmware y tapar la mayoría de los agujeros que permitieron a los investigadores tomar el control del ME.

Los investigadores inhabilitan el ME

Este año, los investigadores de seguridad de Purism, el fabricante de computadoras portátiles basadas en Linux enfocadas en la privacidad, y Positive Technologies comenzaron a buscar formas de desactivar el firmware ME de Intel. Muchos activistas de la privacidad, incluidos los investigadores de seguridad de Purism, temen que ME pueda ser utilizado como puerta trasera.

El modelo propietario de código cerrado del firmware ME también niega a la mayoría de las personas (excepto la NSA) la capacidad de ver lo que este hace en una computadora, lo que significa que podría venir con fallas de seguridad que podrían ser explotadas por atacantes sofisticados.

Ambas preocupaciones llevaron a Google a trabajar en la desactivación de ME para sus servidores, por lo que puede estar más seguro de que no podría ser explotado por los ciberdelincuentes.

La última gran revelación sobre las vulnerabilidades de ME fue un reciente anuncio de un investigador de Positive Technologies de que han logrado el control total de ME (y por lo tanto de la computadora en cuestión) a través del puerto USB. El investigador no reveló más en ese momento, pero está a punto de presentar el hack en la próxima conferencia del Chaos Computer Club (34C3) a fines de diciembre.

Intel anuncia un parche para la vulnerabilidad

Intel anunció que ha completado una revisión de seguridad de su firmware ME, así como los Servicios de plataforma de servidor Intel (SPS) y el Motor de ejecución de confianza (TXE) de Intel con el objetivo de mejorar la resistencia del firmware. La revisión fue impulsada por el último trabajo de “investigadores externos“.

Intel identificó varios fallos de seguridad en las versiones de firmware ME 11.0 / 11.5 / 11.6 / 11.7 / 11.10 / 11.20, así como en el firmware SPS versión 4.0 y la versión 3.0 de TXE. Como Purism nos dijo recientemente, la versión 11 de ME es bastante diferente de la que Intel usó antes y también se ejecuta en un procesador x86 por separado, en comparación con un procesador Arc como antes. Las versiones 11 y posteriores están disponibles para los procesadores Intel de 6ª generación (Skylake) y más recientes.

La lista completa de CPU impactadas incluye:

• 6th, 7th & 8th Generation Intel Core Processor Family
• Intel Xeon Processor E3-1200 v5 & v6 Product Family
• Intel Xeon Processor Scalable Family
• Intel Xeon Processor W Family
• Intel Atom C3000 Processor Family
• Apollo Lake Intel Atom Processor E3900 series
• Apollo Lake Intel Pentium
• Celeron N and J series Processors

Como muchos activistas de seguridad y privacidad han temido, los fallos recientes podrían permitir que un atacante obtenga acceso no autorizado a la funcionalidad ME y secretos de terceros protegidos por el ME, el SPS o el TXE.

Para determinar si las vulnerabilidades encontradas recientemente afectan su sistema, Intel ha creado una herramienta de detección que se puede descargar desde su sitio. La herramienta está disponible solo para usuarios de Windows y Linux.

El parche destinado a corregir estas vulnerabilidades no será provisto por Intel. Deberá consultar con el OEM de su computadora portátil o con el fabricante de la placa base de su PC para ver si han lanzado una actualización de firmware que corrige los fallos recientes.

Purism nos dijo en un correo electrónico que, aunque necesitan probar el nuevo firmware, piensan que todavía deberían poder usar el modo no documentado que la NSA también ha estado usando para continuar desactivando el ME en sus computadoras portátiles, ya que las recientes vulnerabilidades anunciadas por Intel no parecen relacionarse con esta.

La pregunta que me hago es que pasará con procesadores que están aún en operación en multitud de proveedores de hosting, que están más alla de su vida útil y que por lo tanto no recibiran ningún parche. Es muy común en la industria del hosting y de los VPS tener operando procesadores Xeon mucho más alla de que el fabricante ha decretado el final de su vida.

Pero como dicen, incluso hasta el camino más largo empiza con un primer paso. Por lo menos Intel ha reconocido que hay un problema y poco a poco toda los fabricantes de equipos que usan procesadores Intel deberán proveer un parche que solucione el problema. Aunque la verdadera y única solución sería deshabilitar el ME.

La razón por la que las personas compran un smartphone como los Pixel o Nexus es porque desean tener acceso a las últimas versiones del sistema operativo y contar con las actualizaciones de seguridad lo más pronto posible. Especialmente esto último es importante si usamos el smartphone para muchas de nuestras actividades profesionales.

Cuándo compré el Pixel 2 XL, además de hacerlo porque era un smartphone que tenía unas características técnicas que estaban a la par de los demás teléfonos de gama alta, era ante todo para poder instalar las útlimas versiones de Android y sobre todo para poder contar con las actualizaciones de seguridad tan pronto como Google las haga públicas. Y en teoría mi Pixel 2 XL puede hacer todo eso, el problema está en el carrier que uso TMobile.

Según este hilo de Reddit, resulta que TMobile debe autorizar la descarga de la actualización de seguridad a mi dispositivo móvil. No importa que yo lo haya comprado desbloqueado a precio completo, mi carrier por incompatibilidades de su propia tecnología deshabilita actualizaciones en el smartphone en cuánto tenga instalada la SIM.

Para que se hagan una idea de mi frustación cuándo leí el hilo de Reddit, les voy a traducir aquí la parte que me afecta:

Asociación a un operador, y cómo funciona.

Cuando enciende su smartphone por primera vez con una tarjeta SIM instalada, ese smartphone se asocia con esa compañía en la base de datos de Google. Esto NO es un bloqueo de operador y Google lo usa para fines de identificación. Permíteme demostrarlo:

• Haga clic aquí (EDITADO: Haga esto en su PC, no en su teléfono).
• Haga clic en el icono de engranaje en la esquina superior derecha y seleccione “Configuración”.
• Debajo de mis dispositivos, verás la(s) asociación(es) de operadores de todos tus dispositivos Android que actualmente tienen vinculada tu cuenta de Google.
• En mi caso, tengo T-Mobile, Verizon y AT & T para ciertos teléfonos. Mi Nexus Player, Nvidia Shield ATV y LG Watch Style aparecen como “Sin portadora”.

Google mantiene esta lista y cuando envían una actualización, todos los teléfonos asociados a un proveedor que aprobó la actualización o un operador que no tiene ninguna función en el proceso, reciben esa actualización. Las empresas que aún no han aprobado la actualización no envían la actualización.

Puedes cambiar tu asociación de operador intercambiando la tarjeta SIM por una de un operador diferente y reiniciar. O bien, puede eliminar tu asociación de operador apagándo, removiendo la tarjeta SIM (no lo reinsertes), encendiéndolo y reiniciando con la configuración de fábrica. Sin una tarjeta SIM instalada, el smartphone nuevo no tiene una asociación de operador y extraerá la última actualización disponible.

Demostración en vivo.

Aquí está el video, y para aquellos que no pueden verlo ahora, a continuación hay un resumen de lo que sucedió. Tenga en cuenta que voy a desmonetizar el video (sin anuncios míos) durante 48 horas o por el tiempo que esté en la página principal de los subtítulos publicados, lo que dure más. Normalmente me gusta monetizar mi contenido (sin duda de baja calidad), pero mi objetivo con este video y publicación asociada era difundir el conocimiento, no hacer dinero rápido.

• Demuestro que se trata de un smartphone Pixel 2, en la red T-Mobile, con el software 8.0 de septiembre instalado.
• La comprobación manual de la actualización muestra que el sistema está actualizado.
• Cambié la tarjeta SIM a una de AT&T, que no revisa las actualizaciones del Pixel 2 en el mismo grado (si es que lo hace) cuando tiene el SIM de T-Mobile.
• Una vez que se enciende y se conecta a la red de AT&T, la actualización está disponible y comienza a instalarse. Yo apago el smartphone.
• Reinstalo la SIM de T-Mobile y luego de encendido el smartphone, bloquea activamente la instalación de la actualización y una vez más establece que ‘el sistema está actualizado’ con el software de septiembre.

Realmente es frustante que TMobile haga esto a sus clientes, además otros carries (MVNO) más pequeños que corren sobre la red de TMobile que también presentan este mismo problema con los Pixel y Nexus son:

• MetroPCS
• Consumer Cellular
• Net10
• Republic Mobile
• Simple Mobile
• Ultra Mobile
• Univision Mobile
• US Mobile
• Straight Talk
• Ting
• TrackFone

No son todos los MVNO que trabajan sobre la red de TMobile, pero son los más comunes de encontrar en New York City, que es dónde vivo.

He leído una noticia en ZDNet que realmente me ha puesto los pelos de punta, básicamente todos los chips que Intel ha fabricado desde el 2008 tienen un sistema operativo con acceso a redes TCP/IP y un servidor web que permite administrar la computadora por completo en teoría desde cualquier lugar de la tierra. Así como lo escucharon el mismo procesador, lo peor de todo es que no puede ser deshabilitado ya que forma parte integral del sistema.

Si por alguna razón alguien encuentra alguna vulnerabilidad en este sistema operativo propietario de Intel, que está basado en MINIX, pues sencillamente podría llevarnos a la edad de piedra, dado que la mayoría de nuestras computadoras podrían quedar fuera de servicio.

Aquí les traduzco la noticia que realmente es muy impactante:

Quizás no seas paranoico. Sin embargo, tal vez están tratando de atraparte. Ronald Minnich, un ingeniero de software de Google, ha descubierto un sistema operativo MINIX oculto dentro de “aproximadamente mil millones de computadoras” que usan procesadores Intel, tal vez deberías considerar ser paranoico.

¿Por qué? Comencemos con qué. Matthew Garrett, el conocido desarrollador de Linux y seguridad que trabaja para Google, explicó recientemente que, “los conjuntos de chips de Intel desde hace algunos años incluyen un Management Engine [ME], un pequeño microprocesador que funciona independientemente de la CPU principal y el sistema operativo. las piezas de software se ejecutan en el ME, que van desde el código para manejar DRM de medios a una implementación de un TPM. AMT [Active Management Technology] es otra pieza de software que se ejecuta en el ME “.

En mayo, descubrimos que AMT tenía una gran falla de seguridad, que había estado ahí por nueve años.

“Reparar esto requiere una actualización del firmware del sistema para proporcionar un nuevo firmware ME (incluida una copia actualizada del código AMT)”, escribió Garrett. “Muchas de las máquinas afectadas ya no reciben actualizaciones de firmware de sus fabricantes, por lo que probablemente nunca se solucionen”, dijo. “Cualquiera que haya habilitado AMT en uno de estos dispositivos será vulnerable”.

¡Rápido! ¿Cuántos de ustedes parchearon el firmware de su PC o del chip del servidor? ¡Entonces!. Maldigo a algunos de ustedes. Eso es malo. No se trata de todos los procesadores, pero si usted o su proveedor de hardware han “habilitado AMT explícitamente”, su máquina aún es vulnerable a los ataques.

La Electronic Frontier Foundation (EFF) ha pedido a Intel que brinde a los usuarios una forma de desactivar el ME. Los investigadores rusos han encontrado una forma de desactivar ME después de que el hardware se haya inicializado y el procesador principal haya comenzado. Eso realmente no ayuda mucho. ME ya se está ejecutando para entonces.

Pero Minnich descubrió que lo que sucede dentro del chip es aún más problemático. En una presentación en Embedded Linux Conference Europe, informó que los sistemas que usan chips Intel que tienen AMT, están ejecutando MINIX.

Si aprendió sobre los sistemas operativos a finales de los 80 y principios en los 90, sabra que MINIX era el sistema operativo educativo tipo Unix de Andrew S Tanenbaum. Fue utilizado para enseñar los principios de sistemas operativos. Hoy en día, es mejor conocido como el SO que inspiró a Linus Torvalds a crear Linux.

Entonces, ¿qué está haciendo en los chips de Intel? Mucho. Estos procesadores ejecutan una variación de fuente cerrada del MINIX 3 que es un sistema operativo de fuente abierta. No sabemos exactamente qué versión o cómo se ha modificado ya que no tenemos el código fuente. Lo sabemos es que está allí:

• Ni Linux, ni ningún otro sistema operativo tiene el control final de la plataforma x86
• Entre el sistema operativo y el hardware hay al menos 2 kernels y medio de Sistemas Operativos (MINIX y UEFI)
• Estos son propietarios y (quizás no sorprendentemente) amigables con los exploits.
• Y los exploits pueden persistir, es decir, estar escritos en FLASH, y no se puede arreglar eso.

Además, gracias al trabajo de Minnich y sus colegas investigadores, sabemos que MINIX se ejecuta en tres núcleos x86 separados en chips modernos. Ahí, se está ejecutando:

• Una pilas de red TCP / IP (versiones 4 y 6)
• Un sistemas de archivos
• Controladores (disco, red, USB, mouse)
• Servidores web

MINIX también tiene acceso a tus contraseñas. También puede sobreescribir el firmware de tu computadora incluso si está apagada. Déjame repetir eso. Si tu computadora está “apagada” pero todavía está conectada, MINIX aún puede potencialmente cambiar la configuración fundamental de tu computadora.

Y, para mayor diversión, “puede implementar código de auto modificación que puede persistir en los ciclos de reinicio”. Entonces, si un exploit ocurre a este nivel, incluso si desenchufa tu servidor en un último intento desesperado por salvarlo, el ataque seguirá allí esperando por vuelvaa a enchufar tu server para continuar.

¿Cómo? MINIX puede hacer todo esto porque se ejecuta en un nivel fundamentalmente inferior.

Las computadoras basadas en x86 ejecutan su software en diferentes niveles de privilegios o “anillos”. Tus programas se ejecutan en el tercer anillo y tienen el menor acceso al hardware. Cuanto menor sea el número al que se ejecuta tu programa, más acceso tendrán al hardware. Los anillos dos y uno no tienden a ser utilizados. Los sistemas operativos se ejecutan en el anillo cero. Los hipervisores de bare-metal, como Xen, se ejecutan en el anillo -1. La interfaz de firmware extensible unificada (UEFI) se ejecuta en el anillo -2. ¿Y MINIX? Se ejecuta en el anillo -3.

No puedes verlo No puedes controlarlo Simplemente está zumbando allí, ejecutandose en tu computadora. El resultado, según Minnich, es que “hay grandes agujeros gigantes a los que las personas pueden lazar exploits”. Continuó, “¿Ya te dió miedo? Si aún no tienes miedo, quizás no lo explique muy bien, porque yo estoy muy asustado”.

¿Cual es la solución? Bueno, no es “Cambiar a chips AMD”. Una vez, los chips AMD no tenían oculto este tipo de código misterioso, pero incluso los últimos procesadores Ryzen no están totalmente abiertos. Incluyen el proceso de seguridad de la plataforma AMD y también es esta es una caja negra.

Lo que a Minnich le gustaría que suceda es que Intel haga público su código MINIX y use un firmware de código abierto basado en Linux. Esto sería mucho más seguro. El software actual solo está protegido por “seguridad por oscuridad”.

Cambiar a Linux también permitiría a los servidores arrancar mucho más rápido. Según Minnich, arrancar un servidor Open Compute Project (OCP) lleva ocho minutos gracias a los controladores primitivos de MINIX. Con Linux tardaría menos de 17 segundos en acceder a un intérprete de comandos de shell. Esa es una aceleración de 32 veces.

No hay razón para no hacer esta mejora. Minnich señaló: “Probablemente haya más de 30 millones de Chromebooks disponibles y cuando su Chromebook obtenga un nuevo BIOS, una nueva imagen de Linux se actualizará al firmware y no he oído hablar de ningún problema”.

Específicamente, qué propone Minnich a Intel y AMD en relación a este asunto:

• Hacer que el firmware sea capaz de hacer menos daño.
• Haz que sus acciones sean más visibles.
• Eliminar tantos componentes de tiempo de ejecución como sea posible.
• En particular, quitar su servidor web y pila de IP.
• Eliminar la pila IP del UEFI y otros controladores.
• Eliminar la capacidad de sobre-escritura del ME/UEFI entre sí.
• Dejar que Linux administre las actualizaciones de flash.

Sobre esto, el nuevo firmware de Linux tendría un espacio de usuario escrito en Go. Los usuarios trabajarían con este shell de Linux usando comandos familiares. Esto les daría una visión clara de lo que estaba sucediendo con la CPU y otros componentes del sistema.

Al mismo tiempo, dado que UEFI es tan fácil de hackear, quiere que la “ROM de UEFI se reduzca a sus partes más básicas”.

¿Funcionaría esto? Todavía es pronto para saberlo, advirtió Minnich y puede convertir “su computadora portátil en un ladrillo”. Pero tanto para la seguridad como para el rendimiento, es necesario hacerlo.

Está claro que un Unix oscuro como MINIX, gracias a que Intel lo pone en múltiples núcleos en sus chips, puede ser el sistema operativo más utilizado en el mundo. Pero no es forma de ejecutar servidores y mucho menos PC modernos.