Oracle actualiza Java SE 7 Update 7 para Mac OS X

Después del caos que estamos sufriendo con el bug CVE-2012-4681, Oracle ha puesto una actualización de Java SE 7 Update 7 a través de un advisory de seguridad en la que soluciona por fin el bug. Para Mac OS X, si tienes instalada esta versión, deberás entrar el panel de Preferencias de Java y tendrás disponible la actualización.

Figura 1: Actualización Java SE 7 Update 7 disponible para Mac OS X

Tiene 50.2 MB de tamaño, y se descarga directamente desde el panel, con lo que su aplicación es rápida.

Figura 2: Notas de la versión e instalación directa

Desde Seguridad Apple os urgimos a que actualicéis cuanto antes Java en vuestro Mac OS X si habíais instalado Java SE 7, ya que es de alto grado de peligrosidad este bug, debido a la cantidad de sitios explotándolo.

Exploit CVE-2012-4681 funcional en OSX Mountain Lion

Hace unos días saltó la noticia de la aparición de un 0day en la última versión de Java SE 7, la cual a día de hoy sigue sin ser parcheada por Oracle, y de la que había disponible un exploit público utilizándose en Internet masivamente. Para conocer de primera mano el funcionamiento de este bug hemos querido probarlo en OS X Mountain Lion 10.8.1. Para la prueba de concepto se ha utilizado Metasploit Framework, con el que es fácilmente configurable  la realización de la explotación.

Para configurar el módulo con nombre java_jr17_exec se debe especificar el puerto de escucha dónde se colocará el servidor, el payload que se quiere utilizar y la dirección a la que se conectará éste si la conexión es inversa. En la siguiente imagen se puede visualizar como quedaría configurado el módulo.

Figura 1: Configuración de módulo java_jr17_exec en Metasploit

La elección del payload es realmente importante ya que la funcionalidad que disponga el atacante en la máquina remota dependerá de ello. Para la prueba de concepto se ha utilizado un Meterpreter, pero es recomendable visualizar que payloads hay disponibles en este modulo mediante el uso de la instrucción show payloads. En la siguiente imagen se puede visualizar los payloads que están disponibles para su inyección en la máquina remota.

Figura 2: Payloads disponibles pra java_jr17_exec

Una vez se tiene todo configurado estamos preparados para llevar a cabo la explotación. Es un ataque de tipo Client-Side, es decir, del lado del cliente. En este tipo de ataques es el usuario víctima el que se conectará al servidor, configurado por nosotros, y recibirá un Applet malicioso. En el caso de Apple Safari, si se tiene habilitado el uso de Java en el navegador, este Applet provocará la ejecución de código arbitrario, en nuestro caso el payload configurado.

¿Cómo hacer para que las víctimas visiten este servidor? Sencillo, distribución de links en foros, redes sociales, uso de acortadores para no levantar sospechas, spam, webs hackeadas con kits de explotación, etcétera. Por último, en la siguiente imagen se puede visualizar cómo se deja preparado el servidor y una víctima conecta con éste. La explotación es un éxito y en Apple Safari 6 con Java SE 7 sobre OS X Mountain Lion no se muestra ninguna advertencia.

Figura 3: Explotación con éxito de la vulnerabilidad en un Apple Safari 6 con Java habilitado

Una vez que se tiene una sesión, se realiza una captura de pantalla del equipo víctima en la que se puede visualizar que la versión del sistema operativo es un flamante OS X Mountain Lion 10.8.1 al que se le instaló Java SE 7 desde Oracle.

Figura 4: Versión del SO de la víctima

Hasta aquí la prueba de concepto sobre la explotación del CVE-2012-4681. Seguimos esperando la actualización por parte de Oracle para solucionar esta vulnerabilidad - de la que se ha dicho es consciente desde el mes de Abril - que está provocando un caos en Internet, ya que ya se está aprovechando para la distribución de malware, por lo que os recomendamos que tengáis deshabilitado Java, y si no os es posible, tener cuidado con las webs que visitáis e instalad un antimalware profesional.

{OSX/NetWeirdRC | Wirenet}: Troyano para OS X y Linux

La web de la compañía de antimalware Dr. Web ha publicado la información sobre un nuevo malware al que han bautizado como BackDoor.Wirenet.1 que ha llegado a su base de datos de muestras. Este troyano, una vez analizado, ha resultado ser un malware multiplataforma entre OS X y Linux, focalizado en el robo de contraseñas para enviarlas a un panel de control, usando AES (Advanced Encryption Standard) como sistema de cifrado en la comunicación.

El malware roba las contraseñas que son introducidas a través de los navegadores Opera, Firefox, Chrome y Chromium usando funciones de keylogging, además de robar las passwords almacenadas por programas como ThuderBird, SeaMonkey y Pidgin.

Figura 1: Sección de código para el cifrado con AES y envío de datos al C&C

No se tiene claro aún como se despliega este backdoor, pero una vez instalado, se copia en los directorios de usuario.

- Mac OS X: %home%/WIFIADAPT.app.app
- Linux: в ~/WIFIADAPT

Este malware parece ser el mismo que reportaba Intego, al que bautizaron como OSX/NetWeirdRC, y que fue descubierto vía Virus Total. El malware parece que está siendo vendido en Internet al precio de 60 USD, aunque se desconoce más sobre dónde ha podido ser utilizado. En las pruebas realizadas a esta otra muestra, el fichero se copiaba en /tmp/.lbOOjfsO y no parecía soportar la persistencia al reinicio.

Las muestras de malware que funcionan en sistemas Mac OS X ya no son una novedad, y tras ver la que tenemos hoy en día con el 0day de Java, es más que recomendable que tengas un sistema de antimalware con protección en tiempo real activado en tu Mac OS X. Hoy mismo ha reportado Intego, que por medio del bug CVE-2012-4381 se está desplegando una variedad de OSX/Tsunami, del que ya hablamos en Octubre del año pasado.

¿Es tu Mac OS X vulnerable al CVE-2012-4681 de Java?

Estos días está Internet revuelto con el 0day de Java que fue descubierto en uso masivamente por la industria del malware. El 0day se debe a un fallo de Java SE 7, que no ha sido solucionado aún, y que está siendo explotado en Kits de exploits como Black Hole, uno de los más populares del mundo y ya está disponible el módulo en Metasploit. El código del exploit se liberó en Pastebin, así que es el peor escenario posible. El bug afecta a todos los sistemas operativos, y la única solución a día de hoy es deshabilitar Java en los navegadores pero... ¿Son los sistemas Mac OS X vulnerables?

Figura 1: Exploit de CVE-2012-4681 en Metasploit

La respuesta incialmente es Sí, pero esto tiene muchos matices y puede ser que No. ¿Lo será tu Mac OS X? Supongo que esta pregunta se os ha pasado por la cabeza, como a nosotros, y queremos intentar resolverla, porque no es trivial ni generalizada. Así que vamos por partes.

Versión de Java afectada

El CVE-2012-4681 afecta a Java SE 7 y Apple está distribuyendo aún Java SE 6 en todos sus sistemas operativos, así que si has descargado Java solo desde Apple no vas a tener que preocuparte de este fallo.

Por otro lado Oracle actualizó Java SE 7 Update 6 para Mac OS X la semana pasada para las versiones Mac OS X Lion o Mountain Lion, así que si lo instalaste, tienes un equipo potencialmente en riesgo, pero esto no tiene porqué ser así, si Java SE 7 no está configurado para ser utilizado, que puede pasar si no has desinstalado manualmente Java SE 6.

Qué versión de Java está corriendo en tu Mac OS X

Si te ha pasado como a nosotros, y entras en las preferencias de tu Mac OS X, podrás ver un nuevo icono de preferencias de Java. Ese es el panel instalado por Oracle para gestionar Java SE 7, y deberás tener la versión afectada por el fallo actualmente. 

Figura 2: Módulo de Preferencias de Java SE 7 de Oracle

Si vas a actualizar, y le das, de momento Oracle no ha respirado, así que no hay ninguna actualización que llevarse a la boca.

Figura 3: Opción de actualización de Java SE 7

Sin embargo, si no has desinstalado Java SE 6 de tu equipo, y buscas las Preferencias de Java usando Spotlight, te aparecerá el menú de Preferencias de Java que instala Apple con su versión, donde como puedes ver aún aparece la versión 6.

Figura 4: Preferencias de Java SE de Apple con versión 1.6

Si este es tu caso, lo mejor es que pruebes la que tienes configurada en las variables de entorno del sistema, y vayas a un terminal para ejecutar Java -version, y ver cuál es la que está en ejecución, si sale 1.6 no hay riesgo, si sale 1.7 preocúpate.

Figura 5: Versión de Java en el sistema operativo

Qué versión de Java está corriendo en tu navegador

Para comprobar con más seguridad si tu navegador es vulnerable, en Zscaler han puesto una web en la que puedes comprobar si tu Java es vulnerable a este exploit o no, así que visítala y quédate tranquilo... o no.

Figura 6: ¿Está Java activado en tu navegador y eres vulnerable?

Soy vulnerable, pero necesito seguir usando Java

Si necesitas Java en tu navegador, entonces debes tener especial cuidado por los sitios en los que navegas, pero además puedes protegerte contra el malware conocido que está siendo en uso si tienes un antimalware profesional instalado en tu sistema. Las casas de estos productos están trabajando a marchas forzadas y firmando todos los malware que están viendo en uso para protegerte. Un antimalware no es 100% perfecto, pero seguro que puede ayudarte a parar malware en uso y aumentar la seguridad de tu plataforma.

Instalar Metasploit para iOS en iPhone, iPad o iPod Touch

En el blog de Metasploit, Andrew Spangler and James Kirk han publicado una guía para instalar Metasploit en dispositivos iOS. Nos ha parecido muy interesante y directa, así que hemos querido echar un poco de tiempo en ella y traducir la guía al Español para que pueda ser leída en nuestra lengua. Además, nos sirve para dejar actualizado el post que publicamos anteriormente aquí sobre instalar Metasploit Framework y SET (Social Engineering Toolkit) en iPhone. 

Mobile Pwning: Utilizando Metasploit en dispositivos iOS

¿Has querido alguna ver ejecutar un exploit pero te encontrabas lejos de tu puesto de trabajo? ¿No sería fantastico si pudiera lanzar una version completa de Metasploit Framework desde tu teléfono o tablet? Como quizá ya hayas adivinado, ahora puedes hacerlo. Con espíritu aventurero y unos pocos comandos, puedes tener ejecutando Metasploit Framework en tu iPad o iPhone en unos pocos minutos.

Advertencia: Para instalar Metasploit, necesitarás acceso de root a tu dispositivo - que deber ser realizado siguiendo tu procedimiento de jailbreak favorito. Por ejemplo Absinthe. Hacer jailbreak a tu dispositivo puede en potencia causarte problemas a ti o a tu dispositivo, y perderás la garantía. Tú asumes todo el riesgo cuando modificas tu dispositivo. Sin embargo, si quieres instalar Metasploit es porque probablemente disfrutes rompiendo cosas. :-)

Una vez que seas root, necesitar el siguiente software:

- OpenSSH server (vía Cydia)

- apt [APT 0.7+ Strict] (vía Cydia)

- SSH client (iSSH; vía App Store)

Figura 1: instalando el software como root

Primero, asegúrate de que todo el software está actualizado y que tienes instalado subversion:

- apt-get update

- apt-get dist-upgrade

- apt-get install wget subversion

Cuando esté hecho, necesitaremos descargar Ruby y las dependencias de iOS para que corra Metasploit Framework. Cuando se escribió este artículo, los ficheros necesarios estaban amablemente alojados en iNinjas:

- wget http://ininjas.com/repo/debs/ruby_1.9.2-p180-1-1_iphoneos-arm.deb

- wget http://ininjas.com/repo/debs/iconv_1.14-1_iphoneos-arm.deb

- wget http://ininjas.com/repo/debs/zlib_1.2.3-1_iphoneos-arm.deb

Figura 2: Descarga de Ruby y dependencias

Instala los paquetes:

- dpkg -i iconv_1.14-1_iphoneos-arm.deb

- dpkg -i zlib_1.2.3-1_iphoneos-arm.deb

- dpkg -i ruby_1.9.2-p180-1-1_iphoneos-arm.deb

Una vez que las dependencias han terminado de instalarse, puedes eliminar los ficheros con seguridad para ahorrar espacio de almacenamiento en tu dispositivo. Presumiblemente esos serán los únicos ficheros .deb que hayas descargados, así que puedes ejecutar un comando rm -rf *.deb. Si has estado jugueteando con otros ficheros, entonces sustituye el * por el nombre de los ficheros que quieras eliminar.

Si quieres hacer una doble comprobación de que todo está totalmente instalado correctamente, deberías ser capaz de ver la versión de Ruby 1.9.2 ejecuanto el comando ruby -v.

Figura 3: Instalación de paquetes

¡Ahora viene lo bueno! Yo instalé Metasploit Framework en /private/var/msf3. En caso de no estés familiarizado, /private/var es la partición en la que tus apps, contenido multimedia y configuraciones son almacenadas por defecto, así que es con seguridad la partición más grande de las dos que trae por defecto tu dispositivo.

Vamos a usar svn para conseguir el trunk de Metasploit Framework para que sea un proceso simple y evitar problemas de compatibilidad.

- cd /private/var

- svn co https://www.metasploit.com/svn/framework3/trunk/ msf3

Figura 4: Comprobación de versión de ruby e instalación de Metasploit Framework

Y ya está hecho, cd msf/ y ¡lanza Metasploit Framework!

- ruby msfconsole

¡Feliz exploiting!

Figura 5: Metasploit framework corriendo en iOS

Si quieres aprender más sobre cómo funciona Metasploit, puedes leer el libro de Pablo González Metasploit para Pentesters

OSX Mountain Lion 10.8.1: Sin security bugs conocidos

Fiel a su costumbre de dejar a los administradores de sistemas que permanezcan intranquilos durante el fin de semana, el pasado viernes 23 de Agosto, Apple puso a disposición pública OS X Mountain Lion 10.8.1, una actualización muy pequeña de tamaño que ha sido publicada sin información de security bugs, aunque sí con mejoras que impactan en el funcionamiento de los equipos Mac en las redes de una empresa o la seguridad de la plataforma, con mejoras en 802.1x.

A través de Mac App Store la actualización ocupa apenas 7.28 MB, mientras que en descarga directa desde la web el tamaño del fichero de instalación es de 24.2 MB. En la información disponible de la actualización en la Knowledge Base HT5418 se habla de la siguientes mejoras, que como puede verse también afectan a la seguridad del sistema.

Figura 1: Descripción de OSX Mountain Lion 10.8.1

- Arregla un fallo en el Asistente de Migración que hacía fallar a esta función.
- Mejora la compatibilidad con Exchange.
- Arregla un problema con iMessage que no enviaba los mensajes.
- Arregla un problema con la reproducción de audio en monitores Thunderbolt.
- Arregla un problema en el uso de Pinyin.
- Arregla un fallo en la conexión a servidores SMB con nombres muy largos.
- Soluciona un fallo que hacía que Apple Safari 6 no se lanzara cuando se utiliza PAC (Proxy Automatic Configuration).
- Mejora los sistemas de autenticación 802.1x con el uso de credenciales de Active Directory.

Algunos de estos fallos han tenido bastante impacto en el día a día de muchos clientes, por lo que aunque Apple no ha publicado ningún CVE solucionado, ha sacado esta actualización en menos de un mes del lanzamiento del sistema.

Fue Noticia en Seguridad Apple: 13 al 26 de Agosto

Hoy toca repaso, así que vamos a intentar resumir en solo post todo lo que hemos tratado durante las dos semanas que hoy terminan, para que no se te pase nada de lo que hemos publicado. Vamos allá.

Comenzamos el lunes 13 de Agosto con un artículo sobre OSX/FkCodec-A, un malware bastante desplegado entre los equipos Mac OS X que se despliega utilizando trucos de ingeniería social simulando ser un codec de vídeo, y que lleva activo desde Abril de este año.

El martes os hablamos de MIB Browser, una herramienta de consultas SNMPv1 y SNMPv2 gratuita para Mac OS X.

El 15 de Agosto la noticia fue para la publicación de Java SE 7 por parte de Oracle - sin ningún bug de seguridad conocido - y que tras probarla y analizarla, hemos visto que trae más confusión que otra cosa. La instalación de Java SE 7 no quita Java SE 6 - desplegado aún por Apple en OSX Mountain Lion - y tendremos que ver que sucede en la próxima actualización de seguridad crítica. Os informaremos de cómo migrar a Java SE 7 definitivamente.

El 16 de Agosto le dedicamos el posta al adware para realizar Clic Fraud descubierto oculto en aplicaciones Cydia, por parte de un e-criminal que quería ganar dinero a costa de consumir las tarifas de datos de sus víctimas. Muy feo el acto y muy poco castigado el culpable.

El viernes os hablamos de las actualizaciones de software en OSX Mountain Lion, que por desgracia ya  no informan del tamaño que ocupan, lo que puede llevar a que un clic en ellas provoque una descarga de 1.2 Gb. Nos gustaría que volvieran a mostrar el tamaño, tal y como sucedía hasta Mac OS X Lion.

El sábado nos hicimos eco del post publicado por pod2g en el que alertaba de lo fácil que es hacer SMS Spoofing en iPhone, debido a la forma en la que muestra los datos al usuario en la aplicación. La respuesta de Apple fue: "Usad iMessage", algo que deja fuera a las comunicaciones con todos los terminales que no lo pueden utilizar.

El domingo pasado quisimos echar un ojo al informe del robo en casa de Steve Jobs, donde se explica con pelos y señales cómo funcionó la investigación, y cómo detuvieron al delincuente por medio de una conexión realizada desde el iPad que usaba el propio Steve Jobs desde la dirección IP de la WiFi del ladrón. Un nuevo EPIC FAIL de ladrones.

El lunes pasado os hablamos de las opciones de activación y los métodos de análisis del antimalware profesional para Mac OS X ESET Cyber Security. 

Este martes la entrada fue para la actualización de Apple Remote Desktop 3.6.1 para solucionar un bug por el que, aún seleccionando la opción de cifrar las comunicaciones en una conexión a un servidor de terceros, si esto no era posible, el programa realizaba la conexión igualmente sin mostrar ninguna alerta.

El miércoles, primero os hablamos de una nueva campaña de spam para el despliegue de malware para Windows utilizando fotos leakeadas de iPhone 5 - algo que ya se había hecho en el pasado con iPhone 5GS - y por la tarde de Shodan para iOS, una app gratuita para tener el poder de Shodan en iPhone o iPad.

El jueves tocó hablar de OSX/Crisis, para explicar que las funciones más modernas de infección de su rama para Windows, Win/Crisis, con las que infecta pendrives, máquinas virtuales VMWare y terminales Windows Mobile, no están disponibles para Mac OS X...aún.

El viernes le dedicamos la entrada a Latig0SX, unos scripts de análisis de seguridad y fortificación de Mac OS X realizados por Laura García, conocida como lain, y que ayudan a mejorar la seguridad de tu plataforma. Muy recomendables de utilizar tanto para saber si se te ha pasado algo en la configuración de seguridad de tu máquina como para aplicar políticas en redes empresariales con equipos Mac OS X en ellas.

Por último, ayer sábado quisimos traer un post que habla sobre la historia de Apple y la ingeniería inversa. Una historia de cómo hacer ingeniería inversa a la ROM del Apple Macintosh SE. Un estudio genial de un grupo de hackers de Brooklyn.

Y esto fue todo, que como veis no fue poco. Esperamos veros por aquí en dos semanas y cada día en Seguridad Apple. Buen domingo para todos.

Ingeniería inversa de la ROM de Apple Mac SE

Leyendo a nuestros amigos de Cyberhades, hemos llegado a la historia de cómo NYC Resistor, un colectivo hacker con base en Brooklyn, se encontró un Apple Macintosh SE y se pusieron a jugar con él. La gracia de la historia es que decidieron hacer un volcado de la ROM y analizarla, para darse cuenta que había una estructura binaria extraña en una región de la memoria. 

Figura 1: Volcado de ROM con instrucción extraña

Con todo lujo de detalles, cuentan en su blog cómo hicieron la ingeniería inversa de la ROM, comenzando por el volcado de la memoria, y cuáles fueron sus razonamientos para resolver el misterio, lo que lo convierte en un post magistral para los amantes de la ingeniería inversa y el hardware hacking.

Figura 2: Las fotos digitales en la ROM y las originales

Al final, descubrieron que había cuatro fotografías guardadas, las que se ven arriba, del equipo que construyó ese equipo cómo un Huevo de Pascua. Sin embargo, esto era conocido hace tiempo, y en los foros de Apple se podía leer ya en el año 2005.

Figura 3: Cómo ver el huevo de pascua en el Apple Mac SE

A pesar de que no hayan descubierto nada nuevo, el post es una maravilla si te apasiona la tecnología, y casi dan ganas de comprar algún equipo antiguo y analizar la primera ROM que se ponga a tiro. Disfruta de la lectura.

Latig0SX: Scripts de seguridad y fortificación para OS X

Laura Garcia, más conocida como lain, ha puesto a disposición pública dos scripts para la fortificación de sistemas Mac OS X, a los que ha llamado Latig0SX. Los scripts son, el primero de ellos para analizar la configuración del sistema, llamado latigo-check.sh, y el segundo orientado a la fortificación de la plataforma, llamado latigo-hardening.sh, y la verdad es que nos ha encantado como funciona esta primera version.

Latigo-check es un script que comprueba un montón de apartados de seguridad, generando una salida por pantalla que puede automatizarse de forma muy cómoda en empresas donde se quiere establecer una política de seguridad.

Figura 1: Latigo-check.sh en ejecución

Comprueba, por cada equipo, la configuración de las actualizaciones de seguridad, la configuración del firewall, la configuración de la seguridad de la EFI, la configuración de seguridad de la sesión de usuario, las opciones de configuración de IPv6, los archivos con setuid flag activado, aplicaciones inseguras que puedan ser suplantadas, los permisos de archivos de usuario inseguros, etc...

Figura 2: Comprobaciones de IPv6 en la máquina

Latigo-hardening realiza una configuración por defecto, que puede ser adaptada tocando el código y ajustándolo a la política de la empresa, pero que quita los permisos setuid, setgid, configura de forma segura los archivos del perfil de usuario, deshabilita IPv6, etcétera. Aunque realiza la configuración de manera muy rígida, el código es lo suficientemente claro como para que cualquiera pueda tocarlo.

Figura 3: Código de Latigo-hardening.sh

La verdad es que nos ha encantado que Laura haya puesto estos scripts a disposición pública y la queremos felicitar. Desde Seguridad Apple, os animamos a que probéis el script Latigo-check, y si lo creéis conveniente, adaptéis Latigo-hardening a vuestras necesidades.

OSX/Crisis NO infecta máquinas virtuales en OSX...aún

Los investigadores de Symantec han continuado con el análisis del malware Crisis - también llamado Morkut -, que infectaba sistemas Windows y Mac OS X. Este Caballo de Troya saltó a la fama el mes pasado, y se hizo muy famoso por convertir el sistema en un auténtico dispositivo de espionaje, debido a que grababa conversaciones de aplicaciones de mensajería típicas, como Messenger, Adium o Skype. Tras un poco más de trabajo en él, han descubierto tres métodos que utiliza para infectarse en sistemas, a partir de un equipo vulnerado, y hay que reconocer que algunos son muy novedosos.

En primer lugar, el sistema busca ficheros de máquinas virtuales de VMWare en el sistema de ficheros, para montarlos y copiar el malware en el sistema virtual. Esto significa una infección desde la máquina física a la virtual, lo que hará que todos aquellos que usen alguna máquina virtual solo para cosas importantes, como transferencias bancarias, también queden infectados. La única forma de evitar esto, sería tener cifrado el sistema de ficheros de las máquinas virtuales, algo que deberá empezar a tomarse más en serio desde ya.

Figura 1: Esquema de autodistribución de Crisis, creado por Symantec

En segundo lugar, este sistema también busca infectar unidades de almacenamiento que se conecten, colocando ficheros autorun.inf en los discos y pendrives conectados a la máquina infectada. La ultima, es una infección que va desde la máquina física al teléfono, de momento solo a Windows Mobile, debido a que si está conectado los mecanismos de seguridad son inferiores a los que tienen hoy en día Android, iPhone o Windows Phone.

Hay que dejar claro que, por el momento, estos tres métodos de infección son sólo para sistemas Microsoft Windows, pero es probable que en el futuro mute estas funciones a Mac OS X o a otros tipos de máquinas virtuales, como Virtual BOX o Hyper-V, ya que no parece que sea muy difícil de migrar esa funcionalidad. En cualquier caso, hay que reconocer que este malware representa una novedad, y que hay que extremar las precauciones, cada día más, con las nuevas amenazas.

Shodan para iOS gratis en la App Store

La potencia del buscador Shodan, creado por John Matherly, es muy conocida entre los auditores e investigadores de seguridad. Cuando se hace una auditoría de seguridad de una red, siempre se busca la información indexada de la empresa por cualquier buscador, y en concreto también se hace, por supuesto, con Shodan. Lo que le hace peculiar y único en su especia es que su base de datos solo indexa la respuesta que da el banner de una conexión a la dirección IP y permite hacer busquedas en ellos.

Al recorrer todas las direcciones de Internet - a día de hoy tiene indexados datos de 66.895.366 direcciones IP - buscando los puertos HTTP, FTP, Telnet, SSH o SNMP, aparecen resultados inesperados que han dado que hablar muchísimo, ya que se pueden descubrir dispositivos iPhone o iPad, agentes SNMP anónimos que permiten descubrir la red interna de las empresas, sistemas de VoiP [más de 3.5 millones de sistemas SIP], paneles de control de acuarios,  de sistemas de streaming de TV de pago, sistemas NAS, etcétera, etcétera, etcétera.

Figura 1: Shodan para iOS en iPhone

Para tener toda la potencia del buscado a mano, han realizado una aplicación Shodan para iOS gratuita que puede ser descargada desde la App Store, donde se pueden realizar las mismas búsquedas que se hace  través de la web.  Si eres de los que te gusta tener el arsenal de herramientas en tu dispositivo, no dudes en bajártela, y si quieres conocer más de ella te recomendamos nuestro libro de Hacking con Buscadores: Google, Bing y Shodan.

Spam con imágenes de iPhone 5 distribuyen malware

Dentro de cerca de 50 días se cumplirá un año desde que Apple presentara en sociedad iPhone 4S, cuando todo el mundo esperaba el ansiado iPhone 5 en versión concreta iPhone 5GS - que no sea que no se prueban todas las combinaciones posibles -. Por aquel entonces, las campañas de spam para la difusión de malware utilizaban el reclamo de un supuesto iPhone 5 para distribuir malware para Windows.

Figura 1: Spam de iPhone 5 distribuyendo malware para Windows de Octubre de 2011

Ahora, con la otra vez esperada llegada de iPhone 5, las campañas de spam que lo utilizan como reclamo para distribuir malware han vuelto a comenzar. Según reporta Symantec se utiliza un documento malicioso de Microsoft Word en formado .doc para explotar el CVE-2012-1535 que permite la ejecución ejecución de código arbitrario en Adobe Flash Player e instalar un troyano mediante un drooper.

Figura 2: El spam que distribuye el malware

Como todavía no estamos cerca del lanzamiento, se han utilizado imagenes filtradas de las piezas de iPhone 5 - si es que al final se llama así - de las que a día de hoy está plagada la red. En concreto, como se puede ver en el asunto del correo, de las baterías.

Figura 3: Una de las tantas imágenes filtradas de un supuesto iPhone5

Lo más curioso es que al final no está nada claro si todas estas imágenes se corresponden al modelo final, a prototipos filtrados equivocadamente, o a campañas de desinformación creadas desde la propia Apple para dificultar lo máximo la creación de clones piratas y accesorios ilegales. Quién sabrá al final lo que nos presentarán ...

Apple Remote Desktop 3.6.1 arregla el CVE-2012-068

Apple ha publicado en las principales listas de seguridad el Apple-SA-2012-20-8-1 para anunciar la disponibilidad de una actualización de seguridad de Apple Remote Desktop 3.6.1, el cliente de escritorios remotos o servidores de terminales, en la que se arregla un único bug de seguridad, descubierto por un estudiante de la Universidad de Central Connecticut State llamado Mark S.C. Smith y catalogado con el CVE-2012-068.

Según la información disponible en el artículo de la Knowledge Base HT5433, el bug permite, cuando se conecta la aplicación Apple Remote Desktop a un servidor VNC de terceros con la opción de cifrar todos lo el tráfico de red. Si dicho cifrado no se produce, no se muestra ningún aviso y las comunicaciones se hacen en claro, pudiendo llevar a un descubrimiento de información sensible por la red. El fallo se ha solucionado añadiendo un túnel SSH para la conexión VNC en la configuración, y evitando la conexión si dicho túnel no puede ser creado.

El bug no afecta a las versiones Apple Remote Desktop 3.5.1 o inferiores y está solucionado en Apple Remote Desktop 3.6.1, que puede ser descargado desde: Descargar Apple Remote Desktop 3.6.1. Si usáis este cliente, os recomendamos que lo actualicéis cuanto antes.

Antimalware profesional para Mac: ESET CyberSecurity - Parte 2: Activación y Prueba de Detección de Malware

Tras concluir el proceso de instalación visto en la primera parte de este artículo, se debe realizar un reinicio del sistema. Una vez reiniciado Mac OS X, cuando se abre la consola de configuración de ESET CyberSecurity, se pedirá la información de activación del mismo, pudiendo en esta ventana, configurar la licencia de prueba del producto. Solo es necesaria una dirección de correo electrónico, nuestro nombre y el país al que pertenecemos. Si tenemos conexión a Internet la activación será inmediata y estará totalmente funcional el producto inmediatamente.

Figura 9: Activación de licencia  ESET CyberSecurity para Mac OS X

Activado el producto correctamente y dentro de la interface del programa, procederemos a verificar si existen definiciones nuevas de malware. la actualización se lleva a cabo en un corto plazo de tiempo, dejando nuestras base de datos actualizadas y nuestro Mac OS X perfectamente defendido contra el malware y las amenazas conocidas, así como contra actividad maliciosa si hemos habilitado la función de “TreathSense.net” en las opciones de instalación. Esta característica la podemos habilitar siempre y cuando queramos, una vez instalado el software.

Figura 10: Actualización de base de datos de firmas de ESET CyberSecurity para Mac OS X

Terminada la actualización, se informa de que la versión de base de firmas de malware, así como del estado de la protección del sistema.

Figura 11: Estado de la protección en Mac OS X

Como se puede ver en la imagen superior, ya tenemos listo el producto y nuestro equipo protegido por ESET Cyber Security.

Realización de Análisis de Seguridad a Mac OS X

En el apartado análisis relativo a la computadora se pueden ver dos opciones comunes en los sistemas de protección contra software malicioso a la hora de analizar un equipo:

- Análisis estándar: analiza las rutas típicas de archivos del sistema y de usuario con mayor índice de alojamiento de software malintencionado. 

- Análisis personalizado: nos brinda la opción de seleccionar que unidades y archivos queremos analizar.

Figura 12: Análisis del ordenador con ESET CyberSecurity para Mac OS X

Así mismo, tenemos una opción para configurar y editar los perfiles de análisis, ya sea el estándar o el personalizado, pudiendo pre-configurar nuevas rutas, nuevas exclusiones o el uso o no del motor de ThreatSense.net, para adaptarse lo máximo a las necesidades de cada usuario.

Figura 13: Personalización de análisis estándar en ESET CyberSecurity

Actualización de base de datos de firmas y software

ESET CyberSecurity comprobará si hay nuevas versiones del software y se actualizara automaticamente siempre que tengamos una conexión a Internet activa al encender el equipo. También podremos realizar esta comprobación manualmente si asi lo deseamos accediendo a esta opción y con un simple clic se ejecutará la tarea.

Prueba de funcionamiento con Hellraiser

Una vez que instalado un software antimalware, para comprobar si está escaneando un determinado punto del sistema se suelen utilizar firmas de muestra, como EICAR. En este caso, para probar que nuestro software de protección está activo, utilizamos el antivirus con el Troyano Hellriser para Mac OS X para ver si lo detecta.

Figura 14: Malware Caballo de Troya Hellraiser para Mac OS X

Tras lanzar el escaneo de seguridad, ESET CyberSecurity ha detectado el malware y nos ha notificado la existencia del malware.

Figura 15: Troyano HellRaiser 4.2 detectado en el sistema en Cuarentena

no poderlo desinfectar, ha optado por eliminar el archivo, tal y como está establecido en las opciones de configuración del ESET Cybersecurity.

Figura 16: Información del malware detectado por ESET CyberSecurity

En la última parte de esta serie, veremos cuáles son las opciones avanzadas que permite esta solución para ajustar al máximo el funcionamiento de la protección a nuestro sistema Mac OS X.

========================================================================
- ESET CyberSecurity para Mac OS X - Parte 1: El Proceso de Instalación
- ESET CyberSecurity para Mac OS X - Parte 2: Activación y Detección de Malware
- ESET CyberSecurity para Mac OS X - Parte 3: Opciones de Configuración y Estadísticas
========================================================================

Informe de la resolución del robo del iPad de Steve Jobs

El pasado 17 de Julio, la casa de la familia de Steve Jobs en Palo Alto, fue asaltada por un ladrón que aprovechándose de unos días en que se estaban realizando reformas en la casa, después de que terminara la jornada laboral de los empleados, saltó por el muro, se hizo con una llave en el garaje y entró dentro de la casa.

Figura 1: Casa de Palo Alto de la familia Jobs

El ladrón se llevó de allí un par de iMacs, tres iPads - entre los que se encontraba el que usaba Steve Jobs, tres iPods, un collar, unos pendientes de diamantes de Tiffany's, una cartera negra con la licencia de conducir de Steve Jobs y algún que otra cosa más, para salir huyendo en su coche.

Figura 2: Vista parcial del informe de objetos robados

El ladrón, identificado finalmente como Kariem McFarlin, parece que tenía ganas de deshacerse rápidamente del material, ya que cuando REACT (Rapid Enforcement Allied Computer Team), un equipo de organizaciones de los cuerpos de seguridad especializados en los delitos relativos a computadores y tecnología entraron en contacto con Apple, pudieron constatar que uno de los números de serie de los iPads robados, había intentado conectarse al día siguiente a las 07:22 de la mañana para intentar reinstalar el sistema desde una dirección IP de Alameda, en la parte este de San Francisco.

Figura 3: Apple informó de la dirección IP de conexión del iPad de Steve Jobs

Analizando el Apple ID asociado a ese iPad robado, pudieron ver que el Apple ID se conectaba desde otros de los dispositivos robados, y que desde la misma dirección IP se estaban conectado otro Apple ID. La policía quería estar segura de que Kariem McFarlin era el ladrón, así que analizaron sus amigos en Facebook y pudieron comprobar que ese otro Apple ID correspondía con uno de los amigos del sospechoso.

Figura 3: Comprobación de amistad en Facebook con el dueño del otro Apple ID

La última comprobación que quisieron hacer fue que la dirección IP no permitía a una red comunitaria o a una conexión WiFi insegura, y tras descartar esta posibilidad, el 2 de Agosto, detuvieron al ladrón. En la cocina de su casa descubrieron uno de los iMacs robados, y tras detenerles y que el ladrón confesara, pudieron ir recuperar el resto de las cosas robadas.

Figura 4: Foto digital al About del iMac de la Cocina

La investigación completa del caso hecha por REACT está disponible en un Google Docs, con el que se pueden seguir todos los pasos de la investigación, así como los razonamientos y pruebas que se hicieron para concluir con la orden de detención del sospechoso. Solo por lo emocional que puede resultar, pensar que no se iban a tomar todas las medidas necesarias para recuperar el iPad que usaba Steve Jobs es de ser un ladrón muy necio y merece estar en el Hall of Shame de ladrones en modo EPIC FAIL.

Actualización: Al ladrón, al final, le han caído 7 años de cárcel