Touch ID y Touch Bar bajo lupa en el nuevo MacBook Pro

Parece que Apple se ha preocupado por la seguridad de la nueva interfaz, Touch Bar, del MacBook Pro. El desarrollador Steve Troughton-Smith, conocido por sus profundos exámenes de cómo funciona el sistema operativo iOS, reúne algunas de las piezas respecto a la nueva barra táctil del nuevo ordenador de Apple. La reflexión del desarrollador es que existen menos caminos para explotar, es decir, Apple tiene un procesador independiente para gestionar el Touch ID. Los sistemas iOS, watchOS y tvOSson más limitados que macOS, el cual sigue siendo más abierto a ser inspeccionado y manipulado. 

Mientras que iOS ha sufrido exploits, según informa el desarrollador, debería haber menos caminos y posibilidad de exploits que afecten a la Touch Bar, ya que éste actúa como un periférico en lugar de ejecutar aplicaciones directamente. El desarrollador también comenta que cuando Apple anunció su Touch Bar, pensó que debido a la seguridad necesaria con un chip Secure Enclave y la conexión al procesador, ésta no podría ser auto-equipada, pero se equivocó. Gracias al uso de el procesador T1, el Secure Enclave y el sensor Touch ID se encuentran perfectamente integrados. Debido a que la barra táctil se ejecuta por separado, macOS no tiene que estar en estado activo para que un usuario interactúe con Touch ID.

Figura 1: Touch Bar

¿Podría el Touch ID omitir la introducción de una contraseña en un arranque en frío? La respuesta es no. Al igual que ocurre con iOS, Apple tiene una variedad de condiciones bajo las cuales el Touch ID no puede utilizarse, y se debe introducir la contraseña para volver a habilitarlo. Uno de ellos es un reinicio o encendido. La autenticación biométrica a través de una huella dactilar en un Mac plantea los mismos problemas de seguridad que tiene para iOS. La huella digital de una persona puede utilizarse para desbloquear un Mac de igual forma que un iPhone. Apple dice que se podrá desbloquear el Mac con Touch ID, aunque aún no se habilitó la funcionalidad de forma completa. A diferencia de un dispositivo iOS, un Mac tiene sólo una delgada capa de protección a menos que esté apagado, a diferencia de iOSque está asegurado cuando duerme. Sin duda, tendremos noticias y los investigadores intentarán llevar al extremo al Touch ID y a la Touch Bar en los nuevos equipos de Apple.

Información sobre seguridad en los navegaodres Safari y Chrome en 2017

La evolución en el uso de los certificados en Internet y en cómo los navegadores interpretan estos y hacen llegar a los usuarios la información es de vital importancia para la seguridad de este. Cuando un navegador bloquea una conexión que debería ser segura, porque no lo es, es algo realmente bueno. El navegador está evitando que la información del usuario pudiera ser capturada por una tercera parte.

El cifrado web requiere que fabricantes de navegadores y sistemas operativos confíen en las CA, las cuales utilizar criptografía para que cuando un servidor web presente un certificado que le identifique, el navegador pueda verificar realmente esta información. Todo esto es parte de la red de confianza, y requiere que los navegadores, fabricantes de sistemas y CAactúen con integridad y transparencia. Algunas CA tienen problemas con la seguridad, por lo que Apple, Google y Mozilla deben eliminarlas como CA en la que confiar. Hay algunos casos de ejemplo en la historia como Comodo. En Abril de 2015, Apple no actuó rápidamente contra CCNIC, una CA China que parecía estar saltándose las políticas de seguridad. En este caso, Mozilla y Google actuaron rápidamente y quitaron la CA. Apple y Microsoft no hicieron nada. 

Figura 1: WoSign y el informe de Mozilla

Otro caso es el de septiembre de 2015. Mozilladescubrió que la CA WoSign tenía, lo que llamaron, un número de problemas técnicos y de gestión. WoSign tenía un problema que era la emisión de certificados firmados con SHA-1, el cual es un algoritmo de cifrado anticuado que las CA han acordado dejar de emitir. Esto es debido a que SHA-1 se considera roto. Existen más detalles en el infirme que Mozilla presentó sobre este caso. Tras este reporte, y los intentos pobres de WoSign por convencer a Mozilla, fueron eliminados de la lista de confianza el 21 de Octubre.

Apple siguió el ejemplo de manera pública, colocando, incluso, algunos párrafos de texto en la parte superiro de su sitio web dónde se enumeraban los certificados raíz de confianza a principios de octubre. Google y Microsoftsiguieron sus pasos. En Safari, Firefox y Chrome cuando se visita un sitio con un certificado firmado por WoSign o StartCom se genera una advertencia de seguridad. ¿Hacia dónde va esto? Cada año, los fabricantes de navegadores aumentan el tipo y naturaleza de las advertencias que muestran cuando se visita un sitio que está utilizando una seguridad ineficaz o mal configurada. 

Figura 2: Mensaje en Chrome

A partir de enero de 2017, Chrome comenzará a mostrar frases que indiquen al usuario que utilizar tráfico HTTP no es seguro y que no introduzca tarjetas de crédito o credenciales cuando se navegue por HTTP. Google planea pasar gradualmente a mostrar un triángulo de advertencia rojo y no seguro en todas las páginas sin cifrar. De forma transparente, Chrome redireccionará las solicitudes a una versión segura del sitio web si existiese.En Safari también habrá cambios. Los mensajes serán más impactantes y más claros, al estilo Chrome. El año 2017 puede ser el de la concienciación en el uso de certificados correctamente para los usuarios.

Apple Safari fue hackeado en 20 segundos

En el Pwnfest celebrado en Seúl se juntaron algunos de los mejores hackers del mundo. Estos equipos que se concentraron en la ciudad de Korea del Sur tienen como objetivo hackear los principales navegadores y software de las principales compañías tecnológicas. Por ejemplo, Google Pixel fue hackeado en menos de 60 segundos por un equipo denominado Qihoo 360.

Demostraron la posibilidad de, mediante un exploit, conseguir ejecutar código remoto sobre Pixel. Como resultado, obtuvieron 120.000 dólares por el descubrimiento. Del mismo modo, el equipo de Pangu, junto al equipo de JH de China, logró hackear el navegador de Apple Safari en un macOS Sierra. El tiempo que les llevó a estos equipos fue de 20 segundos. Resultaron los primeros en obtener acceso roota la aplicación. Pangu también fue capaz de realizar Jailbreak sobre la última versión de iOS. Al parecer, los resultados del Pwnfest han sido muy buenos para los investigadores, y mejorables para los proveedores.

Figura 1: Ganadores del reto Apple Safari
El esfuerzo llevado a cabo por los distintos equipos, les ha permitido ganar más de 100.000 dólares. En cuando a Apple, Microsofty Google se han embarcado en arreglar o solucionar estas vulnerabilidades tan pronto como sea posible, ya que potencialmente son vulnerabilidades que otros usuarios podrían aprovechar. Los detalles sobre los hackeos no se han hecho públicos, pero los propietarios de las plataformas y los vendedores han sido informado sobre ellos, ya que son vulnerabilidades potencialmente explotables si se descubren o se exponen públicamente.

Shazam no cierra el micrófono en tu macOS y lo oye todo

Han pasado 7 años desde que la aplicación Shazam llegó al mercado y sigue siendo una idea brillante. Solo con presionar un botón se puede saber el nombre de la canción que se está escuchando dónde estemos. El investigador Patrick Wardle, indicó que cuando Shazam no está en ejecución, éste sigue escuchando lo que decimos o se dice a nuestro alrededor. Esto es, claramente, algo que puede afectar a la privacidad de los usuarios. El investigador matizó que esto ocurre en los equipos Mac. 

Antes de levantar la voz al cielo, Wardle matizó sus indagaciones y afirmó que parece ser que Shazam no está haciendo nada malicioso con los datos que puede capturar, es decir, no se guardan, no se procesan o no se envían a sus servidores. Simplemente, sigue a la escucha en vez de cerrar el micrófono. Esto hace parecer que es un error de programación o de diseño de la aplicación, pero tampoco lo es. Shazamcomentó que es intencionado, para que los usuarios no tengan que esperar varios segundos para que la música que se quiere adivinar sea procesada. 

Figura 1: Shazam en Mac

La excusa de Shazam es, cuanto menos, curiosa. El jefe de producto de Shazam, Fabio Santini, explicó que era, solamente, una opción que la compañía hizo en la versión para Mac, y sólo para dicha versión. Además, Santini comentó que, incluso si alguien se hiciera con dichos datos, no podría escuchar las conversaciones personales, ya que Shazam sólo muestra algunos puntos a lo largo de la onda de audio con el objetivo de crear una huella digital o fingerprint que coincida con otras huellas en la base de datos de música de la compañía. Los puntos, no pueden ser invertidos para reconstruir el audio original. Lo que está claro, es que abre una puerta o una motivación para los investigadores, ser capaces de invertir el proceso y poder reconstruir el audio. Seguiremos atentos a esta noticia.

La Touch Bar del nuevo MacBook Pro permite saltar los anuncios de YouTube que hasta ahora no podías saltar

La semana pasada tuvimos oportunidad de conocer el nuevo MacBook Pro con Touch Bar en las oficinas de Apple en Madrid, y en breve esperamos recibir una unidad para analizar.

Mientras tanto, seguimos escuchando nuevas utilidades para la Touch Bar. La última es que podemos utilizar la barra Touch Bar para saltarnos los anuncios de YouTube.

El usuario de Reddit, RomansFiveEight, ha escrito:

En Safari, la Touch Bar muestra un control cada vez que comienza a reproducir un vídeo. Sorprendentemente, puedes utilizarla para pasar un anuncio, incluso uno de los anuncios de 30 segundos que no pueden saltarse al inicio de un vídeo, y comenzar al vídeo.

*********

No conocíamos esta utilidad de la Touch Bar, pero seguro que es muy bien recibida por los usuarios de YouTube. Lo que no sabemos es si durará mucho tiempo o si YouTube eliminará esta funcionalidad – a fin de cuentas, si YouTube no permite saltarse estos anuncios en la web, será por algo.

Winpayloads: Automatizando la generación y el uso de payloads

Winpayloads es una herramienta que nos indica en su descripción que es capaz de generar payloads indetectables para el sistema operativo Windows. La herramienta se encuentra escrita en Python y proporciona una pequeña navaja suiza de automatizaciones útiles en la ejecución del payload y la post-explotación. 

La herramienta tiene diversas posibilidades para la generación de payloads. Como se puede ver en la imagen tenemos la posibilidad de generar varios tipos de Meterpreter y una shell de tipo inversa. Lo curioso, y potente, es que durante el proceso de creación de los payload se puede añadir funciones secundarias en forma de post-explotación. Como se ve en la imagen, una Meterpreter puede ejecutar a posteriori, y de forma automática, un script que permita intentar el bypass del UAC, ejecutar persistencia en el equipo y ejecutar una serie de checks sobre la máquina y devuelvan los resultados.

Para obtener Winpayloads podemos descargarlo desde su Github. Una vez descargado, debemos ejecutar el fichero setup.sh, el cual llevará a cabo la instalación de las dependencias de la herramienta, por si hubiera alguna que no estuviera instalada. 

PoC: Meterpreter con automatización de acciones I

En este ejemplo generamos un binario siguiendo los sencillos pasos de WinPayloads. Al llegar a la opción bypassuac indicamos que sí. Esto genera un script de Powershell y un script de instrucciones de Metasploit. Este último fichero tiene la extensión “rc” y permite configurar de forma automática el binario msfconsole del framework de Metasploit.

Si observamos el fichero bypassuac.ps1 generado, podemos ver como hay un Invoke-Expression de lo obtenido mediante un objeto Net.WebClient que descarga el script de Invoke-BypassUAC desde el repositorio de PowershellEmpire. Es una forma interesante de ejecutar en memoria directamente el script en Powershell y evitar mecanismos de protección en una auditoría. 

En el caso del fichero uacbypass.rc se puede ver el contenido que WinPayloads ejecutará a través de msfconsole -r [nombre fichero RC]. Cargaremos el módulo de post-explotación windows/manage/priv_migrate SESSION=1 y ejecutaremos el módulo de post-explotación denominado windows/manage/exec_powershell SCRIPT=bypassuac.ps1 SESSION=1, siendo el atributo session el adecuado, por lo que quizá hubiera que cambiarlo. 

Como se puede ver a continuación obtenemos una primera sesión con el EXE generado con WinPayloads. Una vez se consigue la sesión, automáticamente, vemos como se ejecuta el script de Powershell y ejecuta el proceso del bypass UAC. Esto consigue devolvernos una nueva sesión, la cual está identificada como segunda sesión, en este caso, ya con privilegios.

En el caso de no utilizar el bypass UAC, se permite utilizar otros scripts como el de persistencia y el de allChecks. 

PoC: Powershell Actions!

WinPayloads dispone de un menú para Powershell y posibles acciones. En la imagen se puede ver cómo se pueden obtener una serie de Payloads inversos: ScreenWatch, Asks Creds o Invoke Mimikatz. Solo por el nombre, podemos ver que son muy ilustrativos. 

En el caso de seleccionar la opción ScreenWatch, se solicita al usuario el puerto en el que nos quedaremos a la escucha, por defecto el 4444. Una vez generado el código codificado en base64, se puede copiar y pegar sobre una máquina con acceso físico, o a través de la explotación de alguna vulnerabilidad a través de, por ejemplo, Metasploit. 

Otras opciones generan scripts preparados para ser lanzados, como Asks Creds que permite realizar un phishing sobre la máquina víctima, en el que se solicita a un usuario que introduzca sus credenciales del sistema. Otra opción es ejecutar un Mimikatz y que los resultados se nos envíen al puerto abierto. WinPayloads es una herramienta interesante que debemos llevar en nuestra mochila de pentesting. Las posibilidades son mucho más amplias, por lo que recomendamos que juegues con la herramienta y veas el potencial de ésta.