OSX.Dummy: El peligro viene por Slack y Discord en macOS

El malware denominado OSX.Dummy utiliza un método de infección poco sofisticado, pero los usuarios que son atacados con éxito abren sus sistemas hasta la ejecución de código remota. Este malware tiene como objetivo ususarios que utilizan criptomonedas y que, además, utilizan plataformas como Slack y Discord. El investigador y experto en ciberseguridad Patrick Wardle comentó que el malware tiene privilegios de root, por lo que cuando éste conecta con el C2, se tiene un entorno privilegiado.

También comentó Wardle que se han visto varios ataques de malware en macOS que se originan en grupos de chats de Slack o Discord. Los atacantes seducen a los usuarios para que ejecuten un script que a su vez descarga el malware de 34 MB OSX.Dummy a través de cURL. La descarga se guarda en el directorio de macOS /tmp/script y luego se ejecuta. El archivo es un gran binario de 34 MB, el cual tiene 0 de 60 en VirusTotal. El script solía engañar a las víctimas para descargar el OSX.Dummy. El binario no está firmado, indica Wardle, agregando que el malware puede eludir Gatekeeper. Es curioso que este binario sería bloqueado por Gatekeeper, pero al ser un binario descargado y ejecutado desde la terminal de comandos, Gatekeeper no entra en juego, por lo que se permite ejecutar el software sin firmar. 

Figura 1: Snippet para ejecutar el script

A medida que se ejecuta el código binario, se hace uso de sudo, por lo que se necesita que el usuario introduzca sus credenciales en el terminal. A partir de ahí, el malware arroja código en varios directorios macOS, incluido /Library/LaunchDaemons/com.startup.plist, lo cual le proporciona a OSX.Dummy la persistencia. El script bash intenta conectarse a una dirección IP, la cual es 185.243.115.230 al puerto 1337. Wardle señala que si el ataque tiene éxito y el malware puede conectarse al C2, el atacante puede tomar el control del sistema objetivo.

Como activar una cuenta Root en Mac

Disponer de una cuenta Root en Mac puede ser muy beneficioso para todos aquellos power ussers a los que les gusta tener un mayor control sobre su dispositivo y acceder a archivos a los que no se puede acceder desde una cuenta de administrador. A pesar de que habilitar una cuenta root sea un proceso muy sencillo, es recomendable que solo la habiliten aquellos usuarios que la necesiten o puedan hacer un buen uso de ella, ya que te proporcionará acceso a varios archivos del sistema. A pesar de disponer de una cuenta Root no podrás acceder a aquellos que se encuentren protegidos por System Integrity Protection por cuestiones de seguridad y protección del equipo.

En este artículo os explicaremos como habilitar la cuenta Root en tu Mac siguiendo 7 sencillos Pasos:

1. Entra en las preferencias del sistema y haz clic en “Usuarios y grupos”.                                             
2. Desde la configuración de “Usuarios y grupos” clica en el icono del candado e introduce tu contraseña.                                                                                                                                         
3. Pulsa sobre “Opciones de inicio de sesión” y posteriormente sobre el botón “Acceder…”.                   



Figura 1: Opciones de inicio de sesión.





4. Haz clic en el botón "Abrir Utilidad de Directorios...".                                                                                          
5. Vuelve a pulsar el icono del candado e introduce tu contraseña.                                                                                                                                                                                  
6. Pulsa “Editar” en la barra superior del menú y selecciona la opción “Habilitar usuario Root”.            
7. Introduce la contraseña para tu cuenta Root.

Figura 2: Pagina de inicio Mac.

Una vez que se haya habilitado la cuenta Root podrás iniciar sesión en ella a través de la pantalla de inicio seleccionando la opción “Otro…” a continuación te aparecerán en pantalla dos campos, en el de usuario deberás introducir “Root” y en el de contraseña la contraseña que configuraste en el séptimo paso. Para terminar pulsa “Enter”.

Por qué está teniendo Apple tantos problemas de seguridad últimamente

Apple es hasta ahora, uno de las plataformas más seguras que existen. Pero debido a los problemas que está teniendo, no sólo con Sierra, sino también con iOS, esta imagen de plataforma segura se está dañando. En menos de un mes Apple ha tenido que reparar dos bugs críticos, el problema del root sin contraseña en macOS y en iOS el de una aplicación de terceros capaz de recuperar las contraseñas almacenadas en el keychain. ¿Qué está pasando?

En el caso del acceso root sin contraseña establecida, era un fallo tan grave que Apple sacó el parche en el mismo día de enterarse de su existencia. Esto es algo realmente impresionante para una empresa de este tamaño. Apple se disculpó ante los usuarios y dijeron que mejorarían la auditoría a los equipos de desarrollo para que este suceso tan grave no se volviera a repetir. 

Pero estos problemas de seguridad parece que no vienen solamente de este último mes. Durante 2017 han aparecido varios problemas en todas los productos Apple siendo el mes de mayo el que más problemas tuvo (66 vulnerabilidades en total). Luego en septiembre apareció otro problema, esta vez no de seguridad pero muy visible para el usuario. De repente al intentar escribir la letra "i" era la letra "A" la que aparecía. Este último ejemplo, aunque no sea de seguridad deja en evidencia la raiz del problema: según Wired, Apple tiene que mejorar las pruebas (test) de sus productos antes de sacarlos al mercado.

Figura 1. Algunas de las vulnerabilidades encontradas en Apple en mayo de 2017. Fuente.

Y es que Apple tiene que sacar productos nuevos cada 12 meses como máximo (ciclo en el que se presenta algún producto nuevo)  sin contar los productos que ya están en el mercado y que tiene también que actualizar. Los últimos problemas que hemos comentado tanto para macOS y iOS son un claro ejemplo que demuestra que a los equipos de QA parece que no tienen tiempo suficiente para testear o probar debidamente los productos antes de lanzarlos al mercado, poniéndolos en circulación demasiado pronto. Lejos quedan atrás aquellos días como cuando se lanzó el Apple OS X 10.6 Snow Leopard en 2009, uno de los lanzamientos más robustos de la compañía en el cual pusieron todo el esfuerzo posible para que saliera al mercado con el menor número de bugs posible. 

De hecho, en el mundo Apple es bastante habitual encontrar usuarios que mantienen una versión anterior del sistema operativo por su estabilidad, evitando actualizar a la última versión hasta que no ha pasado un tiempo razonable. De todas formas, como dijimos al principio, Apple es una de las empresas con los productos más seguros al mercado y seguro que pondrán más medios para las pruebas y más atención en el futuro a los nuevos productos que saquen al mercado en los próximos meses.

Debate sobre la seguridad en iOS en twitter

Tras haber parcheado una vulnerabilidad en macOS High Sierra que permitía a cualquiera obtener permisos root, Apple tiene más trabajo por delante para hacer sus softwares más seguros. En este caso os hablaremos de iOS 11. Recientemente Oleg Afonin, un investigador forense de Elcomsoft ha publicado un artículo en su blog en el que cuenta porque algunas de las actualizaciones introducidas en iOS 11 suponen la eliminación de algunas capas de seguridad del sistema operativo. Según el investigador, las contraseñas no garantizan únicamente acceso a los dispositivos, sino que también a muchos de los servicios vinculados a la nube y otros hardwares asociados.

En iOS 10 y versiones anteriores, los usuarios podían establecer una única contraseña para proteger un backup encriptado de la información almacenada en el iPhone. Esta contraseña viajaba con el hardware y si intentabas conectar el iPhone a otro dispositivo para hacer otro backup vía iTunes deberías introducir la misma contraseña. En iOS 11 todo ha cambiado, si dispones de iOS 11 o una versión superior podrás hacer un backup encriptado de tu dispositivo reseteando la contraseña. Esto es un problema de seguridad porque los backups realizados a través de iTunes contienen mucha más información de la que se podría obtener simplemente desbloqueando el teléfono. Y esa información podría ser analizada con herramientas que muchas empresas como Elcomsoft venden.

“Una vez que un intruso gana acceso al iPhone de un usuario y sabe su contraseña, no existe ninguna otra capa de protección. Todo está completamente expuesto, desde backups de la nube hasta fotografías o historiales de navegación, incluso la contraseña original del Apple ID del usuario”.

Figura 1: Mensaje en twitter

Por lo tanto el riesgo va más allá de un teléfono comprometido y de los dispositivos asociados a él ya que la Keychain de iCloud puede incluir información relativa a contraseñas de Google o Microsoft. Según Alfonin el mejor método por el que podría optar Apple para arreglar este problema sería hacer que las cosas volviesen a ser como antes.

“No creo que a nadie le moleste, La habilidad de resetear la contraseña un Backup de iTunes no es necesaria. Si revirtiesen esto a como era con iOS 10 sería perfecto”. 

Por supuesto, esto es solo la opinión de Alfonin y Elcomsoft. Otros investigadores no comparten la misma opinión, como es el caso de Dino Dai Zovi, cofundador de Cloud security biz Capsulate8, el cual ha dado su opinión sobre el asunto en Twitter.

Analizando la grave vulnerabilidad "I Am Root" en macOS High Sierra

El 28 de noviembre se hizo pública una de las mayores vulnerabilidades nunca vista en un sistema operativo de Apple. Básicamente, cualquier usuario podía utilizar la cuenta "root" sin contraseña para acceder con estos derechos de administrador al sistema, es decir, con acceso total al equipo. Una vez solucionado el problema (este error fue resuelto en la actualización de seguridad 2017-001)  es interesante echar la mirada atrás para intentar comprender los orígenes de esta grave vulnerabilidad.

Este bug se llamó "#IAmRoot" o "#rootgate" y funcionaba en las versiones de macOS High Sierra 10.13 o 10.13.1 sin parchear, haciendo posible que cualquier atacante pudiera abrir una ventana de autenticación y utilizar la cuenta "root" sin contraseña. Realmente no se estaba accediendo sin contraseña, lo que ocurría es que se estaba habilitando la cuenta "root" y al no poner contraseña, estábamos asignado una contraseña en blanco como clave de dicha cuenta. Si la cuenta "root" ya estaba activada previamente, este problema de seguridad no aparecía.

Figura 1. Demostración de acceso root sin contraseña. Fuente.

Este acceso requería estar físicamente delante del ordenador para poder acceder aunque más tarde se demostró una forma de acceder remotamente, siempre y cuando se cumplieran alguna condiciones de configuración en el equipo víctima. Por ejemplo, si el Mac tenía activada la opción de compartir pantalla (Screen Sharing), entonces era posible el acceso por cualquier persona dentro la misma red local. Una vez conseguido este acceso era posible también activar el acceso remoto o la compartición de ficheros.

La primera noticia que tenemos de esta vulnerabilidad apareció en un hilo dentro del foro de desarrolladores de Apple, el 13 de noviembre de 2017. No se habla directamente del problema "root" en sí, sino que aparece después de que un usuario preguntara algunas dudas sobre errores de instalación en la nueva versión de macOS Sierra (aquí podéis ver todo el hilo). Abajo podéis ver una captura de la respuesta dada por un usuario llamado "chethan177", que dice literalmente y parece ser que sin ser consciente del problema "introduce el nombre de usuario: root y deja la contraseña vacía. Pulsa enter (inténtalo dos veces)".

Figura 2. Respuesta en foro de desarrolladores de Apple que delata el problema de #IAmRoot. Fuente.

A partir de aquí empieza una cadena de respuestas centrándose en esa última frase la cual desata y pone en evidencia el problema del "#IAmRoot". Más tarde, una semana después, aparece un video en Twitter donde se demuestra la vulnerabilidad, pero Apple no respondió ni tomo ninguna medida. El problema comenzaría de verdad cuando un desarrollador desde Turquía publicó un tweet donde explicaba con todo detalle cómo explotar la vulnerabilidad. Esta actitud se criticó bastante ya que no es precisamente la mejor práctica publicarlo en Twitter sin antes haberlo discutido internamente con Apple, ya que estaba publicando un ataque "zero day" en toda regla al resto del mundo sin dar tiempo de reacción a solucionarlo.

Otro punto interesante a analizar es cómo ha podido ocurrir este grave problema desde el punto de vista de código. Al parecer, esta vulnerabilidad catalogada como CVE-2017-13872, es un error lógico de programación (un error a la hora de comprobar el resultado de una comparación) del equipo de desarrollo de Apple. En este enlace podéis encontrar un magnífico análisis exhaustivo centrado en el demonio "opendirectory". El problema se basa en el estado "deshabilitado" de la cuenta "root", ya que un error de código el cual verifica las contraseñas de las cuentas, no realizaba correctamente esta comprobación en las cuentas deshabilitadas, dando por lo tanto la opción de dejarla en blanco o introducir una nueva contraseña. La solución a este problema era realmente simple, sólo había que comparar la contraseña con la variable correcta. En esta captura se puede apreciar perfectamente la corrección (arriba la parte sin parchear y abajo parcheada), en la cual se añaden y modifican sólo un par de líneas de código:

Figura 3. Parte desensamblada del código que muestra el problema y la solución a #IAmRoot. Fuente.

Esta vulnerabilidad en el código se parece bastante a otra llamada "goto fail", que apareció en 2013 en las versiones tempranas de OS X Mavericks. Este error fue incluso más simple que el fallo "root", y se debió a la inclusión de una línea de código duplicada la cual permitía realizar un ataque tipo "man in the middle" para interceptar tráfico https. De nuevo, un fallo de programación que no fue detectado por los exhaustivos controles de calidad de Apple y que sólo se detecto una vez el sistema operativo (o la actualización correspondiente) se hizo público.

Un gran error de Apple permite conseguir root con una clave vacía

Es la noticia de la semana, posiblemente del mes y puede que del año. Un grave error de Apple permite a cualquier usuario lograr el acceso al sistema o desbloquear opciones sensibles del sistema sin conocer la contraseña de root, simplemente indicando una clave vacía y fallando un par de veces. Todo comenzó con un tuit de un desarrollador, Lemi Orhan, que alertaba de la situación anómala que había descubierto. El revuelo en twitter ha sido enorme, dónde muchos usuarios indicaban qué versión tenían y si les funcionaba o no funcionaba el trick.

Vía twitter, hubo usuarios que indicaron que si el root disponía de contraseña el fallo no funcionaba, por lo que una posible y rápida solución era ponerle una contraseña al usuario root, por ejemplo con la ejecución del comando passwd root. El fallo afecta a los sistemas de Apple, incluida la versión 10.13.1.

Figura 1: Root en blanco para entrar o desbloquear opciones del sistema

Tras probar el trick nos ha parecido increíble, pero de fácil solución. Es cierto que afecta a un gran número de máquinas, pero nada que no se pueda solventar con la solución indicada anteriormente o con una actualización por parte de Apple que haga que el sistema detecte cuando una cuenta como la de root está deshabilitada por tener una contraseña vacía o no asignada. Dicho esto, estaremos atentos, pero, sin lugar a la duda, es una de las noticias del mes en el mundo Apple.

Dropbox acusado de controlar tu cuenta de admin en OSX

El titular es preocupante, al parecer un grupo de usuarios han comentado que si se tiene instalado Dropbox y se le ha proporcionado las credenciales de la cuenta del administrador se puede tener graves problemas. Lo más "curioso" es que si eliminamos Dropbox de Ajustes - Seguridad y Privacidad - Privacidad - Accesibilidad, que es dónde se encuentran las aplicaciones que pueden tomar control del equipo, podremos quitarla sin problemas, pero al reiniciar Dropbox, ésta volverá a aparecer con permiso para controlar todo el equipo.

Dropbox ha negado las acusaciones de que su cliente Mac robe las contraseñas. El desarrollador Phil Stokes ha acusado a la compañía de robar las contraseñas del administrador en las máquinas en un intento de reducir el número de permisos que la aplicación solicitaba. Stokes dice que en el análisis del cliente Dropbox indica que en /Library/Application Support/com.apple.TCC/TCC.db se puede encontrar la información jugosa. 

Figura 1: Análisis del fichero TCC.db

El desarrollador reitera que Dropbox está utilizando una técnica basada en SQL a través de la base de datos TCC para eludir la política de autorización de Apple, lo cual puede ser también, realmente interesante para futuros malware, si no lo hacen ya. El desarrollador de escritorio de Dropbox, Ben  Newhouse, indicó que la empresa necesita comunicar mejor su uso de permisos y añadiendo que nunca se almacenan las contraseñas de administrador. Esto no ha relajado el nivel de crispación de algunos usuarios. El desarrollador de Dropbox indica que piden permisos una vez, pero que no explican lo que hacen o por qué y que deben arreglar esta falta de comunicación. El debate está servido.

Bug de Heap Overflow en antivirus de Symantec en OSX

La noticia saltó hace unos días y es que se descubrió una vulnerabilidad en el producto de antivirus de Symantec. La vulnerabilidad tiene CVE-2016-2208 y provoca que un atacante pueda ejecutar código en un contexto privilegiado. La vulnerabilidad afecta tanto a las versiones para Windows, como para Linux y OS X. La vulnerabilidad ha sido descubierta por Project Zero el grupo de investigadores de Google. La vulnerabilidad es de ejecución remota, por lo que es bastante crítica. Enviando un email a la víctima o un enlace malicioso se podría lograr explotar.

Además, este mismo grupo, ha encontrado otras vulnerabilidades en otros productos de seguridad. Para los sistemas Linux y OS X, la vulnerabilidad es explotrada en remoto como un heap overflow y en el contexto de root, logrando control total sobre la máquina a través del proceso de Norton. Symantec ha trabajado para liberar un parche.

Figura 1: Norton Antivirus en OS X

Investigar los productos de seguridad que deben ayudar a proteger los activos personales y de las organizaciones es una buena medida. Como se ha demostrado, en algunas ocasiones, las vulnerabilidades pueden encontrarse en cualquier lugar, incluso en el software que debe ayudarnos a estar un poco más seguros.

Escalada de privilegios en OS X: Apple Intel HD 3000 Graphics driver

Hoy traemos uno de esos artículos tipicos que salen de vez en cuando: una escalada de privilegios en OS X. La vulnerabilidad CVE-2016-1743 ha sido publicada por los investigadores Piotr Bania y Cisco Talos. Apple ha proporcionado un sitio web dónde consultar los detalles de la vulnerabilidad y en qué versión del Security Update se ha solucionado. La vulnerabilidad afecta a la versión del sistema operativo OS X 10.11.3 y anteriores, los cuales cuenten con el driver de Intel HD 3000 Graphics. 

La prueba de concepto se encuentra disponible en Internet y el exploit lo podemos encontrar en sitios como exploit-db o  oday.today. La vulnerabilidad permitía a un potencial atacante ejecutar código arbitrario en un contexto privilegiado, como es el contexto dónde ejecuta el driver de Intel. Además, y como es lógico, también puede causarse la denegación de servicio del driver produciendo un memory corruption.

Figura 1: Exploit para driver en OS X 10.11.3

El exploit ha sido liberado el pasado 8 de Abril, una vez que Apple e Intel han solucionado los problemas que tenía respecto al driver. Recomendamos que actualicéis vuestros equipos Mac a la última versión de El Capitan, la cual es la versión 10.11.4. De esta forma solventaréis el riesgo que supone este driver. Es cierto que para que se puede lograr explotar la vulnerabilidad se tiene que estar físicamente delante de la máquina o una sesión no privilegiada en remoto, por la que se pueda lanzar el exploit como si se estuviera en local. Este tipo de ejemplos los hemos visto en otras ocasiones, por ejemplo el caso del bypass del sudo o el caso de DYLD_PRINT.