Informe

Cómo se gestó el ataque de hacking del iPad

de Apple en la conferencia FOCUS 11

Gabriel Acevedo y Michael Price

McAfee® Labs™
 Índice
Motivación 3

Investigación 4
La vulnerabilidad de la implementación de SSL de iOS 4
La vulnerabilidad "JailbreakMe" 5

El ataque de hacking 5
Hardware 5
Software y herramientas 6
Escenario 7
Ataque 8
Resultados 10

Conclusiones 11

Agradecimientos 12

Acerca de los autores 12

2 Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11

En octubre del año pasado McAfee celebró su conferencia FOCUS 2011. McAfee Labs ofreció a los clientes
varias presentaciones sobre malware y otras amenazas, así como muchos otros temas de seguridad.
Uno de los eventos más esperados fue la ponencia Hacking Exposed, que reunió a más de 2.000 personas.
La mayoría de los asistentes apagaron sus portátiles, teléfonos, iPads de Apple y demás dispositivos cuando
el CTO de McAfee, Stuart McClure, anunció que su equipo iba a llevar a cabo un ataque de hacking en
directo durante la sesión. Los numerosos rumores aparecidos en Twitter y en otras redes sociales habían
despertado una gran expectación y, sin duda, fue un tema muy comentado en la conferencia. Los más
escépticos afirmaban que no sería una demostración en directo, pero la presentación no había hecho
más que empezar cuando el hotspot Wi-Fi de FOCUS falso ya estaba funcionando.

Una cámara de televisión filmaba la pantalla del iPad que iba a ser pirateado para que los asistentes
pudieran seguirlo en directo. Mientras McClure cargaba Gmail a través de una conexión Secure Socket
Layer (SSL), nosotros veíamos el esquema de URI HTTPS y el icono de candado en Safari. Al mismo
tiempo, se estaba cargando un exploit e instalando un servidor Secure Shell (SSH). Unos segundos más
tarde, ante los aplausos del público, la pantalla del iPad aparecía en nuestro cliente de control remoto
VNC. El iPad ya estaba en manos de los "piratas". Teníamos acceso de administrador (root) a través
del terminal y, además, acceso gráfico a través de VCN que nos permitía ver en directo lo que hacía
McClure e interactuar con su dispositivo. En la misma situación, un usuario de iPad típico no tendría ni
idea de que nos habíamos hecho con el control de su sistema. La víctima no estaba visitando un sitio
web malicioso; simplemente estaba consultando su correo electrónico a través de una conexión segura.
¿Cómo habíamos podido piratear su dispositivo?

En este informe contestaremos a esta pregunta y, además, explicaremos nuestra investigación,

los problemas a los que nos hemos enfrentado y las herramientas que hemos creado.

(En este informe describiremos las técnicas utilizadas con el único fin de informar e instruir sobre los
hechos y principios de seguridad afectados. McAfee ni utiliza ni aprueba el empleo de dichas técnicas
para infringir la ley aplicable o traspasar los límites del comportamiento ético).

Motivación
En julio de 2011, el equipo SpiderLabs de TrustWave1 reveló una vulnerabilidad relacionada con un
error de validación de limitaciones básicas en una cadena de validación de certificados SSL de iOS.
Los investigadores descubrieron que era posible generar un certificado falso utilizando otro que, aunque
válido, no debía ser utilizado para generar certificados para otros sitios web. Sin embargo, SpiderLabs
no proporcionaba muchos detalles. ¿Era muy complicado reproducir la vulnerabilidad? ¿Para qué podían
utilizar los agresores esta vulnerabilidad, además de para descubrir datos que debían ser privados?

Ya hace tiempo que se divulgaron las vulnerabilidades que empleaba jailbreakme.com (conocidas de forma
colectiva como JailbreakMe, o JBME). Hasta el momento, el único uso público que hemos observado es el
de jailbreakme.com y son muchos los usuarios que desean desbloquear un dispositivo Apple. Sin embargo,
lo que algunos no saben es que la técnica JBME aprovecha vulnerabilidades para conseguir el control
del dispositivo y, como ocurre con muchas otras vulnerabilidades, éstas pueden aprovecharse con fines
malintencionados.

¿Qué pasaría si combináramos estas dos vulnerabilidades? ¿Es posible utilizarlas en un ataque sofisticado,
silencioso y eficaz? Tenga en cuenta que la vulnerabilidad de SSL no era imprescindible para el ataque
de hacking; simplemente queríamos demostrar que, incluso cuando las víctimas creen que están a salvo,
es posible poner en peligro el dispositivo. Por este motivo, nuestra idea era atacar el sistema mientras la
víctima visitaba un sitio web de un banco, consultaba el correo electrónico o realizaba un pago online,
todo a través de una conexión SSL.

Estas dos vulnerabilidades han sido corregidas en las últimas versiones del sistema operativo iOS de
Apple. Sin embargo, muchos usuarios no han actualizado su sistema operativo por diversos motivos;
desde el desconocimiento hasta el hecho de que desean desbloquear sus dispositivos e instalar
aplicaciones que no están disponibles en la tienda Apple Store. ¿Cuántos de ellos son aun vulnerables?

Hemos planteado muchas preguntas. En los apartados siguientes, les daremos respuesta.

Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11 3

 Investigación
La vulnerabilidad de la implementación de SSL de iOS
En julio de 2011 Paul Kehrer y Gregor Kopf revelaron una vulnerabilidad relacionada con un error de
validación de entrada (CVE-2011-0228) en Apple iOS. El sistema operativo para móviles no podía validar
la cadena de certificados X.509, con lo cual el agresor podía capturar o modificar datos protegidos
por SSL/TLS y llevar a cabo ataques de intermediario. La vulnerabilidad afectaba a las versiones 4.3.4
y anteriores de iOS en dispositivos para redes GSM y a las versiones 4.2.9 y anteriores de los dispositivos
para redes CDMA. Los investigadores informaron a Apple, que publicó las actualizaciones de seguridad
HT4824 y HT4825 para los dispositivos CDMA2,3. Posteriormente, durante DEFCON 19, Kehrer reveló
nuevos detalles, como que iOS ignoraba la extensión de limitaciones básicas X.509 v34.

Los certificados emitidos para entidades raíz e intermedias deben incluir la extensión de limitaciones
básicas X.509 v3 con un campo CA definido como TRUE (verdadero)5. Por ejemplo:
Extensiones de X509v3:
1.3.6.1.4.1.311.20.2:
...C.A
Uso de clave de X509v3:
Firma digital, Firma del certificado, Firma de la lista de
revocación de certificados
Limitaciones básicas de X509v3: crítica
CA:TRUE

Sin embargo, para certificados de usuario el parámetro CA debe ser FALSE. Por ejemplo:
Extensiones de X509v3:
Limitaciones básicas de X509v3:
CA:FALSE

El defecto de estas versiones de iOS permite a un agresor utilizar un certificado legítimo sin autoridad de
certificación (CA:FALSE) con el fin de firmar otros certificados para cualquier dominio y conseguir que
los dispositivos los acepten sin avisar, como si se tratara de un certificado X.509 normal firmado por una
entidad válida. Por ejemplo, la siguiente cadena de certificados funcionará en iOS versión 4.3.4, pero no
en las versiones con parches (como la versión 4.3.5):
Certificado raíz
Certificado intermedio (CA:TRUE)
Certificado de usuario final (CA:FALSE)
Certificado de un dominio arbitrario —De confianza

La extensión de limitaciones básicas tiene también un parámetro opcional: pathlen. Este parámetro
indica el número máximo de certificados que pueden aparecer debajo de éste en la cadena. Por lo
tanto, partiendo del ejemplo expuesto, si en el Certificado intermedio (Intermediate Certificate) el
parámetro pathlen es cero, el dispositivo con iOS no confiará en el Certificado de un dominio arbitrario
(Some Arbitrary Domain Certificate) generado por el Certificado de usuario final (End User Certificate).
La siguiente cadena de certificados no funcionará ni siquiera en iOS 4.3.4.
Certificado raíz
Certificado intermedio (CA:TRUE,pathlen:0)
Certificado de usuario final (CA:FALSE)
Certificado de un dominio arbitrario —No de confianza

4 Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11

Hemos llegado a esta conclusión mientras intentábamos reproducir esta vulnerabilidad. Según la
recomendación original, iOS no reconocía todas las limitaciones básicas, pero nosotros llegamos
a la conclusión de que las versiones vulnerables sólo ignoraban el valor del parámetro CA.

Por lo tanto, para generar un certificado X.509 falso con el fin de aprovechar la vulnerabilidad
CVE-2011-0228, el certificado de la cadena que precede inmediatamente al que genera el
certificado falso no debe incluir el parámetro pathlen, o bien debe contener un valor de pathlen
lo suficientemente elevado.

La vulnerabilidad "JailbreakMe"
JBME es un sitio web que contiene un grupo de desbloqueos (o jailbreaks) para distintas versiones de
iOS. Estos han sido diseñados por comex y aprovechan fallos en Safari y en el kernel. La primera versión
se distribuyó en 2007 y funcionaba en el firmware 1.1.1 del iPhone y del iPod Touch de Apple. En agosto
de 2010 se publicó otra versión para iOS 4.0.1 y la última versión vio la luz en julio de 2011. Funciona
en iOS 4.3.3. Apple corrigió las vulnerabilidades aprovechadas por JBME en la versión 4.3.4 de iOS.

La versión de julio de 2011 de JBME —también conocida como Saffron— aprovecha una vulnerabilidad
(CVE-2011-0226) en el componente de análisis FreeType del navegador Mobile Safari, mediante un
archivo PDF diseñado específicamente para este fin. La rutina del PDF creará y cargará una carga útil ROP
(del inglés Return-Oriented Programming, programación orientada a instrucciones de retorno) en la pila
y aprovechará una vulnerabilidad del kernel en la interfaz IOMobileFrameBuffer IOKit (CVE-2011-0227).
A continuación, la rutina utilizará otra carga útil para modificar algunas funciones del kernel con el fin
de desactivar la implementación de la firma de código y conseguir privilegios de nivel de administrador.
Una vez finalizado el exploit, un agresor podría instalar aplicaciones sin firmar, como Cydia y todas las
que ofrece dicho sistema6.

Miles de usuarios utilizan JBME para desbloquear sus dispositivos, para acceder a aplicaciones no
disponibles en la tienda Apple Store o para modificar parámetros de configuración no accesibles para
usuarios normales. Pero lo que a veces ignoran es que para poder realizar el desbloqueo sus dispositivos
sufren un exploit.

El ataque de hacking
Hardware
No necesitábamos mucho: un portátil Apple MacBook Air y una llave de conexión inalámbrica. Utilizamos
la llave para localizar distintos puntos de acceso desde los que lanzar nuestra demostración de ataque.
El MacBook Air es muy práctico para conferencias, cafeterías o salas de espera en aeropuertos.
Se necesita un Mac para regenerar el PDF malicioso. Para lo demás, no importa qué ordenador portátil
o de sobremesa utilice, pero el sistema operativo debe ser tipo UNIX, como Mac OS X, Linux o FreeBSD.
De esta forma, es más fácil dirigir el tráfico a través de un firewall de kernel, como ipfw o iptables.
Asimismo, necesitará algunas herramientas que vienen instaladas de forma predeterminada en estos
sistemas operativos.

Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11 5

 Software y herramientas
Para el ataque de hacking, utilizamos algunas aplicaciones muy prácticas. Algunas eran simples secuencias
de comandos, otras, software sofisticado, como Apache HTTP Server o herramientas incluidas en el sistema
operativo de forma predeterminada y otras aplicaciones personalizadas.

Para generar el PDF, necesitamos la herramienta star_ de comex. Este código contiene todos los archivos
para generar el PDF malicioso, que requiere la herramienta xpwn de posixninja7. En ese proyecto,
encontrará también el exploit del kernel. Necesitará un firmware de iPad descifrado personalizado
o bien puede generar el suyo propio con xpwn (las claves de descifrado no siempre se incluyen)8.
Con las herramientas y las instrucciones de comex, generamos los siguientes archivos:
• PDF: se hace con el control inicial del sistema.
• freeze.tar.xz: contiene los archivos y aplicaciones (como VNC) que se van a instalar.
• install-3.dylib: biblioteca dinámica utilizada durante el ataque
• saffron-jailbreak.deb: archivo comprimido que contiene una serie de archivos binarios para iniciar el
proceso de instalación.

Para transmitir el exploit y las aplicaciones al iPad, utilizamos el software Apache HTTP Server, que es
el componente para compartir en la Web, incluido en Mac OS X. El servidor web tenía que transmitir
el contenido a través de SSL, por lo que tuvimos que crear el correspondiente certificado SSL. Para ello,
usamos la herramienta OpenSSL que se incluye de forma predeterminada en OS X.

La herramienta tcpdump (incluida en OS X) nos permitió verificar que el iPad efectivamente solicitaba
el exploit. Configuramos la carga útil freeze.tar.xz para colocar un archivo en /var/mobile/Media/post-
jailbreak, que ejecutará el exploit star_ (si está presente). En dicho archivo incluimos un comando para
enviar un ping a nuestro sistema de forma que supiéramos cuándo estaba activo SSH. Empleamos
tcpdump para verificar si el iPad estaba enviando un ping a nuestro portátil.

Con la herramienta ipfw de BSD definimos algunas reglas de firewall en el portátil para redirigir el tráfico
del iPad a nuestra herramienta de ataque de intermediario, iSniff.

iSniff es obra de hubert3, que se inspiró en la herramienta sslsniff de Moxie9. La herramienta de hubert3
inspecciona el tráfico SSL enviando a la víctima certificados falsos generados sobre la marcha. Editamos
el código fuente de iSniff para poder modificar los datos que enviaba la víctima al servidor y viceversa.
(iSniff se diseñó para Debian GNU/Linux; nosotros lo modificamos para que funcionara en OS X).

6 Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11

Escenario
Utilizamos la interfaz inalámbrica USB de nuestro MacBook para conectarnos al hotspot Wi-Fi de FOCUS
y la interfaz inalámbrica incorporada AirPort para crear un hotspot con un nombre SSID similar al de la red
legítima. Utilizando para nuestro hotspot un nombre similar al verdadero, podríamos incitar a la víctima
a conectarse a nuestra red. Un truco fácil es utilizar un nombre SSID habitual y crear otro añadiendo un
espacio delante. De esta forma, el nombre del hotspot imitado se coloca al principio de la lista de redes.

Normalmente los agresores dejan el hotspot abierto (sin requerir contraseña). Sin embargo, en este caso,
añadimos una contraseña para que los asistentes a nuestra presentación no cayeran en la trampa de
manera involuntaria.

Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11 7

 Ataque
Conectamos el portátil a Internet con una llave inalámbrica, iniciamos el servidor web y compartimos la
conexión a Internet a través de AirPort para hacer creer a las víctimas que éramos un hotspot Wi-Fi gratuito.

Abrimos dos fichas en la aplicación Terminal del Mac. En la primera, iniciamos tcpdump para que
escuchara en la interfaz de red compartida. En la segunda ficha de Terminal, creamos dos reglas de
firewall mediante ipfw. Una de ellas fue especialmente útil:
sudo ipfw add 1013 fwd 127.0.0.1,2000 tcp from any to any 443 recv en1

En esta regla, 1013 es el nombre de la regla, 127.0.0.1,2000 indica dónde escucha el proxy utilizado
para el ataque de intermediario, 443 indica que deseamos interceptar conexiones a través del puerto
estándar para SSL y en1 es la interfaz de red a través de la cual compartimos la conexión a Internet.
A continuación, iniciamos el servidor proxy para el ataque de intermediario (iSniff). Está configurado
para escuchar en el puerto 2000.

Observamos cómo nuestras víctimas visitaban https://mail.google.com en el iPad.

El proxy intercepta la conexión de la víctima, genera un certificado para el nombre de dominio al que la
víctima intenta acceder (mail.google.com), envía el certificado a la víctima para establecer una conexión
"segura" con el dispositivo y, por último, suplanta a la víctima para establecer una conexión con el
destino final.

Como la versión vulnerable de iOS no puede verificar la cadena de certificados SSL, confió en el
certificado que nosotros habíamos generado y no activó alarmas ni generó ningún error. En este caso,
vimos todo el tráfico de entrada y salida y, además, podíamos modificarlo.

8 Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11

La herramienta de ataque de intermediario modificó la solicitud HTTP de la víctima y solicitó al servidor
una página no comprimida, lo que nos facilitó la tarea de procesar y modificar la página web devuelta
para insertar un elemento HTML iframe justo delante de la etiqueta de cierre </body>.

El elemento iframe contenía una página web con un vínculo a un PDF malicioso. Conseguimos reducir
el tamaño del iframe de manera que era casi imperceptible para el usuario. Además, lo insertamos en la
parte inferior de la página. Durante la demostración, conservamos un iframe de gran tamaño para que
el público pudiera verlo en la pantalla.

El archivo PDF contenía una fuente FreeType Type 1, especialmente diseñada, para atacar al navegador
web Mobile Safari y ejecutar código especial con el fin de descargar una carga útil en el dispositivo.
El iPad descargó todos esos archivos (el archivo comprimido .deb saffron, freeze.tar.xz, install.dylib) de
nuestro servidor HTTP local. Generamos un certificado SSL para el dominio que apuntaba a nuestra
máquina local, por lo que la conexión seguía protegida mediante SSL mientras se descargaba el PDF,
y Safari mostraba el icono de candado durante todo el proceso, lo que inspiraba confianza al usuario.

Mientras comprometíamos el iPad de la víctima, descargamos una carga útil que instaló el servidor
SSH, VNC y algunas dependencias de nuestro servidor HTTP. Normalmente, llegados a este punto,
JBME instalaría Cydia, pero no queríamos revelar ningún signo de ataque, por lo que modificamos el
código star_ de JBME para que no se creara el icono en el escritorio ni se instalara Cydia. Utilizamos la
secuencia de comandos postinstall para borrar algunas de nuestras huellas, como el icono de VCN y la
configuración en el menú Configuración de iOS. Posteriormente la secuencia de comandos postinstall
envió un comando ping para que supiéramos que el dispositivo estaba listo y aceptaba conexiones en
el puerto 22. Nosotros detectamos el ping con la herramienta tcpdump en Terminal.

Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11 9

 Resultados
A continuación, utilizamos SSH para llegar al dispositivo con privilegios de administrador y así podíamos
realizar cualquier acción: leer mensajes personales, descargar fotografías privadas, conseguir la lista de
contactos o instalar más aplicaciones (por ejemplo, un registrador de pulsaciones o keylogger) entre otras.

10 Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11

Recargamos la interfaz del iPad para que el servidor VNC respondiera correctamente a nuestras
conexiones. A continuación, iniciamos nuestro cliente VNC favorito y nos conectamos al dispositivo.
Veíamos todo lo que la víctima hacía en el iPad e incluso podíamos interactuar con el dispositivo.

Mientras trabajamos de incógnito, la víctima seguía consultado Gmail y visitando sitios web, ajena al
hecho de que habíamos irrumpido en su sistema y comprometido todos sus datos personales.

En cuanto la "springboard" del iPad apareció en la pantalla, el público de FOCUS comenzó a aplaudir.
Algunos se aproximaron para hacer preguntas y, en algunos casos, para cerciorarse de que no habíamos
pirateado ningún otro dispositivo durante la conferencia. Naturalmente, no lo hicimos. Simplemente
demostramos de lo que son capaces los piratas reales.

Conclusiones
Apple iOS es más seguro que muchos otros sistemas operativos, pero no es impenetrable. A veces se
descubren sus vulnerabilidades y las de sus aplicaciones. A pesar de que Apple niega esta circunstancia,
no podemos confiar exclusivamente en el proveedor para la protección de nuestros dispositivos móviles.

En el momento en que nos consideremos seguros, seremos más vulnerables. Para este ataque
de hacking, no importaba si la víctima utilizaba SSL. Todo lo que necesitamos fue un usuario
poco informado o poco precavido. Tendemos a creer que la seguridad de nuestros sistemas —así
como la de nuestros datos, nuestro dinero y nuestra identidad online— depende únicamente de
una contraseña segura, de un firewall caro (o cualquier otro dispositivo) o de un buen programa
antimalware. En realidad, nuestra seguridad se basa en una combinación de todos estos elementos.
Pero lo más importante para garantizar nuestra protección es la información. Debemos ser conscientes
de que hay malhechores deambulando por la Web y de que hay vulnerabilidades, y saber que es
fundamental corregirlas o impedir que puedan ser aprovechadas.

Cómo se gestó el ataque de hacking del iPad de Apple en la conferencia FOCUS 11 11

 En ocasiones, una sola vulnerabilidad parece inofensiva. Si se analizan de manera aislada, podemos creer
que es imposible que alguien las utilice para acceder a su dispositivo. Sin embargo, si se combinan entre
ellas, pueden suponer un riesgo importante. No olvide que siempre es posible reconvertir herramientas
prácticas e inofensivas para destinarlas a fines malintencionados. Si caen en las manos equivocadas,
estas herramientas pueden convertirse en armas capaces de poner en peligro nuestros sistemas.

La mayoría de las aplicaciones de software presentan vulnerabilidades. Debemos estar atentos a los
avisos de seguridad de los proveedores e instalar los parches correspondientes o tomar las medidas
oportunas para evitar los riesgos. Asimismo podemos aprovechar las herramientas de seguridad que
nos alertan de la presencia de vulnerabilidades en el software de nuestras redes.

Agradecimientos
Queremos agradecer a Stuart McClure por su continua motivación y a Raul Collantes por sus ideas
y revisiones.

Acerca de los autores

Gabriel Acevedo es un investigador de seguridad en la oficina de McAfee Labs en Santiago de Chile.
Se encarga de la investigación de vulnerabilidades nuevas y existentes en las plataformas Microsoft
Windows y Unix, los dispositivos de seguridad y otros sistemas. Acevedo es miembro del equipo McAfee
Vulnerability Management Content (antes McAfee Foundstone®), un equipo internacional responsable
de la implementación de comprobaciones de software para detectar la presencia de vulnerabilidades
en sistemas informáticos remotos. Además, es líder del grupo de trabajo Mobile Security Working
Group, que forma parte de McAfee Labs, encargado de investigaciones de seguridad colaborativa en
dispositivos móviles e integrados.

Michael Price es exdirector de operaciones de McAfee Labs en la oficina de Santiago de Chile.

En McAfee, ha colaborado con entidades externas en Chile y Latinoamérica promocionando la
excelencia técnica y la innovación. En la actualidad, Price es arquitecto jefe de iOS en Appthority,
donde se encarga de las investigaciones sobre la seguridad de las aplicaciones y de iOS.

1
Kehrer, Paul. "Trustwave’s SpiderLabs Security Advisory TWSL2011-007"
(Notificación de seguridad de SpiderLabs de Trustwave), julio de 2011. https://www.trustwave.com/spiderlabs/advisories/TWSL2011-007.txt
2
Apple. "Acerca del contenido de seguridad de la actualización de software del iOS 4.3.5 para iPhone", julio de 2011.
http://support.apple.com/kb/HT4824?viewlocale=es_ES
3
Apple. "About the security content of iOS 4.2.10 Software Update for iPhone" (Acerca del contenido de seguridad de la actualización de software del
iOS 4.2.10 para iPhone), julio de 2011. http://support.apple.com/kb/HT4825
4
Percoco, Nicholas y Paul Kehrer. "Getting SSLizzard" (La utilidad SSLizzard), agosto de 2011. http://defcon.org/html/defcon-19/dc-19-speakers.html#Percoco
5
Para obtener más información sobre autoridades de certificación y certificados, consulte http://mcaf.ee/2mjdv
6
Bédrune, Jean-Baptiste. "Analysis of the jailbreakme v3 font exploit" (Análisis del exploit sobre las fuentes en jailbreakme versión 3), julio de 2011.
http://esec-lab.sogeti.com/post/Analysis-of-the-jailbreakme-v3-font-exploit
7
https://github.com/comex/star_
8
https://github.com/posixninja/xpwn
9
https://github.com/hubert3/iSniff

La información de este documento se proporciona únicamente con fines informativos y para la conveniencia de los clientes de McAfee.
La información aquí contenida está sujeta a cambio sin previo aviso, y se proporciona "tal cual" sin garantías respecto a su exactitud
McAfee, S.A. o a su relevancia para cualquier situación o circunstancia concreta.
Avenida de Bruselas nº 22
Edificio Sauce McAfee, el logotipo de McAfee, McAfee Labs y McAfee Foundstone son marcas comerciales o marcas comerciales registradas de McAfee,
28108 Alcobendas Inc. o de sus empresas filiales en EE. UU. y en otros países. Los demás nombres y marcas pueden ser reclamados como propiedad de otros.
Madrid, España Los planes, especificaciones y descripciones de productos mencionados en este documento se proporcionan únicamente a título informativo
Teléfono: +34 91 347 8535 y están sujetos a cambios sin aviso previo; se ofrecen sin garantía de ningún tipo, ya sea explícita o implícita. Copyright © 2012 McAfee, Inc.
www.mcafee.com/es 41724wp_ipad-hack_0212_fnl_ETMG