Un fallo de seguridad en la aplicación Zoom (videoconferencias) permite activar la cámara web de forma remota sin consentimiento

Los problemas de seguridad en entornos Apple no aparecen únicamente en el software desarrollado por la compañía de la manzana. Ya hemos visto muchos casos de apps o programas los cuales tienen alguna vulnerabilidad y esta puede ser explotada para conseguir activar funcionalidades (como la cámara web en este caso que vamos a ver) o incluso para ejecutar algún tipo de malware. La conocida aplicación Zoom para videoconferencias tiene una de estas vulnerabilidades que ha puesto en alerta a toda la comunidad Apple.

El investigador Jonathan Leitschuh ha descubierto una forma de forzar prácticamente a cualquier Mac a unirse a una videollamada con la app de Zoom enviando un simple enlace como este: https://zoom.us/j/492468757. Es decir, puede hacer que un usuario que tenga la aplicación instalada se una a la videollamada (sin ningún proceso de validación o aceptación) lo que implica la activación de la cámara web sin su consentimiento (CVE-2019–13450). Hay que destacar que esta vulnerabilidad está en conocimiento de la empresa Zoom desde el mes de marzo sin que haya sido solucionada por completo. De hecho (y esto es una funcionalidad) la aplicación permite habilitar una opción que activa la cámara web por defecto de los integrantes de la videoconferencia (Figura 1), aunque esta vulnerabilidad permite activarla incluso con esta opción desactivada.

Figura 1. Activación automática de la cámara cuando se crea una videollamada con Zoom. Fuente.

La app crea un servidor web en cada dispositivo utilizando para ello el puerto 19421 y de esta forma, facilitar todo el proceso de videollamada. En este servidor web es el lugar en el cual recae la vulnerabilidad que puede ser explotada para controlar la webcam, simplemente insertando el código malicioso en dicho servidor web "oculto" que se instala en cada máquina cada vez que se une a una videollamada. La solución para evitar que alguien pueda explotar esta vulnerabilidad en nuestro equipo es sencilla, ya que sólo hay que desactivar la opción "Turn off my video when joining a meeting" (Figura 2).

Figura 2. Activación de la opción para evitar que se active el vídeo por defecto al unirse a una videollamada. Fuente.

Pero además, el investigador ha descubierto que dicho servidor web persiste en el Mac incluso si la aplicación se ha desinstalado por completo, lo que implica que la única forma de eliminarlo sea manualmente. Por otro lado, también ha encontrado una forma de ataque DoS con CVE-2019–13449 el cual sí que fue solucionado por Zoom en mayo. En cambio, este otro, relacionado con la cámara web, continua activo ya que la empresa no le otorga mucha importancia a este problema. En el blog del investigador se encuentra toda la información detallada e incluso una PoC. Parece que al final no es mala idea eso de tener una pegatina que tape la webcam ;)

Apple ha lanzado una actualización de seguridad para sus Airport Base Stations

Apple ha lanzado una serie de actualizaciones relativas a varios problemas de seguridad en el firmware de sus AirPort Base Stations. Lanzados el 30 de mayo estos cambios arreglan 8 vulnerabilidades que afectaban a los rúters AirPort Extreme y al AirPort Time Capsule con 802.11ac. Casi la mitad de los bugs arreglados permitían la realización de un ataque de denegación de servicio (DoS). Apple ha solucionado una de estas vulnerabilidades con código CVE-2019-8588 utilizando una validación de entrada mejorada para corregir una referencia de puntero nula. El gigante tecnológico aprovechó un procedimiento similar para resolver el CVE-2018-6918, un bug que permitía a un atacante causar una denegación de servicio.

El tercero de estos fallos, el CVE-2019-7291 también permitía a un usuario con privilegios realizar un ataque de denegación de servicios. Apple abordó este problema mediante el establecimiento de una mejor gestión de la memoria. Las vulnerabilidades restantes cubrían una serie de problemas de seguridad, dos de las vulnerabilidades, CVE-2019-8578 y CVE-2019-8572. Hacían posible que un atacante remoto ejecutase código arbitrario. El fabricante de iPhones soluciono el primero de estos fallos a través de una mejora en la gestión de la memoria y el segundo perfeccionando la validación de entrada para eliminar una de referencia nula puntero.

Figura 1: Funcionamiento de estaciones AirPort Base

Para terminar os hablamos de las otras tres vulnerabilidades a las que se les ha asignado un código CVE:

• CVE-2019-8581: este bug permitía a un atacante remoto filtrar la memoria del dispositivo, Apple arreglo este fallo mejorando la validación de entrada.
  CVE 2019-8575: Esta vulnerabilidad hacía que al hacer un factory reset en algunas ocasiones no se borrase toda la información del usuario. Apple soluciono el problema mejorando el borrado de datos.
• CVE-2019-8580: Con este fallo se aceptaban paquetes IPv4, para resolverlo solo hubo que deshabilitar la función de recibir este tipo de paquetes por defecto.

Estas vulnerabilidades resaltan la necesidad de organizaciones que estén al tanto de todas las vulnerabilidades conocidas que podrían afectar tanto al software como al hardware de los dispositivos. Con ese fin, deberían considerar la posibilidad de crear un programa de gestión de vulnerabilidades con la ayuda de un Proveedor de Servicios de Seguridad Gestionada (MSSP).

MacCharlie, el extraño periférico que intentó unir el mundo del PC con el del Macintosh ... más o menos

El 2 de abril de 1985 apareció en el mercado raro periférico llamado MacCharlie, el cual parecía resolver el gran problema de la compatibilidad entre los PC y los Macintosh de la época. Era tan especial que incluso muchos pensaron que era una broma (el 2 de abril es el Fool´s day) pero no, era un dispositivo totalmente funcional que mas que convertirlo en un PC, simplemente los interconectaba. Vamos a ver un poco más en profundidad la curiosa historia de este dispositivo tan especial.

El MacCharlie fue creado por la empresa Dayna Communications y tenía 256KB de RAM, disquetes de 5"1/4 de doble densidad y un adaptador de teclado para conectar el del Macintosh (el cual añadía todas las teclas que le faltaban al de Mac como las de función). Dentro del MacCharlie había una CPU 8088 a 4,77 MHz, una ROM de 16KB, puerto RS232 y dos RS422. Además se podía expandir su memoria a 640KB (el estándar de la época) e incluso añadir una segunda unidad de discos, configuración que se denominó MacCharlie Plus. El precio de salida era de unos 1.195$ para MacCharlie y 1.895$ para el MacCharlie Plus.

Figura 1. Publicidad de MacCharlie. Fuente.

La conexión entre el Macintosh y el MacCharlie se realizaba simplemente por el puerto serie. Por lo tanto, lo único que se podía obtener era un DOS ejecutándose en una terminal del Macintosh. De hecho, era lógico que se conectara por el puerto serie ya que los Macintosh originales no tenían demasiados puertos por donde conectarse con el mundo exterior. Por lo tanto, sólo se podían ejecutar aplicaciones de DOS tipo texto, lo cual tampoco era un gran inconveniente excesivo para la época, ya que la mayoría de aplicaciones, sobre todo empresariales, funcionaban bajo modo texto.

Figura 2. Detalles frontal y trasero (con los puertos) de un MacCharlie. Fuente.

A pesar de todo, no era una mala idea, pero su mayor problema era la velocidad de funcionamiento, extremadamente lenta por conectarse desde el puerto serie, como ya hemos comentado. Por lo tanto, gastarse casi 2.000$ en un PC que conectabas por el puerto serie a un Macintosh no tenía demasiado sentido. Era casi mejor comprar un PC completo y ponerlo al lado el Macintosh, con su monitor, teclado y ratón por separado. De todas formas apareció en el momento oportuno, solamente un año después de la salida al mercado del Macintosh cuando existía realmente un problema de incompatibilidad entre ambos sistemas. En este enlace se pueden encontrar los manuales y muchas de sus características.

Figura 3. Vista completa de un MacCharlie donde se aprecia la CPU y el extensor de teclado. Fuente.

No hay apenas información sobre cuántas unidades se vendieron o se fabricaron. De hecho, sólo hemos encontrado unas pocas fotos del dispositivo. Ni siquiera se encuentra en eBay por lo que seguramente es uno de los aparatos más buscados por los coleccionistas de artículos Apple. Es interesante este intento de compatibilizar ambos sistemas, utilizando hardware, justo antes de empezar a buscar soluciones por software utilizando virtualización. Otra pieza de la historia de la Informática.

El primer virus en un ordenador personal apareció en un Apple II

En 1981, el ordenador más extendido no era el IBM PC (el cual salió al mercado justo ese mismo año) y tampoco lo era por lo tanto el sistema operativo MSDOS. El más utilizado en aquella época era el Apple II (sobre todo en EEUU) por lo tanto era de esperar que el primer virus fuera creado para ser ejecutado en su plataforma, en concreto para DOS 3.3. En 1982 apareció el primer virus de ordenador con capacidad para infectar otros ordenadores y expandirse. Su nombre era Elk Cloner y fue creado por un chico de 15 años.

Si tenías la suerte de tener una de las magníficas unidades de disco para el Apple II diseñadas por Wozniak, era muy probable que fueras infectado por Elk Cloner. El virus interceptaba algunos comandos muy utilizados por el DOS, como RUN, LOAD, BLOAD y CATALOG. Dependiendo de un contador que iba guardando en el sector de arranque del disco, este ejecutaba una acción diferente. Por ejemplo podía infectar otro disco, reiniciar el Apple II, imprimir la versión del virus, invertir la pantalla, ejecutar sonidos en el altavoz, imprimir texto en pantalla con un flash, cambiar las letras  de la pantalla o provocar un error de sistema. Además si el contador tenía el valor 50 y se pulsaba el botón RESET, el virus mostraba en pantalla el siguiente poema:

Figura 1. Poema escrito en pantalla por el virus Elk Cloner. Fuente.

Más allá de estos "inocentes" payloads, el virus no tenía una incidencia grave sobre el sistema. En cambio lo que le hacía realmente especial, era su capacidad de expandirse infectando cualquier disco de 5 1/4 pulgadas que se insertaba en un sistema con el virus residente en memoria. Este almacenaba el virus en el sector de arranque y de esa forma se aseguraba que sería ejecutado en otro ordenador cuando este arrancara desde el disco. Para no reescribirse una y otra vez, el programa dejaba una firma para identificar que el disco había sido infectado. Este virus apareció cuatro años antes del primer virus creado para un sistema Microsoft, el famoso "Brain" el cual apareció en 1986.

Elk Cloner fue creado por Rich Skrenta en Apple II como parte de una broma sin imaginarse las implicaciones que su creación llegaría a tener. Al principio, no tuvo mucho impacto, ya que los discos infectados se quedaron dentro de su círculo de amigos pero luego comenzó a expandirse cuando Rick empezó a compartir copias piratas de programas en discos infectados con su virus. Además Rick era habitual de un club de ordenadores en Pittsburg e intercambiaba regularmente programas con otros miembros de dicho club. Al menos parece confirmado que le entregó uno de esos discos con el virus a uno ellos e incluso llego a darle uno de esos discos infectados a un primo suyo que trabajaba en la US Navy. En aquella época no había ningún antivirus que pudiera detectar la infección lo que facilitó su expansión entre la comunidad de usuarios de Apple.

Figura 2. Parte del código fuente de Elk Cloner donde almacena el texto del poema

Rich recibió su ordenador Apple II en 1980 como regalo de Navidad. Empezó programando en BASIC pero pronto se interesó por el lenguaje Ensamblador debido a su potencia. Investigando el hardware y el software del Apple II, encontró algunos agujeros de seguridad en una de las aplicaciones del núcleo del sistema (System Monitor) que más tarde utilizó en el código de Elk Cloner. Tardó dos semanas en escribir el programa en lenguaje Ensamblador para el microprocesador 6502 y tenía bastante nivel técnico a pesar de su sencilla operativa. Al cabo del tiempo, viendo la gran repercusión que tuvo su programa, él mismo creo una herramienta para detectarlo y desinstalarlo. Finalmente Rich terminó trabajando en seguridad informática, en concreto en un proyecto de Sun Microsystems relacionado con criptografía. Actualmente es el CEO en Blekko, un nuevo buscador de Internet, que ha sido adquirido por IBM. 

Es curioso que durante al menos diez años, nadie se tomó muy en serio el programa creado por Rich que más tarde llegaría a convertirse indirectamente en una industria que mueve hoy día miles de millones. Sólo cuando comenzaron a aparecer otro tipos de virus, sobre todo en la plataforma Windows (como por ejemplo Brain), fue cuando comenzó a tomarse en serio este tipo de amenaza. 

Scammers: Nuevo malware lanza D.o.S. sobre macOS

Una nueva estafa aparece en el mundo Apple. En esta ocasión es una estafa dirigida a los usuarios de Mac. En el momento en el que el malware entra en el sistema, a través de un correo electrónico o un sitio web malicioso, el supuesto soporte técnico anima a los usuarios a llamar a un número de teléfono falso para que el sistema vuelva a normalidad. Según investigadores de Malwarebytes, los sitios web maliciosos son la gran fuente de infección, debido a que simplemente por visitarlos con Safari pueden provocar la ejecución del ataque y la estafa. Los investigadores de Malwarebytes han publicado un reporte sobre este nuevo malware y estafa encadenada.

Una vez el malware se ha ejecutado en el sistema, se comprueba primero qué versión de OS X está utilizando la víctima para, posteriormente, desencadenar un ataque de denegación de servicio al abrir repetidamente correos electrónicos de tipo borrador. El DoS es contínuo. En los mensajes se le dice al usuario que ha sido infectado y que debe llamar al número de teléfono de soporte técnico de Apple. También se han detectado casos en los que el software malicioso abre iTunes sin que ningún usuario lo pida y muestra el número de teléfono falso allí.

Figura 1: Dominio malicioso

Los usuarios que ejecutan la versión macOS Sierra 10.12.2 no parecen estar afectados por este tipo de ataque, por lo que una buena medida sería actualizar el sistema a la versión 10.12.2. Los usuarios deben estar atentos, primero conociendo los sitios que visitan, teniendo en cuenta que el software debe estar actualizado, ya que como se dijo anteriormente, los usuarios que ejecutan la versión actualizada del sistema operativo no parecen afectados.

Llevar tu iPhone o iPad a UNIX Epoch Time lo "brickea"

Hace ya varios meses publicamos en Seguridad Apple que algo no estaba bien con el calendario en iOS ya que si lo llevabas a hace mucho, mucho tiempo, en una galaxia muy lejana, empezaba a hacer cosas raras. Los años desaparecen, los días se cambian, etcétera. Jugando con la fecha y la hora de todos los iOS de 64 bits, es decir, de iOS 8 adelante, se puede conseguir que el sistema se muera y el terminal iPhone se convierta en un bonito pisapapeles o, como dicen los anglosajones, en un bonito ladrillo "brick" de alrededor de 1.000 dólares de precio.

Para conseguir este brickeo hay que llevar la fecha del sistema a UNIX Epoch Time, o lo que es lo mismo, el 1 de Enero de 1970, que es el contador 0 del tiempo en los sistemas UNIX. A partir de ahí cada segundo aumenta el contador - excepto los leap seconds - Al configurar esta fecha y estar en una zona horaria con diferencia negativa, el sistema se configurar con tiempo negativo, es decir, entramos en la zona de anti-tiempo o como quieran llamarlo los científicos a este efecto temporal. Y el sistema no sabe salir de ahí.

Figura 1: iClarified explica el proceso para brickear tu iPhone

Dependiendo de tu zona horaria, los programas de arranque, la versión exacta de iOS que tengas y los demás pequeños matices que haya en cada iPhone, algunos usuarios han sido capaces de volver algunos de sus terminales a la vida después de horas de reinicio y recargas de batería. Pero por el coste del sistema, yo que tú no lo haría con tu iPhone si has tenido que ahorrar para disfrutarlo.

Bug en Calendar desemboca en exploit que crashea iOS

La noticia de hoy habla de un 0day en iOS que permite a un atacante remoto crashear el sistema. Por lo que sabemos no se puede ejecutar código arbitrario, pero al menos a día de hoy se puede tumbar el sistema reiniciando iOS. Existe un desbordamiento que provoca la caída comentada, por lo que se puede atacar la disponibilidad de una persona de manera remota. 

La vulnerabilidad fue publicada por un investigador llamado Bone, el cual además publicó un exploit como prueba de concepto. El investigador indicaba que la aplicación del calendario de iOS contiene un parámetro que provoca el desbordamiento.

Lo importante de la noticia es que incluso sin acceso físico, simplemente conociendo la cuenta de correo electrónico que se utilice en el Exchange se podría llegar a realizar el ataque.

Figura 1: iPhone 6 reiniciado por la ejecución del exploit

El investigador ha puesto en conocimiento de Apple este problema de seguridad quedando a la espera de una decisión sobre esto. Suponemos que Apple sacará pronto una actualización para solventar el problema. 

OSX Keychain: Bug que permite realizar un DoS al llavero

El investigador Juan Sacco, conocido entre otras cosas por su kit de explotación Exploit Pack, ha publicado una vulnerabilidad sobre el Keychain de OS X. La vulnerabilidad provoca la denegación de servicio del llavero y a día de hoy no tiene solución. Hay que recalcar que la vulnerabilidad no permite ejecutar código, ni acceder a información sensible del llavero, al menos que se conozca. La vulnerabilidad permite dejar al usuario sin posibilidad de acceder al llavero, por lo que habrá autenticaciones que no podrán ser llevadas a cabo.

¿Cómo reproducir el fallo? Para reproducir el fallo y el posterior volcado de información del proceso Keychain Access hay que llevar a cabo lo siguiente:

• Seleccionar un certificado cualquiera y pulsar botón derecho "New Certificate Preference".
• Escribir en "Location or Email Address" un valor aleatorio con un tamaño de más de 9000 caracteres.
• Pulsar sobre "Add".

En la siguiente imagen se puede visualizar lo que veremos al llevar a cabo la prueba de concepto que Juan Sacco ha publicado. El investigador ha avisado a Apple sobre este error, ya que su crasheo deja al usuario sin poder utilizar las contraseñas almacenadas en el Keychain.

Figura 1: Volcado del DoS al Keychain de OS X 10.10.4

Seguiremos atentos a la evolución de esta vulnerabilidad, y veremos si Apple decide parchear pronto, aprovechando la salida de un nuevo pack de actualizaciones que ya nos debe el del 0day que permite elevación de privilegios que está usando el malware.

AwSnap: Un link que "crashea" Google Chrome en OS X

Google Chrome Crash

Ha sido uno de los fallos de la semana en el mundo Google Chrome, el enlace que provocaba el crash del navegador ocurría debido a una cadena de caracteres maliciosa que el navegador no puede procesar correctamente. Esto afectaba a Google Chrome en diferentes plataformas como Microsoft Windows, OS X o Chrome OS. Cuando un usuario accede a este tipo de enlace, la versión 41 de Google Chrome no puede manipular un dirección URL malformada. Algo muy similar a lo que vimos hace poco con los caracteres que hacen crashear a Google Chrome en OS X.

El enlace en cuestión que debe abrirse en cualquier Google Chrome hasta la versión 41 es el que se puede ver a continuación en la siguiente imagen, así que si lo pruebas en tu equipo verás como se cae.

Figura 1: Enlace que hace que se caiga Google Chrome en OS X

El error ha sido bautizado como AwSnap y se describe en github. En Reddit se dan más detalles, aunque si se accede al sitio con Google Chrome, el navegador fallará. Puedes probarlo con el enlace malicioso.

Figura 2: Comentarios en Reddit sobre la versión vulnerable

Se recomienda tener cuidado con este enlace y estar atentos para actualizar tu Google Chrome y solventar este error. Este crash no parece afectar más allá de realizar una DoS de la aplicación, pero estaremos atentos a próximas noticias. 

Cómo se puede bloquear cualquier cuenta de Apple

En los últimos meses ha existido mucho revuelo con iCloud de Apple, el caso de las famosas, el fallo de diseño que permitía que se hicieran ataques de fuerza bruta con iBrute a los Apple ID, herramientas como iDict que permitían explotar este tipo de fallos, etcétera. Hace un tiempo en Eleven Paths hicimos una pequeña prueba de concepto para ver como Apple solucionaba el fallo que permitía realizar fuerza bruta, y verificar que estaba solucionado. Pudimos observar que sí, que a los X intentos la cuenta quedaba bloqueada, teniendo que ir a iForget a rescatar la cuenta. Hemos visto también en las últimas semanas como si tienes activada la Verificacion en Dos Pasos de tu cuenta y se te olvida la clave de recuperación Apple no te la desbloqueará.

Figura 1: Cómo se puede bloquear cualquier cuenta de Apple

Hoy queremos exponer el pequeño script que realizamos que permite bloquear un Apple ID conociendo el correo electrónico de la persona. Hay mucha gente que lleva su vida digital diaria en iCloud, y el impacto que esto puede tener si se automatiza para que aunque el usuario recupere su cuenta ésta vuelva a ser bloqueada es grande. El funcionamiento del login de sitios como iCloud es el siguiente:

1. En el panel de login se inicia sesión, si la contraseña es incorrecta se devuelve un código HTTP 200. 
2. Al tercer intento con una contraseña incorrecta se devuelve un código 302, es decir una redirección. 
3. Ahora el navegador del usuario obtiene una nueva cookie y se procede a que el usuario vuelva a introducir contraseñas.
4. Cuando la cuenta queda bloqueada, no se produce el paso 2, es decir, en ningún momento se redirecciona al usuario, por lo que siempre se devuelve la misma página con un código de respuesta 200.

Prueba de Concepto de bloqueo de cuentas Apple

En primer lugar podemos observar como al ejecutar el script se ven claramente los pasos comentados anteriormente. La cuenta a bloquear ha sido configurada en el interior del script.

Figura 2: Lanzamiento del script

Una vez que se intenta iniciar sesión diversas tres veces, se puede ver el redirect que se devuelve al script por lo que éste debe volver a obtener una cookie y continuar con el proceso. Es importante ver que la contraseña va cambiando, son los números y letras que se ven entre los códigos de respuesta HTTP. Si siempre enviamos la misma contraseña no obtendremos el redirect por lo que no sabremos si el proceso es válido o no.

Figura 3: Detección de cuenta bloqueada

En la imagen anterior se puede ver como empezamos a recibir códigos de respuesta HTTP con valor 200, esto es sospechoso, por lo que el script se detiene e imprime por pantalla el texto "blocked!?". Ahora ya no obtenemos el código de respuesta 302, por lo que parece que algo extraño ocurre con el servidor, por lo que abriendo un navegador intentamos iniciar sesión con la cuenta configurada en el script.

Figura 4: Comprobación de cuenta bloqueada

Como se ha visto es bastante sencillo bloquear el Apple ID de cualquier persona conociendo su dirección de correo electrónico. Evitar este tipo de ataques sería sencillo con el equipo de confianza, es decir, configurar en la cuenta un equipo de confianza desde el cual se puede iniciar sesión aunque se esté recibiendo ataques desde otras ubicaciones, pero recordad que si no protegéis vuestros terminales, existen muchas otras formas de hackear iPhone o iPad.

Crash en Apple Safari 8 en OS X 10.10.X Yosemite

Cada día salen nuevas vulnerabilidades en OS X y los productos de la gente de Apple. Esto es debido en parte a la cuota de mercado que están alcanzando, y en el interés generado por estudiar e investigar sus sistemas y aplicaciones. No hay que irse muy lejos para recordar la vulnerabilidad rootpipe en la que se consigue elevar privilegios y obtener una shell como root. Se espera que Apple ponga solución a esto en Enero de 2015.

La última versión de Apple Safari en OS X trae un fallo que produce el crash de la aplicación produciendo el cierre inesperado del navegador. Un posible atacante puede provocar el cierre de Apple Safari utilizando un enlace que lleve a la víctima a ejecutar el contenido que el atacante ofrece. En la imagen se puede visualizar el código necesario para provocar la caída del proceso, el cual puede ser descargado de sitios como exploit-db.

Figura 1: Código que provoca el crash de Safari 8 en OS X 10.10

Cuando la víctima accede al recurso malicioso compartido por el atacante, se puede leer en el navegador que el contenido web de Apple Safari se cierra inesperadamente. Si se abre el recurso con otro navegador web, esta situación no ocurre, por lo que según se indica en exploit-db este fallo solo ocurre en Apple Safari.

Figura 2: Crash de Safari

Cuando Apple Safari se cierra pide al usuario informar a Apple del error y en opciones más avanzadas podremos visualizar el volcado que se hace, el cual es muy similar al que se puede ver en exploit-db o 1337day. Al final esta vulnerabilidad no deja de ser un DoS contra la aplicación, por lo que estaremos atentos a una actualización que solvente el problema. A día de hoy, no existe parche por lo que hemos podido probar. 

Caída en iMessage también en iOS 8.1.1 & OSX 10.10.1

A lo largo del último mes fueron muchos los usuarios de dispositivos Apple que se quejaron del mal funcionamiento del servicio de mensajería iMessage, alegando que les era imposible hacer un uso normal del mismo ya que los mensajes no se llegaban a enviar. Eventualmente estos problemas se solucionaron. Sin embargo esta misma semana, coincidiendo con la publicación de las nuevas versiones de los sistemas operativos de Apple (iOS 8.1.1 y OS X Yosemite 10.10.1), algunos usuarios han vuelto a reportar el mismo bug: los mensajes no se envían.

Ante el malestar creciente de esos usuarios, que se han visto obligados a volver a usar SMS, Apple ha investigado el problema y concluido que no tiene nada que ver con las actualizaciones. Parece que todo ha sido una infeliz casualidad, ya que muchos de los usuarios afectados ni siquiera llegaron a actualizar sus dispositivos.

Figura 1: A día de hoy iMessage y todos los servicios están up and running

En su página de System Status, Apple ha documentado el incidente, que aparentemente ha durado solo un par de horas, desde las 9.30 a las 11.30 hora del Pacífico. Sin embargo, una rápida búsqueda en Twitter revela que hay usuarios que siguen sin poder utilizar iMessage, con lo que habrá que estar al tanto de cómo evoluciona la situación.

OSX 10.9.2 y Apple Safari 7.0.2: Fallos con la memoria

A mediados de este mes de Marzo, en la lista BugTraq, se publicó un artículo que apunta a una vulnerabilidad de denegación de servicio remota en OS X 10.9.2, Apple Safari 7.0.2, Mozilla Firefox 27 y el antivirus Kaspersky. El bug se encuentra en los controles de memoria en las la función regcomp() de BSD, en GNU/libc() y en los sistemas operativos Apple en regcomp/libc(). Esto quiere decir que una función que llame recursivamente a expresiones regulares puede generar problemas en la memoria llevando a un consumo excesivo y al bloqueo de la aplicación vulnerable.

Para probarlo se pusieron disponibles varias PoC para OS X 10.9.2 y Apple Safari 7.0.2, que nosotros hemos querido testear. El código que se propone en el caso de Apple OS X Mavericks 10.9.2 es una expresión regular lanzada desde la consola de comandos. Como se puede ver, se produce un error en la función de gestión de memoria no controlada, lo que muestra que este defecto está presente en la librería.

Figura 1: Este comando genera un error en la reserva de memoria.

Para el código HTML/JavaScript que se propone en Apple Safari, sí que hemos podido ver que la web se queda pesada y tarda mucho tiempo en responder, pero en ningún momento hemos visto que hubiera que cerrar el navegador - si la pestaña -.

Figura 2: Código HTML/JavaScript para la PoC

En cuanto al consumo de memoria, se puede ver en el comando top que no es excesivo en el sistema, aunque según informan en plataformas Microsoft Windows se han llegado a consumos de 4 GB.

Figura 3: Consumo de la PoC en Apple Safari 7.0.2 sobre OS X Mavericks 10.9.2

En cualquier caso, este problema no está solucionado aún, y deberemos esperar a la nueva versión de OS X Mavericks con una actualización de Apple Safari a ver si lo solucionan.

Un bug de SnapChat puede crashear tu iPhone

El investigador español Jaime Sánchez (@segofensiva) ha publicado una prueba de concepto que muestra cómo un ataque de flooding de mensajes a un destinatario de SnapChat haga uso de la app en un terminal iPhone puede acabar crasheando y forzando un reinicio del sistema. En los terminales Android, el sistema se vuelve lento y difícil de manejar, pero en el caso de iPhone, el sistema sufre una denegación de servicio, tal y como se puede ver en el siguiente vídeo.

Figura 1: PoC de crash de iPhone por flooding de mensajes de SnapChat

Los bugs de denegación de servicio por medio de flooding no son desconocidos en las apps de mensajería y sistemas como iMessage sufrieron ataques de DoS en el pasado, o en WhatsApp los mensajes de gran tamaño han generado problemas de funcionalidad en ellas. Si tienes SnapChat en tu iPhone, alguien podría hacerte lo que se ve en el vídeo hasta que se solucione este fallo.

Hard Link Memory Corruption en Apple OS X Mavericks

Es conocido que en la mayoría de los sistemas *NIX un enlace duro a un directorio está reservado para el usuario root, cuando se indica un path absoluto. En Mac OS X 10.6 existía una vulnerabilidad de este tipo, la cual se encuentra documentada en el siguiente CVE-2010-0105. La semana pasada ha sido descubierta una vulnerabilidad en Mac OS X 10.9 Mavericks, el cual provoca un kernel panic al intentar listar un enlace duro con recursividad infinita. Como se puede leer en la Wikipedia, para evitar la recursividad infinita, los sistemas operativos más modernos no permiten enlaces duros a directorios.

Además, los enlaces duros en los directorios conducirían a la inconsistencia en las entradas del directorio padre. La excepción confirmada es Mac OS X 10.5 Leopard, el cual utiliza enlaces duros a directorios para el mecanismo de copia de seguridad Time Machine, solamente.  Conocido esto, hay que decir que el investigador Maksymilian Arciemowicz ha descubierto que en Mac OS X 10.9 se puede crear un enlace a disco provocando recursividad infinita, con un sencillo código en C. El código lo exponemos a continuación.

#include 
#include 

void usage(const char* program)
{
    const char* message = " [src_dir] [target_dir]";
        fprintf(stderr, "%s%s\n", program, message);
}

int main(int argc, char* argv[]) {
    if (argc!=3) {
        usage(argv[0]);
            return 1;
    }
    
    int ret = link(argv[1],argv[2]);
    
    fprintf(stderr,"link(3) return= %d\n", ret);

    return ret;
}

El autor opina que es un fallo de seguridad y que Apple debería corregirlo, aunque Apple no ha concedido esto como vulnerabilidad y  en la lista Bugtraq se ha debatido el porqué del problema: "los enlaces duros de directorios no pueden tener el mismo padre". La ejecución de dicha vulnerabilidad con el código se puede visualizar a continuación:

mac-cxs-XK:pochd XK$ gcc -o test test.c
mac-cxs-XK:pochd XK$ ls
test test.c
mac-cxs-XK:pochd XK$ mkdir DIR1
mac-cxs-XK:pochd XK$ ./test DIR1 Hardlink1
link(3) return= -1
mac-cxs-XK:pochd XK$ mkdir DIR1/DIR2
mac-cxs-XK:pochd XK$ ./test DIR1/DIR2 Hardlink2
link(3) return= 0
mac-cxs-XK:pochd XK$ cd DIR1
mac-cxs-XK:DIR1 XK$ mkdir DIR2/DIR3
mac-cxs-XK:DIR1 XK$ ../test DIR2/DIR3 Hardlink3
link(3) return= 0
mac-cxs-XK:DIR1 XK$ cd DIR2
mac-cxs-XK:DIR2 XK$ mkdir DIR3/DIR4
mac-cxs-XK:DIR2 XK$ ../../test DIR3/DIR4 Hardlink4
link(3) return= -1

Puede haber muchas consecuencias negativas que se obtienen del mal manejo del enlace duro. Se sabe que existe la vía de agotar los recursos del sistema a través de dicha vulnerabilidad, pudiendo causar bloqueos de aplicaciones, o como se produce con esta vulnerabilidad kernel panic. Habrá que esperar a una nueva actualización de OS X Mavericks. 

Apple II DOS: El código fuente publicado para su estudio

Hoy no podemos dejar de hablar de la liberación que se ha producido a través de Computer History Museum del código fuente transcrito del sistema operativo Apple II DOS para que pueda ser utilizado con fines educativos.

Figura 1: El Apple II

Los equipos Apple II se vendían a diferentes precios dependiendo de la capacidad de la memoria del sistema - algo similar a lo que se sigue haciendo hoy en la compañía, pero todos ellos eran equipos que permitían trabajar con cualquier monitor en color, disponían de tarjetas de sonido, conectores para juegos, además de venir con el compilador de BASIC totalmente integrado que creo la propia Microsoft - pero no venía con disquetera.

Figura 2: La lista de precios de Apple II

Steve Wozniak había creado no solo el diseño hardware de la disquetera de 5 1/4 con 8 circuitos integrados, sino que había programado también el controlador para hacer por software funciones que otras disqueteras hacían por hardware y fue presentada en el Computer Electronics Show en Enero de 1978, y daría lugar a la Disk Division que montaría más tarde Apple, antes de que se pasaran a los discos de 3 1/2 más adelante, pero esa es otra historia que ya os hemos contado.

Figura 3: BASIC de Microsoft creado para Apple Computer

Para poder utilizarlo en los Apple II era necesario software de alto nivel que permitiera hacer uso de sus capacidades, y como prueba de concepto entre el propio Steve Wozniak y Randy Wigginton diseñaron un software de ejemplo bastante rudimentario, pero hacía falta un software a más alto nivel que permitiera trabajar y organizar ficheros y datos en los discos.

Figura 4: Disquetera Apple de 5 1/4

En aquel entonces las capacidades de Apple eran muy limitadas - solo eran 15 empleados - así que Steve Jobs firmó un contrato de 13.000 USD con Bob Shepardson de Shepardson MicroSystems, para que entregara un gestor de ficheros, un interface de BASIC y varias utilidades que deberían ser entregadas el 15 de Mayo de 1978. El trabajo quedó en manos de un programador subcontratado llamado Paul Laughton, que cumplió con creces su cometido, ya que en Junio de ese mismo año se presentaba "Apple II DOS version 3.1"

Figura 5: Paul Laughton

Gracias a Paul Laughton y con la ayuda del Dr. Bruce Damer fundador de DigiBarn Computer Museum - y con la autorización de Apple Comptuer que posee aún los derechos - se ha recuperado todo el material que veis a continuación para su uso académico.

Figura 7: Sección del código re-escrito del Apple II DOS

- Lista de precios escaneada de Junio de 1978.
- Lista de precios escaneada de Octubre de 1978.
- Código fuente re-escrito de Octubre de 1978 (no se ensamblado aún puede tener typos)
- Rutinas a bajo nivel de lectura y escritura escritas por Steve Wozniak y Randy Wigginton. 
- Especificaciones técnicas y diseños relativos a la unidad de disco de Apple II.
- Contratos y anexos entre Apple y Shepardson Microsystems.
- Minutas de una reunión entre Apple y Shepardson Microsystem sobre bugs y mejoras.

Apple II sería parte de la historia de la informática y que llegó a contar con sistemas de vision digital - el famoso DS-65 Digiselector, pero además en el mundo de la seguridad informática tendría el honor de ser el primer ordenador personal para el que se diseño un virus, el famoso Elk Clonner.

BSOD: Blue Screen Of Death en iPhone 5s con iOS 7.0.2

Ya cuando apareció el bug en iOS 7 que permitía llamar a cualquier número de teléfono desde el panel de llamadas de emergencia, se podía ver que algo no funcionaba bien en el sistema operativo, ya que de repente aparecía el logo de Apple como si algún elemento interno se estuviera reiniciando. Ahora, con la nueva versión de iOS 7.0.2 muchos son los usuarios que utilizando diferentes apps están experimentando esa misma situación, pero con una BSOD en toda regla, tal y como se puede ver en el siguiente vídeo.

Figura 1: Vídeo en el que se puede ver un BSOD al usar Pages en iOS 7

Ya se han recibido conexiones de dispositivos desde Apple trabajando con iOS 7.0.3, así que se espera que Apple solucione de una vez estos problemas, ya que somos muchos los que notamos que algo no va bien con el sistema. En las distintas actualizaciones de iOS 7 nosotros hemos tenido que reiniciar ya varias veces un terminal iPhone 5 que se había quedado totalmente bloqueado. ¿Será que el iPhone 5S con iOS 7 que se presentó esta en un estado similar a cómo se presentó el primer iPhone?

Bug en CoreText crashea aplicaciones en iOS y Mac OS X

Ayer mi navegador crasheo cuando leía los feeds RSS en Feddly, pero también lo hizo la app en iPhone, así que pensé que era un bug en el lector, pero luego, al navegar un poco por la web apareció la respuesta. Un bug en CoreText que crashea las apps en iOS y Mac OS X cuando se leen una serie de caracteres en codificación arábiga. El bug recuerda al que ya tuvimos tiempo atrás con File:///, que tumbaba también todas las aplicaciones, y de nuevo será una molestia para los usuarios de iOS y Mac OSX.

Figura 1: Codificación UTF-8 que crashea CoreText en iOS y Mac OS X

Cualquier correo leído por por un cliente de Mac OS X o iOS, tumbará la app. Un twitt en tu time-line con esa cadena crashea Twitter. Una página web con esa cadena tumbará cualquier navegador - como la de hackplayers , etcétera, etcétera, etcétera. Para poder hacer unas capturas esos caracteres hemos tenido que utilizar una máquina virtual con Microsoft  Windows e Internet Explorer.

Figura 2: Aspecto de la cadena de caracteres arábigos que tumban la web

Esperemos que Apple reaccione rápido y solucione este molesto bug, ya que aunque no se ha conseguido ejecución de código con él, la denegación de servicio constante puede ser una auténtica molestia para los usuarios.

OSX 10.8.3 DoS por ftpd Remote Resource Exhaustion

El investigador Maksymilian Arciemowicz ha enviado a la lista de correo de Bugtraq un reporte de seguridad con una demostración en vídeo de un viejo fallo de seguridad en el servicio FTP de equipos con sistema operativo OS X Mountain Lion que, a pesar de haber sido supuestamente corregido por Apple, sigue siendo explotable en OS X 10.8.3 para realizar un ataque de Denegación de Servicio, tal y como se puede ver en el siguiente vídeo.

Figura 1: Vídeo de la PoC de DoS en OS X 10.8.3 con ftpd

El fallo se produce porque por una falta de control en el consumo de recursos que se produce desde una máquina remota en el servicio FTP que utiliza Apple, basado en tnftpd. Incialmente, Apple utilizaba la librería libc que fue parcheada en el CVE-2010-2632 en Mac OS X 10.6.8. Sin embargo, parte del código de libc - incluyendo la función glob vulnerable al CVE-2011-0418 - fue migrada a código propio de Apple, y parece que a partir de la version del 22 de Marzo de 2013 - incluida en OSX Mountain Lion 10.8.3 - el parche de control de recursos no se migró.

Figura 2: CVE-2010-2632 resuelto en Mac OS X 10.6.8

Es decir, Apple ha reintroducido un viejo bug de seguridad en OS X Mountain Lion, lo que lleva a que una prueba de concepto del año 2010 vuelva a funcionar perfectamente para hacer un D.O.S. a cualquier servidor OS X Mountain Lion con el servicio ftp, ya que el consumo de recursos afecta al sistema completo.

Figura 3: Servidores OS X con servicio FTP en Internet descubiertos con Shodan

Como se puede ver en la imagen superior, buscando con Shodan es posible encontrar en Internet miles de servidores OS X con el servicio FTP abierto a Internet que podrían ser objetivos de este tipo de ataques. Si tienes un servidor con Mac OS X Snow Leopard, asegúrate de tener instalada la versión 10.6.8. Si tienes un servidor con OS X Mountain Lion 10.8.3 configura reglas en el firewall de tu red para detectar múltiples conexiones al servicio ftp desde una misma dirección.

Ataques D.O.S. y de Spam en iOS iMessages app

En un ataque producido este miércoles a algunos desarrolladores de herramientas populares de jailbreak - publicado por The Next Web - se han dado a conocer varios fallos de seguridad a la hora de gestionar los límites en la app de iMessages para dispositivos iOS que permiten realizar fácilmente ataques de denegación de servicio, haciendo imposible abrir la aplicación para leer los mensajes y dejando inutilizado el servicio.

Flooding de iMessages

El primero de los problemas es que iMessages no comprueba la velocidad con que se mandan los mensajes, así que con un sencillo programa escrito en AppleScript es posible enviar un flood de iMessages a la víctima hasta que el número es tan grande que la app para iOS no es capaz de renderizarlos y deja de funcionar. 

Figura 1: Flooding de iMessages hecho con un AppleScript

Rederización de mensajes complejos en iMessages

El mismo problema sucede, que termina anormalmente la app, cuando se mandan mensajes muy largos y muy complejos de renderizar, como los escritos utilizando caracteres Unicode para enviar mensajes escritos en Zalgo. 

Figura 2: Gran iMessage escrito en Unicode que tira la app de iMessages

Spam a través de iMessages

El último y, quizá más importante problema, es que estos ataques han demostrado que no hay ninguna opción antispam en iMessage, y teniendo que este servicio se puede utilizar de forma gratuita, cualquiera puede registrar cuentas de correo electrónico de usar y tirar, hacer una campaña de spam por iMessage, y saber que llegará a todos los poseedores de este servicio sin que nadie lo bloquee.

Figura 3: Spam enviado a varios desarrolladores iOS

Esto, que aún no es hecho por prácticamente nadie, puede convertirse en un problema serio para la usabilidad de iMessages si no se ataja de raiz pronto.