La placa base del prototipo del M68 (Purple 2), más conocido como iPhone o cómo trabajar en un producto sin conocer sus detalles

La historia de cómo Apple desarrolló el iPhone es realmente fascinante. Internamente, el proyecto se llamó tanto "M68" o "Purple 2" y muchos de sus ingenieros no estaban seguros del producto final en el cual estaban trabajando o los que lo sabían, no tenían ni idea de su diseño. No es fácil mantener todos estos secretos dentro de una empresa tan grande desarrollando un producto de estas características. La placa base del prototipo del iPhone M68 es una prueba ellos, donde vemos una plataforma de pruebas, sin dar apenas pistas del diseño final del producto.

Esta placa de desarrollo (de la cual vamos a hablar a continuación), creada para trabajar en el nuevo iPhone, estaba diseñada a conciencia para mantener el secretismo del producto final. Todas las partes del iPhone estaban distribuidas a lo largo de una placa base (parecida a la de un ordenador de hace unos años). En concreto, esta placa base del prototipo del iPhone estaba diseñada sobre todo para los ingenieros que trabajaban en la parte de radio. Muchas veces incluso esta no tenía ni siquiera la pantalla conectada a la placa del prototipo (aunque si tiene salida RCA para video). Este tipo de placa se denomina EVT o Engineering Validation Test. En The Verge han tenido la oportunidad de analizar una de ellas, en concreto esta que se muestra en la imagen:

Figura 1. Placa base del Prototipo del iPhone M68 de 2006/2007. Fuente.

Como antes hemos comentado, en apariencia es como una placa base de un PC. De hecho, muchos de los componentes son los mismos, excepto que no vemos bancos de memoria o ventiladores. Pero en cambio tiene conexión de red, mini USB, Bluetooh, WiFi e incluso un puerto RJ11 (como el de los teléfonos) para probar las llamadas de voz. El resto de componentes ya son más exclusivos y directamente orientados hacia el producto final del iPhone, como por ejemplo un puerto para insertar una SIM o la placa de radio que es exactamente la misma que al final se llevó a producción. 

Figura 2. Detalle de los componentes de la placa base del prototipo del iPhone. Fuente.

En el centro de la placa se observa un procesador ARM a 620MHz (ARM1176JZF) el cual es el encargado de ejecutar el sistema operativo Darwin. Darwin es un sistema operativo basado en UNIX el cual es la base del sistema operativo de todos los macOS, iOS, watchOS, tvOS y audioOS, es decir, todos los productos de Apple. Además es descendiente directo de NeXTSTEP, el sistema operativo que desarrolló Steve Jobs en su empresa NeXT cuando fue expulsado de Apple. La memoria utilizada por este procesador ARM es de la marca Samsung modelo K9HBG08U1M de 4GB tipo NAND, la cual se puede apreciar en el centro de la placa con el color verde. 

Figura 3. Algunos detalles de la placa base del prototipo. Fuente.

Impresiona ver la cantidad de puertos de expansión y conexión que tiene la placa de desarrollo, uno de los mayores terrores de Steve Jobs ;). Vemos conectores tipo JTAG los cuales se utilizan para debugging a bajo nivel, incluso a nivel de señales y voltajes para ver cómo reaccionaría el prototipo bajo estas circunstancias. También hay varios microinterruptores (dip switches) y además de los puertos que y hemos mencionado antes, no falta el clásico puerto serie RS232. 

Figura 4. Placa de prototipo del iPhone 4. Fuente.

Apple ya no utiliza placas bases de este tipo para sus desarrollos, las de ahora son más pequeñas como la que aparece en la figura 4. El motivo es que de esta forma, al ser más pequeños, es posible introducir toda la electrónica dentro de una caja y así no ver el diseño final (además de ocultar mejor sus características). De todas formas, este prototipo de iPhone es una joya de la historia de la informática que nos enseña un poco mas ese trabajo en secreto que desarrollan empresas como Apple, la cual depende mucho del diseño del producto final.

El primer servidor de la Word Wide Web y todo su desarrollo se creó en un ordenador diseñado por Steve Jobs

El pasado martes día 12 de marzo se celebró el día de la World Wide Web justo en su 30 aniversario. Antes de la creación de la www navegar por internet era más bien un mar de BBS, FTP, etc. Pero todo cambió cuando Tim Berners desarrolló en las oficinas el CERN el HTML (HyperText Markup Language), HTTP (Hyper Text Transfer Protocol) y las URL (Uniform Resource Locator). Pero además, todo el trabajo lo hizo en un NexTCube, un ordenador diseñado por Steve Jobs.

Ya hemos hablado en alguna ocasión que Jobs fue forzado a abandonar Apple en 1985 y ese mismo año creó la empresa NeXT. Estas nuevas estaciones de trabajo (estaban orientadas más al mundo empresarias, científico y de diseño que al uso personal) tenían unas caracteríticas hardware realmente interesantes para la época pero la estrella de la empresa era sin duda su sistema operativo, el NeXTSTEP, el cual más adelante se convertiría en la base del sistema operativo actual de Apple , el macOS.

Figura 1. NeXTSTEP GUI. Fuente.

Jobs puso toda su energía en NeXT para crear el ordenador de sus sueños sin ningún tipo de limitación. Además, para lograrlo, se llevó a muchos ingenieros de sus confianza que aún trabajaban en Apple, como por ejemplo a Rich Page, creador de todo el hardware del ordenador, anteriormente director del equipo que había creado el ordenador Lisa. Los equipos eran bastante caros (con un precio incial de unos 6.500$ por unidad) por lo que no era un ordenador para comprar un usuario medio pero sí era perfecto para universidades y el mundo académico en general.

Mike Sendall, jefe en esa época (1989) de Tim Berners Lee adquirió un ordenador NeXTCube para evaluar si era un buen ordenador para su departamento en el CERN. Berners Lee ya había presentado su proyecto llamado WorldWideWeb pero necesitaba un buen entorno de desarrollo para crear una prueba de concepto. El sistema operativo NeXTSTEP destacaba frente al resto gracias a su gran cantidad de herramientas de programación y desarrollo disponibles. Esto era justo lo que necesitaba para empezar a programar.

Figura 2. Paper original de Tim Berners Lee. Fuente.

En noviembre de este mismo año sería cuando por fin se ejecutaría el primer programa cliente-servidor basado en la teoría desarrollada por Tim Berners Lee. El primer servidor web había nacido (aunque de momento era un servicio interno) y se había ejecutado en un ordenador con alma de Apple, el NeXTCube, el cual sería muy popular en el CERN gracias a la pegatina que decía "Esta máquina es un servidor. NO LO APAGUES". No sería hasta 1991 cuando por fin se publicaría online el primer sitio web de la historia: info.cern.ch (también ejecutado en un NeXT). La primera página web de la historia aún se puede visitar: http://info.cern.ch/hypertext/WWW/TheProject.html

Figura 3. NeXTCUBE utilizado por Tim Berners Lee con la famosa pegatina "Esta máquina es un servidor. NO LO APAGUES". Fuente.

NeXT se fusionó con Apple cuando Steve Jobs volvió a Apple en 1997, adquiriendo todos los productos que se habían completado durante su corta vida como empresa independiente. Las palabras de Tim Berners Lee sobre el ordenador NeXT y su sistema operativo avalan la buena fama de este ordenador para la historia: "The NeXT era brillante. Tenía gran cantidad de nuevas caracteristicas como sistema óptico de almacenamiento (CDROM), Objetive C, DSP para el sonido, Mach kernel, Unix, Postscript, InterfaceBuilders, etc.". El ordenador se puede ver en el Museo de la Ciencia de Londres.

Estos son algunos de los problemas que ha tenido Apple relacionados con la seguridad de los usuarios

Cuando hablamos de Apple sabemos que una de sus principales características es la seguridad, sin embargo con el incremento del malware con Apple como objetivo se ha  demostrado que en muchas ocasiones los productos de Apple no son tan seguros como aparentan. Un hábito común que demuestra nuestra "ignorancia" en este aspecto es cuando tapamos la webcam de nuestro ordenador portátil y no lo hacemos con la cara frontal de nuestro iPhone, si lo pensamos bien, nuestro teléfono móvil nos acompaña durante más horas a lo largo del día y a sitios en los que nuestra intimidad se puede ver mucho más comprometida. Aquí teneis algunos ejemplos de ello.

1. Brecha en el centro de desarrolladores: En este caso los afectados no fueron los usuarios de dispositivos Apple, sino su propia comunidad de desarrolladores. Durante 2013 un grupo de hackers atacaron el centro de desarrolladores de Apple comprometiendo el nombre, direcciones y correo electrónico de miles de desarrolladores. Mientras solucionaba el problema Apple decidio desactivar temporalmente su página de desarrolladores. Pocos meses después se supo la compañía fue avisada por el investigador Ibrahim Balic de su brecha de seguridad, sin embargo este fue ignorado con terribles consecuencial para Apple.                                                      



Figura 1: Apple deshabilita su página de desarrolladores temporalmente

                                                                                                                                               
2. Hack de iCloud con filtraciones de las celebrities: Apenas un mes antes del lanzamiento del iPhone 6 se filtraron fotografías intimas de al menos 500 celebrities, este leak recibió el nombre de The Fappening y fue posible debido a una mala configuración. Los ajustes por defecto en los iPhone hacían que al sacar una fotografía automáticamente se almacenase una copia en el servidor de iCloud. La duda entre la fuerza bruta y la no restricción de intentos y el engaño a las víctimas mediante ingeniería social produjo, seguramente, este incidente. Ya hemos hablado mucho sobre este tema en el blog. Nuestra opinión, es que el engaño a la víctima fue claro y la fuerza bruta no tuvo que ver.                                                                                                                                         
   

   

   Figura 2: Vulnerabilidad crítica de High Sierra

    
3.  La vulnerabilidad crítica de High Sierra en 2017:  Con el lanzamiento de MacOS High Sierra se descubrió un fallo de seguridad crítico que permitía acceder a cualquier equipo bloqueado sin necesidad de introducir una contraseña. El co-fundador de CraftBase, Lemi Orhan Ergin descubrió que introduciendo el texto “root” en el campo de usuario y dejando el campo de la contraseña en blanco era posible acceder al equipo, sin duda un fallo crítico y que dio mucho de lo que hablar.

Integración de Latch en la TouchBar del MacBook Pro

En este blog hemos hablado en varias ocasiones sobre Latch y las distintas implementaciones y servicios que ofrece para nuestros dispositivos Apple. En esta ocasión vamos a presentaros la integración de Latch en la Touchbar de los nuevos MacBook Pro. Esta pequeña aplicación hace uso de la librería de Latch para Swift creada para el modulo de Exfiltración multiplataforma, que recoge una serie de métodos para controlar la sincronización, consulta y modificación de cerrojos. Así que en este post explicaremos como configurar el proyecto para hacerlo funcionar en cualquier Mac con TouchBar. 

Creación de cuenta de Latch

En primer lugar tenemos que crear una cuenta en el Developer Area de Latch. Una vez hecho, nos dirigiremos al apartado de Mis aplicaciones para añadir una nueva aplicación. Procederemos a rellenar los datos y guardaremos el ID de aplicación y el Secreto. Todos estos pasos están detallados la entrada del blog sobre como instalar y configurar Latch para proteger macOS.  

Figura 1: Aplicación de Latch del Area de Desarrolladores

Descarga e instalación

Con la aplicación Latch creada, tendremos ahora que descargar el proyecto de Github y abrirlo en XCode. A grandes rasgos el proyecto consta de dos partes:

• El controlador de la ventana principal, con un SegmentedControl sincronizado a una variable para controlar el estado y una ventana para realizar el proceso de enlace con Latch. 
•  El delegado de la Touchbar con un SegmentedControl sincronizado a la misma variable del segmento de arriba. Con esto conseguiremos que ambas interfaces estén sincronizadas en todo momento.

Por otro lado tenemos un objeto de la librería de Latch en Swift con el que controlaremos nuestra aplicación Latch y podremos realizar el proceso de enlace. Ya solo queda colocar el Application ID y el Secret en las constantes APP_ID y APP_SECRET, ejecutar la aplicación desde XCode e introducir el token generado en Latch para sincronizar el proyecto y poder tener operativo Latch en la TouchBar.

Figura 2: Proyecto en XCode

PoC: Jugando con la Touchbar

Por último vamos a mostrar una prueba de como funciona el proyecto. En el video podemos ver la aplicación Latch para iOS ejecutándose en un iPhone junto a el emulador de la TouchBar. Al haber introducido previamente el token de sincronización el cuadro de dialogo para introducirlo estará oculto. Al iniciar la aplicación, el estado del SegmentedControl se sincroniza con el estado de Latch y a partir de ese momento, al cambiar de estado en los botones de la TouchBar cambiará también el estado del cerrojo de nuestra aplicación.

Apple libera la API de Apple Health para los desarrolladores

A la vez que se ha desarrollado la Worldwide Developers Conference (WWDC), conferencia en la que Apple tiene una importante participación, la empresa de la manzana ha anunciado en su página web que ha abierto la API de su aplicación de salud para los desarrolladores. Durante este año Apple lanzó Health Records, una aplicación en la que se unifica la información de los hospitales y clínicas cercanas con la ya existente aplicación de salud de iOS. El fin de esta nueva app es facilitar a sus clientes la gestión de sus datos médicos y ofrecerles un mayor control sobre su medicación o alergias.

Health Records, que trabaja conjuntamente con más de 500 hospitales y clínicas utilizando rápidos recursos de interoperabilidad de asistencia médica, es capaz de ofrecer a los pacientes la información encriptada relativa a sus tratamientos directamente en su teléfono móvil. Al liberar esta API para los desarrolladores, Apple ofrecerá la posibilidad de desarrollar aplicaciones de terceros que interactúen directamente con Health Records. Por lo tanto, si los usuarios lo deseen podrán optar por compartir su información médica con aplicaciones de confianza que hagan un seguimiento u ofrezcan recordatorios acerca de las medicaciones o dietas de los pacientes.

Figura 1: Aplicación de Apple health.

“Con la API de Heath Records abierta a nuestra increíble comunidad de desarrolladores e investigadores, los consumidores podrán personalizar sus necesidades médicas con las aplicaciones que utilicen a diario” Ha dicho Jeff Williams, Chief Operating Officer de Apple.

En términos de seguridad, los datos relativos a Apple Health se encuentran cifrados en el dispositivo de cada usuario y se encuentran protegidos por una contraseña. Además los usuarios tendrán que aceptar una petición a la hora de compartir su información con cualquier aplicación de terceros. La información recopilada por la aplicación de Apple Health nunca será almacenada en los servidores de Apple, sin embargo puede que si se almacene en los de las aplicaciones que trabajen conjuntamente con ella.

Apple hizo pasar por Internet Explorer su navegador Safari para mantenerlo en secreto

En la famosa MacWorld Expo celebrada en Boston en 1997, un renacido Steve Jobs (que acaba de volver triunfante a su querida Apple) anunciaba una serie de acuerdos con Microsoft, centrados sobre todo en el uso de patentes y la implementación de Office para Mac. Este vídeo ya lo conocéis por su parte mítica donde aparece Bill Gates ante el estupor y rabia de todos los asistentes. Lo que no es tan conocido es que allí también se presentó al público la incorporación de Internet Explorer al mundo Apple.

Antes de 1997, los ordenadores Apple tenían como navegador oficial Netscape y Cyberdog. Gracias al acuerdo que hemos comentado antes y que se presentó en la MacWorld Expo de Boston, a partir de la versión Mac OS 8.1. en adelante y durante cinco años, Internet Explorer sería el navegador oficial de Apple. Finalmente, en 2003, en la MacWorld Expo de San Francisco, se presentó la primera versión de Safari, el navegador propio de Apple. Vamos a ver un poco de su interesante historia.

El 25 de junio de 2001, un empleado de Apple llamado Don Melton fue asignado como encargado de formar un equipo para trabajar en un nuevo proyecto alto secreto de Apple: un navegador web. El desarrollo era totalmente alto secreto, hasta el punto que sólo los que formaban parte del proyecto sabrían exactamente el objetivo del mismo. Pero cuando Apple contrató a Dave Hyatt (co-creador de Firefox) el cual era una eminencia en el mundo de los navegadores web por crear el navegador Chimera o  también denominado Camino (el cual estaba basado a su vez en el motor de Mozilla Gecko), comenzaron los rumores y especulaciones sobre el nuevo proyecto de Apple. Las dos especulaciones más comentadas eran que Chimera sería portado oficialmente a Mac (aunque ya funcionaba bajo esa plataforma).

Figura 1. Navegador Chimera / Camino. Fuente.

Internamente en Apple, el proyecto del nuevo navegador se conocía con el nombre de "Alexander" ó "iBrowser". Finalmente, después de muchas reuniones el nombre final fue Safari. Durante su desarrollo, una de las principales preocupaciones de Don Melton era que se filtrara el proyecto y echara al traste el factor sorpresa, incluso obligaban bajo juramento a no revelar nada del proyecto. Era importante que Apple se independizara con su propio navegador lo antes posible. Para conseguir que todo el desarrollo se mantuviera en secreto, una de las claves era no revelar ninguna pista de los servidores web que estaban utilizando, como por ejemplo la cadena "User-Agent" o las direcciones IP. Era importante falsear esta información para que nadie pudiera seguir alguna pista cuando se analizaran los logs de acceso a sus servidor web.

Como antes hemos mencionado, Apple tenía un acuerdo desde 1997 para utilizar Internet Explorer, entonces ¿qué puede ser mejor que hacerse pasar por este navegador para despistar a los administradores de los sitios web que estaban visitando?. En cambio, había ciertas pruebas que tenían que usar la cadena "User-Agent" de Safari en vez de las de Internet Explorer. Para este tipo de pruebas, el plan era utilizar dicha cadena sólo cuando se encontraran fuera del campus o mejor dicho, cuando las pruebas se realizaran en ordenadores que no tuvieran la dirección IP de Apple (cualquier IP de clase A que empiece por "17.X.X.X" pertenece a Apple). De esta forma no se podría relacionar el "User-Agent" de Safari con Apple.

Safari no se creó desde cero, se basó en motores de renderizado Open Source como KHTML y KJS, el motor Konqueror, base del navegador web de KDE. En la MacWorld del 7 de Enero de 2003, por fin se presenta Safari a un público entregado (aunque se quedaron mudos cuando Steve Jobs explica que está basado en KHTML). La presentación de Safari comienza en el minuto 54:10 del siguiente vídeo:

Un gran detalle que tuvo Don Melton fue enviar un correo durante la MacWorld de presentación de Safari a la lista de desarrollo de KDE, agradeciendo el gran trabajo que habían realizado con KHTML y KJS. También anunció que publicarían todas las mejoras y cambios que habían realizado al motor, las cuales fueron incorporadas de inmediato a KDE.

XCodeGhost: Un malware que infecta las apps en XCode

Los creadores de malware han dado un paso más allá en la infección de las apps para iOS y OSX, infectando directamente los archivos del instalador de XCode que estaba alojado en los servidores de Baidu, en China. A este malware se le ha llamado XCodeGhost. El objetivo es bastante sencillo, conseguir que cuando una nueva aplicación sea creada para iOS o para OSX con uno de estos compiladores infectados, la app irá infectada desde su creación, subiendo después a la App Store o a la Mac App Store. Y no han sido pocas las apps afectadas ni los usuarios.

En total son 76 apps las que se han detectado infectadas con este malware, y entre ellas se encuentra alguna tan popular como WeChat Messenger, por lo que se estima que hay millones de usuarios afectados por este malware, y que podría haberse utilizado en muchas operaciones.

Figura 1: Código malicioso de XCodeGhost

Por supuesto, tal y como se ha explicado, al manipularse la app directamente desde su creación, no es necesario que el dispositivo que se va a infectar tenga realizado el jailbreak, ya que el creador de la app firmará el código malicioso y lo subirá firmado a AppStore. Una nueva vuelta de tuerca en el mundo del malware.

DrupalCamp 2015: Mundo Drupal en Jerez de la Frontera

22 al 24 de Mayo en Jeréz de la Frontera

Este año hay una cita del 22 al 24 de Mayo de 2015 en Jerez de la Frontera. Los amantes de Drupal esperan la cita que juntará a grandes expertos en la materia. El mundo del desarrollo y de la seguridad van de la mano, y por ello la organización ha escogido algunas charlas que hablarán de cómo proteger estos entornos. Nuestro compañero de Eleven Paths Ricardo Martín impartirá una charla sobre los peligros que acechan a la identidad digital y cómo protegerla en Drupal con nuestra solución Latch. 

Ricardo hablará de amenazas y vulnerabilidades que pueden afectar gravemente al uso de nuestra identidad digital en Internet, centrándose en entornos como Drupal. Desde Eleven Paths hemos realizado videos dónde se puede ver lo sencillo que es la integración de nuestra solución de seguridad para proteger plataformas Drupal con Latch en 10 minutos.

Figura 1: Proteger plataformas Drupal con Latch en 10 minutos

La agenda del evento contará con ponentes destacados como Tobias Stöckler, Jorge Galindo o Cathy Theys además de nuestro compañero Ricardo Martín. Durante el evento el asistente contará con diferentes habitaciones dónde podrá elegir el tipo de charla a la que quiere asistir. En el sitio web del evento se puede encontrar información sobre el nivel de dificultad que plantea cada charla, por lo que te lo ponen fácil para ajustarte al nivel de cada temática. Por si quieres ir probando Latch en Drupal, aquí te dejamos la guía de integración.

Figura 2: Guía de integración de Latch Drupal 7 español

Si quieres pasar un fin de semana acompañado de buenas charlas, buen vino y buena comida no dudes en asistir a Drupal Camp 2015 en Jerez de la Frontera. ¡No te lo pierdas!

Visual Studio Code para OS X: ¿Una FOCA para OS X?

Microsoft ha dado a conocer a través de su famosa conferencia Build su primera versión de Visual Studio para Mac y Linux. La nueva herramienta ha tomado el nombre de Visual Studio Code y hace que desarrollar código .NET, junto a otros muchos lenguajes, sea fácil hoy día en sistemas basados en OS X y Linux. De este modo Visual Studio se convierte en un entorno multiplataforma con el que seguro llegará a mucha más gente. 

En Build Microsoft habló de la ligereza y flexibilidad que tiene Visual Studio Code. Integración con Git y soporte completo Intellisense. Microsoft ya la ha puesto disponible para que sus usuarios puedan descargarla y ejecutarla en los entornos como OS X. En la imagen se puede visualizar el uso de Visual Studio en OS X y el uso de código .NET.

Figura 1: Visual Studio Code y .NET

Microsoft empieza a tener en cuenta la cuota de mercado de Apple y otros sistemas Linux, y empieza a ver la necesidad de la globalidad. Con este movimiento conseguirán llegar a muchos más developers, quizá una decisión en la que todos salen ganando, ya que muchos devs podrán utilizar la tecnología .NET en entornos antes prohibidos.

Figura 2: Una FOCA corriendo en SUSE Linux sobre Wine ¿Quieres una FOCA en OSX?

La verdad es que a nosotros en Eleven Paths, que contamos con muchas herramientas escritas en .NET, como son FOCA o Evil FOCA, nos abre la posibilidad de hacer compilaciones para Linux - donde ahora sólo se consigue con Wine - y OS X. Veremos si somos capaces de adaptar estas aplicaciones a nuevos entornos.

Aprende Sinfonier Project los días 16 y 17 de Abril en Jaén y gana un MacBook Pro, un iPhone o un iPad Air

Tras su participación en eventos por todo el mundo, el grupo de personas que está detrás de Sinfonier Project hará una parada en la Escuela Politécnica Superior de Jaén los días 16 y 17 de Abril con el Hackathon “Desfragmentando la Identidad”. Este evento organizado por Telefónica, la Escuela Politécnica Superior, la Universidad Jaén, y la Sociedad Española de Procesamiento del Lenguaje Natural pretende ser un punto de encuentro para la generación de inteligencia a través de fuentes abiertas de información utilizando las topologías de Sinfonier.

Durante estos dos días, expertos y apasionados de la seguridad se darán cita para conocer este proyecto abierto que pretende democratizar el procesamiento de datos en tiempo real. Para ello, se plantearán diferentes objetivos enfocados al diseño y desarrollo de módulos y topologías que aporten soluciones óptimas relacionadas con el problema de la “Atribución” en base a la información de las identidades digitales.

Objetivos del hackathon

• Obtener información de identidades digitales a través de técnicas de scraping.
• Identificar identidades digitales asociadas al mismo sujeto.
• Establecer relaciones entre los perfiles de diferentes for.

Requisitos de los/as participantes:

• Conocimientos de desarrollo en Java y/o Python.
• Inquietudes en el ámbito de la ciberseguridad y del procesamiento de información en tiempo real.
• Ganas de pasarlo bien.

Como novedad para este evento el equipo de Sinfonier ha preparado un entorno de desarrollo para facilitar aún más el desarrollo sobre la plataforma. Conscientes de la necesidad de tener un entorno agíl durante eventos de este tipo por un lado y un entorno que permita una depuración sencilla y profunda la comunidad de Sinfonier se puso manos a la obra. Durante unas semanas Gaspar Muñoz, miembro y parte del equipo que hizo posible el nacimiento del proyecto, trabajó en un entorno de pruebas donde poder realizar pruebas unitarias a los diferentes módulos que se crean en Sinfonier.

Figura 1: Github de Sinfonier Project

Para ello Gaspar creó un entorno que simula la ejecución de una topología y que permite definir tanto los parámetros de entrada de un módulo como la información que va a recibir durante su ejecución. Además una vez se produce la ejecución, haciendo uso de la librería JUnit, es posible escribir una serie de test unitarios para validar que la ejecución ha sido correcta.

Figura 2: Ejemplo de código de Sinfonier

El proyecto creado por Gaspar se presentó en el último MeetUP que se realizó el mes de Marzo de este mismo año y con ese trabajo como base el equipo ha creado una maquina virtual que contiene todo lo necesario para comenzar a trabajar en ese entorno de desarrollo. La maquina virtual, distribuida en formato .ova, contiene una distribución de eclipse con los plugins necesarios para trabajar con Maven y los repositorios GIST de Github (que iremos ampliado con documentación y todos los recursos que vayamos teniendo disponibles). Lo que permite a los usuarios de Sinfonier poder desarrollar sus módulos, probarlos de forma exhaustiva y al finalizar la fase de desarrollo crear con un simple clic un repositorio GIST con el que poder crear el módulo en el portal de Sinfonier.

Si eres alumno de la Escuela Politécnica Superior de Jaén y crees que esto es para ti registrate. Si no eres alumno y también crees que esto es lo tuyo, puedes pedir acceso a la comunidad y estar a atentos a nuestro próximos eventos para participar en alguno de nuestros múltiples retos que se realizarán en España y en otros países s lo largo del año. Además, como en cualquier concurso las tres mejores soluciones al problema planteado obtendrán Premio. Un MacBook Air, un iPhone o un iPad Air pueden ser tuyos. Apúntate!

Apple ha liberado iOS 7.1 beta 4 para los desarrolladores

Parece que es en Marzo cuando Apple tiene pensado liberar la nueva versión del sistema operativo iOS 7.1 así que está agilizando la salida de las versiones beta para los desarrolladores. Hace un par de semanas estaba disponible iOS 7.1 beta 3 y ya tenemos la nueva versión del sistema operativo con código de compilación 11D5134c.

Figura 1: iOS 7.1 beta 4 disponible en la web de developers

Esta versión no viene sola, y Apple ha liberado también XCode 5.1 beta 4 con número de compilación 5B90f, lo que es más que lógico si ha cambiado alguna función en el sistema operativo que necesita estar disponible en la herramienta para desarrolladores.

Figura 2: XCode 5.1 beta 4 disponible en la web de developers

En las versiones anteriores de iOS 7.1 parece que había problemas con con el envío de mensajes, la pila de conexión Bluetooth y las aplicaciones de 32bits no funcionaban bien en los dispositivos de 64bits. Por su parte, XCode también ha corregido un buen número de fallos que había sido reportados. En cualquier caso, sobre los bugs de seguridad que han sido arreglados, y si se parcharán los explotados por evasi0n7, la herramienta que permite hacer jailbreak, aún no se sabe nada, así que habrá que esperar hasta marzo para conocer más detalles sobre la nueva versión iOS 7.1

FileMerge: Automatizar el proceso de comparar de archivos

FileMerge es una de esas herramientas que todo administrador de sistemas o desarrollador de software debería tener en su cajón de herramientas, ya que a menudo tenemos la necesidad de comparar varios archivos con distintas versiones para ver los cambios que podemos tener. Ver las pequeñas diferencias entre dos archivos de texto con distintas versiones no es algo rápido, por lo que utilizar herramientas como FileMerge ayudará y mucho. En muchas ocasiones utilizamos scripts con pocos centenares de líneas, pero cuando utilizamos código con miles de líneas la cosa empieza a coger complejidad. 

¿Dónde conseguir FileMerge?

FileMerge es una de las herramientas que vienen con el disco de instalación de Mac OS X, y se instala conjuntamente a Xcode y todo el entorno de desarrollo de Mac OS X. En otras palabras, la tenemos al alcance de la mano, pero por defecto no viene instalada.

Figura 1: Comparar archivos con FileMerge

Una vez tenemos Xcode instalado podemos arrancar la herramienta e interactuar con la interfaz de File Merge. Esta interfaz es realmente intuitiva como se puede visualizar en la imagen. Simplemente interactuando con el diálogo de selección de archivo o arrastrando directamente un archivo al cuadro izquierdo o derecho quedarían seleccionados. Por último, pinchando sobre "Compare" se realiza la comparación de archivos, y unos segundos obtenemos las dos versiones de los ficheros con sus diferencias marcadas y bien diferenciadas.

Figura 2: Diferencias entre archivos

Se ven dos partes diferencias, la izquierda corresponde con un fichero y la derecha con la otra versión. Las diferencias quedan marcadas en ambos lados. Además, se ofrece al usuario un recuento de diferencias, como dato interesante. Como hemos podido ver, es realmente intuitivo el uso de esta herramienta, totalmente gráfica. La comparación de archivos ya no es una ardua tarea cuando superan las miles de líneas de código. Si quieres aprender más de XCode, puedes leer el libro de Desarrollo apps para iOS.

HP: El 90% de las aplicaciones iOS tiene vulnerabilidades

El informe que la empresa HP ha presentado sobre las pruebas de seguridad que han realizado a más de 2000 aplicaciones móviles de iOS ha destapado un secreto a voces, o lo que muchos ya sospechaban desde el boom del mercado de desarrollo móvil. Las apps que se han utilizadas de prueba tienen un uso comercial por unas 600 grandes empresas en 50 países. El informe muestra que 9 de cada 10 aplicaciones, es decir, un 90% tenían serias vulnerabilidades. Mike Armistead, vicepresidente y gerente general de HP, dijo que las pruebas se realizaron en 22 categorías distintas de Apple Store, con el foco puesto en herramientas que son utilizadas en business to business, como la banca o el comercio minorista.

HP explicó que el 97% de estas aplicaciones acceden a fuentes de información privadas de manera inapropiada dentro del propio dispositivo, y que el 86% resultó ser vulnerable a los ataques de inyección SQL. Este hecho es algo revelador para el desarrollo móvil, ya que parece que se está generando en grandes cantidades y realizando de manera inadecuada. Las guías de desarrollo de Apple pueden ayudar a los desarrolladores, pero esto no es suficiente para fortificar las aplicaciones, según comento Mike Armistead.

Las aplicaciones móviles están siendo utilizadas para extender la web corporativa en muchos de los casos, y lo que se está logrando es que las empresas abran una mayor superficie de ataque, comentó Armistead. No hay que irse muy lejos, para constatar esta realidad, y hace poco contábamos por aquí la presentación de Alejandro Ramos donde mostraba demostraciones prácticas de apps inseguras para iOS.

Figura 1: Facebook Recover explota el almacenamiento de sesiones inseguras

En su resumen de las pruebas, HP dijo que el 86% de las aplicaciones probadas carecía de los medios para protegerse o fortificar las vulnerabilidades comunes, tales como el uso indebido de las API de cifrado, Cross-Site Scripting y transmisión insegura de datos. El 75% de las aplicaciones no utilizaron técnicas de cifrado adecuadas para el almacenamiento de datos en los dispositivos móviles, lo que deja los datos no cifrados al alcance de un potencial atacante. Un porcentaje alto de las aplicaciones no implementaban SSL/HTTPS correctamente, pero ¿Cómo descubrían los desarrolladores los agujeros de seguridad? Los desarrarrolladores realizaban pruebas de penetración, pentesting. 

La necesidad de desarrollar aplicaciones móviles de forma rápida para fines de negocios es uno de los principales factores que contribuyen y dan lugar a la debilidad de estas aplicaciones disponibles para su descarga pública. La debilidad que constituye el lado del cliente, está impactando en el lado del servidor también. "Creemos sinceramente que el ritmo y el costo de desarrollo en el espacio móvil ha obstaculizado los esfuerzos de seguridad", dice HP en su informe. Además, "La seguridad de aplicaciones móviles está todavía en su infancia" añadieron.

Si quieres tienes un libro de desarrollo de apps para iOS que enseña buenas prácticas de desarrollo, y además tienes esta conferencia para aprender buenas prácticas con ejemplos.

Demos prácticas de fallos de seguridad en apps para iOS

En una reciente conferencia sobre seguridad realizada en la Universidad Europea de Madrid, Alejandro Ramos (@aramosf) impartió una conferencia con demostraciones de fallos de seguridad en apps diseñadas para sistemas iOS. La presentación completa la tenéis en SlideShare, y lleva incluidos los vídeos de todas las demostraciones, con lo que se pueden ver no sólo las explicaciones, sino paso a paso los vídeos.

Figura 1: Ejemplos de seguridad en aplicaciones moviles (IOS)

La presentación primero sitúa las vulnerabilidades siguiendo el OWASP Mobile Top Ten Security Risks , para explicar cada una de las demostraciones. Este proyecto, al igual que el OWASP Top Ten que recoge las vulnerabilidades más explotadas en aplicaciones web, cataloga cuáles son los 10 riesgos de seguridad más importantes en las apps diseñadas para dispositivos móviles, y en esa sesión se aplica a las apps desarrolladas para iOS.

Ejemplo 1: App de CINESA

El primer ejemplo es con la app del grupo CINESA destinada a gestionar los puntos de fidelización. En ella, la vulnerabilidad que tiene lugar es que el envío de credenciales de acceso es totalmente inseguro, al enviarse usuario y contraseña por parámetros GET, sin codificación alguna y sin hacer uso de HTTPs. Esto hace que cualquier conexión en una red compartida deje las URLs con los datos de acceso al alcance de cualquiera.

Figura 2: Vídeo de la demostración sobre la app de CINESA

Ejemplo 2: App Runkeeper

El segundo ejemplo que se mostró es con la app Runkeeper, destinada a quienes quieren compartir sus logros deportivos con el resto del mundo. Esta app tiene activado el uso del Apple System Log para el envío de la información de debugging, y entre otra información envía el token OAuth que se utiliza para publicar en Twitter, es decir, cualquier otra app del sistema podría robar este valor y usarlo para publicar twitts con él y hacer spam.

Figura 3: Vídeo demostración sobre la app de Runkeeper

Ejemplo 3: Juego Dark Nebula

En este caso el juego solo desbloquea niveles cuando se han superado las anteriores, pero los niveles se almacenan en local, con lo que es posible manipular el nivel en que se encuentra un jugador, y por supuesto su puntuación.

Figura 4: Demostración con la app del juego Dark Nebula

Ejemplo 4: App de Dropbox

Este ejemplo de almacenamiento inseguro ya lo habíamos publicado por aquí, ya que se trata del PIN de Dropbox que bloquea el acceso a la app. Este PIN está guardado en texto plano y cualquiera puede leerlo y acceder a él.

Figura 5: PIN de la app de Dropbox para iOS almacenado en un plist

Ejemplo 5: Robo de sesión de la app de Facebook

Este caso se debe a que la app de Facebook para iOS almacena cookies persistentes con información de la sesión de usuario. Esto permitiría a cualquier persona con acceso al terminal o al backup, robar una sesión de Facebook. Esto se explica en detalle en el libro de Hacking iOS: iPhone & iPad, y se ha publicado la aplicación Facebook Recover que permite hacer esto con un simple botón.

Figura 6: Facebook Recover

Ejemplo 6: App de cifrado MobiSafe

Esta app permite a un usuario cifrar las fotos con un cifrado robusto, pero el PIN que cifra y descifra las fotos es de solo 4 dígitos y se almacena en formato MD5 dentro de una base de datos SQLite, lo que permite a cualquiera con acceso desproteger cualquier fotografía.

Figura 7: Vídeo demostración con la app MobiSafe

La charla fue muy instructiva y una llamada para la atención a los desarrolladores de apps para iOS. En el libro de Desarrollo iOS: iPhone & iPad se tocan muchos de estos temas para evitar este tipo de errores tan habiutales. 

XCode 5.0: Soporte final de iOS 7 y un serio CVE en GIT

Con el lanzamiento de iOS 7 también Apple ha tenido que actualizar XCode a la versión 5, para dar soporte final a todas las APIs del nuevo sistema operativo. La nueva versión está disponible desde Mac App Store y tienes más información de ella en la web de desarrolladores. Pero además de dar soporte completo a iOS 7, esta nueva versión viene con el Security Advisory APPLE-SA-2013-09-18-3 Xcode 5.0 en el que se informa de la solución del CVE-2013-0308 en GIT, que permite a un atacante hacer un ataque de red man in the middle con cualquier certificado y robar las credenciales de Apple ID.

Según se explica en el informe del Security Advisory, cuando se usa la función imap-send, el motor de GIT no verifica que el hostname del certificado digital X.509 corresponda con el nombre de dominio.

Figura 1: Bug CVE-2013-0308 en GIT parcheado en XCode 5.0

Así, en esta nueva versión de XCode 5.0 se ha actualizado la versión de GIT a la 1.8.3.1 que soluciona este problema, por lo que si desarrollas en un entorno de red, te recomendamos que actualices lo antes posible. Si quieres aprender a desarrollar apps en iOS, tienes más información en el libro de Desarrollo de apps para iOS: iPhone & iPad.