Nos acercamos al final de enero y en Seguridad Apple no descansamos para traeros algunas de las mejores noticias en el ámbito de la seguridad informática relacionadas con el mundo de la manzana. Este es nuestro nuevo Fue Noticia, sección en la que os traemos un breve resumen de las noticias más relevantes de las últimas dos semanas. Todo ello aderezado con el mejor contenido de otros sitios de referencia.
Comenzamos el lunes 14 haciéndoos un listado de las 14 aplicaciones de Apple que pueden ser dañinas para tu dispositivo al usar los mismos servidoes que el malware Golduck.
El miércoles 16 os contamos como una empresa llamada Zerodium basa su actividad en la compraventa de bugs llegando a pagar hasta 2 millones por un malware.
El jueves 17 os avisamos de que el jailbreak para iOS 11.4.1 podría estar a la vuelta de la esquina y vendria de la mano del autor de EtasonJB y h3lix.
El viernes 25 os enseñamos como podéis convertir vuestra Raspberry Pi en un receptor de AirPlay.
Finalmente, ayer sábado celebramos el 35 aniversario del Macintosh con esta entrada donde nos preguntamos qué ha sido del equipo original que lo desarrolló.
Hoy os traemos un post de desarrollo en el que explicaremos como convertir una Raspberry Pi en un dispositivo “AirPlay Enabled”. AirPlay es un protocolo de transmisión de audio y video desarrollado por Apple lanzado en 2010 junto a iOS 4. Este protocolo requería en sus principios de una red Wi-Fi para comunicarse entre dispositivos, que fue sustituido por una comunicación ah-hoc en iOS 8.Actualmente Airplay se encuentra en su segunda versión, introduciendo mejoras como soporte para sincronización estéreo o soporte para el Homepod, aunque en este post nos centraremos en la versión 1 del protocolo, que fue implementada mediante ingeniería inversa en 2011 en la librería que hoy os vamos a enseñar.
Shairport-Sync es una librería con soporte para múltiples sistemas operativos que es capaz de transformar cualquier dispositivo en un receptor Airplay. Su instalación en bastante sencilla y su popularidad es tan grande en Rapsberry que tiene una guía específica para estos dispositivos.
Para instalar esta librería en nuestra Raspberry debemos primero actualizar nuestro sistema:
$ apt update
$ apt upgrade
Después, si estamos usando wifi, debemos desabilitar la administración de energía WiFi, debido a que por defecto la Raspberry se pondrá el WiFi en modo de baja energía cuando lo considere inactiva, por lo que no respondería a los eventos de la red.
> iwconfig wlan0 power off
Después de esto tendremos compilar e instalar la aplicación. Primero instalando los paquetes necesarios para que funcione la librería:
Para luego descargar Shairport-Sync desde su repositorio, configurarlo e instalarlo:
> git clone https://github.com/mikebrady/shairport-sync.git
> cd shairport-sync
> autoreconf -fi
> ./configure --sysconfdir=/etc --with-alsa --with-avahi --with-ssl=openssl --with-systemd
> make
> sudo make install
Una vez instalado, deberemos modificar el fichero de configuración para adaptar su uso a nuestro requerimiento, en la wiki del proyecto aparece los requisitos mínimos para Raspberry:
// Sample Configuration File for Shairport Sync on a Raspberry Pi using the built-in audio DAC
general =
{
volume_range_db = 60;
};
alsa =
{
output_device = "hw:0";
mixer_control_name = "PCM";
};
El siguiente paso es habilitar el proceso de shairport para arrancarlo al iniciar el sistema y por último iniciar el proceso:
Con esto deberíamos tener nuestra Raspberry funcionando, el nombre del dispositivo es el hostname de la Raspberry con la primera letra en mayúscula. El sonido saldrá por el puerto de audio de la Raspberry así que si la conectamos a nuestros altavoces analógicos y probando las distintas configuraciones que ofrece podemos conseguir un dispositivo Airplay económico.
Comienza noviembre y en Seguridad Apple seguimos trabajando para traeros las mejores noticias en el ámbito de la seguridad informática relacionadas con Apple. Este es nuestro nuevo Fue Noticia, sección en la que os traemos un breve resumen de las noticias más relevantes de las últimas dos semanas. Todo ello aderezado con el mejor contenido de otros sitios de referencia.
Comenzamos el lunes 23 contándoos que el senador Al Franken escribió una carta a Tim Cook mostrándole la preocupación por la seguridad y la privacidad respecto a la llegada del nuevo Face ID.
El martes día 24 os avisamos de la llegada del Big Data Innovation Day, un evento en el que os mostramos las novedades del último año en el creciente mundo del big data.
El miércoles 25 os alertamos de la aparición de un nuevo troyano para Mac OSX que se propaga a través de la descarga del reproductor multimedia Elmedia player debido a que su base de datos se vio comprometida.
El jueves 26 os avisamos de la llegada de una de nuestras ElevenPaths Talks, en la que se abordará sobre la inevitable evolución de la seguridad gestionada, y os invitamos a seguir de cerca esta tercera temporada.
El viernes 27 os contamos como la EFF ha lanzado una dura crítica contra Apple debido al nuevo control center implementado en iOS 11 y las posibles brechas de seguridad que supone su uso.
El sábado 28 echamos la vista atrás para indagar un poco en la historia de Apple para hablaros del desconocido Apple II, el primer ordenador relacionado con el mundo de la música.
El domingo cerramos la semana contándoos como una vulnerabilidad de Java en ordenadores Mac permitió que una base de datos de Microsoft que guardaba información sensible fuese vulnerada.
El lunes 30 os contamos como unos videos publicados en You Tube en los que se mostraba el nuevo iPhone X han provocado el despido de uno de los ingenieros de Apple.
El martes 31 os avisamos de la llegada de una de nuestras CodeTalks4Devs, en la cual se hablará sobre Dirtytooth y se contará como realizar su instalación en una Raspberry usando un paquete DEB.
El miércoles 1 os presentamos iOS 11.1, una actualización con la que se pretende acabar con los problemas de batería que tenían algunos terminales y que incorpora algunas novedades como un nuevo pack de emojis.
El jueves 2 os hablamos sobre como un fallo descubierto en iOS que permite a algunas aplicaciones acceder a la cámara de tu dispositivo sin solicitar ninguna clase de permiso.
El viernes 3 os contamos como es posible que algunas aplicaciones de iOS puedan acceder a tu ubicación a través de la galería y os explicamos como se puede evitar.
Os esperamos de nuevo en dos semanas para mostraros nuestro resumen de todo lo que ocurre en el mundo de la manzana mordida. Sin duda, un mundo apasionante y que semanalmente nos proporciona un gran número de noticias de interés.
El próximo 1 de noviembre nuestros compañeros Pablo González y Álvaro Nuñez-Romero nos hablarán, en un nuevo Code Talk for Devs, sobre la implementación de Dirtytooth en una Raspberry Pi a través de un paquete DEB que hemos generado para vosotros. En el webinar se detallarán los pasos y el código utilizado para llevar a cabo el proyecto. Además, se mostrarán ejemplos de uso y cómo la Raspberry Pi puede obtener datos interesantes de iOS. El proyecto Dirtytooth proporciona más información en su web.
Dirtytooth es un hack para iOS que se aprovecha de la gestión de los perfiles Bluetooth realizada por el sistema operativo. Con Dirtytooth hay un impacto en la privacidad de los usuarios que utilizan la tecnología Bluetooth en su dispositivo iOS diariamente. Este hack permite extraer información como datos de contacto o las llamadas realizadas por el usuario.
Figura 1: ElevenPaths Code Talks for Devs
Además, comentaros que el proyecto Dirtytooth estará en la próxima edición de Black Hat Europe, junto a otra herramienta desarrollada en Eleven Paths denominada UAC-A-Mola. Si quieres saber más sobre Dirtytoothy su instalación en una Raspberry Pi te esperamos el próximo miércoles 1 de noviembre a las 15:30h (CET) en nuestro canal de YouTube y también en nuestra comunidad, donde nuestros expertos estarán disponibles para responder cualquier tipo de duda respecto al webinar ¡Te esperamos!
En el artículo anterior hicimos una migración del plugin Lockifi a su versión para OS X totalmente funcional. Al hacer la migración observamos que sería muy sencillo para cualquier usuario doméstico utilizar una Raspberry Pi y poder utilizarla como punto de acceso WiFiconectada al router, por lo que el WiFidel router lo deshabilitariamos. Nuestra Raspberryestaría ejecutando nuestro plugin y gestionando de forma sencillo cuando el punto de acceso debe estar arriba o abajo. Para llevar a cabo esta implementación, ¿Qué necesitamos?
Como vais a ver no será difícil poder implementar esto en cualquier entorno. Los requisitos son bastante obvios y son los siguientes:
Raspberry Pi.
Adaptador WiFi. En la nueva Raspberry Pi 3 ya viene el adaptador integrado. Es vital que el adaptador utilizado sea compatible.
Distribución Linuxpara la Raspberry. En esta implementación se ha utilizado una versión de Kali Linux para Raspberry, pero valdría, por ejemplo, con una Raspbian.
Nuestro plugin Lockifi OS X creado en el anterior artículo. El plugin sufrirá una ligera modificación.
Paso 0: Empezando con hostapd y dnsmasq
Lo primero es convertir nuestra Raspberryen un punto de acceso WiFi. hay que tener en cuenta que utilizaremos la Raspberrycomo punto de acceso y haremos forwardinga los paquetes que lleguen por dicha interfaz. El forwardingse realizará por el cable Ethernetque el dispositivo tendrá enchufado. Este cable Ethernetestará conectado entre la Raspberryy el router de casa.
Lo primero es instalar, en caso de que sea necesario, eldriverdel adaptador Wireless. Esto dependerá del modelo de adaptador utilizado. Una vez que vemos que ejecutando ifconfigo iwconfigobtenemos información del adaptador podemos continuar. La instalación de hostapdy dnsmasq es importante. El primero será el que "levante" el punto de acceso, mientras que el segundo se encargará de proporcionar dirección IP a los clientes que se conecten a la WiFimediante DHCP y proporcionar también un servidor DNS a los clientes conectados. Para instalarlos debemos ejecutar:
apt-get install dnsmasq.
apt-get install hostapd.
Una vez instalado ambas aplicaciones y sus dependencias debemos configurar una dirección IP estática para el punto de acceso. Para este caso hemos utilizado la dirección IP 10.0.0.1. Esta configuración se lleva a cabo dentro de la Raspberryen el fichero /etc/network/interfaces. La configuración del fichero es la siguiente:
Respecto al fichero/etc/hostapd/hostapd.conf debemos configurar lo siguiente:
interface=[interfaz WiFi] ssid=freewifi channel=[número canal] driver=[driver de nuestro adaptador]
Si queremos fortificar la red WiFipodremos configurar WPA2 en ese mismo fichero. Ahora crearemos un scriptdenominado run.sh, el cual se encargará de ejecutar todo lo necesario para "levantar" el punto de acceso en el arranque y configurar el forwardingentre interfaces. Las instrucciones necesarias son las siguientes:
Si escaneamos las redes WiFicon nuestro iPhone podremos observar una red denominada freewifi, tal y como se puede ver en la imagen.
Figura 1: Punto de acceso disponible desde la Raspberry Pi
Paso 1: Modificando el programa Ruby
Ahora tenemos que modificar la aplicación que hicimos para gestionar la WiFidesde OS X. El cambio será sencillo, ya no tenemos que entrar por SSH al router. Solamente tendremos que indicar en nuestro código que cuando Latch esté cerrado se pare el servicio hostapdy cuando Latchesté abierto el servicio hostapdarranque. El algoritmo utilizado es realmente sencillo:
Mientras true Compruebo estado de Latch Si Latch está Abierto Indico que está abierto Levanto hostapd Si no Indico que se cerrará Apago hostapd Fin Si Fin Mientras
Figura 2: Snippet de código del nuevo ssh.rb corriendo en Raspberry Pi
Paso 2: Comprobar funcionalidad
Con todo preparado ejecutamos el scriptrun.sh sobre la Raspberry, si no lo configuramos para arrancar en el arranque del sistema operativo. A los pocos segundo veremos que podemos conectarnos a la WiFiconfigurada. Abriremos Latch con el objetivo de que el programa escrito en Rubyverifique que el punto de acceso debe estar levantado.
Figura 3: Lockifi OS X Raspberry abierto
Viendo la salida del programa se observa como nos indica "Open". Cuando pasen 20 segundos, esto es totalmente configurable, se volverá a preguntar si Latchestá abierto o no. En el caso de que esté cerrado se ejecutará la instrucción service hostapd stop, con el objetivo de "tirar" la red WiFicreada con el servicio.
Figura 4: Comprobación del estado
Ahora conectamos un dispositivo móvil o equipo a la red WiFi, pero decidimos cerrar el Latch. Cuando el programa despierte de la función sleepse encontrará con que Latchfue cerrado, por lo que nos mostrará el mensaje "No Open" y ejecutará la instrucción para parar el servicio de hostapd.
Figura 5: Deteniendo el servicio del punto de acceso WiFi
Cuando se detecte que Latchestá cerrado se nos mostrará un mensaje en el dispositivo móvil indicando que hubo un intento de acceso. Esto quiere decir que se ha comprobado el estado de Latch y éste estaba cerrado. La acción a realizar es clara, detener el servicio. Esto puede ser similar a salir de casa y decidir apagar la WiFi, para que solo pudiéramos conectarnos por cable. Al final es similar a minimizar el nivel de exposición de nuestra red WiFi.
Figura 6: WiFi apagada
Es fácil entender el potencial que tiene esto. Otra opción sería integrar Latch en routers con OpenWRTcon el que ya se hizo una primera integración. De esta forma no tendríamos que tener un punto de acceso aparte. Sea como sea, el potencial y la imaginación dependerá de vosotros. Cada vez hay más aplicaciones y usos de Latch en el mundo IoTy alineado en todo momento con la seguridad de nuestra información.
Por último, ¿Cómo evitar el polling? Para evitar estar constantemente realizando consultas a Latch podríamos utilizar la técnica de esperar un paquete en un puerto concreto de nuestra Raspberry. En otras palabras, nuestra Raspberrypodría tener a la escucha en la interfaz Ethernetun servicio en un puerto X. El objetivo es que cuando se reciba un paquete en dicho puerto se invoque la ejecución, de una sola iteración, de nuestro programa Ruby. Éste consultará el estado de Latchy en función del on/offse realizará una u otra operación. Para más información sobre este tipo de soluciones se puede consultar el artículo "Modo Paranoia: Port-Knocking y Latch para fortificar tus sistemas".
Uno de los plugins que participaron en el concurso de Latch era Lockifi, un plugin que permitía al usuario habilitar y deshabilitar el acceso WiFi en el router. El objetivo es claro, cuando no vaya a utilizar la WiFirestrinjo el tiempo de exposición y la deshabilitóde forma automática gracias a la autorización con Latch. La idea nos gustó y decidimos migrar este plugin a un sistema OS X. Al principio nuestra idea fue migrar el plugin, por ejemplo a un lenguaje como Ruby, y crear un ítem en el inicio de sesión del usuario para que la aplicación estuviera preguntando automáticamente al iniciar sesión por el estado de Latch.
Tras echarle un poco de tiempo obtuvimos un código en Rubyque realizaba la misma operación que Lockifipara Windowsy preparamos el entorno para que autoarrancara. Aquí tenéis el vídeo de Lockifi para que veáis su propuesta. El código de este plugin está disponible en GitHub: Lockifi.
FIgura 1: Plugin Lockifi para Windows
Paso 0: El código
Como se ha mencionado esto es una migración del plugin Lockifi, escrito por Samuel Rodriguez. Migrar el código a otro lenguaje no era tarea difícil y decidí utilizar Ruby. El objetivo era que se ejcutara de forma sencilla en OS X. La versión deOS Xutilizada en este artículo ha sido El Capitan. Para llevar a cabo la migración se ha utilizado tres archivos más el SDK de Latch para Ruby. Además, debemos disponer de una cuenta de Latch en el área de desarrolladores, lo cual es gratuito. Deberemos crearnos una app dentro del área de desarrolladores. Como se puede ver en la siguiente imagen creamos una app con el nombre Lockifi OS X.
Figura 2: Creación de App Lockifi OS X en el área de desarrolladores
Nos tenemos que fijar en dos valores de la appque se acaba de crear: el Application ID y el secret. Estos valores serán necesarios para que nuestra aplicación Rubypueda comunicarse con Latchy nuestra cuenta de usuario. Pulsando el botón con el icono del lápiz se puede editar y visualizar estos dos parámetros.
Figura 3: VIsualización de Application ID y Secret
Los archivos son los siguientes:
main.rb. Este fichero se encarga de pedirnos un token para parear nuestra appde Latch con nuestra aplicación Ruby. El resultado que devolverá el main.rb es elAccount ID. Este Account ID deberá ser utilizado también por nuestra aplicación Rubypara comunicarse con Latch.
ssh_latches.rb. Este fichero implementa cuatro métodos que podrán ser utilizados para interactuar con Latch. El método statusdevolverá el estado de Latchpasándole el Account ID. El método pairnos facilita el pareo y será utilizado por main.rb. Esta clase se basa en el SDK de Latchpara implementar sus métodos.
ssh.rb. Este fichero implementa la lógica que proponemos para cada X tiempo consultar el estado de Latch y en función de éste habilitar o deshabilitar laWiFiprevia conexión al router.
Paso 1: main.rb
En primer lugar hay que echar un vistazo al código del main.rb. El objetivo es sencillo, un pequeño programa que nos pida un token y haga el paircon la app de Latch. El resultado será el Account ID, si todo va bien.
Figura 5: Código de main.rb
El programa mainnecesita del Application IDy el Secretpara poder llevar a cabo su acción de parear. El método pairestá invocado a través del SDK de Latch. En la imagen se puede ver un pequeño ejemplo de su invocación. Al introducir el token que generamos desde Latch, mainnos devolvería el Account ID que necesitaremos utilizar en ssh.rb.
Figura 6: Obtención del Account ID
Paso 2: Lógica de ssh.rb
El archivossh.rb implementa toda la lógica necesaria para llevar a cabo el control sobre la WiFidel router. La estrategia o algoritmo es sencilla. Mediante la realización de consultas periódicas al estado de nuestro Latchpodremos detectar cuando éste ha cambiado de estado. En el momento que se detecte que se ha cerrado el Latch el fichero ssh.rb lanzará una conexión al routerpor medio del protocolo SSH y "tumbará" la interfaz. El algoritmo quedaría algo como así:
Mientras true Compruebo estado de Latch Si Latch está Abierto Indico que está abierto Levanto la interfaz WiFi del router Si no Indico que se cerrará Apago interfaz WiFi del router Fin Si Fin Mientras
Como se puede ver es un algoritmo realmente sencillo. Haciendo una pequeña prueba antes de crear una aplicación con Automatory configurarla para que arranque al inicio de sesión del usuario. Cuando abrimos el cerrojo de Latch en Lockifi OS Xy visualizamos las peticiones que hacessh.rbobservaremos que nos indica "Open" y la WiFi seguirá operativa.
Figura 7: Lockifi OS X abierto
Para esta prueba hemos mostrado el texto en un terminal bashen OS X. El mensaje es claro, cuando comprueba el estado, cada 20 segundos por ejemplo, y detecta el cerrojo abierto nos indica "Open". Cuando cerramos el cerrojo y la aplicación detecta esto nos indicará "No Open" y llevará a cabo el proceso de deshabilitar la WiFidel routera través de una conexión SSH al dispositivo.
Figura 8: Mensajes que proporciona Lockifi OS X
Antes de pasar al siguiente paso, vamos a hacer hincapié en una zona del código de ssh.rbimportante. Cuando se comprueba el estado de Latchy no se encuentra abierto nos iremos por la rama elsede nuestro algoritmo. Esta parte es realmente la importante, la que deshabilitará a través del routerla posibilidad de conectarnos a nuestra WiFi de casa u oficina.
Observando el código se ve que se crea un objeto SSH cuya configuración para la conexión es la dirección IP del router, el segundo parámetro es el usuario y el tercer parámetro es la contraseña. La conexión por SSH se lanza a través del métodoexec!y ejecuta un ifconfigpara "tumbar" la interfaz WiFi. Hay que tener en cuenta que esto en otros modelos de routerspuede cambiar, pero no la estrategia.
Figura 9: Snippet de código de ssh.rb que deshabilita el WiFi del router
Paso 3: Automatizando la ejecución del programa en OS X
Ahora que tenemos el programa funcional decidimos hacerlo autoejecutable al comienzo de la sesión del usuario. De este modo, cuando nuestro OS X inicie sesión podremos comprobar si queremos que la WiFiesté disponible para otros usuarios o no.
Para llevar a cabo esta tarea utilizamos Automator, el cual viene con OS Xy permite automatizar tareas y flujos de trabajo de manera muy sencilla. El primer paso es arrancar la herramienta, la cual puede ser fácilmente localizada a través de Spotlight. Una vez arrancada debemos elegir, entre sus opciones, "Ejecutar el Script Shell". Esto nos abrirá un recuadro a la derecha dónde podremos escribir un script de shell, por ejemplo para bash.
Figura 10: Creando script de shell para automatizar con Automator
Es importante invocar, dentro del scriptde shell, a Rubycon su path completo. Una vez escrito el scriptse puede probar con el atajo CMD + R. Esto ejecutará el contenido del script. Ahora debemos convertir este scripten una app. Para esto,Automator, proporciona la posibilidad de guardarlo directamente como una aplicación, tal y como puede verse en la siguiente imagen.
Figura 11: Creación de aplicación
Una vez creada la aplicación debemos ir a "Preferencias del sistema" -> "Usuarios" y en este apartado seleccionar "Ítems de Inicio". Aquí podremos añadir, fácilmente, la aplicación generada con Automator, tal y como se puede ver en la imagen.
Figura 12: Adición como Ítem de Inicio
Paso 4: Comprobación final
Ahora, solo falta comprobar que al iniciar sesión se está ejecutando nuestra aplicación correctamente. Para esta prueba dejamos el cerrojo abierto e iniciamos sesión en nuestro OS X. Si tenemos habilitado en nuestra aplicación de Latchque nos avise cuando haya un intento de acceso cuando el Latchesté abierto nos llegará una notificación, como la que se muestra a continuación.
Figura 13: Acceso al servicio Lockifi OS X
Para verificar que nuestra aplicaciónRuby Lockifi OS X está corriendo, lo mejor es abrir un terminal en nuestro OS X y ejecutar, por ejemplo, ps aux | grep ruby. Debemos observar que la instrucción que introdujimos cuando creamos el script de shell con Automatorse encuentra levantada. En este caso se puede ver de forma sencilla y nuestro programa está en ejecución y realizando consultas a Latchpara comprobar si tiene que deshabilitar la WiFio habilitarla.
Figura 14: Comprobación de proceso ssh.rb
En el siguiente artículo realizaremos modificaciones para integrar en casa una Raspberryque levante un punto de acceso WiFi. La Raspberryla conectaremos al routerde casa mediante un cable Ethernet. Nuestro programa no se ejecutará en nuestro equipo, si no que se ejecutará en la Raspberry. Cuando desde la Raspberrynuestro programa detecte que se ha bloqueado el acceso a la WiFi"tirará" la interfaz WiFi. Lógicamente, el routerde casa tendrá que tener deshabilitado la WiFipara que esto tenga sentido. El esquema es sencillo, los usuarios de casa se conectarán al punto de acceso de la Raspberry y está hará forwardingde paquetes hacia el router, el cual nunca tendrá habilitado la interfaz Wireless. Es un esquema con el que cualquier usuario de casa podría desbloquear y bloquear la WiFicon Latch y lo tienes publicado aquí:Bloquear la WiFi con Latch desde Raspberry Pi.
El esquema básico del ataque es el siguiente: si un dispositivo iOSse conecta a una red WiFi, el sistema operativo, regularmente, intenta conectar por NTP para sincronizar su hora. En algunos casos, todo lo que se necesita es spoofear el dominio time.apple.com y en la respuesta de la petición NTP que realice el dispostivio forzar a la fecha 1 de Enero de 1970. En este momento el dispositivo quedará "desahuciado". Los investigadores en Krebs on Security han detallado una prueba de concepto de lo más interesante.
Figura 1: Esquema del protocolo NTP
En la prueba de concepto utilizar una Raspberry para generar el punto de acceso WiFiy luego un cable de red Ethernetpara dar salida a Internet. También se podría utilizar un adaptador 3Gy dar salida a Internet por dicha interfaz. La idea que proponen es juntar la vulnerabilidad del bugde la fecha, junto a la no autenticación del punto de acceso al que te conectas por parte de iOS, es decir, si nuestro dispositivo se encuentra una red WiFique conoce, y que por ejemplo sea abierta, el dispositivo se conectará sin preguntar.
Después, lo comentado, el dispositivo preguntará, de vez en cuando, al dominio de Applepor la hora, por lo que la Raspberrytiene instalado un servidor NTP que spoofearáesas peticiones para devolver la fecha 1 de Enero de 1970.
Instalar y hacer ejecutar un sistema de Apple, por muy antiguo que sea, sobre una plataforma no oficial puede ser algo complejo. En el post de hoy hablamos de cómo una persona ha luchado para lograr correr una Mac OS Clásico sobre una Raspberry Pi. El protagonista de la historia admique el reto no iba a ser algo rápido, pero sí muy divertido. A priori no se puede ejecutar unMac OS en una plataforma como la Pi, pero a día de hoy el hardware de Pi tiene capacidades para hacer funcionar un sistema antiguo.
En el post mencionado anteriormente se puede ver algo del espíritu de Wozy el Apple Iy IIreflejado en la Raspberry Pi. En primer lugar se pensó utilizar un binario precompilado para hacer la emulación de ello en la Raspberry Pi, y todo lo que había que hacer era correr un script. Al final todo se redujo a esto, aunque el periodista tecnológico que ha publicado como instalarlo mostraba sus diferentes problemas. Cuenta como le llevo todo un día el realizar la instalación.
Figura 1: Raspberry Pi arrancando
Utilizando RetroPie y leyendo en el foro de Reddit sobre Vintage Apple se pueden sacar diferentes cosas útiles para esta instalación, tal y como hizo esta persona. Al final dan una serie de pasos para llevarla a cabo de forma exitosa. RetroPie es una colección de hardware emulado con el que se pueden lanzar una serie, una gran colección, de plataformas antiguas. De este modo, todo es mucho más sencillo.
Figura 2: Foro de Reddit sobre Apple Vintage
Esta es una nueva de las cosas Vintage de Apple, la cual no es la primera vez que vemos en Seguridad Apple. Las cosas retro son divertidas verlas ejecutarse en las nuevas arquitecturas, y por ello damos pie a este tipo de posts. Hay que recordar la colección de programas Retro liberados de Apple o un Mac OS 7.5.5 corriendo en un Apple Watch.
Nos acercamos al final de enero y en Seguridad Apple no descansamos para traeros algunas de las mejores noticias en el ámbito de la seguridad informática relacionadas con el mundo de la manzana. Este es nuestro nuevo Fue Noticia, sección en la que os traemos un breve resumen de las noticias más relevantes de las últimas dos semanas. Todo ello aderezado con el mejor contenido de otros sitios de referencia.
El martes 15 os hablamos de la beta 1 de Supercharge, la primera aplicación capaz de crear e instalar tweaks.
El miércoles 23 os avisamos de que Apple ha publicado oficialmente watchOS 5.1.3 e iOS 12.1.3 para iPhone, iPad y Homepod.
