Nunca atribuyas a la maldad lo que puede ser explicado por la estupidez

Estándar

El título de este post es el famoso Principio de Hanlon, y creo que puede explicar muy bien el grave error que ha tenido el programa de correo electrónico Microsoft Outlook que por al menos 6 meses según se ha hecho público ha estado enviando correos encryptados a la vez que envia una copia del mismo en texto plano.

De acuerdo a la firma de consultoría de seguridad informática SEC Consult, desde al menos los últimos 6 meses, los mensajes de correo electrónico enviados en forma encriptada por Microsoft Outlook, también estaban siendo enviados con una copia no encriptada del mismo, exponiendo todas las comunicaciones secretas y sensibles de la empresa a posibles intrusos.

El protocolo S/MIME (Secure/Multipurpose Internet Mail Extensions), es un protocolo de encriptación de extremo a extremo basado en la criptografía de clave pública y que funciona igual que las conexiones SSL, lo que permite a los usuarios enviar mensajes cifrados y encriptados digitalmente.

De acuerdo con un aviso de seguridad publicado por SEC Consult a principios de esta semana, un error grave que ha recibido el código de error CVE-2017-11776, en el cliente de correo electrónico de Microsoft Outlook que hace que los mensajes de correo electrónico encriptados con el protocolo  S/MIME se envíen con sus versiones sin encriptar a la par de la versión encriptada.

Cuando los usuarios de Outlook utilizan S/MIME para cifrar sus mensajes y formatear sus correos electrónicos como texto sin formato, la vulnerabilidad permite que los correos electrónicos aparentemente cifrados se envíen en formularios de texto claro tanto como encriptados, lo cual los hace legibles para los humanos.

Los usuarios no eran conscientes de este problema de seguridad, ya que los mensajes aparecerían como cifrados en la carpeta “Enviados” de la aplicación de Outlook.

La activación de esta vulnerabilidad no requiere una participación activa de un atacante. Es más un atacante podría permanecer completamente pasivo. El impacto de esta vulnerabilidad es muy serio ya que un supuesto correo cifrado S/MIME destinado al envio de información confidencial se puede leer sin las claves privadas del destinatario. Esto resulta en pérdida total de la privacidad proporcionadas por el cifrado.

Los atacantes con acceso a las conexiones no cifradas de servidor a servidor o cliente a servidor podrían aprovechar fácilmente esta vulnerabilidad para leer las comunicaciones de correo electrónico en texto sin formato. Cómo se puede acceder a una comunicación de servidor a servidor o de un cliente a servidor, pues sencillamente escuchando todo el tráfico a través del puerto 25 que es el usado por el protocolo SMTP para envio de correos.

Por lo tanto, si utilizó el cifrado S/MIME de Outlook para correos electrónicos en los últimos 6 meses, sus correos electrónicos no se han cifrado en absoluto; en su lugar, salieron en texto plano.

Según los investigadores, el alcance de la vulnerabilidad depende de cómo se haya configurado Outlook.

En el caso de un Outlook con Exchange en la misma network.

Si está utilizando Outlook con Exchange, la versión de texto sin formato de los correos electrónicos cifrados sólo alcanzará un salto, ya que el envío de correos electrónicos al servidor de correos externo eliminará la parte de texto plano del mensaje.

Pero si el destinatario y el remitente están en el mismo dominio (servidor), la parte de texto plano también se enviará al destinatario. Pero en este caso cómo todo ocurre dentro de la misma empresa, el impacto debería ser limitado.

Si, existe una computadora infectada dentro de la red local de la empresa que colecta información, entonces habría un problema.

Outlook usando SMTP con un servidor externo.

Si está ejecutando Outlook con SMTP, la versión de texto sin formato de los correos electrónicos cifrados no sólo será recibida por el destinatario sino también por todos los servidores de correo a lo largo de la ruta que conectan el servidor de origen con el servidor de destino.

Este es el peor escenario posible de todos. Ya que técnicamente hay millones de correos electrónicos “cifrados” con una copia en texto plano distribuidos alrededor de un número no conocido de servidores SMTP alrededor del mundo.

Los investigadores de la SEC Consult descubrieron el problema en mayo y lo informaron responsablemente a Microsoft, pero no recibieron noticias del gigante de la tecnología. Lo cuál es desconcertante, ya que este es un grave error que compromete la seguridad mayormente de la base de usuarios más importante de Microsoft, los usuarios corporativos.

Microsoft lanzó un parche para corregir el error en el lanzamiento de actualizaciones de seguridad de este mes y calificó el problema como “importante”, alegando que la explotación de esta vulnerabilidad era “improbable” en estado salvaje. Lo cuál realmente nos indica lo desconectados que están de la realidad los ingenieros de Microsoft.

Por lo tanto, si Ud. utilizo el S/MIME de Outlook para encriptar sus correos electrónicos sensibles, se recomienda que actualize el sistema lo antes posible.

Creo que ahora ya pueden comprender porque a este post lo titulé con el famoso Principio de Halon.

ATMii el malware que hace escupir dinero a los cajeros automáticos

Estándar

Kaspersky Lab ha descubierto y hecho público a través de un post en su blog un malware llamado ATMii que hace realidad la peor pesadilla de un banco, hace escupir dinero a los cajeros automáticos.

Este malware se compone de dos partes: un módulo inyector que se dirige al software del cajero automico (ATM por sus siglas en inglés) y al módulo a inyectar. El código incorrecto utiliza una bibliotecas propietarias legítimas; los ciberdelincuentes pueden acceder al ATM objetivo a través de la red o físicamente a través de puertos USB disponibles en muchos ATM en nuestros días, para cargar los archivos maliciosos en los sistemas.

Travis Smith, principal investigador de seguridad de Tripwire, también señaló que el malware ATMii está muy orientado a un objetivo específico, no sólo por el hecho de que esté sólo ataca a los cajeros automáticos que tienen Windows 7 como su sistema operativo, sino también porque está dirigido a un ejecutable ATM específico (atmapp.exe), que es específico de ciertos modelos de cajeros y que al parecer fue desarrollado sin mucho cuidado.

Según lo publicado por Travis Smith:

Según el informe inicial de Kaspersky, se trata de una aplicación propietaria, por lo que es improbable que esta variante de malware tenga un gran impacto en el mercado de cajeros automáticos en todo el mundo. Incluso con un impacto mínimo, es muy fácil prevenir la ruta de infección del malware mediante la implementación de controles de base. Limitar el acceso a la red y la desactivación de los puertos USB reducirá la superficie de ataque lo suficiente como para que este tipo simple de malware no llegue a un cajero automático.

Kaspersky Lab dijo también en su blog que ATMii es otro ejemplo de cómo los cibercriminales pueden usar un pequeño pedazo de código para enriquecerse a sí mismos. Una muestra del malware ATMii fue proporcionada a Kaspersky Lab por un socio de la industria financiera en abril de este año; comparte algunas similitudes con la última versión de otro malware orientado a cajeros automáticos llamado Skimer, malware que fue reportado por Kaspersky Lab el año pasado.

Durante nuestros recientes casos de Respuesta a Incidentes relacionados con el abuso de cajeros automáticos, hemos identificado Tyupkin, Carbanak y los ataques de la caja negra“, dijo Kaspersky Lab. “La evolución de Backdoor.Win32.Skimer demuestra el interés del atacante en estas familias de programas maliciosos, ya que los cajeros automáticos son un mecanismo muy efectivo para los criminales. Kaspersky Lab ha identificado 49 modificaciones de este malware, con 37 de estas modificaciones dirigidas a los cajeros automáticos ensamblados por un solo fabricante “.

Para protegerse contra tales ataques, Kaspersky Lab recomienda a los operadores de cajeros automáticos incorporar políticas de denegación predeterminada y control de dispositivos, así como medidas técnicas para proteger el cajero automático contra el acceso físico.

Grave vulnerabilidad de iOS revela el password del Apple ID

Estándar

El empresario de herramientas de desarrollo Open Source Felix Krause, ha hecho público en su blog personal bajo el título “Privacidad de iOS: robar.password – Obtenga fácilmente la contraseña de una cuenta Apple ID, simplemente preguntando“, una grave vulnerabilidad que permite acceder al password de una cuenta Apple ID usando técnicas de phishing.

El mecanismo descrito para obtener el password sería el siguiente:

iOS le pide al usuario su contraseña de iTunes por muchas razones, las más comunes son las actualizaciones del sistema operativo iOS recientemente instaladas o las aplicaciones iOS que están bloqueadas durante la instalación.

Como resultado, los usuarios están entrenados para ingresar su contraseña de ID de Apple siempre que iOS se los solicite que lo haga. Sin embargo, esas ventanas emergentes no sólo se muestran en la pantalla de bloqueo y en la pantalla de inicio, sino también en aplicaciones aleatorias, por ejemplo cuando se quiere acceder a iCloud, GameCenter o a compras dentro de un App.

Esto podría ser abusado fácilmente por cualquier aplicación, sólo por mostrar un UIAlertController, que se ve exactamente como el diálogo del sistema.

Incluso los usuarios que saben mucho sobre tecnología tienen dificultades para detectar que esas alertas son ataques de phishing.

Aquí una gráfica que comprara ambos tipos de pop-up, el oficial y uno creado programáticamente para robar el password:

Cómo es posible protegerte contra una aplicación diseñada para robar tu password, pues Felix Krause nos recomienda lo siguiente:

  • Pulse el botón de inicio, y ver si la aplicación se cierra:
    • Si la aplicación se cierra y con ella el diálogo, entonces esto fue un ataque de phishing
    • Si el diálogo y la aplicación siguen visibles, entonces es un diálogo del sistema. La razón de ello es que los diálogos del sistema se ejecutan en un proceso diferente y no como parte de ninguna aplicación de iOS.
  • No introduzca sus credenciales en una ventana emergente, en su lugar,  desechela y abra la aplicación Settings manualmente. Este es el mismo concepto, como el de que usted nunca debe hacer clic en los enlaces en los correos electrónicos, pero en su lugar abrir el sitio web manualmente
  • Si pulsa el botón Cancelar en un cuadro de diálogo, la aplicación seguirá accediendo al contenido del campo de contraseña. Incluso después de introducir los primeros caracteres, la aplicación probablemente ya tiene su contraseña.

El investigadir Krause ha reportado el bug a Apple y esperemos que pronto esto quede solucionado para el bien de los usuarios de esta plataforma. Pero es increíble cómo en un periodo tan corto de tiempo el hasta no hace mucho considerado “sistema más seguro”, está haciendo agua por todos lados.

Alphabet solicita a las autoridades permiso para proveer servicio Internet en Puerto Rico con globos

Estándar

El viernes pasado (6 de Octubre) en  la revista de tecnología Wired se reportó que ingenieros en Alphabet, la compañía madre de Google, que podían ofrecer conectividad a Internet en Puerto Rico usando el famoso Proyecto Loon. Recordemos que los huracanes Irma y María dejaron más del 90 por ciento de la isla sin cobertura de teléfono móvil. Sólo siete días después, la Comisión Federal de Comunicaciones (FCC) dio a Alphabet la luz verde para volar 30 globos sobre Puerto Rico y las Islas Vírgenes de Estados Unidos hasta por seis meses, para proveer servicio de voz y datos.

Si todo va como se ha planeado, los globos de Alphabet pronto ayudarán a reemplazar a las miles de torres de teléfonos móviles que han sido puestas fuera de servicio por los vientos de los huracanes que golperon la pequeña isla en el caribe. Los globos proporcionarían servicios de voz y datos a través de los operadores locales a los teléfonos móviles de los usuarios.

Esta no es la primera vez que el proyecto Loon de Alphabet ha sido desplegado. Durante las inundaciones que sufrió el Perú a principios de este año, los globos de Loon fueron usados para proporcionar servicio telefónico de emergencia. En Perú, Alphabet ya había estado trabajando estrechamente con el carrier local de telefonía móvil, Telefónica, para coordinar el uso del espectro y preparar a los teléfonos para trabajar con sus globos.

Con la licencia temporal especial de la FCC obtenida por Alphabet en Puerto Rico, la empresa planea trabajar en la misma línea que en Perú. Treinta globos Loon flotarán a 20 kilómetros de la Tierra en la estratosfera, transmitiendo las comunicaciones entre las propias estaciones terrestres de Alphabet conectadas a las redes inalámbricas supervivientes y los teléfonos de los usuarios.

Cada globo puede servir aproximadamente 5,000 kilómetros cuadrados, por lo que se espera que la flota de 20 globos preste servicio a todo Puerto Rico y partes afectadas de las Islas Vírgenes de los Estados Unidos. Alphabet ha dicho que consultaría con las redes en las Islas Vírgenes Británicas para minimizar la interferencia allí.

Un bug en Apple macOS High Sierra expone la contraseña para los volúmenes de APFS encriptados como sugerencia

Estándar

En un post publicado en el portal de noticias de seguridad informática TheHackerNews, se da cuenta del descubrimiento de un bug de seguridad muy severo descubierto por el desarrollador brasileño Matheus Mariano, esta vulnerabilidad afecta a los volúmenes cifrados utilizando APFS, donde la sección de sugerencias (hint) de contraseña muestra la contraseña real del volumen en formato de texto plano.

Sí, Ud. ha leido bien. Las computadoras Mac revelan la contraseña real en lugar de una sugerencia de cómo debe ser la misma.

En septiembre, Apple lanzó MacOS High Sierra 10.13 con APFS como el sistema de archivos por defecto para unidades de estado sólido (SSD) y otros dispositivos de almacenamiento totalmente flash, prometiendo tanto un cifrado fuerte y un mejor rendimiento.

Mariano descubrió el problema de seguridad mientras usaba Disk Utility en macOS High Sierra para agregar un nuevo volumen APFS cifrado a un contenedor. Al agregar un nuevo volumen, se le pidió que estableciera una contraseña y opcionalmente el sistema ofrecía una pista para ello.

Sin embargo, Mariano notó que cuando hizo clic en el botón “Show Hint”, se mostraba la contraseña real del volumen en texto plano en lugar de la sugerencia de contraseña.
Puede ver la demostración del problema en el siguiente vídeo:

 

Este problema de seguridad no es el único descubierto en la último versión del sistema operativo de escritorio presentado por Apple.

Recordemos que a pocas horas antes del lanzamiento de High Sierra, el ex hacker de la NSA, Patrick Wardle, reveló públicamente los detalles de una vulnerabilidad crítica que permitía a las aplicaciones instaladas robar contraseñas y datos secretos del Keychain macOS.

Afortunadamente para los usuarios de macOS, Apple lanzó una actualización suplementaria de MacOS High Sierra 10.13 el pasado 28 de Septiembre, para abordar ambos problemas. Los usuarios de Mac pueden instalar la actualización desde la Mac App Store o descargarla desde el sitio del software de Apple.

Para una compañía que afirma tener como meta la excelencia, todos estos problemas revelan una mala gerencia y un pésimo control de calidad en sus procesos de desarrollo de software. Eso sin mencionar la recientes quejas de usuarios en China que dicen que los iPhone 8 están explotando.

Hackers rusos robaron datos de la NSA sobre la defensa cibernética estadounidense

Estándar

En el Wall Street Journal ayer se hizo público que una violación de seguridad informática, considerada la más grave hasta la fecha, podría permitir a Rusia evadir la vigilancia de la NSA y infiltrarse más fácilmente en las redes de los Estados Unidos.

De acuerdo a lo informado por WSJ, unos ciberdelincuentes que podrían trabajar para el gobierno ruso robaron detalles de cómo los Estados Unidos penetran en las redes de computadoras extranjeras y se defiende contra ataques cibernéticos luego de que un contratista de la Agencia de Seguridad Nacional (NSA) retiró el material altamente clasificado y lo puso en su computadora de casa, según varias personas con conocimiento del asunto.

Los hackers parecen haber apuntado a dicho contratista después de identificar los archivos a través del uso del de una vulnerabilidad/backdoor del antivirus hecho por la empresa Kaspersky Lab de Rusia, todo esto según dice el WSJ.

El robo, que no ha sido revelado, es considerado por los expertos como una de las violaciones de seguridad más significativas en los últimos años. Además ofrece una visión rara en cómo la comunidad de inteligencia piensa que la inteligencia rusa explota un producto de software comercial y extensamente disponible para espiar en los Estados Unidos y esta tal vez es una de las razones por las cuales las autoridades norteamericanas han prohibido a todos los entes gubernamenteles y contratistas de los mismos no usar Kasperky Antivirus.

El incidente que ocurrió en 2015, pero no fue descubierto sino hasta la primavera del año 2016, dijeron las personas familiarizadas con el tema.

El material robado incluyó detalles sobre cómo la NSA penetra en las redes de computadoras extranjeras, el código de computadora que esta agencia usa para tal espionaje y cómo se defienden las redes dentro de los Estados Unidos.

El hecho de disponer de esta información podría dar al gobierno ruso información sobre cómo proteger sus propias redes, lo que dificulta que la NSA lleve a cabo su labor de vigilancia. También podría dar a los rusos métodos para infiltrarse en las redes de Estados Unidos y otras naciones alidas de Estados Unidos.

En lo personal, lo que más preocupa no es que esta información esté en manos de la inteligencia rusa, que ellos la usaran para hacer su trabajo. Lo que me preocupa es lo corrupto del sistema ruso a todos sus niveles y que pronto esta información este disponible, si es que ya no lo está, en la deep web al mejor postor.

¿Cuál es el lenguaje de programación más propenso a errores?

Estándar

Un estudio a gran escala del efecto de los lenguajes de programación sobre la calidad del software que se produce se ha publicado este mes en el website de la ACM (Association for Computer Machinary). Y en este post presentamos algunas de sus principales conclusiones relacionadas con la prevalencia de los errores en los diferentes lenguajes.

Los investigadores Baishakhi Ray, Daryl Posnett, Premkumar Devanbu y Vladimir Filkov utilizaron datos de GitHub para una investigación empírica sobre el eterno debate presente entre los programadores en cuanto a qué lenguaje de programación es mejor para una tarea determinada. Combinaron el modelado de regresión múltiple con la visualización y la analítica del código, para estudiar el efecto de características del lenguaje tales como el tipado estático contra el tipado dinámico en calidad del software producido.

La versión corta de sus conclusiones se da en el resumen del paper presentado:

El diseño del lenguaje de programación tiene un efecto significativo pero modesto en la calidad del software. Lo más notable es que no permitir type confusion es modestamente mejor que permitirlo y entre los lenguajes funcionales, la tipificación estática es también algo mejor que la tipificación dinámica. También encontramos que los lenguajes funcionales son algo mejores que los lenguajes procedurales.

El objetivo de este estudio fue arrojar luz sobre la idea de que la elección del lenguaje de programación afecta tanto al proceso de codificación como al programa resultante, haciendo hincapié en la tipificación estática versus dinámica:

Los defensores de la tipificación fuerte y estática tienden a creer que el enfoque estático detecta los defectos temprano; para ellos, una onza de prevención vale una libra de cura. Los defensores de la tipificación dinámica argumentan, sin embargo, que la verificación conservativa del tipo estático es un desperdicio de recursos para los desarrolladores y que es mejor confiar en la comprobación de tipo dinámico fuerte para detectar errores de tipo a medida que surgen. Estos debates, sin embargo, han sido en gran parte de la variedad de los muchos, apoyados sólo por pruebas anecdóticas.

Para esta investigación, el equipo escogió los 19 lenguajes de programación más usados en GitHub, agregando a Typescript como el número 20 e identificó los 50 primeros proyectos escritos principalmente en cada uno de los lenguajes de programación seleccionados. Luego descartaron cualquier proyecto con menos 28 commits (el primer cuartil) y cualquier lenguaje utilizado en un proyecto multilingüe con menos de 20 commits en ese lenguaje.

Como se muestra en el cuadro a continuación, este estudio incluyó 728 proyectos desarrollados en 17 lenguajes de programación. Los proyectos abarcaron 18 años de historia e incluyeron 29,000 desarrolladores diferentes, 1,57 millones de commits y 564,625 commits de corrección de errores:

Luego, el equipo de investigadores definió las clases de idiomas, distinguiendo entre tres paradigmas de programación: procedural, scripting y funcional; dos categorías de comprobación de tipo: estática y dinámica; si la conversión implícita de tipos está prohibida o permitida y si la memoria es administrada en oposición a la no administrada, cómo resultado de este proceso se produjo la siguiente tabla de clasificación de los lenguajes:

Utilizando la búsqueda de palabras clave para el 10% de los mensajes de corrección de errores para luego introducirlo en un clasificador de errores, los investigadores identificaron la causa y el impacto de cada commit en la correción de errores. El siguiente cuadro resume sus resultados:

La primera pregunta que trata de abordar este estudio es “¿Son algunos lenguajes de programación más propensos a errores que otros?” y esto se hizo utilizando un modelo de regresión para comparar el impacto de cada lenguaje en el número de errores, con el impacto medio de todos los lenguajes, contra la corrección de errores en los commits:

En la parte superior de la tabla mostrada arriba de este párrafo, se encuentran las variables que se utilizan como controles para los factores que pueden estar correlacionados. La edad del proyecto se incluye ya que los proyectos más antiguos generalmente tendrán un mayor número de correcciones de errores; el número de desarrolladores involucrados y el tamaño bruto del proyecto también se espera que afecten el número de errores y finalmente el número de commits está presente. Se encontró que los cuatro tenían coeficientes positivos significativos. Los lenguajes con los coeficientes positivos más fuertes, es decir, asociados con un mayor número de correcciones de errores son C ++, C y Objective-C, también PHP y Python. Por otro lado, Clojure, Haskell, Ruby y Scala tienen coeficientes negativos significativos que implican que estos lenguajes son menos propensos que el promedio a dar lugar a corrección de errores en los commits.Con respecto a las clases de lenguajes, los lenguajes funcionales se asocian con menos errores que los lenguajes procedurales o de scripting.

Los investigadores, luego volvieron su atención a la tendencia a producir errores de los lenguajes, la proporción entre los commits hechos para corregir errores y los commits totales por cada lenguaje y dominio y produjeron un mapa de calor donde el color más oscuro indica mayor propensión a los errores:

Del mapa de calor anterior, los investigadores concluyeron que no existe una relación general entre el dominio de la aplicación y la propensión a errores del lenguaje de programación. Sin embargo, si observamos la relación entre la clase de lenguaje y la categoría de errores, los investigadores indicaron que:

Los tipos de errores que están fuertemente asociados con los lenguajes, como algunos tipos de bugs como errores de memoria y de concurrencia también dependen de las primitivas del lenguaje. El lenguaje importa más para categorías específicas que para los defectos en general.

Dado que este mapa de calor muestra una fuerte relación entre la clase de lenguaje Procedural-Static-Implicit-Unmanaged y los errores de simultaneidad y memoria, también muestra que los lenguajes estáticamente tipados son en general más propensos a fallos y errores de rendimiento, a los que le siguen los lenguajes Functional-Dynamic-Explicit-Managed, como Erlang.

En resumen, las conclusiones del informe son las siguientes:

Los datos indican que los lenguajes funcionales son mejores que los lenguajes procedurales; sugiere que no permitir la conversión implícita de tipos es mejor que permitirlo; que el tipado estático es mejor que el dinámico y que el uso de memoria administrada es mejor que no administrado. Además, el hecho de que los lenguajes de programación en general no estén relacionadas con los dominios del software. Además, los lenguajes de programación están más relacionados con las categorías de errores individuales que con los errores en general.

Aquí termino mi resumen del extenso y detallado estudio, en caso se sientan interesados en conocer más y entender cómo se produjeron las estadísticas los remito al estudio original.

Las Apple Mac siguen siendo vulnerables a hacks de Firmware EFI

Estándar

Uno de los consejos más populares y críticos que cada experto en seguridad informático le sugiere encarecidamente a todos los usuarios es: “Mantener actualizado el sistema operativo y el software a la última versión”, para así poder evitar ataques cibernéticos importantes.

Sin embargo, incluso si sigue fielmente esta política y aplica a su sistema cada actualización de software disponible, hay una buena probabilidad de que su equipo permanezca obsoleto y vulnerable a ataques.

Los investigadores de la empresa de seguridad Duo Labs analizaron más de 73.000 sistemas Mac y descubrieron que un sorprendente número de computadoras Apple Mac falla al instalar parches para las vulnerabilidades de firmware de EFI o no recibe ninguna actualización en absoluto por parte del fabricante.

Apple utiliza la Interfaz de Firmware Extensible (EFI, por sus siglas en inglés), diseñada por Intel para ordenadores Mac y que funciona a un nivel inferior al Sistema Operativo de una computadora o un hipervisor (en sistemas virtualizados), controla el proceso de inicio del hardware. Anteriormente esta capa de firmware en computadoras personales era conocida como el BIOS.

Debido a que EFI se ejecuta antes de que el sistema operativo MacOS arranque y tiene privilegios de nivel superior que este, si son explotados por ciberdelincuentes, podrían permitir que el software malicioso de EFI controle todo sin ser detectado.

En el comunicado de Duo Labs podemos leer lo siguiente:

Además de la capacidad de eludir controles de seguridad de nivel superior, atacar el EFI también hace que el adversario sea muy furtivo y difícil de detectar (es difícil confiar en el sistema operativo para obtener la verdad sobre el estado del EFI); también hace que el adversario sea muy difícil de eliminar: instalar un nuevo sistema operativo o incluso reemplazar el disco duro por completo no es suficiente para desalojarlos

¿Que puede ser peor? Pues además de no implementar las actualizaciones de EFI en algunos sistemas, Apple ni siquiera advierte a sus usuarios sobre el fallido proceso de actualización del EFI o fallos técnicos, dejando a millones de usuarios de computadoras Mac vulnerables a sofisticados y avanzados ataques cibernéticos persistentes.

En promedio, Duo dijo que el 4.2% de la muestra de 73,324 Macs del mundo real utilizados en los entornos empresariales se encontraban ejecutando una versión de firmware EFI diferente al que debería estar ejecutando basado en el modelo de hardware, la versión del sistema operativo y la versión EFI publicada con esa version de Sistema Operativo.

Uno se sorprendería al conocer los números de algunos modelos de Mac específicos, el 43% de los modelos de iMac analizados (los de 21.5 pulgadas de finales del 2015) se encontraban ejecutando firmware inestable y por lo menos 16 modelos de Mac nunca había recibido ninguna actualización de firmware EFI cuando el MacOS X 10.10 y 10.12.6 estaban disponibles.

Duo también encontró 47 modelos que ejecutaban versiones de macOS 10.12, 10.11, 10.10 que no recibieron la actualización de firmware de EFI con parches para resolver la vulnerabilidad conocida Thunderstrike 1.

Mientras que 31 modelos no recibieron el parche de firmware de EFI que se dirigía a la versión remota de la misma falla, Thunderstrike 2.

Los ataques Thunderstrike, inicialmente desarrollados por la Agencia de Seguridad Nacional (NSA), también fueron expuestos en los volcados de datos de WikiLeaks Vault 7, que también mencionó que el ataque se basa en el firmware obsoleto.

Si Ud. es el propietario de uno de los 16 modelos de Mac mostrados en el siguiente diagrama y está ejecutando MacOS, el estudio llevado acabo por Duo Labs indica que su sistema no habrá recibido ninguna actualización de firmware de EFI y por lo tanto es vulnerable tanto al Thunderstrike 1 y 2:

Mac Model Version Number
iMac iMac7,1; iMac8,1; iMac9,1; iMac10,1
MacBook MacBook5,1; MacBook5,2
MacbookAir MacBookAir2,1
MacBookPro MacBookPro3,1; MacBookPro4,1; MacBookPro5,1; MacBookPro5,2; MacBookPro5,3; MacBookPro5,4
MacPro MacPro3,1; MacPro4,1; MacPro5,1

Es triste que una compañía que cobra tan caro por sus productos a los que califica de premium y se reserva el derecho de ser ellos los únicos que pueden abrirlos para efectuar mentenimientos que usuarios de PC pueden hacer por si mismos, no tenga una política de seguridad más estricta, ya que sus propios usuarios están limitados en cuánto a lo que pueden hacer para protejer apropiadamente sus equipos.

Una raya más a la ya maltrecha reputación de Apple.

iPhone vulnerable a ataques WiFi

Malware para móvil
Estándar

Ahora tienes otra buena razón para actualizar tu iPhone al recientemente lanzado iOS 11, si es que aún tenías dudas de actualizarte, ya que existe una vulnerabilidad de seguridad en iOS 10 y anteriores, para el cual existe un exploit públicamente disponible.

Gal Beniamini, un investigador de seguridad con Google Project Zero, descubrió una vulnerabilidad de seguridad (CVE-2017-11120) en el iPhone de Apple y otros dispositivos que utilizan chips de Broadcom Wi-Fi y que resulta fácil de explotar.

Esta falla es similar a la que Beniamini descubrió en el Broadcom WiFi SoC (System-on-Chip) en abril y la vulnerabilidad BroadPwn revelada por Nitay Artenstein, un investigador de Exodus Intelligence, en julio. Todas estas vulnerabilidades permiten tomar de forma remota el control de los smartphones a través de redes Wi-Fi.

La vulnerabilidad recientemente descubierta, que Apple corrigió con su importante actualización de iOS publicada el 19 de septiembre, podría permitir a los hackers tomar el control del iPhone de la víctima de forma remota. Todo lo que necesitan es la dirección MAC del iPhone o la ID del puerto de red. Lo cuál es fácil de conseguir ya que la muchos de los routers que ofrecen accesso WiFi público pueden ser fácilmente vulnerados, es por ello que esta vulnerabilidad es considera una seria amenaza para los usuarios del iPhone.

Beniamini informó en privado de esta vulnerabilidad tanto al fabricante del chip WiFi que es Broadcom como también en el sistema de gestion de errores de Google Chromium el 23 de agosto. Ahora, luego de la liberación pública de iOS 11, Beniamini publicó un exploit de prueba de concepto (PoC) para dicha vulnerabilidad, para demostrar los riesgos que esta falla podría representar en los usuarios del iPhone.

Beniamini dice que el problema existe en los chips de Broadcom que ejecutan la versión de firmware BCM4355C0, que no sólo es utilizada por los iPhones sino que también es utilizada por un gran número de otros dispositivos, incluidos los teléfonos inteligentes Android, el Apple TV y muchos televisores inteligentes.

Una vez que su exploit se ejecuta, Beniamini fue capaz de insertar una puerta trasera en el firmware del chip de Broadcom, lo que le permitió leer y escribir a distancia comandos para el firmware, lo que a su vez permite un control remoto fácil sobre el chip Wi-Fi.

Los investigadores probaron su exploit sólo contra el firmware de Wi-Fi en iOS 10.2, pero creen que el exploit también debería funcionar en todas las versiones de iOS hasta 10.3.3.

Ya que no hay manera de averiguar si tu dispositivo está ejecutando la versión de firmware afectada (BCM4355C0), se recomienda a los usuarios actualizar iPhones a iOS 11. Apple también ha solucionado el problema en la versión más reciente de tvOS.

Además, Google ha parchado esta vulnerabilidad en los dispositivos Nexus y Pixel a principios de septiembre. Sin embargo, los usuarios de smartphone Android de otros fabricantes, deben esperar a que estos envien las actualizaciones a sus dispositivos.

Detectado primer malware de Android que usa Dirty COW para ganar privilegios de root

Malware para móvil
Estándar

Casi un año después de la divulgación de la vulnerabilidad DirtyCOW que afectó al kernel de Linux, los ciberdelincuentes han comenzado a explotar dicha vulnerabilidad contra los usuarios de Android, según han advertido investigadores de seguridad.

Dirty COW estuvo presente en una sección del kernel de Linux, una parte de prácticamente todas las distribuciones de Linux usaron, las distribuciones afectadas incluían a las populares RedHat, CentOS, Debian y Ubuntu y fue explotado activamente debido a su naturaleza.

La vulnerabilidad permite que un atacante local sin privilegios de root, obtenga acceso de superusuario a través de un problema con la condición de carrera, se desarrollaron varios scripts de prueba de concepto que permitía acceder a privilegios de root e incluso habían scripts que permitían el ataque remoto a través de Exim (un popular servidor de correo electrónico).

Sin embargo, no ha sido sino hasta ahora que un grupo de investigadores de seguridad de Trend Micro publicaron en el blog de la empresa que la vulnerabilidad de escalamiento de privilegios (CVE-2016-5195), conocida como Dirty COW, ha sido explotada activamente por una muestra de malware de ZNIU, detectada como AndroidOS_ZNIU.

De acuerdo a los investigadores de Trend Micro, esta es la primera vez que observan un ejemplo de malware que contiene dicha vulnerabilidad para comprometer dispositivos móviles.

El malware detectado utiliza la vulnerabilidad DirtyCOW para ganar acceso de root en los dispositivos Android a través del mecanismo de copia en escritura (COW) en el núcleo Linux que está presente en Android e instalar una puerta trasera que puede ser utilizado por los atacantes para recopilar datos o generar beneficio a los hackers través del clásico mecanismo de forzar llamadas a un número de teléfono premium que cobra por minuto las llamadas entrantes.

Los investigadores de Trend Micro detectaron el malware de ZNIU en más de 1,200 aplicaciones Android, algunas de las cuales se disfrazaban de pornografía y aplicaciones de juegos gratuitas, junto con sitios web de host que contenían rootkits maliciosos que explotan la vulnerabilidad DirtyCOW.

Mientras que la vulnerabilidad DirtyCOW afecta todas las versiones del sistema operativo de Android, la explotación de la misma por parte de ZNIU afecta solamente a los dispositivos Android con la arquitectura ARM/X86 de 64 bits. Sin embargo, el exploit reciente puede utilizarse para eludir SELinux y plantar puertas traseras.

Aquí está cómo explota la DirtyCOW ZNIU en un dispositivo Android:

ZNIU cadena de infección

ZNIU cadena de infección

Una vez descargada e instalada la aplicación de malware, ZNIU se comunica con su servidor de Comando y Control (C&C) para comprobar si hay actualizaciones de código, mientras que la vulnerabilidad DirtyCOW proporciona escalamiento de privilegios locales para obtener acceso de root en el dispositivo y plantar una puerta trasera para posibles ataques de control remoto en el futuro.

El malware también recolecta la información del carrier (proveedor del servicio móvil) del usuario e intenta enviar pagos a través de mensajes SMS premium que fueron dirigidos a una compañía de fachada en China.

Una vez que la transacción SMS ha terminado, el malware también elimina los mensajes del dispositivo con el fin de borrar la evidencia de que el equipo ha sido comprometido.

Los investigadores descubrieron que el malware ya ha infectado a más de 5,000 usuarios de Android en 40 países en las últimas semanas, con la mayoría de las víctimas localizadas en China e India, mientras que también se han detectado aunque de manera minoritaria víctimas en pasies como: Estados Unidos, Japón, Canadá, Alemania e Indonesia.

Google ha lanzado una actualización para Android que entre otras fallas corrige oficialmente la vulnerabilidad DirtyCOW. El gigante de la tecnología también confirmó que Play Protect ahora protege a los usuarios de Android contra este malware.

La forma más sencilla de evitar que nuestro equipo se vea infectado por este malware u otros similares que aparezcan en el futuro es evitar descargar aplicaciones de fuentes de terceros y descargar siempre nuestras aplicaciones desde la tienda oficial de Google Play.